Что такое корпоративная архитектура и как она связана с бизнес стратегией

В самом общем виде под архитектурой организации (ЕА — Enterprise Architecture ) понимается всестороннее и исчерпывающее описание (модель) всех ее ключевых элементов и межэлементных отношений. Согласно ISO 15704 (» Industrial Automation Systems – Requirements for Enterprise -Reference Architectures and Methodologies . 1999″) архитектура организации должна включать роль людей, описание процессов (функции и поведение), и представление всех вспомогательных технологий на протяжении всего жизненного цикла организации. Архитектура (в соответствии с документом » Federal Enterprise Architecture Framework. Dev. by: The Chief Information Officers Council (USA)») является стратегической информационной основой, определяющей:

1. структуру бизнеса;
2. информацию, необходимую для ведения бизнеса;
3. технологии, применяемые для поддержания бизнес-операций;
4. процессы преобразования, развития и перехода, необходимые для реализации новых технологий в ответ на изменение/появление новых бизнес-потребностей.

Архитектура организации традиционно представляется в виде следующих слоев (таблица 1.1):

Александр Кварцхава. Корпоративная архитектура и стратегический менеджмент.

1. корпоративные миссия и стратегия, стратегические цели и задачи;
2. бизнес-архитектура;
3. системная архитектура (ИТ — архитектура).

Корпоративные миссия и стратегия определяют основные направления развития организации и ставят долгосрочные цели и задачи.

Под миссией организации понимается основная ее общая цель или задача, четко выраженная причина ее существования. Фактически миссия организации обобщает и унифицирует такие понятия как предназначение, стратегическая установка, кредо, политика, бизнес-идея и др. Миссия объединяет задачу и коренную причину, оправдывающую существование данной конкретной организации, она позволяет потребителю отличить одну организацию от другой, занимающейся аналогичной деятельностью.

Таблица 1.1. Слои архитектуры организацииКорпоративные миссия и стратегияБизнес-архитектураСистемная архитектура

Бизнес-процессы	Организационно-штатная структура	Система документооборота
Приложения	Данные	Оборудование

Назначение миссии заключается в том, что она способствует формированию имиджа организации во внешнем мире. Внутренняя задача миссии заключается в поддержке и развитии корпоративного духа, поскольку она проясняет сотрудникам общую цель существования организации, выражает принципы и ценностные ориентиры организации, облегчает сотрудникам осознание своего места и роли в системе деловых отношений, что в конечном итоге способствует созданию благоприятной атмосферы.

Конкретизация миссии осуществляется посредством формирования основных (стратегических) целей организации и последующей разработки корпоративной стратегии и корпоративной философии (культуры). При этом вырабатываемые на основе миссии цели (отвечающие на вопрос «Чего мы хотим достичь?») служат критериями всего последующего процесса принятия управленческих решений – если основные цели неизвестны, то у руководства нет точки отсчета для выбора наилучших по тем или иным параметрам решений.

Корпоративная архитектура: что это такое?

Под корпоративной стратегией понимается долгосрочное направление развития организации, следование которому приведет к достижению стратегических целей.

Стратегия формулирует общие направления развития организации, в первую очередь касающиеся производимой продукции и каналов ее продвижения. При этом стратегия должна обеспечить концентрацию усилий в той области, где будут иметься устойчивые конкурентные преимущества. Разработка корпоративной стратегии позволяет перейти от управления организацией, зависящего от воздействия случайно возникающих внешних и внутренних факторов, к планомерной деятельности по достижению определенных результатов с возможностью оценки их достижимости по определенным критериям и применения адекватных управляющих воздействий.

Корпоративная культура направлена на формирование общих для всех сотрудников организации целей, ценностей и принципов поведения, она должна способствовать развитию организации и достижению ею своих бизнес-целей. Основным принципом формирования корпоративной культуры является ее соответствие всем элементам системы управления. На практике этот принцип означает, что при разработке или внедрении изменений в стратегии, структуре и в других элементах системы управления необходимо оценивать степень их реализуемости в рамках существующей культуры и, при необходимости, предпринимать шаги по ее изменению. При этом нужно учитывать, что культура по своей природе более инертна, чем остальные элементы системы управления. Поэтому действия по ее изменению должны опережать все остальные преобразования, необходимо понимать, что результаты будут видны не сразу.

Бизнес- архитектура на основании миссии, стратегии развития и долгосрочных бизнес-целей определяет необходимые бизнес-процессы , информационные и материальные потоки, а также поддерживающую их организационно-штатную структуру.

Системная архитектура определяет совокупность методологических, технологических и технических решений для обеспечения информационной поддержки деятельности организации, определяемой его бизнес-архитектурой, и включает в себя архитектуру приложений, архитектуру данных и техническую архитектуру.

Архитектура приложений, в свою очередь , включает в себя:

1. собственно прикладные системы, поддерживающие исполнение бизнес-процессов;
2. интерфейсы взаимодействия прикладных систем между собой и с внешними системами и источниками или потребителями данных;
3. средства и методы разработки и сопровождения приложений.

Архитектура данных включает в себя:

1. базы данных и хранилища данных;
2. системы управления базами данных или хранилищами данных;
3. правила и средства санкционирования доступа к данным

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ. Сетевая архитектура включает в себя:

