Как составить архитектуру предприятия

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 канале, посвященном вопросам: проектирования программных продуктов, ИТ архитектуре и социальной инженерии.

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

Предпосылки трансформации

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

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

Что делает архитектор

Архитектор предприятия выступает идеологом и руководителем программы трансформационных проектов. Чтобы понять, какие шаги предпринять, ему необходимо:

• описать текущее состояние предприятия (As IS),
• разработать его целевое состояние (To Be),
• разработать программу трансформационных проектов (Road Map).

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

Сначала архитектор описывает текущее состояние производства. После чего переходит к разработке целевого состояния производства. Этот процесс включает несколько этапов.

Разработка целевого состояния предприятия

Первый этап: постановка бизнес-задач

В нашем примере с производственной компанией бизнес-задач четыре:

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

Второй этап: проработка будущего ландшафта информационных систем

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

Архитектор:

• описывает основные объекты данных предприятия (изделия, заказы, клиенты, сотрудники);
• моделирует основные потоки данных, сопровождающие бизнес-процессы (движение накладной, заказ-наряда, формирование плана выпуска продукции);
• планирует, в каких системах будут происходить процессы (ERP-система — класс систем для управления производством, CRM-система, система управления проектами, система автоматизированного проектирования);
• решает, в каких базах будут размещаться данные.

Третий этап: проектирование инфраструктуры

Разобравшись с данными и необходимыми прикладными средствами (ПО), архитектор проектирует для них инфраструктуру.

При проектировании инфраструктуры ему важно учесть три момента.

1. Обеспечить работоспособность систем при сбоях

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

2. Предусмотреть новые роли в производстве

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

3. Обеспечить информационную безопасность

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

Теперь можно говорить, что целевое состояние описано.

Разработка программы трансформационных проектов («дорожная карта»)

Сравнив «что есть» и «что должно быть», архитектор выявляет несоответствия — это называется gap-анализ. По его результатам формируются проекты. Проекты могут быть разные, к примеру:

• развитие системы управленческого учета,
• разработать кадровую политику,
• создать подразделение ИТ-бизнес-партнеров,
• мигрировать CRM на новую платформу,
• модернизировать функциональность систем автоматизированного проектирования (САПР),
• внедрить практики управления сервисами,
• резервировать системы управления базами данных (СУБД) и т.д.,

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

Дальнейшие шаги

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

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

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

Как найти архитектора

Перед владельцами бизнеса встает резонный вопрос: а где найти специалистов по архитектуре предприятия? Есть два пути.

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

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

Напоследок рассмотрим, какие задачи архитектор может решить в ретейле и банковской сфере.

Пример: архитектурный подход в ретейле

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

Многие аналитики выделяют следующие
подходы процессу построения архитектуры
предприятия:

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

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

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

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

1. Общая схема архитектурного процесса

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

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

• организация необходимых структур с
  привлечением руководства предприятия,
  бизнес — подразделений и планирование
  работ,

• понимание стратегии развития бизнеса
  организации,

• формирование общих для бизнеса и ИТ
  требований к целевой архитектуре,

• разработка принципов построения
  архитектуры предприятия.

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

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

На первом этапе построения архитектурного
процесса необходимо ответить на следующие
вопросы:

• Какие цели преследует организация?

• Какие задачи она ставит при внедрении
  методологии?

• Какие результаты организация планирует
  получить?

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

Один из традиционных вопросов возникающих
при разработке архитектуры предприятия
это обоснование необходимости ее
внедрения. Большинство топ менеджеров
обоснования инвестиций в архитектуру
предприятия в виде ROI(ReturnonAssets) для оценки подобных
проектов, но, по мнению аналитиков
компанииGartner, ни одно из
этих обоснований не являлось правдоподобным.
«За десять лет работы с тысячами компанийGartnerне видел ни одного
примера надежного обоснованияROIдля программы созданияEA»,
— говорит Брайн Бурк, один из ведущих
аналитиковGartnerв области
построения архитектуры предприятия:
«Вывод: этого нельзя сделать – и не
начинайте».

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

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

Рисунок
2.1. Выгоды от ИТ получает бизнес (Gartner)

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

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

• Результаты программы. Дает ли программа
  архитектуры предприятия, обещанные
  результаты?

• Зрелость программы. Уровень зрелости
  программы сравнивается на примере
  сравнения с аналогичными эффективными
  архитектурными процессами других
  компаний.

• Выгоды для ИТ. Как архитектура предприятия
  непосредственно влияет на ИТ?

• Выгоды для бизнеса. Как архитектура
  предприятия непосредственно влияет
  на бизнес.

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

Подобные цели непосредственно зависят
от роли, выполняемой различными людьми
в компании:

• Цель руководителя:

  • Продемонстрировать вклад архитектуры
    предприятия в бизнес.

