Методики создания бизнес архитектуры содержат

Контекст разработки архитектуры предприятия

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

Витрувий, архитектор времен Римской империи

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

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

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

• методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими;
• модель Захмана;
• методика TOGAF;
• методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.

Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве Обороны США DoDAF (Department of Defence Architecture Framework).

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

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

Если говорить формально, то существуют индустриальные стандарты на описание архитектуры предприятия, принятые такими организациями, как Институт инженеров электрики и электроники (IEEE – Institute of Electrical and Electronics Engineers), международная организация стандартизации (ISO – International Organization for Standardization), The Open Group и т.д. Но ни один из этих стандартов не занимает доминирующего положения. Более того, ни один из них, взятый в отдельности, не дает группам, ответственным за разработку архитектуры, всех инструментов, необходимых с методической точки зрения и с точки зрения шаблонов, используемых для описания архитектуры. Однако этот накопленный арсенал методик и стандартов предоставляет архитекторам широкие возможности выбора архитектурных моделей, примеров и опыта различных индустрий [5.2].

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

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

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

• достаточно высокий уровень детализации для практического использования специалистами в области информационных технологий при разработке новых систем;
• простоту для понимания бизнес-аудиторией;
• динамику рассмотрения (т.е. «Архитектура как есть» – «Краткосрочные и среднесрочные задачи» – «Стратегические планы»);
• возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных (ad-hoc) проектов.

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

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

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

Первое определение говорит о том, что «архитектура – это описание некоторой сложной системы в определенный момент времени». Оно аналогично схемам описания и чертежам здания, города, сада или компьютерной сети. Этому определению архитектуры соответствует центральная секция таблицы. Данная часть таблицы описывает два представления архитектуры: существующее и будущее состояния. В лекциях 10-12, посвященных организации архитектурного процесса, мы отдельно обсудим, как должны, с точки зрения затрачиваемых усилий, соотноситься эти два представления архитектуры.

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

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

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

Время на прочтение
6 мин

Количество просмотров 2.8K

Бизнес-архитектура и ее место в компании

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

Таким образом, архитектура в городе — это наука не только о строительстве и проектировании, но еще и о структурировании.

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

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

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

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

Взгляд со стороны ИТ

Зачем вообще разрабатывать единую архитектуру для работы компании? Рассмотрим этот вопрос с точки зрения Блока информационных технологий Страхового Дома ВСК.

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

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

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

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

Основные бизнес-составляющие

Так случилось, что в один момент ИТ‑архитектура нашей компании устарела и перестала отвечать на вызовы рынка. Развитие ее стало долгим, дорогим и мучительным. Появилась явная цель — избавиться от старых приложений (legacy out) и реализовать новые.

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

Сервисы

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

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

В методологии Agile, во фреймворке SAFe, есть понятие «Value stream». Это картирование — сбор и анализ информации о процессах в потоке, оптимизация операций с точки зрения ценности действий и целесообразности затрат. Ценность рассматривается с точки зрения клиента.

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

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

Способности

Способность (Capability) — это умение (или навык) компании. Мы только начинаем работу в этом направлении. На данный момент совместно с Ассоциацией ФинТех (далее — АФТ) разработан драфт функциональной карты страхового рынка. На ее основании реализован каталог способностей до 3 уровня.

Каждую из способностей можно детализировать на бизнес‑функции (4ый уровень) и смаппировать на сервисы. Такой подход обеспечит связь сервисов и бизнес‑процессов.

Дашборды

Речь идет о визуализации показателей в информационном разрезе компании. Дашборды представляют собой матрицу, имеют цветовую идентификацию и возможность Drill Down.

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

Архитектура решения

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

Фронт работ над ПО: развитие функционала по первичному учет сервисов, интеграция с Jira, автоматическое обновление дашбордов, формирование требований и разработка функционала по работе со способностями.

Касательно сервисов, важно отметить следующие пункты:

• по каждому сервису необходимо определить реального владельца, отвечающего за его развитие;

• для каждой задачи в Jira необходимо указать сервис и/или способность;

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

  