1. локальные и территориальные вычислительные сети
2. используемые в сетях коммуникационные протоколы, сервисы и системы адресации;
3. аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ включает в себя:

1. аппаратные средства вычислительной техники — серверы, рабочие станции, накопители и другое компьютерное оборудование;
2. операционные и управляющие системы , утилиты и офисные программные системы;
3. аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом — серверов) и баз данных в условиях чрезвычайных обстоятельств.

Значение архитектуры организации в современных условиях постоянно увеличивается за счет обеспечения возможностей эффективного использования существующих технологий и эволюционного перехода к новейшим технологиям. Фактически, архитектура организации является одним из главных средств управления изменениями, обеспечивая при этом:

1. оказание помощи менеджерам при анализе потенциальных изменений и их реализации;
2. предоставление основы для совместной работы бизнес-менеджеров и ИТ-менеджеров над целями, бизнес-процессами и выстраиванием организации в целом;
3. предоставление единого хранилища всей информации об организации;
4. обеспечение менеджерам поддержки в принятии решений: они могут обозревать отношения, задавать вопросы, идентифицировать проблемы, выполнять моделирование и т.д. Таким образом, концепция корпоративной архитектуры напоминает градостроительство в области ИТ – составление общего плана интеграции различных объектов в рамках всей организации, определение порядка их использования и путей построения необходимых для этого механизмов. Ее суть заключается в том, чтобы разработать план использования ИТ-ресурсов бизнес-процессами, а также совокупность принципов управления, позволяющих выразить стратегию бизнеса через ИТ.

Непосредственно архитектура организации не описывает конкретные технические решения отдельных информационных систем, но позволяет получить существенную выгоду для бизнеса организации в целом. Основные аспекты связаны с повышением эффективности эксплуатации информационных систем, снижением рисков инвестиций в ИТ, а также с повышением гибкости или возможности относительно простой адаптации под изменяющиеся внешние условия и требования бизнеса.

Наличие в организации разработанной архитектуры обеспечивает:

Архитектура является средством снижения рисков и увеличения отдачи от инвестиций в ИТ. Причина в том, что она четко определяет структуру как существующих, так и будущих ИТ-систем, что приводит к снижению их сложности. А наличие ясной стратегии будущих закупок, выбора поставщиков технологий и планируемых изменений позволяет упростить и ускорить все процессы, связанные с закупками, при одновременном обеспечении совместимости и взаимодействия компонент ИТ-систем организации.

Наконец, необходимая гибкость развития бизнеса и структурных изменений обеспечивается за счет простоты доступа к интегрированным информационным ресурсам в масштабе организации. Ускорение выхода новых продуктов на рынок может осуществляться за счет быстрого внедрения новых или модификации существующих приложений. Существенный выигрыш может быть получен при проведении слияний и поглощений, связанных с реинжинирингом процессов или объединением ИТ-систем и служб.

Таким образом, имеется три причины использования архитектурного подхода:

1. рост масштаба и сложности ИТ, рост их стоимости и рисков в проектах их создания и внедрения;
2. включение ИТ в основную деятельность, рост требований к эффективности инвестиций в ИТ;
3. переход к процессному подходу, интегрирующему деятельность подразделений, рост требований к эффективному взаимодействию ИТ-систем между собой.

В результате его использования обеспечивается:

1. Информационная поддержка работ по сопровождению и развитию ИТ-инфраструктуры, включает:

1. выявление бизнес-процессов, требующих первоочередной автоматизации;
2. выявление первоочередных направлений совершенствования каналов связи;
3. анализ ИТ-систем и их взаимодействия, оценка степени покрытия бизнес-процессов и информационных потоков существующими системами;
4. оптимизация обработки информации во взаимодействующих системах (избавление от дублирующих систем и данных, согласование справочников и классификаторов, используемых в различных системах и т.п.);
5. выявление, согласование, формализация и документирование требований к перспективным ИТ-системам, контроль внедрения новых систем на предмет соответствия согласованным требованиям в части покрытия информационных потоков;
6. анализ альтернативных вариантов совершенствования ИТ-инфраструктуры.

1. выявление бизнес-процессов, требующих совершенствования;
2. избавление от дублирующих действий в различных сценариях (ввод одних и тех же сведений в различные системы);
3. анализ альтернативных вариантов совершенствования бизнес-процессов.

Контрольные вопросы и упражнения

1. Что такое стратегическое управление информационными системами?
2. В чем заключаются основные отличия процессного подхода от функционального?
3. Назовите этапы развития ИТ, какой из этапов является революционным?
4. Каковы основные цели использования ИТ?
5. Перечислите проблемы и причины неудач при внедрении ИТ в организации.
6. В чем состоят задачи стратегических ИТ-консультантов?
7. Что такое стратегический ИТ-аудит?
8. Что понимается под архитектурой организации?
9. Что включает в себя ИТ-архитектура, каково ее место в архитектуре организации?
10. За счет чего архитектура обеспечивает более эффективное использование ИТ-систем?
11. Каковы основные причины использования архитектурного подхода?

Источник: intuit.ru

Применение архитектурного подхода в информатизации