• Цель управляющего:

  • Уменьшение рисков и усовершенствование
    процесса работы, использования ресурсов,
    соответствия требованиям и предсказуемости
    проблем.

Что можно оценивать при внедрении
архитектуры предприятия (до и после
разработки):

• Изменения в бизнес-процессах. Бизнес
  процессы становятся более пригодными
  для использования.

• Увеличение разнообразия числа продуктов.

• Сокращение времени завершения проектов,
  увеличение производительности
  (сокращение доработок связанных с
  плохим планированием).

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

• Интеграция с партнерами упрощается
  (заранее планируется, заранее реализуются,
  является гибкой).

• Количество сбоев в информационных
  системах снижается и, соответственно,
  возрастает готовность ИС.

• Упрощается доступ к информации и
  сокращается число «одноразовых»
  отчетов.

• Изменение показателей простоя/доступности.

• Снижение количества срочных
  инфраструктурных проектов (реактивность).

В таблице 2.1. представлены преимущества
разработки архитектуры предприятия
для ИТ и общие показатели.

Таблица 2.1.

Преимущества разработки архитектуры предприятия
Выгоды от EA	Примеры показателей
Меньшее время предоставления ИТ решения	Повторное использование общих конструкций ускоряет принятие решений в проектах: меньше времени на завершение проекта, проекты успешны.
Лучше интеграция между системами	Сокращение количества интерфейсов и их стандартизация обеспечивают сокращение времени интеграции информационных систем и обеспечивают ее простоту.
Уменьшение ненужной сложности.	Уменьшение общего числа стандартных технологий / продуктов. Устраняются разрывы и дублирование функциональности информационных систем и программно аппаратного обеспечения.
Эффективное использование инфраструктуры	Сокращение количества приложений с идентичной функциональностью. Ужесточение контроля за инфраструктурными компонентами, позволяющими отслеживать не используемые элементы. Стандартизация программно аппаратного комплекса.
Управление будущими инвестициями	Оптимизацию инвестиций за счет вложений в наиболее критичные для бизнеса места.
Зависимость новых технологий и требований бизнеса	Оптимизацию выбора и использования новых технологий в соответствии с требованиями бизнеса. Определение соответствия бизнес стратегии и проектов.
Возможность быстрых изменений.	Сокращение сроков реализации проектов и упрощение внедрения новых систем за счет создания зависимости между бизнес стратегией, бизнес процессами, информационными системами и программно-аппаратным комплексом их поддерживающим.

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

• Определения устава и границ проекта.

• Бизнес обоснование реализации проекта.

• Получение административного ресурса
  (поддержки руководства).

• Определение состава рабочей группы.

• Определение необходимого набора
  высокоуровневых «стартовых» документов.

• Создание рабочих групп по разным
  направлениям деятельности (EBA,EIA,ESA,ETA).

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

• Бизнес — факторы, влияющие на деятельность
  предприятия.

• Внутренние и внешние технологические
  факторы и тенденции.

• Общее видение архитектуры предприятия
  (цели и задачи).

• Принципы построения архитектуры
  предприятия.

Один из самых первых и наиболее удачных
процессов разработки архитектуры
предприятия был предложен Стивеном
Спиваком (StevenSpewak)
и называлсяEAP(EnterpriseArchitecturePlanning).
Модель выделяет в архитектуре предприятия
семь шагов, разделенных на четыре уровня
(рисунок 2.2.), и обеспечивает высокоуровневый
взгляд на предприятие с точки зрения
бизнеса.

Рисунок 2.2. Уровни
архитектурного процесса

Уровень 1.Это уровень начало работ
и активации архитектурного процесса.
На этапеинициирования процесса
планированияразрабатываются и
описываются основные концепции развития
архитектуры предприятия. Разрабатываются
принципы построения архитектуры.

Уровень 2 описывает состояние
предприятия в настоящий момент времени.
Другими словами это уровень разработки
текущей архитектуры предприятия. Здесь
происходитбизнес моделирование(разработка текущей бизнес архитектуры)
и описаниетекущих систем и технологий(документирование текущей архитектуры
информационных систем).

Уровень 3описывает возможные
варианты развитияархитектуры данных,
архитектуры приложений, технологической
архитектурыв соответствии с
требованиями бизнеса. Другими словами
на этом уровне происходит разработка
целевой архитектуры.

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

Процесс разработки архитектуры
предприятия имеет циклическую структуру.
Рисунок 2.3. показывает основные элементы
архитектурного процесса в виде бок
схемы.

Рисунок 2.3. Основные элементы
архитектурного процесса

Инициирование проектапостроения
архитектуры предприятия является первым
шагом построения архитектурного процесса
и включает в себя:

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

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

• Определение требований к данным.
  Описывает категории данных, степень
  детализации и метрики.

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

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

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