Перспективы развития

В 2022 году мы определили целевую концепцию и разработали базовый функционал по сервисам. Далее рассматриваем следующий план взаимодействия с Бизнесом:

• ИТ дорабатывает инструмент, осуществляет первичное наполнение данными и использует дашборды для общения с Бизнесом об уровне и качестве автоматизации;

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

Стратегия развития бизнес‑архитектуры следующая:

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

• автоматизация сбора информации: автоматизация сбора данных об уровне и качестве автоматизации на основании сервисов, сбор статистики по сервисам → автоматизация ручного ввода;

• прогнозирование изменения конъюнктуры: апробирование гипотез и трендов — цифровой двойник* → наличие модели, помогающей предсказывать последствия планируемых изменений.

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

Заключение

Выше описан взгляд Страхового Дома ВСК на организацию бизнес‑архитектуры и практический подход к реализации.

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

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

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

Если у Вас есть интерес — пишите skirillov@vsk.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модели:

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

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

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

Элементы:

• Миссия
  и видение.

• Руководящие
  принципы.

• Цели,
  задачи и стратегии.

• Архитектура
  информационных технологий.

• Политики
  (правила).

• ИТ-стандарты.

• Процедуры.
  Процедуры – это инструкции, описывающие,
  как выполняются политики и стандарты.
  Процедуры устанавливают и описывают
  процессы, которые выполняются на
  регулярной основе.

• Руководства
  или рекомендации (guidelines).

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

Инструменты
моделирования

• Декомпозиция
  бизнес-процессов

• Анализ
  бизнес – событий

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

• Модель
  местоположения

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

• Модель
  интеграции

определяет
связь бизнес-процессов и бизнес — событий.

Ниже
приведены примеры общих принципов,
связанных с архитектурой в целом:

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

• Функциональное
  руководство и руководство в области
  ИТ должно основываться на общем видении.

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

• Функциональные
  (бизнес-) требования должны формировать
  архитектуру.

• Архитектура
  должна обеспечивать совместимость и
  взаимодействие.

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

• Архитектура
  должна быть инструментом реализации
  изменений.

• Архитектура
  должна уменьшать сложность интеграции
  и способствовать улучшению качества
  бизнес-процессов.

• Тенденции
  рынка должны учитываться при проектировании
  технологической архитектуры.

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

Данная статья включает основные понятия по теме «архитектура предприятий», а также анализ популярных методик, предназначенных для описания таких архитектур, с выявлением наиболее подходящей модели при создании такого комплексного решения, как ESB (enterprise service bus) — корпоративной интеграционной шины [1] информационных систем компаний, занимающихся проектированием и сооружением сложных инженерных объектов.

Введение

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

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

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

В результате применение фреймворков Solution Architecture (Архитектура прикладных решений) оказывается недостаточным для проектирования и успешной реализации такого сложного продукта, как ESB. Логичным становится использование Enterprise Architecture (Архитектура предприятия). Остается вопрос выбора наиболее подходящей методологии описания архитектуры при создании интеграционных решений на предприятиях по проектированию и сооружению сложных инженерных объектов.

Архитектура предприятия

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

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

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

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

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

• методика TOGAF;
• методика Gartner;
• методика META Group.

Методика TOGAF

Методика TOGAF является описанием архитектуры предприятия, которая предлагает способы и подходы для выстраивания, планирования, применения  IT­архитектуры предприятия и, впоследствии, управления ею. TOGAF принимает, но не строго придерживается определения ISO/IEC 42010:2007. В TOGAF термин «архитектура» имеет два значения, в зависимости от контекста:

1. Формальное описание системы или детальный план системы на уровне ее компонентов для руководства ее реализацией.
2. Структура компонентов, их взаимосвязь, а также принципы и руководящие указания по их разработке и эволюции во времени [6].

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

1. Архитектура бизнеса.
2. Архитектура приложений.
3. Архитектура данных.
4. Архитектура технологии.

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

Методика TOGAF включает два направления:

1. Методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры.
2. Базовая архитектура (Foundation Architecture).

Методика ADM включает несколько фаз, которые представлены на рис. 1.

Рис. 1. Методика ADM TOGAF

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

Концепция Базовой архитектуры основывается на иерархии архитектур, а именно:

• архитектуры общих систем;
• отраслевой архитектуры;
• архитектуры организации [5].

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

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

Методика Gartner

Компания Gartner трактует понятие «архитектура предприятия» как процесс перевода видения и стратегии бизнеса в эффективное изменение компании посредством создания, обсуждения и улучшений ключевых требований, принципов и моделей, которые описывают будущее состояние компании и делают возможным ее развитие [7].

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

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

Методика META Group

Данная методика рассматривает архитектуру предприятия в интеграции с другими процессами, к примеру с процессом управления корпоративными IT­программами и проектами и процессом выработки стратегии и планирования.

Основными этапами разработки архитектуры предприятия являются:

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

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

Сравнительный анализ

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

Можно заметить, что у всех методик есть как общие линии пересечения, так и кардинальные отличия друг от друга. Для сравнения методологий выделим несколько критериев, основываясь на экспертном мнении Роберта Сешнса [8] — известного практика компании Microsoft в области архитектуры предприятий, и с помощью таблицы соответствий определим, какая из методик более подходит для решения ранее поставленной задачи.

Из таблицы соответствия явно видно преимущество методики TOGAF. Как же выглядит применение методики на реальном проекте?

Таблица сравнения методик

Критерий/Методика	Методика TOGAF	Методика Gartner	Методика Meta Group
Возможность описания различных структурных элементов	+		+
Описание процесса создания архитектуры предприятия	+	+	+
Полезность использования архитектуры предприятия в целом	+	+	+
Полезность использования архитектуры предприятия по предметным областям	+		+
Визуальное схематичное отображение архитектуры предприятия	+
Восприятие архитектуры предприятия любыми специалистами	+		+
Доступность методики (ее инструментов и сервисов)	+		+
Рекомендации по управлению архитектурой	+	+	+

Archimate — фреймворк, представляющий логическую структуру для классификации этой информации и содержащий набор понятий для описания архитектуры предприятия [9]. Воспользовавшись данным графическим языком, мы получаем визуализацию нашей архитектуры с различных предметных областей, а также можем объединить их в единую архитектуру предприятия (рис. 2).

Рис. 2. Применение Archimate при интеграции двух программных комплексов

Данная иллюстрация отображает интеграцию двух компонентов корпоративной шины — САПР (система автоматического проектирования) и расчетного комплекса. Архитектура включает проработку с разных точек зрения, а именно: бизнес­уровень, уровень приложений и технологический уровень, а также их объединение в общую архитектуру решения, что позволяет выделить основные векторы развития и определить, какие области архитектуры требуют детализации.

Заключение

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

Список литературы:

1. David Chappell. Enterprise Service Bus. Publisher: O’Reilly Media. Release Date: June 2009. Совнет. Ассоциация управления проектами.
2. Управление проектами. Свод профессиональных знаний. Национальные требования к компетентности специалистов. Версия 3.0.
3. ISOIEC 42010:20077: Systems and Software Engineering — Recommended Practice for Architectural Description of Software­Intensive Systems, Edition 1 (technically identical to ANSI/IEEE 1471­2000).
4.  https://msdn.microsoft.com/ru­ru/library/ee895290.aspx.
5. Данилин А., Слюсаренко А. «Архитектура и стратегия. «Инь» и «янь» информационных технологий предприятия». Издательство: Интернет­Университет Информационных технологий.
6. https://www.ibm.com/developerworks/ru/library/ws­soa­term1/
7. Джеймс Г., Грета А., Роберт А. Хэндлер, Энн Лапкин и Николас Галл. «Структура архитектуры предприятия Gartner: развитие, 2005 г.». Код Gartner: G00130855.
8.  https://msdn.microsoft.com/ru­ru/library/ee914379.aspx
9. http://pubs.opengroup.org/architecture/archimate3­doc