В этом цикле статей мы рассказываем о том, что такое корпоративная архитектура и какое место она занимает в информатизации бизнеса, какие существуют архитектурные представления и как перейти от архитектурных моделей к их реализации. В первой статье были затронуты общие актуальные вопросы повестки для ИТ-лидеров. Во второй статье предлагается рассмотреть примеры применения архитектурного подхода в информатизации.

Как заниматься информатизацией сегодня?

Когда компания занимается информатизацией, она регулярно решает такие группы задач:

• Анализ и проектирование архитектуры
• Планирование и реализация
• Эксплуатация и развитие

Задачи информатизации

Первым этапом в цикле, безусловно, является анализ и проектирование. Проработка архитектуры при этом может доходить до уровня системной архитектуры для ключевых ИТ-систем.

Когда у нас есть архитектура, которая описывает все сущности и взаимосвязи между ними, необходимо запланировать её реализацию. План реализации архитектуры по сути представляет собой ИТ-стратегию. Сформированная стратегия должна завершиться дорожной картой и портфелем проектов.

К этой карте всё время будет идти тонкий «ручеёк» новых требований: требования заказчика будут расширяться, обновляться и добавляться. Этот «ручеёк» всегда необходимо анализировать на предмет соответствия корпоративной архитектуре. Если новые требования не вписываются в архитектуру, но являются значимыми, надо понять, как адаптировать к ним архитектуру.

Архитектурный контроль проектов направлен на то, чтобы вовремя корректировать проекты, реализующие архитектуру. Помимо формального управления, которое включает в себя контроль сроков, результатов и достижения целей проекта, необходимо следить за тем, чтобы эти результаты не искажали архитектуру компании и не несли риски лишних доработок или переделок проекта.

Когда мы убеждаемся в правильности реализации ИТ-решений, встают задачи по их вводу в эксплуатацию с последующим мониторингом и контролем возможных изменений. Мониторинг является важной частью эксплуатации ИТ-решения, так как позволяет отслеживать эффективность его работы и своевременно выработать рекомендации по развитию или замене ИТ-решения. Помимо этого немаловажной является необходимость контроля вывода ИТ-решений из эксплуатации.

Практика показывает, что при планировании систем всегда существуют ожидания определённого эффекта от внедрения. При инициации проекта и его выполнении об этих ожиданиях часто забывают, но, упустив из вида ожидаемый бизнес-эффект, мы по завершении проекта обнаружим, что система разработана и внедрена, но бизнес-эффекта не приносит.

По статистике, треть проектов в ИТ-сфере не приносят ожидаемого эффекта, поэтому задача своевременного мониторинга соответствия системы бизнес-целям становится очень актуальной.

Корпоративная архитектура.
Архитектурный подход в информатизации

Что представляет собой корпоративная архитектура? Корпоративная архитектура — это симбиоз, согласованная совокупность бизнес-архитектуры, то есть модели хозяйственной деятельности предприятия, и ИТ-архитектуры, то есть набора моделей данных, информационных систем и ИТ-инфраструктуры.

Можно сказать, что корпоративная архитектура — это набор взаимосвязанных моделей. Этот набор позволяет увидеть части архитектуры как кусочки пазла, которые хорошо соединены друг с другом.

Взаимосвязь объектов бизнеса через архитектуру

Модели деятельности, информационные системы, проекты, бизнес-требования, внедрённые системы — все это объекты, имеющие разный подход к управлению. Архитектура при этом является средством, позволяющим объединить такие объекты путём установления связей между ними. Когда все эти сущности связаны друг с другом, мы можем говорить об архитектуре как о наборе взаимосвязанных моделей. Эти модели позволяют хорошо управлять информатизацией.

В чём заключается сущность архитектурного подхода в информатизации? Архитектурный подход предполагает ни что иное, как взаимосвязанное и согласованное рассмотрение бизнес-архитектуры и ИТ-архитектуры при разработке информационных систем предприятия.

Архитектурный подход в информатизации также означает, что архитектуру нужно использовать в качестве средства контроля бизнес-требований, ИТ-проектов и эксплуатируемых ИТ-решений, и регулярно актуализировать для отражения изменений. Такой подход позволяет реализовать эффективное управление информатизацией, обеспечивающее её успешность в условиях неопределённости.

Являясь набором моделей и средством для управления информатизацией, архитектура устанавливает общий язык между участниками деятельности в сфере IT. Инвестиции в слаженное взаимодействие дают ценность, которую достаточно легко донести до бизнеса. Безусловно, архитектура позволяет увидеть бизнес со всех ракурсов, демонстрирует недочеты, помогает понять, как их исправлять, какие системы развивать и почему, что делать с ИТ-инфраструктурой, и так далее. Но гораздо убедительнее для бизнеса тезис о том, что с появлением корпоративной архитектуры все участники, имеющие разные точки зрения на уровне целей и задач компании, начнут говорить на одном языке.

Изначально все участники имеют разные точки зрения на бизнес, разные вопросы и приоритеты. Каждый смотрит «со своей колокольни». Акционеры смотрят на компанию с точки зрения целевых показателей. Они ставят показатели и ожидают, что высшее руководство придумает, как этих показателей достичь.