Концептуальная архитектураописывает
состояние «идеального» предприятия с
точки зрения бизнеса.

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

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

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

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

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

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

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

Следует отметить, что архитектурный
процесс является элементом нескольких
процессов CobiT:

• PO1 Определить стратегический
  план ИТ (defineastrategicITplan). Обеспечивает подготовку
  стратегического плана развития
  информационных технологий на предприятии
  с точки зрения требований бизнеса
  (бизнес стратегии).

• PO2 Определить
  информационную архитектур
  (define the information architecture). Считается,
  что процесс обеспечивает разработку
  ИТ архитектуры и включает в себя: анализ
  существующих программно аппаратных
  средств и поддержку текущей архитектурной
  картины в актуальном состоянии,
  разработку целевой архитектуры,
  проведениеGAPанализа,
  разработка предложений по изменениям
  архитектуры (проекты, инициативы).

Рисунок 2.4. Схема
архитектурного процесса (РО2 и РО3)

• PO3 Определить технологическое
  направление (determinethetechnologicaldirection).
  Процесс обеспечивает мониторинг
  современных тенденций в области
  информационных технологий, выработку
  рекомендаций по использованию программно
  аппаратных средств, разработку и
  модернизацию стандартов.

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

В таблице 2.2. представлен набор
универсальных архитектурных документов

Таблица 2.2.

Набор универсальных архитектурных документов
Раздел	Описание
Резюме	Основной документ, описывающий основные цели и задачи стоящие перед архитектурным процессом и его роль в функционировании предприятия. Цель данного документа – объяснить руководству необходимость архитектурного процесса.
Организация проекта	Отражает границы охвата проекта. Описывает состав участников и планируемых работ. Критические факторы успеха, выбранную методологию и средства описания архитектуры.
Бизнес требования	Бизнес требования формируются на основе стратегии развития предприятия.
Связь бизнеса и информационных технологий	Документ связывает существующие бизнес процессы, ИТ услуги, информационные системы в единое целое. На основе этих данных строится матрица соответствия между бизнес требованиями и ИТ услугами.
Текущее состояние	Документирование текущего состояния архитектуры предприятия, обеспечивающий сбор информаций о информационных системах и бизнес процессах компании. Документ описывает проблемы в обеспечении бизнес.
Целевое состояние	Документ описывает предполагаемые варианты реализации основных бизнес процессов в будущем состоянии.
Концептуальная архитектура	Описывает основные требования и принципы к построению бизнес процессов на предприятии и информационных систем. Рассматривает возможность использования технологических инноваций в компании. Возможно формирование матрицы, описывающей корреляцию между данными принципами и бизнес требованиями.
Анализ расхождений	GAPанализ, или другими словами анализ расхождений производит сравнение текущего и целевого состояния. На основании этой информации делаются заключения о необходимости внесения изменений в структуру предприятия.
Планирование преобразований	Выделяется набор проектов в соответствии с бизнес приоритетами компании. Оцениваются ограничения по бюджетам и срокам реализации. Проводится анализ рисков при реализации и отказе от преобразований.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

В статье «Зачем вам автоматизировать проектное управление?» я уже говорил о том, как важно при внедрении информационной системы управления проектами (далее — ИСУП) соблюсти баланс между пользой, которую она приносит заказчикам, и усилиями, необходимыми для ее функционирования.

И одно из первых препятствий при внедрении ИСУП — разработка требований к системе.

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

Готовое решение имеет четкую архитектуру, и большинство новых «хочу» требует привлечения IT-разработчиков. При этом быстро добавить ранее упущенное, как правило, не получается (если это в принципе реально в выбранной ИСУП). Поэтому уже внедренная система может какое-то время простаивать, ее невозможно использовать.

С No-Code- / Low-Code-инструментами (например, Coda, Fibery, Airtable, Jira) ситуация обратная. Полноценные требования к такой ИСУП часто вовсе не формируются, а разработка ведется с помощью итеративного прототипирования решения. Но, как я говорил в статье «NoCode-инструменты для управления проектами: преимущества и недостатки», хаотичное добавление объектов, полей, атрибутов может привести к потере взаимосвязи между данными. Из-за этого пользователям будет сложно получить цельную картину, например, сформировать отчетность по проекту или портфелю.

Ключом к решению данных проблем может стать построение модели ИСУП до начала или в самом начале ее внедрения.

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

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

Давайте рассмотрим основные этапы объектного моделирования.

Этап 1. Выделение аспектов

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

В стандартах проектного менеджмента, например, в PMBoK, аспекты называют предметными областями, а в PRINCE2 — темами.

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

1. Структурирование деятельности компании в виде проектов всегда имеет какие-то цели: достижение определенного эффекта, применение результатов в процессах компании.

