Архитектура организации это способ

Архитектурные методы: что это и зачем они нужны

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

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

Даем определение и делаем аналогии

Здесь на авансцену и выходят архитектурные методы. Что это такое? Метод — это руководство, как создавать и внедрять архитектуру и ИТ-решения проверенным и последовательным образом. По факту, это руководство является сбором знаний и опыта ведущих специалистов организации. Методы закрывают полный жизненный цикл создания архитектуры и продуктов и включают в себя материалы для проектирования, планирования и внедрения ИТ-решений. Метод можно сравнить с методичкой для студента, которая описывает, что, кому и когда нужно делать и что в итоге получится. Или упрощенно метод можно представить как руководство пользователя (user manual) по использованию любой техники – в целом, можно обойтись и разобраться самому, но зачем, если уже все написано.

Фреймворк vs метод – в чем разница?

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

Логично ведь иметь одну единую классификацию ролей, единый список архитектурных артефактов или практик, а не пять разных. Куда разумнее иметь пять разных способов их использования или, по-другому, методов. Безусловно, метод может использовать не все роли и не все артефакты из фреймворка. В IBM, к примеру, существует единый фреймворк с созвучным названием Unified Method Framework, где приведен исчерпывающий список практик, артефактов, ролей, и с которым связаны практически все использующиеся методы. Среди открытых стандартов можно привести пример The Open Group Architecture Framework (TOGAF) и Architecture Development Method (ADM) в области управления и создания корпоративной архитектуры.

Составляющие метода

Подробнее разберем, что же включает в себя описание метода, из каких частей он состоит? Во-первых, каждый метод должен быть однозначно идентифицирован по названию (например, Architecture Quickstart, Agile with Discipline). Казалось бы, это весьма очевидная мысль, но на практике она нередко выручала, когда международная команда архитекторов (еще и из разных стран) обсуждает основные шаги предстоящего проекта. Достаточно сказать пару слов из названия метода, и все понимают, про что идет речь, так как методы едины для всей компании. В целом, важность названия не стоит недооценивать.

Идем дальше: метод должен включать описание процесса создания архитектуры решений и ключевых действий. Можно сказать, что метод дает последовательную инструкцию: сделай раз, сделай два, сделай три. Все шаги процесса связаны с ролями, описанными в фреймворке. Ролью может быть архитектор приложений, проектный менеджер, Agile коуч, DevOps инженер.
Метод также дает связь между шагами процесса и созданием необходимых рабочих продуктов (work products). Эти самые рабочие продукты можно разбить на 2 категории: артефакты и deliverables (результирующие продукты). Отличие очень простое – артефакты могут быть промежуточными результатами и не использоваться как результат на ключевых вехах проекта. Примером артефакта можно назвать результат интервью при сборе требований, gap-анализ сравнения с референсной архитектурой, один или несколько сценариев использования (use cases). К слову, упражнение по сравнению текущей архитектуры с референсной делается практически в каждом проекте и наиболее частыми областями в последнее время являются cloud-native и концепция data reservoir.

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

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

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

База знаний методов

Видно, что метод – это описание, как правильно создавать архитектуру, основанное на практическом опыте более опытных людей. Логично, что такие описания должны храниться в компании централизованно и быть доступны всем желающим. В IBM, к примеру, это реализуется на базе портала IBM MethodWeb, где находится список архитектурных методов и их описание. Для повышения эффективности использования методов они могут быть встроены в специальные инструменты, которые используют архитекторы при проектировании решений (это было давно реализовано в Rational System/Software Architect и может быть сделано в других программных продуктах. Описание метода может быть выгружено, к примеру, в xml формат и импортировано в инструментарий.

Методы – не только для архитекторов

В примерах выше встречались практики или артефакты, которые относятся не только к задачам архитекторов, но и деятельности разработчиков. Это сделано не случайно – методы могут использоваться не только в архитектуре, но и в разработке (IBM Garage Method – метод по созданию cloud-native приложений) или даже в понимании бизнес-проблем (Enterprise Design Thinking). Структура у этих методов может немного отличаться друг от друга, но задача по систематизации подхода остается прежней.

Типы методов

Важно отметить, что вряд ли нужно стремиться к наличию единого метода по разработке архитектуры. В IBM, к примеру, больше сотни архитектурных методов и все они решают разные задачи. Посмотрим, какие типы методов существуют: сразу можно разделить на те, которые используются при проектировании (на стадии pre-sale), и те, которые используются при внедрении решений (на стадии delivery). Есть методы специально для прикладной архитектуры, инфраструктуры, данных или корпоративного уровня (enterprise architecture). Существуют методы, специализирующиеся на Agile разработке, другие – на waterfall. Не так давно появились методы, заточенные на создание продуктов на базе cloud-native стека технологий. Также существуют методы, которые сфокусированы на конкретном семействе продуктов, например SAP или Oracle, где есть свои отличительные черты.

Жизненный цикл метода

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

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

Что же получается в итоге?

Метод – это интеллектуальный капитал компании, где отражаются опыт и знания ее сотрудников по результатам выполненных проектов. Благодаря этому не нужно каждый раз изобретать колесо в начале проекта и думать, с чего начать. Методы повышают повторное использование материалов из проекта в проект, позволяя в то же время грамотно распределять задачи между участниками. Многие компании в области консалтинга используют различные методы при выполнении проектов для клиентов. В IBM часть методов является закрытой (Architecture Quickstart), часть возможна к лицензированию и использованию (Team Solution Design), а часть – открыта (IBM Garage Method).

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

Источник

Архитектура ИТ решений. Часть 1. Архитектура предприятия

I. Вступление

Архитектура распределяет массы и объемы.
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.

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

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

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

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

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

II. Определение понятия «архитектура»

А что можно думать об архитектуре?
Она, как солнце: большая, блестящая и она рядом.
Роджер Желязны. (Мастер сновидений)

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

Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:

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

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

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

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

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

Раз уж речь зашла о едином подходе, давайте внесем ясность и в этот вопрос:

Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом заинтересованных лиц (2).

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

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

1. Разделы ИТ Архитекторы

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

1) Информационная архитектура (Enterprise Information Architecture, сокр. EIA), набор методик и инструментов, описывающий информационную модель предприятия. Включает:

• базы данных и хранилища данных;
• информационные потоки (как внутри организации, так и связи с внешним миром).

2) Архитектура прикладных решений (Enterprise Solution Architecture сокр. ESA) – представляет архитектуру приложений, включающую в себя совокупность программных продуктов и интерфейсов между ними. Делится на два направления:

• область разработки прикладных систем;
• портфель прикладных систем.

3) Техническая архитектура (Enterprise Technical Architecture сокр. ETA) — совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений. Описывает полное представление инфраструктуры предприятия, включая:

• информацию об инфраструктуре предприятия;
• системное программное обеспечение (СУБД, системы интеграции);
• стандарты на программно-аппаратные средства;
• средства обеспечения безопасности (программно-аппаратные);
• системы управления инфраструктурой.

Плюс к этому добавляется и архитектура самого предмета автоматизации:

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. Резюме раздела

Итак сделаем краткую выжимку из рассмотренного нами материала:

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

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

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

Источник