Высшее руководство формирует бизнес-стратегию и ставит задачи функциональным направлениям, в том числе и ИТ-блоку. Интерес руководителей функциональных направлений заключается в том, чтобы сделать свои регулярные функции наиболее эффективными. ИТ-блок, в свою очередь, готов внедрять решения. Его задача состоит в том, чтобы «хорошо внедрять и эксплуатировать». Бизнес-партнеров волнует эффективность процессов взаимодействия между компаниями, а контрагенты предлагают внедрить различные продукты и услуги, потому что это в их интересах.

Архитектура устанавливает сквозную и двунаправленную связь между целями и показателями, регулярными функциями подразделений и их проблемами, требуемыми видами данных, существующими системами и недостатками существующего ИТ-ландшафта, дополнительными системами и ИТ-проектами. Для руководителей подразделений архитектура поможет расставить приоритеты и показать, какие функции нуждаются в автоматизации в первую очередь.

Именно архитектура позволяет показать любому участнику бизнеса, какой эффект для бизнеса имеет внедрение того или иного ИТ-решения.

Структура архитектуры предприятия

В соответствии с открытым международным стандартом TOGAF, архитектура — это структурированное поэлементное описание перспективного состояния предприятия, включающее его цели, функции, информацию, информационные системы, информационно-коммуникационную инфраструктуру и связи между элементами.

С учётом рекомендаций стандарта TOGAF архитектура предприятия должна состоять из нескольких слоёв или доменов. Эти слои в TOGAF обозначаются как рекомендательные, их структура и описание не являются догмой. Выбор конкретных описаний, нотаций, представлений и их наименований остаётся за пользователем стандарта. На рисунке ниже показано классическое представление архитектуры в соответствии со стандартом TOGAF.

Классическое представление архитектуры в соответствии со стандартом TOGAF

Каждый слой содержит одну или несколько моделей (различные представления сущностей в рассматриваемом слое архитектуры).

В основе архитектуры предприятия лежит архитектура деятельности, которая определяет границы и состав решений в других слоях архитектуры. Этот слой не содержит ничего, связанного с технологиями.

Информационная архитектура может содержать разные модели: информационная поддержка, интеграция, данные и обмен ими, подход к управлению нормативно-справочной информацией и другие. Здесь мы говорим о том, что представляют собой данные и как эти данные поддерживают деятельность.

Третий слой архитектуры — это архитектура систем. Системы внедряются ради управления данными. При построении архитектуры необходимо показать, что определённый набор регулярных функций должен поддерживаться определёнными данными. У этих данных есть характеристики, которые нужно принимать в расчёт, когда мы решаем, какими должны быть системы для работы с этими данными.

Системы живут в инфраструктуре, и следовательно четвёртый слой архитектуры — это слой информационно-коммуникационной инфраструктуры.

Как выбрать стиль корпоративной архитектуры?

Залог успеха при проектировании корпоративной архитектуры — выбор правильного архитектурного стиля. Главное здесь — увидеть факторы, показывающие, какие принципы необходимо применять здесь и сейчас. Эти факторы зависят по сути от самой компании.

На рисунке ниже показаны три основных архитектурных стиля с интересной бытовой аналогией.

Архитектурные стили

Если компания находится на стадии развития, экспериментирует, если требуется быстро решать задачи, идеи о создании единой интеграционной среды и применении современных решений могут потерпеть крах, потому что компания к ним просто не готова. В таких условиях необходимо научиться жить со стилем «лоскутное одеяло». Несмотря на то, что такой стиль многие не любят, потому что его использование может приводить к проблемам, многие компании (даже крупные) живут в такой парадигме.

«Слабая» интеграция делает акцент на создание интеграционного комплекса, позволяющего установить взаимодействие между разными, лучшими в своём классе системами.

«Сильная» интеграция предполагает применение ERP-систем и действительно интегрированное информационное пространство.

Крупные компании всегда существуют в гетерогенной среде со множеством систем с разными стилями, но в любой компании надо понимать, какой стиль имеет смысл применять, стоит ли переходить на новый стиль или необходимо повременить.

Очень важно уметь распознавать «звоночки», указывающие на необходимость использования того или иного архитектурного стиля. Например, когда регулярно накапливаются проблемы связанные с потерей клиентов, увеличением времени обработки данных, увеличением объёмов деятельности, ухудшением уровня консистентности данных, очевидно, что пора переходить на «сильную» интеграцию — внедрять хорошую систему и делать интегрированную IT-среду.

В противовес этому можно привести ситуацию, когда полностью интегрируемые модули ERP-системы перестают отвечать функциональным требованиям по любым направлениям. Например, у нас сильно усложнился складской модуль и стало понятно, что часть функции стоит выделить в отдельную систему класса WMS, то есть переходить к «слабой» интеграции.

Нельзя не упомянуть, что в настоящее время, под влиянием высокого темпа изменений и смещения акцента с процессов и систем на управление данными, начинает формироваться новый тип архитектуры, который условно можно назвать «Интеграция данных». Тем не менее описание интеграции данных выходит за рамки статьи, поэтому углубляться в эту тему мы не станем.

Компонентное моделирование — подход
к созданию архитектуры деятельности