2. Проекты реализуются в рамках важных для бизнеса ограничений. Для кого-то важна реализация в срок, для кого-то — минимальный расход ресурсов.

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

Классификации аспектов можно найти в любом стандарте по управлению проектами. Я в своей практике выделяю двенадцать основных аспектов:

Вы можете использовать этот список аспектов либо сформировать свой.

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

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

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

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

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

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

Этап 2: Определение объектов

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

Допустим, вы выбрали аспект «сроки», так как для вас важно завершение проектов в срок. В этом случае мы воспользуемся объектом «проект» и зададим для него даты сроков окончания.

Если вам хочется видеть, соответствует ли процесс работы над проектом графику «внутри» этих сроков, то у вас появляется еще один объект — «работа», и у него тоже есть сроки начала и окончания.

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

Чем больше объектов вы выделите в рамках аспектов, тем сложнее, но одновременно и полнее будет ваша модель проектного управления.

Выделение объекта в системе проектного управления и дальнейшее управление им с помощью ИСУП позволят вам:

Мы видим, что объект может не быть уникальным для какого-либо аспекта. Например, такой объект, как «работа», будет присутствовать и в аспекте «сроки» для контроля сроков исполнения, и в аспекте «содержание и качество» для определения состава работ. А возможно, и в аспекте «финансы», если вы контролируете затраты на выполнение конкретной работы.

То есть не обязательно увеличивать количество объектов, вы можете просто задать необходимые свойства (см. 3-й этап).

Этап 3: Определение свойств объектов

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

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

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

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

Я выделяю две группы свойств объектов ИСУП:

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

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

Самым распространенным способом описания состояний являются статусы. Например, в процессе исполнения работ можно использовать такие статусы, как:

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

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

При описании состояний объекта необходимо сформировать полный перечень состояний с описанием их смысла и условий переходов между ними.

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

Несмотря на некоторую сложность определения, а скорее даже сложность согласования состояний при использовании ИСУП, они значительно упрощают подготовку и восприятие управленческой отчётности.

Этап 4: Определение взаимосвязей между объектами и свойствами

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

Определенные в рамках ИСУП взаимосвязи позволяют:

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

Таким образом, объектная модель формирует смысловой скелет ИСУП, обеспечивает полноту и достаточность требований к системе.

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

Для решений No-Code / Low-Code объектная модель становится каркасом, позволяющим избежать дублирования данных и не связанных ни с чем данных («повисших в воздухе»). При этом большинство No-Code- / Low-Code-решений (например, Coda, Jira) позволяет создать иерархию объектов любой сложности, настроить изменения их свойств, в том числе автоматизированный переход по фазам жизненного цикла объекта, и задать взаимосвязи между ними.

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

1. Подготовительный этап

Выбор референсной модели

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

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

Мы рекомендуем использовать Референсную модель бизнес-архитектуры Deep Vision.

Определение набора точек зрения

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

Точки зрения позволяют бизнес-архитекторам продемонстрировать решение задач и проблем заинтересованных сторон в рамках бизнес-архитектуры.

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

Выбор подходов и инструментов

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

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

Подготовка такого рода позволяет существенно упростить процесс создания бизнес-архитектуры.

Формирование подхода к моделированию

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

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

В совокупности вышеуказанные действия определяют подход к моделированию бизнес-архитектуры.

Подготовка перечня каталогов

Каталог – перечень и описание однотипных элементов бизнес-архитектуры. Например: каталог организационных единиц, каталог бизнес-процессов, каталог ИТ сервисов и т.д.

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

Каталоги имеют свою иерархию, то есть они содержат описание классов, подклассов и конкретных элементов. Например: каталог организационных единиц, каталог должностей, каталог ролей.

Каталоги являются исходным материалом для разработки моделей и матриц.

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

Выбор набора матриц

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

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

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

Определение необходимых диаграмм

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

Диаграммы отражают одну или несколько точек зрения на бизнес в соответствии с требованиями заинтересованных сторон.

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

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

Сбор бизнес-планов

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

Формирование сценариев бизнес-архитектуры

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

Подготовка базы знаний бизнес-архитектуры

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

На данном этапе необходимо подготовить базу знаний для дальнейшего наполнения.

Выявление требований

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

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

Требования должны:

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

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

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

Целевой объем содержания требований нужно определить заранее. Он, объем, должен быть определен для каждой итерации проработки бизнес-архитектуры.

2. Описание текущей архитектуры

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

Помимо этого объем и степень детализации зависит еще от двух факторов:

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

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

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

3. Разработка целевой архитектуры

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

Объем описания и степень детализации определяются на основании:

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

Да, фишка не только в том, что нет одинаковых архитектур, но и в том, что требования к описанию архитектуры разняться от компании к компании.

Вы всегда можете обратиться в нашу компанию по вопросам описания и разработки бизнес-архитектуры