какие существуют уровни корпоративной архитектуры и в чем заключаются ключевые принципы на каждом
Уровни архитектуры предприятия
Рассмотрим теперь более подробно, какие отдельные понятия в рамках представления об «архитектуре» существуют, и как они связаны между собой. Можно выделить, по крайней мере, 3 различных «измерения» в данном континууме определений:
· иерархия архитектур различных организационных систем;
· соотношения между объективной реальностью и субъективным восприятием;
· соотношения между общесистемной архитектурой и частными архитектурами.
Точно так же, как и в строительстве, существуют различные уровни архитектуры (план города, план застройки района, планы отдельных зданий), требуется дальнейшая детализация высокоуровневых определений и классификация архитектуры бизнеса и информационных технологий на различных уровнях [3.10].
Таким образом, мы можем говорить об
1. архитектуре предприятия в целом,
2. архитектуре уровня отдельных проектов или семейства продуктов,
3. архитектуре отдельной прикладной системы.
И в первом, и во втором, и в третьем случае – это все архитектуры. Вопрос заключается в декомпозиции сложных систем и в том, на каком уровне принимаются те или иные архитектурные решения.
Архитектура предприятия определяет общую структуру и функции систем (бизнес и ИТ) в рамках всей организациив целом (включая партнеров и другие организации, формирующие так называемое «расширенное предприятие») и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры уровня отдельных проектов. Общее видение, обеспечиваемое архитектурой предприятия, создает возможность единого проектирования систем, адекватных, с точки зрения обеспечения потребностей организации, и способных к взаимодействию и интеграции там, где это необходимо.
Архитектура уровня отдельных проектов определяет структуру и функции систем (бизнес и ИТ) на уровне проектов и программ (совокупностей проектов), но в контексте всей организации в целом, т.е. не в изолированном рассмотрении индивидуальных систем. Архитектура уровня отдельных проектов детализирует, соответствует и существует в рамках архитектуры предприятия.
Архитектура прикладных систем определяет структуру и функции приложений, которые разрабатываются с целью обеспечения требуемой функциональности.
Некоторые элементы этой архитектуры могут быть определены на уровне архитектуры предприятия или архитектуры отдельных проектов (в форме стандартов и руководств) в целях использования лучшей практики и соответствия принципам всей архитектуры в целом.
Рис. 3.3. Уровни принятия архитектурных решений
Отличительной характеристикой решений, принимаемых в отношении архитектуры, является то, что эти решения должны приниматься с учетом широкой, или системной, перспективы.
Любое решение, которое может быть принято локально (например, в рамках подсистемы), не является архитектурным для системы в целом. Это позволяет делать различие между детальным проектированием и принятием решений по поводу практической реализации системы, с одной стороны, и архитектурными решениями – с другой.
Первые решения имеют локальное влияние, а вторые – систематическое. Поэтому для проектных решений нужна соответствующая более широкая перспектива, позволяющая учесть системное влияние решений более высокого уровня, что дает возможность достичь желаемого уровня компромиссов и соглашений между составными частями для обеспечения должного уровня качества системы в целом.
Например, если система, которую мы рассматриваем, является прикладной программной системой, то свобода принятия решений, которые могут приниматься на уровне отдельных ее компонент или модулей, должна быть предоставлена соответствующим разработчикам этих подсистем. Архитектор прикладной системы должен рассматривать вопросы, которые важны для системы в целом.
Если предметом рассмотрения является архитектура проекта или некоторого решения (например, проект создания портала организации, который интегрирует информацию из некоторого количества информационных систем), то решения по поводу архитектуры отдельных прикладных систем должны приниматься, соответственно, разработчиками этих систем.
На уровне архитектуры проекта должны рассматриваться только те вопросы, которые имеют систематическое значение или важны для проекта в целом.
Например, в нашем примере с порталом это могут быть решения о структуре метаданных, которыми должны руководствоваться все прикладные системы для того, чтобы информация из этих систем могла бы быть опубликована на едином портале.
В этом смысле, чтобы еще раз уточнить предмет содержания данного курса, можно сказать, что мы обсуждаем вопросы и подходы, которые относятся, в основном, к уровню предприятия в целом.
При этом под предприятием понимается организация (или государственное ведомство) со всей совокупностью ее информационных систем, либо государство (регион, город) с соответствующей совокупностью информационных систем ведомств.
Определяющей характеристикой, которая отличает архитектуру предприятия (или Корпоративную архитектуру) от других типов архитектур является соответствующий корпоративный масштаб и охват. Она пересекает и пронизывает все внутренние организационные границы: границы различных бизнес-подразделений и границы отдельных функций.
Возникает вопрос: «Почему мы должны делать нечто, что соответствует широте охвата уровня предприятия в целом?» Ответ заключается в том, что это открывает новые возможностии позволяет решать проблемы так, как было бы невозможно на более «низком уровне», т.е. в более узких рамках. Например, это позволяет улучшить совместную работу так, что мы сможем уменьшить дублирование между бизнес-подразделениями, и это, в конечном итоге, приведет к созданию более эффективных систем и экономии затрат. Теперь рассмотрим «другое измерение», отражающее гносеологический аспект проблемы. С нашей точки зрения, представляется полезным описать следующий «прагматический» подход к формулировке того, «что такое есть архитектура», который частично использует идеи из [3.11].
Каждая информационная система представляет собой сложный, комплексный объект, который к тому же динамически изменяется во времени. Для упрощения мы можем выделить его наиболее существенные характеристики, которые и образуют архитектуру системы, понимаемую как компонентный состав системы и связи между ними.
Такой подход позволяет с достаточной определенностью оценивать характеристики системы, планировать ее развитие и сравнивать различные системы. В то же время конкретная реализация информационной системы будет, наряду с архитектурой, «включать» все многообразие экземпляров данных, физическое расположение компонент, фактическую реализацию процессов управления и т.п.
Таким образом, архитектура будет представлять собой некоторую модель реальной системы, которая динамически изменяется, сохраняя соответствие оригиналу, как показано на рисунке 3.4.
Рис. 3.4. Архитектура как модель реальной информационной системы
Второй постулат заключается в том, что выделяются два понятия: собственно архитектура информационной системы – как объективная реальность, включающая существующие компоненты и их связи; описание архитектуры (architecture description) – отражение объективной или планируемой реальности в какой-либо документированной форме. Взаимосвязь этих понятий иллюстрируется на рисунке 3.5.
Рис. 3.5. Описание архитектуры как проекции реальности
Разделение этих понятий приводит к интересным следствиям. Архитектура системы (внешняя область – Рисунок 3.5) по определениюявляется бесконечно сложным, глубоким и неявным понятием. Только часть этого общего понятия, которая в принципе доступна для восприятия архитекторами, может быть переведена в явную документируемую форму – модель или набор моделей с неизбежными упрощениями, ограничениями и субъективными искажениями. Такая проекция и представляет собой «описание архитектуры». Поэтому при использовании подобных описаний при проектировании систем необходимо всегда помнить об их неизбежной неполноте. При этом совершенно уместным является остроумное замечание о том, что «все модели являются, в общем-то, неверными, но некоторые из них при этом являются полезными».
Таким образом, ИТ-архитектура существует независимо от предпринимаемых в организации проектов по ее описанию, упорядочиванию и развитию. Более того, так как сама система неизбежно претерпевает изменения, то и ИТ-архитектура может со временем меняться даже без целенаправленной деятельности предприятия и его ИТ-службы.
Обратимся еще раз к аналогии со строительством: отсутствие решений в области ИТ или бессистемное их принятие на практике приводят к появлению «зоопарка» аппаратных средств и приложений, напоминающих спонтанную застройку в условиях отсутствия градостроительных планов, появление вагончиков и «шанхаев» со всеми вытекающими последствиями.
В дальнейшем мы будем использовать термин «архитектура», который, в зависимости от контекста, может означать как существующую реальность, так и соответствующее описание.
Еще одно формальное определение приведено в стандарте IEEE 1471 Института инженеров- электриков и электронщиков, который предоставляет метамодель для определения архитектуры.
Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. в соответствии со схемой, показанной на рис. 3.6.
Рис. 3.6. Рамочная модель разработки архитектуры по IEEE 1471
В соответствии с этим представлением система обладает некоторой архитектурой, которая может быть определенным образом описана с различных точек зрения в зависимости от интереса тех людей (участников), которые рассматривают архитектуру системы.
Каждой точке зрения на архитектуру системы соответствует определенное представление, основу которого составляет некоторый набор моделей. Однако этот стандарт не определяет структуру собственно архитектуры предприятия.
Например, говорится о том, что необходимо иметь различные представления архитектуры, но при этом не указывается, какие это должны быть представления.
Подробную информацию об этом стандарте описания архитектуры можно получить по адресу
Возвращаясь к предмету нашего обсуждения, можно рассмотреть различные аспекты понятия архитектуры ИТ.
В частности, можно выделять такие подмножества, как системная архитектура (архитектура систем – System Architecture) и программная архитектура (архитектура программного обеспечения – Software Architecture).
Вспомним, что мы уже отмечали неоднозначность трактовки терминов. На практике, в зависимости от контекста, термин «системная архитектура» может относиться либо к архитектуре ИТ-системы предприятия (в дополнение к бизнес-архитектуре) или даже в еще более узком смысле к технологической инфраструктуре информационной системы, либо – к архитектуре сложного продукта или семейства продуктов, выпускаемых предприятием.
В последнем случае понятие разработки системной архитектуры близко по смыслу понятию Системное проектирование.
Вообще говоря, Системное проектирование (Systems Engineering [3.12]) – это междисциплинарный подход и средства, предназначенные для создания успешных систем.
Он фокусируется на определении нужд потребителя и требуемой функциональности в начале цикла разработки, на документации требований, с переходом к конструкторскому синтезу и комплексной аттестации системы при полном учете таких проблем, как функционирование, производительность, испытания, изготовление, затраты и планирование, обучение и сопровождение, вплоть до вывода из эксплуатации.
Системное проектирование интегрирует все нужные дисциплины и группы специалистов в командные усилия, формируя структурированный процесс разработки, который выполняется от создания концепции до осуществления продуктивной работы системы.
В системном проектировании учитываются как нужды бизнеса, так и технические потребности всех клиентов для получения качественного продукта, который отвечает потребностям пользователей.
Хотя методика описания и проектирования архитектуры отдельных прикладных систем имеет много общего с подходами к описанию архитектуры предприятия в целом, тем не менее, архитектура программных систем является отдельной областью знаний, которой посвящено большое количество соответствующей литературы.
Под «программной архитектурой», опять же в зависимости от контекста, может пониматься как архитектура взаимодействия приложений в рамках информационной системы предприятия (т.е. архитектура приложений), так и архитектура программных модулей или архитектура взаимодействия различных классов в рамках одного приложения.
Каждая из отмеченных архитектур, в свою очередь, может рассматриваться с тем или иным уровнем детализации и под определенным углом зрения. Так, для программной архитектуры традиционными являются следующие перспективы или уровни описания архитектуры: концептуальная архитектура определяет компоненты системы и их назначения, обычно в неформальном виде.
Это представление часто используется для обсуждения с нетехническими специалистами, такими как руководство, бизнес-менеджеры и конечные пользователи функциональных характеристик системы (что система должна уметь делать, в основном, с точки зрения конечного пользователя); логическая архитектура выделяет, прежде всего, вопросы взаимодействия компонент системы, интерфейсы и используемые протоколы.
Это представление позволяет эффективно организовать параллельную разработку; физическая реализация, которая описывает привязку к конкретным узлам размещения, типам оборудования, характеристикам окружения, таким как, например, используемые операционные системы и т.п.
Все эти «частные» архитектуры – системная архитектура, программная архитектура – представляют, тем не менее, существенный интерес для нашего внимания, так как опираются на одни и те же подходы и методы, а также используют сходные средства описания и представления результатов.
Еще более интересным является тот факт, что и сами процессы разработки данных архитектур, требования к архитекторам и понимание того, что является действительно хорошей архитектурой, во многом совпадают.
Поэтому мы можем полагать, что для эффективного овладения проблематикой архитектуры предприятия будет, несомненно, полезно использовать соответствующие наработки в данных «смежных» областях, тем более, что в указанных ниже работах достаточное внимание уделяется и нашему основному предмету.
В частности, хорошее введение в предмет Программной архитектуры и в специфику профессии Программного архитектора представляет собой работа [3.4].
Архитектура ИТ решений. Часть 1. Архитектура предприятия
I. Вступление
Архитектура распределяет массы и объемы.
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.
Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы «собственного исполнения». Такая работа, естественно, требовала привлечения специалиста высокой квалификации. А как это сделать дешево и сердито, чтобы призванный варяг был «и чтец и жнец и на дуде игрец»? Решили без всяких излишеств разработчика ПО, поименовать архитектором, и заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их на свое усмотрение, принимать самостоятельные решения и т.п…
Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют достаточно низкоуровневое проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути — является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове.
И документации вроде бы много, но она разрознена по репозиториям проектов, Вики системам и т.п. Найти логически целостное описание решения и рекомендации по его использованию крайне сложно, а уж проследить ответвляющиеся частные технические решения по цепочке: от потребностей пользователя, до конечной поставки заказчику, вообще не реально, И это несмотря на то, что для заказчика обычно готовится некая версия на базе типового продукта, доработанного в соответствии с его специфическими потребностями. А ведь иногда бывает так необходимо отследить, например, с кем связан компонент, который предполагается использовать при проектировании нового модуля. С кем он, так сказать, разделен шестью рукопожатиями, и какое пагубное влияние могут оказать все эти неучтенные связи на стабильность его поведения.
Подобная ситуация царит во многих крупных ИТ компаниях. Вроде есть архитекторы и архитектурные советы и прочие атрибуты «высокой» архитектуры, а порядка в этом царстве не наблюдается. По вышеперечисленным симптомам, выходит, что на предприятии свирепствует – «острая архитектурная недостаточность».
Мне стало интересно разобраться со всеми аспектами архитектуры, собрав в данной статье структурированно и последовательно информацию о том, что же такое ИТ архитектура, кто такие ИТ архитекторы, и «с чем их едят».
II. Определение понятия «архитектура»
А что можно думать об архитектуре?
Она, как солнце: большая, блестящая и она рядом.
Роджер Желязны. (Мастер сновидений)
Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.
Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:
Довольно лаконичное определение, дополнив которое можно приблизится к пониманию, что же принято ассоциировать с явлением — ИТ Архитектура.
Во-первых, это специально подобранный, набор структурных элементов, организованных определенными способами для взаимодействия друг с другом, складывающихся в единый программно-аппаратный комплекс. Я бы еще добавил: выстроенный в угоду достижения определенных бизнес целей.
Во-вторых, место «совокупности этих элементов», как части, в более крупных системах, включая поведение, точки взаимодействия и т.п. То есть возможность абстрагирования рассматриваемой архитектуры на более высокий уровень, и соответственно детализация архитектуры в наборы составных архитектур нижнего уровня.
В-третьих, использование всеми участниками — единого подхода для организации решений в процессе производства информационных систем.
Раз уж речь зашла о едином подходе, давайте внесем ясность и в этот вопрос:
Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом заинтересованных лиц (2).
Ведь в ходе проектирования, разработки, развития и модернизации программной системы, «совокупность решений о ее организации» (Архитектура), требует постоянного обсуждения со всеми заинтересованными лицами проекта, включая бизнес. Опять же принципиально, чтобы все при этом выстраивали перед собой одну и туже картинку, в том числе учитывающую текущее актуальное состояние архитектуры.
Итак, размявшись на общих положениях и задав направление для исследования понятия Архитектура, продолжим углубляться в суть этого явления.
1. Разделы ИТ Архитекторы
Поскольку понятие ИТ архитектуры охватывает целый букет аспектов производства программных продуктов, начиная еще от определения целей автоматизации и заканчивая аж утилизацией устаревшего в какой-то момент ПО, принято делить его на несколько частей:
1) Информационная архитектура (Enterprise Information Architecture, сокр. EIA), набор методик и инструментов, описывающий информационную модель предприятия. Включает:
4) Бизнес-архитектура предприятия (Enterprise Business Architecture, ЕВА) — целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес-целями. В ходе построения бизнес-архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.
Соответственно для работы с каждым из вышеперечисленных разделов, требуется своя группа заинтересованных лиц, имеющих различную квалификацию и предпочтения, а возможно и цели. Поэтому многочисленные этапы ведения проекта порождают артефакты, описывающие аспекты архитектуры в разных стилях и жанрах. В добавок, они создаются чаще всего разнородными инструментами, используя разнообразные нотации, приемы, представления и т.п.
Стало быть, каждому разделу архитектуры соответствует как минимум одна группа стейкхолдеров, имеющая свои взгляды на представления и методы описания архитектуры. Подыщем определение для этой реалии.
Архитектурная группа описаний (англ. architectural view) — представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания (2).
Разобравшись вкратце с концепцией, направлениями и разделами архитектуры, а также выявив несовпадения в представлениях архитектуры разными группами заинтересованных лиц, перейдем к разбору непосредственно самих этих представлений (артефактов), отражающих архитектуру.
2. Представления ИТ Архитекторы
Нередко наблюдаю ситуации, когда очень интересные и перспективные замыслы гинут в болоте непонимания, только лишь из-за оторванности генератора идеи от общего уровня сознания профсообщества. Иными словами, он пытается донести концепцию, которая в его мыслях сложена в цельную и стройную идею, выдавая окружающим лишь ее “огрызки”: «ну ведь остальное и так понятно». А это «остальное» действительно не всегда понятно для электората, и он голосует против бредовой и непонятной с его точки зрения идеи, своим равнодушием и игнорированием. Автор же задумки зачастую просто не смекает, почему же все пошло не так, и отчего никто не проникся чудо решением.
По всей вероятности нужна была какая-то подводка. А очень может быть, сначала надо было открыть людям целый новый мир, и только потом, в его свете, доносить эту свою идею. Это сродни тому, как иностранцу, не владеющему твоим родным языком, объяснять на нем теорию относительности Эйнштейна. Особенно если ты ее сам как-то не очень…
Очевидно, что и для эффективного представления архитектурных решений всем заинтересованным лицам, требуется некий способ, позволяющий доступно, но достаточно развернуто донести их суть до максимально широкого круга лиц. Таким способом может служить принятый в организации стандарт — Архитектурное описание и соответствующие методы их поддержания. Для более точного осмысления этого явления, пустим в ход и их определение:
Архитектурное описание (англ. architectural description) — рабочий продукт, использующийся для выражения архитектуры (2).
Архитектурный метод описания (англ. architectural viewpoint) — спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам (2).
Тем самым, выделенные архитектурные группы, используя единые архитектурные методы описания, значительно повышают эффективность своей работы, достигая максимально согласованного и целостного восприятия обсуждаемых проблем.
Но можно ли загнать специалистов разных направлений, имеющих разную квалификацию, а возможно и образ мышления, в единые рамки, и действительно ли это так необходимо?
Например, диаграмма, описывающая формирование целей и показателей на основании выявления стекхолдеров, вызовов и их проблематики см. рис.1, по своей природе очень сильно отличается от диаграмм со схемой прокладки сети, а также диаграмм в нотации UML и прочих.
Рисунок 1. Модель выработки целей и показателей
На практике использование разнородных артефактов является большой проблемой, поскольку теряется возможность сквозной трассировки архитектурных решений от целей и стратегий к потребностям, далее к описанию бизнес-процессов и функций системы, от них к структуре данных и поведенческим моделям, от моделей к макетам экранов и т.д. по цепочке. Ведь создают все эти артефакты специалисты разных архитектурных групп, которые формировались сами по себе, подбирая годами под себя оптимальные инструменты и методики.
Фиксируя все эти разнообразные описания и представления, возникает резонный вопрос: Как же их объединить в некий всеобъемлющий контекст?
Например, для разработки больших информационных систем еще в конце прошлого века использовали модель Закмана (3), в качестве схемы организации архитектурных артефактов.
Модель Закмана основана на дисциплине классической архитектуры и призвана обеспечить общее толкование архитектурных аспектов и предоставить набор перспектив, или структур (framework), для описания сложных корпоративных систем.
Сама модель представляется в виде матрицы — таблицы, имеющей пять строк и шесть столбцов, см. рис. 2. Каждая ячейка таблицы – презентует набор артефактов, раскрывающих один из насущных аспектов архитектуры.
Рисунок 2. Представление модели Закмана
Примечательно, что основная идея матрицы помимо того, чтобы вынудить заполнить все ячейки, не пропустив важные характеристики системы, состоит и в определении последовательности заполнения. Ведь только заполнив одни ячейки, открывается возможность на основании их заполнить следующие, пока пазлы не сложатся в цельную картинку. Таким образом, различные по своему представлению архитектурные описания ложатся в разные ячейки матрицы и ею же увязываются в единое архитектурное полотно.
Стоит отметить, что на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Модель Закмана со временем дорабатывалась и послужила прародителем для многих архитектурных каркасов и спецификаций.
Одной из таких актуальных спецификаций является например, графический язык ArchiMate, содержащий набор понятий для описания архитектуры предприятия и фреймворк, представляющий логическую структуру для классификации этой информации Последняя версия стандарта 3.0 вышла в июне 2016 года.
В ArchiMate, при создании моделей, используются базовые понятия «элемент» и «отношение» см. рис.3. На основе элементов и отношений строятся модели предприятия или его отдельных частей.
Рисунок 3. Основные понятия ArchiMate 3.0
Вся прелесть подхода состоит в том, что элементами могут быть проекции самых разнообразных реальных сущностей и явлений, встречающихся в жизни. Например, мотивационные элементы (стейкхолдеры, драйвер мотивации, цель, результат, ценность и т.д.), элементы организации и поведения (исполнители, роли, процессы, функции, события, взаимодействие и т.д.), бизнес элементы (информационный актив, соглашение, продукт/услуга, компонент приложения, интерфейс приложения, автоматизируемая функция и т.д.), технологические элементы (узел/ресурс, устройство, коммуникационная сеть, технологический процесс и т.д.). Каждый вид элемента представлен на диаграммах своим уникальным обозначением. Таким образом в одном информационном пространстве могут сочетаться столь разные отражения сущностей, явлений, событий, действий и т.д., образующих архитектуру предприятия.
Сами модели располагают в одной из ячеек каркаса на пересечении Слоя (уровень представления) и Аспекта. Схематично структура фреймворка представлена на рис. 4.
Рисунок 4. Слои фреймворка ArchiMate 3.0
В качестве Слоев рассматриваются конструктивные субсистемы предприятия, образующие некое самодостаточное представление (срез) организации. А Аспекты в свою очередь относят элементы, к одному из трех основных типов:
1) Активный структурный элемент (active structure element) позиционирует его, как некую сущность, которая способна выполнять определенные действия
2) Пассивный структурный элемент (passive structure element) позиционирует его, как некоторый объект, над котором выполняются действия.
3) Элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами.
Более подробно ознакомится со спецификацией можно в обзоре ArchiMate (4).
Такого рода инструменты позволяют объединить в единое информационное пространство разнородные аспекты архитектуры, используя унифицированное архитектурное описание и методы, обеспечивая трассировку между диаграммами и элементами.
Погрузившись во все эту «карусель» сложностей и разнообразия возникает один немаловажный вопрос: А всегда ли необходимо выполнять такой сложный и ресурсоемкий процесс описания архитектуры? На самом деле существует несколько подходов к ее построению, например:
1) Стандартный подход, заключается в разработке или выборе на начальном этапе общей схемы и правил для описания архитектуры. На основании выработанных стандартов, описывается базовая (текущая) архитектура, и отталкиваясь от нее, проектируется целевая (новая). Определив разницу, формируют мероприятия по переходу от базовой архитектуры к целевой. Только после этого начинается конструирование, приобретение и разработка компонентов системы. В качестве недостатков, можно выделить: существенные начальные инвестиций, как финансовые, так и временные. Также этот подход может привести к тому, что называется «паралич из-за анализа».
2) Подход «статус-кво». Разработка рассматривается как реакция на те или иные возникающие затруднения или воздействия.
3) Сегментный подход, опирается на модель разработки сегментов архитектуры в рамках общей структурированной схемы. Он сосредотачивается на главных областях бизнеса. Позволяет сократить возможные риски, обеспечить снижение начальных затрат и добиться быстрой отдачи от проекта. Могут возникнуть проблемы на этапе интеграции сегментов.
3. Резюме раздела
Итак сделаем краткую выжимку из рассмотренного нами материала:
Со следующей частью статьи можно ознакомиться, перейдя по ссылке