Ранее мы говорили о том, что верхним и определяющим слоем корпоративной архитектуры является архитектура деятельности.

Бизнес-модель, модель деятельности, процессная модель, альбом бизнес-процессов — все эти понятия по сути являются синонимами понятия «архитектура деятельности».

Для описания деятельности существует очень много подходов. Традиционным является описание процессов, в результате которого формируется альбом бизнес-процессов. Существуют и другие нотации: модель Захмана, модель Портера.

В целях построения корпоративной архитектуры я рекомендую использовать функциональную компонентную модель. Компонентная модель фактически демонстрирует весь бизнес буквально на одной странице. По сути модель показывает, какие значимые процессы и активности регулярно происходят в бизнесе. Эта модель позволяет объединить как внутренние регулярные активности, так и внешние, предоставляемые бизнесу партнёрами.

Пример компонентной модели для розничной торговли

Столбцы отражают компетенции бизнеса, определяемые как крупные предметные области с характерными особенностями и необходимыми навыками, такие как производство продукции или управление цепочкой поставок (логистика).

Например, для крупного металлургического комбината такими областями могут быть: разведка, добыча, обогащение, выплавка, изготовление изделий, управление оборудованием и бэк-офис, т. е. управление бизнеса (финансы, кадры, юристы и т. д.).

Бизнес-компонент представляет потенциально самостоятельную часть организации, которая в принципе может быть частью другой компании. Компонент имеет определённую бизнес-ценность, использует ресурсы, информацию и приложения.

Уровень управления и ответственности характеризует границы и цели действий и принимаемых решений. В компонентной модели рассматриваются три подуровня управления и ответственности:

• Стратегия (Directing) определяет общие стратегические направления и политики.
• Контроль (Controlling) охватывает мониторинг, управление по отклонениям и принятие тактических решений.
• Исполнение (Executing) фокусируется на реальном выполнении операций.

Как построить компонентную модель?

Проще всего оттолкнуться от организационной структуры и идентифицировать в ней ключевые подразделения, дополнительно выделив внешние структуры, которые интегрированы с нашим бизнесом. У этих ключевых подразделений необходимо сначала определить основные функции, а затем объединить смежные или сопутствующие друг другу функции в укрупнённые группы.

Полученные группы являются функциональными компонентами. В качестве примера можно привести такой функциональный компонент как «Договорная деятельность». Это компонент, так как в него хорошо встраиваются такие функции как подготовка договоров, заключение договоров, контроль исполнения договоров и т. д.

Важно помнить, что каждый компонент должен быть уникален и по отношению друг к другу компоненты должны обладать примерно одинаковым весом. Основываясь на практике, можно сказать, что компонентная модель крупного предприятия будет состоять из 50−80 компонентов, которые будут распределяться по 5−8 областям деятельности.

Такая модель является представлением деятельности AS-IS. При этом, учитывая, что компания предполагает развитие и оптимизацию, необходимо также сформировать и целевую модель деятельности.

Как сформировать целевую модель деятельности?

Хорошим инструментом для формирования целевой модели деятельности является матрица Игоря Ансоффа (матрица товар-рынок).

Матрица Ансоффа

Матрица задает возможные сегменты, в который нужно попытаться найти сценарии развития бизнеса. Ансофф предлагает рассматривать все возможные направления развития в контексте клиентов и продуктов/услуг.

Использование этого инструмента позволяет построить карту сценариев развития бизнеса. Полученные сценарии можно представить в виде набора требований к функциям модели деятельности.

Чтобы трансформировать модель AS-IS в целевую модель TO-BE, необходимо трансформировать или дополнить функциями компоненты исходной модели таким образом, чтобы это позволяло реализовать выбранный сценарий развития.

Подводя итоги второй части нашего цикла статей, можно выделить следующие тезисы.

1. Архитектурные задачи занимают важное место в информатизации. Архитектура позволяет не только описать все бизнес-сущности и взаимосвязи между ними, но и осуществлять контроль сопутствующих проектов и мониторинг соответствия систем бизнес-целям.

2. Архитектура позволяет не только увидеть бизнес со всех ракурсов, но и установить общий язык между участниками деятельности в сфере ИТ: для руководителей подразделений архитектура поможет расставить приоритеты и показать, какие функции нуждаются в автоматизации в первую очередь; ИТ-блок сможет увидеть ценность реализации проектов для компании; бизнес-партнеры смогут построить эффективное взаимодействие между компаниями.

3. В основе архитектуры предприятия согласно стандарту TOGAF лежит архитектура деятельности. Для её построения лучше всего использовать функциональную компонентную модель. Компонентная модель фактически демонстрирует весь бизнес буквально на одной странице. Модель показывает, какие значимые процессы и активности, как внутренние, так и предоставляемые партнёрами, регулярно происходят в бизнесе.

4. Для построения компонентной модели проще всего обратиться к организационной структуре предприятия, выделив в качестве компонент основные функции подразделений. Полученная таким образом модель является моделью AS-IS. Для построения целевой модели можно применить такой инструмент, как матрица Игоря Ансоффа, и описать релевантные бизнес-модели, для реализации которых компании потребуется развернуть дополнительные функции — эти функции должны быть добавлены в компонентную модель компании, что сделает её «целевой» моделью.

В следующей части мы поговорим о том, с помощью каких инструментов можно осуществлять анализ компонентной модели, анализ данных и систем предприятия.

Источник: systems.education

Архитектура предприятия (Корпоративная архитектура)

Современные подходы к формулированию понятия архитектуры ИТ являются попытками предоставить такой язык, понятный и полезный одновременно для бизнес-руководства и для специалистов в области ИТ.

Представление об архитектуре предприятия имеет свои корни в дисциплине, которая получила название «системный анализ».

Еще одно важное замечание состоит в уточнении понятия «Предприятие». Что мы имеем в виду, когда говорим о предприятии в контексте архитектуры? Это может быть организация в целом или одно из ее бизнес-подразделений, или же это может быть некоторая совокупность предприятий или организационных единиц в рамках единой цепочки создания добавочной стоимости.

Под термином «Предприятие» имеем в виду формальное объединение, не обязательно связанное с коммерческой деятельностью. Это может быть и государственная организация, и общественное, в том числе неформальное, объединение участников, связанных общей целью. Согласно более общему определению, Предприятие «. представляет собой комплексную систему культурных, технологических и процессных компонент, организованных для достижения целей организации».

Вы можете применять архитектурные подходы к целому предприятию, подразделению или даже к отдельной прикладной системе. Вы сами определяете для себя соответствующие границы рассмотрения.

Архитектура предприятия является одним из инструментов организационных изменений и всего предприятия в целом с использованием ИТ, и особенно той части организации, которая отвечает за информационные технологии. существуют два основных подхода к организационным изменениям. Первый подход связан с реорганизацией, реинжинирингом процессов, а второй – с управлением знаниями.

По большому счету, архитектура предприятия – это прежде всего управление знаниями, т.е. процесс сбора и распространения информации о том, как организация использует и должна использовать ИТ в своей деятельности. Включение же в архитектуру предприятия представлений о бизнес-архитектуре обеспечивает связь с возможностями оптимизации бизнес-процессов.

Архитектура: основные определения

Многие организации испытывают постоянные трудности и находятся в постоянном поиске синхронизации целей и задач бизнеса и процессов развития своих информационных систем. Существует как бы «облако неопределенности» между определением организацией и обеспечивающей ее ИТ-инфраструктурой своих целей и задач.

Процесс транслирования этих целей в конкретные ИТ-системы часто носит очень неразвитый характер и ограничивается ежегодным бюджетным процессом, участие в котором представителей бизнеса и ИТ является основным способом общения и взаимодействия.

Рис. 3.1. «Облако неопределенности» между целями организации и информационными технологиями

Архитектура информационных технологий и архитектура предприятия в целом как раз и является основным механизмом интерпретации и реализации целей организации через адекватные ИТ-инфраструктуру и системы. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений. Имеется множество методик описания архитектуры, и все они разбивают архитектуру предприятия на различное количество моделей и определений, которые относятся к таким областям, как бизнес, информация, прикладные системы, технологическая инфраструктура.

Бизнес-модели описывают стратегию организации, структуры управления, требования, ограничения и правила, а также основные бизнес-процессы, включая взаимосвязи и зависимости между ними. Т.е. бизнес-архитектура описывает на уровне предприятия в целом то, как реализуются основные функции организации, включая организационные и функциональные структуры, роли и ответственности.

Архитектура информации определяет ключевые активы, связанные со структурированной и неструктурированной информацией, требующейся для бизнеса, включая расположение, время, типы файлов и баз данных и других информационных хранилищ.

Архитектура прикладных систем описывает те системы, которые и обеспечивают необходимый функционал для реализации логики бизнес-процессов организации.

С точки зрения технологической архитектуры, важные модели включают описание ИТ-сервисов, которые требуются для реализации перечисленных выше трех других областей архитектуры. Причем логические модели ИТ-сервисов построены в абстрактной, технологически независимой форме и оставляют свободу для оптимального выбора конкретных технологий.

Но, в конце концов, архитектура предприятия завершается физическими моделями, которые определяются технологиями, аппаратными и программными платформами, выбранными для реализации ИТ-сервисов.

Термин «ИТ-архитектура» может означать множество близких по смыслу, но, тем не менее, различающихся понятий. Для различных людей смысл одного и того же термина может быть разным.

Одно из самых простых (словарь Уэбстера) заключается в том, что ИТ-архитектура – это «способ, который используется для организации и интеграции компонент компьютерной системы».

Еще одно определение заключается в том, что «Архитектура системы состоит из нескольких компонент, внешних свойств и интерфейсов, связей и накладываемых ограничений, а также архитектуры этих внутренних компонент». Итеративное, иерархическое построение архитектуры позволяет решить и еще одну важную задачу – облегчить ее восприятие человеком.

Рис. 3.2. Элементы архитектуры предприятия

«Архитектурный взгляд» на системы (как ИТ-системы, так и бизнес-системы) определен в стандарте ANSI/IEEE 1471-2000 как «фундаментальная организация системы, состоящая из совокупности компонент, их связей между собой и внешней средой, и принципы, которыми руководствуются при их создании и развитии».

В самом общем виде, в соответствии с определениями Gartner, архитектура – это:

1. общий план или концепция, используемая для создания системы, такой как здание или информационная система, или «абстрактное описание системы, ее структуры, компонентов и их взаимосвязей»;

2. семейство руководящих принципов, концепций, правил, шаблонов, интерфейсов и стандартов, используемых при построении совокупности информационных технологий предприятия.

Обратите внимание, что первое определение сфокусировано на описании существующих и будущих систем, второе – на процессе их построения.

Еще несколько определений:

1. «Архитектура – это инвестиция в стандарты процессов, технологий и интерфейсов в целях улучшения возможностей организаций и уменьшения стоимости разработки и сопровождения информационных систем. Преимущества инвестиций в архитектуру распространяются на несколько проектов сразу, но не все эти проекты могут быть известны в момент разработки архитектуры»;

2. «Корпоративная архитектура ИТ – это видение, принципы и стандарты, которыми организации руководствуются при разработке и внедрении технологий» (Giga Group);

Архитектура ИТ и принципы ее построения, с одной стороны, зависят от общих стратегических планов, бизнес-потребностей организации, общего видения роли ИТ в деятельности организации, а с другой стороны, определяют многие аспекты, такие как принятая практика по планированию капитальных затрат, обеспечение жизненного цикла систем и т.д..

Рассмотрим теперь более подробно, какие отдельные понятия в рамках представления об «архитектуре» существуют, и как они связаны между собой:

1. иерархия архитектур различных организационных систем;

2. соотношения между объективной реальностью и субъективным восприятием;

3. соотношения между общесистемной архитектурой и частными архитектурами.

Точно так же, как и в строительстве, существуют различные уровни архитектуры (план города, план застройки района, планы отдельных зданий), требуется дальнейшая детализация высокоуровневых определений и классификация архитектуры бизнеса и информационных технологий на различных уровнях. Таким образом, мы можем говорить об архитектуре предприятия в целом, архитектуре уровня отдельных проектов или семейства продуктов, можем говорить об архитектуре отдельной прикладной системы. И в первом, и во втором, и в третьем случае – это все архитектуры. Вопрос заключается в декомпозиции сложных систем и в том, на каком уровне принимаются те или иные архитектурные решения.

Архитектура предприятия определяет общую структуру и функции систем (бизнес и ИТ) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое «расширенное предприятие») и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое архитектурой предприятия, создает возможность единого проектирования систем, адекватных, с точки зрения обеспечения потребностей организации, и способных к взаимодействию и интеграции там, где это необходимо. Чуть позже мы вернемся к определению понятия архитектура предприятия.

Архитектура уровня отдельных проектов определяет структуру и функции систем (бизнес и ИТ) на уровне проектов и программ (совокупностей проектов), но в контексте всей организации в целом, т.е. не в изолированном рассмотрении индивидуальных систем. Архитектура уровня отдельных проектов детализирует, соответствует и существует в рамках архитектуры предприятия.

Архитектура прикладных систем определяет структуру и функции приложений, которые разрабатываются с целью обеспечения требуемой функциональности. Некоторые элементы этой архитектуры могут быть определены на уровне архитектуры предприятия или архитектуры отдельных проектов (в форме стандартов и руководств) в целях использования лучшей практики и соответствия принципам всей архитектуры в целом.

Рис. 3.3. Уровни принятия архитектурных решений

Отличительной характеристикой решений, принимаемых в отношении архитектуры, является то, что эти решения должны приниматься с учетом широкой, или системной, перспективы. Любое решение, которое может быть принято локально (например, в рамках подсистемы), не является архитектурным для системы в целом. Это позволяет делать различие между детальным проектированием и принятием решений по поводу практической реализации системы, с одной стороны, и архитектурными решениями – с другой. Первые решения имеют локальное влияние, а вторые – систематическое. Поэтому для проектных решений нужна соответствующая более широкая перспектива, позволяющая учесть системное влияние решений более высокого уровня, что дает возможность достичь желаемого уровня компромиссов и соглашений между составными частями для обеспечения должного уровня качества системы в целом.

Например, если система, которую мы рассматриваем, является прикладной программной системой, то свобода принятия решений, которые могут приниматься на уровне отдельных ее компонент или модулей, должна быть предоставлена соответствующим разработчикам этих подсистем. Архитектор прикладной системы должен рассматривать вопросы, которые важны для системы в целом.

Если предметом рассмотрения является архитектура проекта или некоторого решения (например, проект создания портала организации, который интегрирует информацию из некоторого количества информационных систем), то решения по поводу архитектуры отдельных прикладных систем должны приниматься, соответственно, разработчиками этих систем. На уровне архитектуры проекта должны рассматриваться только те вопросы, которые имеют систематическое значение или важны для проекта в целом. Например, в нашем примере с порталом это могут быть решения о структуре метаданных, которыми должны руководствоваться все прикладные системы для того, чтобы информация из этих систем могла бы быть опубликована на едином портале.

В этом смысле, чтобы еще раз уточнить предмет содержания данного курса, можно сказать, что мы обсуждаем вопросы и подходы, которые относятся, в основном, к уровню предприятия в целом. При этом под предприятием понимается организация (или государственное ведомство) со всей совокупностью ее информационных систем, либо государство (регион, город) с соответствующей совокупностью информационных систем ведомств.

Определяющей характеристикой, которая отличает архитектуру предприятия (или Корпоративную архитектуру) от других типов архитектур является соответствующий корпоративный масштаб и охват. Она пересекает и пронизывает все внутренние организационные границы: границы различных бизнес-подразделений и границы отдельных функций.

Каждая информационная система представляет собой сложный, комплексный объект, который к тому же динамически изменяется во времени. Таким образом, архитектура будет представлять собой некоторую модель реальной системы, которая динамически изменяется, сохраняя соответствие оригиналу, как показано на рис. 3.4.

Рис. 3.4. Архитектура как модель реальной информационной системы

Второй постулат заключается в том, что выделяются два понятия:

1. собственно архитектура информационной системы – как объективная реальность, включающая существующие компоненты и их связи;

2. описание архитектуры (architecture description) – отражение объективной или планируемой реальности в какой-либо документированной форме.

Взаимосвязь этих понятий иллюстрируется на рис. 3.5

Рис. 3.5. Описание архитектуры как проекции реальности

Разделение этих понятий приводит к интересным следствиям. Архитектура системы (внешняя область – Рис. 3.5) по определению является бесконечно сложным, глубоким и неявным понятием. Только часть этого общего понятия, которая в принципе доступна для восприятия архитекторами, может быть переведена в явную документируемую форму – модель или набор моделей с неизбежными упрощениями, ограничениями и субъективными искажениями.

Таким образом, ИТ-архитектура существует независимо от предпринимаемых в организации проектов по ее описанию, упорядочиванию и развитию. Обратимся еще раз к аналогии со строительством: отсутствие решений в области ИТ или бессистемное их принятие на практике приводят к появлению «зоопарка» аппаратных средств и приложений, напоминающих спонтанную застройку в условиях отсутствия градостроительных планов, появление вагончиков и «шанхаев» со всеми вытекающими последствиями.

В дальнейшем мы будем использовать термин «архитектура», который, в зависимости от контекста, может означать как существующую реальность, так и соответствующее описание.

Еще одно формальное определение приведено в стандарте IEEE 1471 Института инженеров-электриков и электронщиков, который предоставляет метамодель для определения архитектуры. Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. в соответствии со схемой, показанной на рис. 3.6.

Рис. 3.6. Рамочная модель разработки архитектуры по IEEE 1471

В соответствии с этим представлением система обладает некоторой архитектурой, которая может быть определенным образом описана с различных точек зрения в зависимости от интереса тех людей (участников), которые рассматривают архитектуру системы. Каждой точке зрения на архитектуру системы соответствует определенное представление, основу которого составляет некоторый набор моделей.

Разработки системной архитектуры близко по смыслу понятию Системное проектирование. Вообще говоря, Системное проектирование (Systems Engineering – это междисциплинарный подход и средства, предназначенные для создания успешных систем. Он фокусируется на определении нужд потребителя и требуемой функциональности в начале цикла разработки, на документации требований, с переходом к конструкторскому синтезу и комплексной аттестации системы при полном учете таких проблем, как функционирование, производительность, испытания, изготовление, затраты и планирование, обучение и сопровождение, вплоть до вывода из эксплуатации. Системное проектирование интегрирует все нужные дисциплины и группы специалистов в командные усилия, формируя структурированный процесс разработки, который выполняется от создания концепции до осуществления продуктивной работы системы. В системном проектировании учитываются как нужды бизнеса, так и технические потребности всех клиентов для получения качественного продукта, который отвечает потребностям пользователей.

Под «программной архитектурой», опять же в зависимости от контекста, может пониматься как архитектура взаимодействия приложений в рамках информационной системы предприятия (т.е. архитектура приложений), так и архитектура программных модулей или архитектура взаимодействия различных классов в рамках одного приложения. Каждая из отмеченных архитектур, в свою очередь, может рассматриваться с тем или иным уровнем детализации и под определенным углом зрения. Так, для программной архитектуры традиционными являются следующие перспективы или уровни описания архитектуры:

1. концептуальная архитектура определяет компоненты системы и их назначения, обычно в неформальном виде. Это представление часто используется для обсуждения с нетехническими специалистами, такими как руководство, бизнес-менеджеры и конечные пользователи функциональных характеристик системы (что система должна уметь делать, в основном, с точки зрения конечного пользователя);

2. логическая архитектура выделяет, прежде всего, вопросы взаимодействия компонент системы, интерфейсы и используемые протоколы. Это представление позволяет эффективно организовать параллельную разработку;

3. физическая реализация, которая описывает привязку к конкретным узлам размещения, типам оборудования, характеристикам окружения, таким как, например, используемые операционные системы и т.п.

Все эти «частные» архитектуры – системная архитектура, программная архитектура – представляют, тем не менее, существенный интерес для нашего внимания, так как опираются на одни и те же подходы и методы, а также используют сходные средства описания и представления результатов.

Архитектура предприятия (Корпоративная архитектура)

Дата добавления: 2019-02-12 ; просмотров: 1083 ; Мы поможем в написании вашей работы!

Источник: studopedia.net