Что представляет собой архитектура ит сети компании

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

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

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

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

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

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

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

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

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

Что такое архитектура IT и зачем она нужна

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

IT архитектура:

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

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

Кому нужно знать архитектуру IT и предприятия

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

Архитекторы всех уровней

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

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

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

Бизнес-аналитики и системные аналитики

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

Разработчики и системные инженеры

Занимаются непосредственно ПО и IT-инфраструктурой предприятия.

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

Друг архитектора — Archimate

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

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

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

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

Главные плюсы в использовании Archimate

В практическом применении Archimate есть следующие плюсы:

· с его помощью можноописать всю деятельность предприятия в комплексе, от архитектуры предприятия до продуктов и сервисов;

· подходит для бизнеса любой сферы деятельности;

· прост в использовании (по убеждению профессионалов);

· легко устанавливается на любые операционные системы;

· позволяет генерировать разные варианты отчетов;

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

Где всему этому научиться

21 ноября в CORS Academy стартует новый уникальный курс «Моделирование архитектуры IT и предприятия. Archimate».

Именно в рамках данного курса вы:

— познакомитесь с нотацией языка ArchiMate 3.1 и возможностями его применения для моделирования архитектуры предприятия и IT- архитектуры;

— приобретете навыки построения архитектурных моделей с применением ПО российского производителя.

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

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

Авторы курса “Моделирование архитектуры IT и предприятия. Archimate”

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

Знакомьтесь с авторами курса «Моделирование архитектуры IT и предприятия. Archimate»:

Ольга Ковальчук, эксперт по продуктам класса EnterpriseArchitect с опытом разработки крупных интеграционных проектов в компаниях Вымпелком, Ростелеком, Росатом, Альфа-банк, МОЭК.

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

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

Почему выгодно подать заявку на обучение прямо сейчас?

При оплате курса до 21 ноября вы получите 50% скидку!

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

Уровень зарплат архитектора начинается от 130 000 рублей в небольших организациях с минимальным опытом работы, а с опытом работы от 5-ти лет по профилю — от 300 000 рублей.

Зачем нужны архитектура IT и предприятия?

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

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

Где всему этому научиться

21 ноября в CORS Academy стартует новый уникальный курс«Моделирование архитектуры IT и предприятия. Archimate».

При оплате курса до 21 ноября вы получите 50% скидку!

ИТ-архитектура является одним из важнейших компонентов организации (корпоративной архитектуры). Есть различные стандарты, подходы и модели (framework) к построению и развитию ИТ-архитектуры и корпоративной архитектуры, например: ITIL, TOGAF, ISO 15288, 20000, 27000, Zachman, COBIT, IT4IT и др. В данной статье рассмотрим комплекс основных этапов, который уже многократно зарекомендовал себя и апробирован во многих организациях. Каждый этап состоит из набора взаимосвязанных задач и инструкций. Детально они рассмотрены в источниках [1], [2] и [3].

Для создания всех графических моделей, реестров и справочников (классификаторов) по ИТ-архитектуре рекомендуется использовать специализированные программные продукты, например Business Studio, Archi, Microsoft Visio + Excel. Ключевыми исполнителями данных работ являются: ИТ-архитектор и ИТ-департамент в целом, процессный офис (или департамент бизнес-архитектуры), рабочие группы (команды) по соответствующим направлениям.

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

12 этапов построения и развития ИТ-архитектуры организации

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

1. Разработка ИТ‑стратегии

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

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

2. Разработка иерархического реестра (каталога) всех ИТ‑систем и ИТ‑платформ организации

С точки зрения TOGAF должно быть построено два иерархических реестра (дерева): слой приложений (application layer), слой системных технологий и ИТ-платформ (technology layer).

Первый слой (реестр) необходимо детализировать до модулей и функций (см. Рис. 1). В зависимости от размера организации данный реестр может иметь 5-8 и более уровней детализации (иерархии).

Рис. 1. ИТ-архитектура (на примере банка, фрагмент) и карточка (набор параметров) ИТ-системы

Перечислим минимальный набор ИТ-систем (приложений), которые работают практически в каждой организации:

• CRM и Front-office (маркетинг, продажи, работа с клиентами),
• Электронный документооборот (ЭДО),
• Кадровые и зарплатные системы,
• Бухгалтерские системы,
• Офисные системы (работа с документами и таблицами),
• BPMS (управление процессами и задачами),
• Юридические системы (договора, законодательство),
• Системы информационной безопасности (Firewall, Antivirus).

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

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

3. Заполнение детальных параметров (карточек, спецификаций) всех ИТ‑систем и модулей

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

• Контуры функционирования: test (development), pre-production, production,
• Площадки и расположение: «облачное, cloud based» (за пределами организации), собственные ресурсы,
• Типы лицензий: временные (подписка), постоянные,
• Оборудование и ИТ-платформы, на которых работают ИТ-системы (приложения),
• Владелец ИТ-системы в организации (ответственный),
• Сроки (периодичность) обновления, сроки оплаченной внешней техподдержки,
• Версия и тип (категория) ИТ-системы,
• Финансовая информация: первоначальные вложения (CAPEX), стоимость сопровождения (OPEX),
• Операционные риски и риски информационной безопасности,
• Влияние на критичную архитектуру организации,
• Требования к отказоустойчивости, дублированию компонентов и резервному копированию,
• Срок восстановления системы в случае сбоев,
• Максимальное количество пользователей,
• Зависимость от иностранного программного обеспечения,
• Комментарии и техническая информация.

На основе данных параметров очень удобно автоматически формировать отчёты (точные аналитические срезы) по ИТ-архитектуре. Например, выборка ИТ-систем, которые работают на «облачном формате», имеют самые высокие расходы (OPEX), влияют на критичную архитектуру, имеют высокие риски. Далее на основе данной выборки можно принять решения о модификации ИТ-архитектуры.

4. Разработка архитектурных моделей ИТ-систем

Архитектурная модель ИТ-системы (см. Рис. 2) показывает основные её технические и логические компоненты, а также их взаимодействия (потоки данных). Например, серверная часть (приложение), сервер баз данных, внешние и вспомогательные сервера, клиентская часть (приложение), другие виды устройств и компонентов.

Рис. 2. Архитектурная модель программного продукта (на примере Business Studio)

5. Разработка графических моделей по интеграции (связям) ИТ-систем

Необходимо отобразить ключевые потоки данных (см. Рис. 3) между ИТ-системами организации (ИС1 <=> ИС2), между ИТ-системами и базами данных (ИС1 <=> БД1), между ИТ-системами организации и внешними субъектами, другие виды связей (в зависимости от специфики организации). Дополнительно может быть указана информация о протоколах, шлюзах, сервисах, требованиях и т. п.

Рис. 3. Модели интеграции ИТ-систем (общий вид, без детализации названий фигур и стрелок)

6. Разработка иерархического реестра (каталога) всех баз данных (структур данных) и их параметров

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

7. Разработка технической архитектуры и дополнительных моделей (в зависимости от задач)

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

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

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

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

В дополнение к технической архитектуре могут разрабатываться другие модели под разные задачи, например в форматах (нотациях): BPMN, ArchiMate, UML. Большое количество примеров содержатся в источниках [1] и [3].

8. Установление связей объектов и моделей ИТ‑архитектуры с объектами и моделями бизнес-архитектуры

Очень важно, чтобы построение и развитие ИТ-архитектуры и бизнес-архитектуры выполнялось внутри одной базы данных и платформы, например Business Studio [4]. Только в таком случае мы сможем быстро и эффективно установить большое количество связей (со стратегией, бизнес-процессами, показателями KPI, организационной структурой), проследить взаимные влияния, оценить функционирование и полноту (целостность) всей корпоративной архитектуры.

9. Проработка операционных рисков (ИТ-рисков) и системы информационной безопасности

Параллельно с этапами 1-8 выполняется идентификация, оценка и проработка рисков. Разрабатываются предупреждающие действия (мероприятия) для минимизации и предотвращения рисков. Подробная информация по этой теме содержится в источнике [5]. Следует отменить, что сейчас и на многие годы вперёд для российских организаций главная задача — это уменьшение зависимости от иностранных производителей программного обеспечения и защита критичной архитектуры от внешних угроз.

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

10. Разработка нормативных документов и форм документов

Все рассмотренные выше этапы (работы) и их результаты должны быть детально документированы, см. [1]. Разрабатываются и актуализируются нормативные документы, например:

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

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

11. Проведение аудита (оценки) ИТ-архитектуры по чек-листу и аналитических работ

Необходимо разработать и заполнить чек-лист с детальными требованиями (более 100). Фрагмент приведён на Рис. 4. Способы оценки требований: наблюдение за работой ИТ-систем и оборудования, наблюдение за работой ИТ-персонала, интервью и опросы сотрудников, изучение документов и отчётов (включая историю значений показателей, историю операционных рисков и др.). На основе проведённого аудита составляется план задач для проработки выявленных недостатков и включается в план развития (оптимизации) ИТ-архитектуры на следующий период (этап 1).

Рис. 4. Фрагмент чек-листа «Диагностика и аудит ИТ-архитектуры организации»

12. Сбор новых требований и задач к автоматизации и цифровизации от подразделений

Требования и задачи к автоматизации формируются непрерывно (практически ежедневно). Они должны быть сгруппированы и ранжированы по приоритетам (важности и срочности). Срочные задачи могут оперативно выполняться в рамках методологий гибкого управления Agile (Scrum, Kanban). Крупные глобальные задачи включаются в план развития ИТ (этап 1).

Рекомендуемая литература и источники информации:

1. Большая библиотека системного аналитика и ИТ-архитектора.
2. Исаев Р. А. ИТ-архитектура организации и система регламентации ИТ-департамента.
3. Исаев Р. А. 60 примеров успешных и проблемных проектов организационного развития.
4. IT Architect: система управления ИТ-архитектурой.
5. Большая библиотека риск-менеджера и специалиста по операционным рискам

Опубликовано по материалам:
https://www.it-world.ru/cionews/business/184573.html

Май 2022 г.

Рекомендуемые материалы по тематике

Best practice проектов автоматизации бизнес-процессов. От методологии до инструментария. Часть 1 — интервью с руководителем консалтинговых проектов «Консист Бизнес Групп» Андреем Кочетковым

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

Цифровой двойник организации: требования, структура, примеры

Подходы к автоматизации

Цель

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

Длительность – 2 часа.

План

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

2. Стратегические цели и задачи предприятия.

3. Бизнес-архитектура предприятия.

4. ИТ-архитектура предприятия:

• информационная архитектура (EIA);

• архитектура прикладных решений (ESA);

• техническая архитектура предприятия (ЕТА).

Краткий конспект лекции

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

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

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

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

Под архитектурой предприятия (Enterprise Architecture, ЕА) обычно понимается полное описание (модель) структуры предприятия как системы, включающее описание ключевых элементов этой системы, связей между ними [Сизов, 2008].

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

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

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

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

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

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

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

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

• разработкой стратегии и планированием на уровне предприятия;

• управлением корпоративными проектами.

Разработка стратегии современного предприятия (Strategy and Planning) и управление корпоративными проектами (Enterprise Program Management) включают направление, связанное непосредственно с информационными технологиями. Современные тенденции рассматривают ИТ-проекты и стратегические инициативы как определенный актив компании, которым можно управлять аналогично финансовым активам.

Управление портфелем информационных технологий (Business and IT Portfolio Management) – это процесс управления инвестициями в области управления ИТ-проектами. Под портфелем понимается совокупность проектов, выполняемых на общем пуле ресурсов (финансы, люди, оборудование, материалы, энергия); при этом пул ресурсов и результаты всех проектов портфеля находятся в компетенции одного центра ответственности.

Аналитики компании МЕТА Group считали, что это – область пересечения архитектуры предприятия, стратегии предприятия и управления корпоративными проектами. Стратегия и планирование при этом обеспечивают основу для выработки ИТ-стратегии предприятия, в соответствии с которой появляются проекты внедрения (модернизации) информационных систем. Управление проектами можно рассматривать, в первую очередь, как механизм, обеспечивающий переход от текущего состояния к планируемому, или, другими словами, переход от текущей архитектуры предприятия к целевой архитектуре [Ермошкин, Тарасов, 2003].

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

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

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

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

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

Текущая архитектура (Current Architecture) описывает существующее состояние архитектуры предприятия. Называется также архитектурой «как есть», или базовым состоянием существующей архитектуры.

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

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

Процесс разработки текущей архитектуры аналогичен процессу ITIL/ITSM (управление конфигурацией – Configuration Management). Для упрощения процесса разработки текущей архитектуры многие компании используют базу данных конфигурационных единиц (CMDB), дополнив ее необходимой информацией.

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

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

• стратегические требования к бизнес-процессам и информационным технологиям;

• информация о выявленных «узких местах» и путях их устранения;

• анализ технологических тенденций и среды бизнес-деятельности предприятия.

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

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

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

• Стратегические цели и задачи предприятия.

• Бизнес-архитектура предприятия.

• Архитектура информационных технологий (ИТ-архитектура предприятия), в том числе:

– информационная архитектура (Enterprise Information Architecture);

– архитектура прикладных решений (Enterprise Solution Architecture);

– технологическая архитектура (Enterprise Technical Architecture).

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

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

• цели и задачи, стоящие перед предприятием;

• бизнес-решения, необходимые для достижения поставленных целей и задач;

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

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

• проекты, которые можно запустить для выполнения бизнес-стратегии;

• варианты решения текущих задач и проблем;

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

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

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

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

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

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

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

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

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

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

Традиционно ИТ-архитектуру предприятия представляют в виде трех взаимосвязанных компонентов:

• Enterprise Information Architecture (EIA) – информационная архитектура;

• Enterprise Solution Architecture (ESA) – архитектура прикладных решений;

• Enterprise Technical Architecture (ETA) – техническая архитектура.

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

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

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

• базы данных и хранилища данных;

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

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

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

Архитектуру прикладных решений разделяют на два направления:

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

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

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

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

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

• взаимодействие с другими системами (интерфейсы) – описывает взаимодействие приложения с внешними объектами (программными продуктами, пользователями).

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

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

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

• информацию об инфраструктуре предприятия;

• системное программное обеспечение (СУБД, системы интеграции);

• стандарты на программно-аппаратные средства;

• средства обеспечения безопасности (программно-аппаратные);

• системы управления инфраструктурой.

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

Литература

Данилин А.В., Слюсаренко А.К Архитектура и стратегия. Инь и янь информационных технологий предприятия. М.: Интернет-университет информационных технологий, 2005.

Ермошкин Н.Н., Тарасов АЛ. Стратегия информационных технологий предприятия. М.: Московский гуманитарный университет, 2003.

Сизов А. В. Разработка архитектуры и модернизация системы управления предприятием. М.: Оверлей, 2008.

CIO Council. A Practical Guide to Federal Enterprise Architecture, 2001.

META Group. Executive Insights. Enterprise Architecture Desk Reference, 2002.

Schekkerman J. How to Survive in the Jungle of Enterprise Architecture Frameworks, TRAFFORD 2003.

Scott A.B. Introduction to Enterprise Architecture; Publisher: authorHOUSE™, 2005.

Контрольные вопросы

1. Что такое архитектура предприятия (Enterprise Architecture)?

2. Зачем нужна архитектура предприятия?

3. Перечислите основные слои архитектуры предприятия.

4. Опишите основные объекты Enterprise Business Architecture.

5. Опишите основные объекты Enterprise Information Architecture.

6. Опишите основные объекты Enterprise Solution Architecture.

7. Опишите основные объекты Enterprise Technical Architecture.

8. Что представляет собой текущая архитектура предприятия – ЕТА?

9. Объясните назначение и сущность архитектурной модели МЕТА Group.

Данный текст является ознакомительным фрагментом.

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

Что такое архитектура информационной системы

Начнем с определения: согласно Федеральному закону РФ от 27.06.2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации», информационная система – это совокупность содержащейся в базах данных информации и обеспечивающих её обработку информационных технологий и технических средств. Проще говоря, под информационной системой (ИС) обычно мы понимаем базу данных и интерфейс работы с ней, который позволяет решать специализированные бизнес-задачи, удовлетворяя потребности пользователя. Причем слово интерфейс здесь имеет общее значение как средство взаимодействия чего-то с чем-то, например, интеракция пользователя с программным обеспечением ПО реализуется через GUI и набор программных интерфейсов (API, Application Programming Interface).

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

• Слой представления – клиентская часть с графическим интерфейсом пользователя (GUI, Graphical User Interface), которая выполняет роль терминала – средства представления данных и отправки команд. Часто этот слой называют frontend.
• Слой бизнес-логики, где происходит обработка команд, полученных от клиента и выполняются основные вычисления. Чаще всего это реализуется в виде серверного приложения (backend). Здесь же располагается система управления базой данных (СУБД) как надстройка над базой данной (БД), которая позволяет обратиться к данным и манипулировать ими, о чем мы писали здесь.
• Слой доступа к данным, т.е. сама БД как хранилище данных в структурированном виде, что в конечном итоге на низком уровне сводится к файлам с записанными данными.

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

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

Поскольку компоненты распределенной системы распределены по разным устройствам (узлам), им необходимо средство взаимодействия друг с другом, т.е. сеть передачи информации. Передача данных по сети выполняется по правилам сетевых протоколов, которые регламентируют вид и формат передаваемых данных. Лучше всего эту идею иллюстрирует 7-ми уровневая модель OSI (Open Systems Interconnection) — модель стека сетевых протоколов OSI/ISO. Она показывает, как разные сетевые устройства могут взаимодействовать друг с другом и определяет различные уровни взаимодействия систем, каждый из которых выполняет при этом специализированные функции. О том, что представляет собой модель OSI, мы поговорим в следующий раз, а пока вернемся к видам распределенной архитектуры.

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

• Файл-серверная – самая примитивная распределенная архитектура, когда слои представления и бизнес-логики находятся на клиенте, а также там реализуется часть вычислений, т.е. операторов по обработке данных. Сервер отвечает только за хранение и управление файлами. Это простое и дешевое с точки зрения реализации решение подходит только ИС, небольших по количеству пользователей, имеет низкую производительность и предполагает передачу по сети огромного объема данных.
• Клиент-серверная, которая делится на 2 подвида:
  • двузвенная – своего рода развитие файл-серверной версии. Она также обеспечивает многопользовательскую работу с данными, но имеет более высокую надежность, т.к. теперь на клиенте находится лишь слой представления и часть слоя бизнес-логики, такая как операторы обращения к СУБД. А другая часть манипулирования с данными, зашитая в СУБД, например, хранимые процедуры (объект БД в виде набора SQL-инструкций, компилируется лишь однажды и хранится на сервере), непосредственное выполнение запросов, обработка транзакций, а также само хранение файлов с данными и управление ими – реализуется на мощном сервере. Это снижает требования к клиентскому узлу, но не устраняет необходимость передачи большого объема данных по сети. Клиент становится тоньше по сравнению с файл-серверной моделью, но это все еще «толстый клиент».
  • трехзвенная – устраняет недостатки двухзвенной архитектуры, располагая каждый из слоев на отдельном узле. Теперь на клиенте находится только пользовательский интерфейс со средствами вывода данных и ввода команд. По сути, клиент превращается в терминал и называется «тонкий клиент». За выполнение вычислений и формирование запросов к СУБД отвечает сервер приложений, а слой доступа к данным в виде СУБД и БД находится на отдельном сервере данных. Таким образом, трехзвенная архитектура устраняет почти все недостатки файл-серверной и клиент-серверной на 2-х звеньях ценой увеличения расходов на администрирование и разработку серверных частей.

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

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

А детально познакомиться с основами архитектуры и интеграции информационных систем вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

• Основы архитектуры и интеграции информационных систем
• Разработка ТЗ на информационную систему по ГОСТ и SRS
• UML для бизнес-аналитика: основы ООП и разработка моделей

Концепция Архитектуры Предприятия

I. Архитектура инфраструктуры

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

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

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

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

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

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

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

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

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

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

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

В традиционном понимании ИТ архитектура разделяется на Enterprise Information Architecture, Enterprise Solution Architecture и Enterprise Technical Architecture, то есть на информационную, техническую архитектуру и архитектуру прикладных решений. Если говорить об информационной инфраструктуре, то это целый набор управляемых методик, которые описывают информационную модель компании. Сюда включены такие компоненты, как базы и хранилища данных, а также информационные потоки. Архитектура решения ИТ – что это? Это архитектура приложений, которая включает в себя различные программные продукты и взаимодействие между ними. Здесь также представлено два направления. Это сфера разработки прикладных систем и портфель различных прикладных систем. Техническая архитектура представляет собой программно-аппаратные средства, а также различные стандарты и методы, которые обеспечивают качественное функционирование различных приложений. Здесь представляется полная инфраструктура предприятия. Это информация об инфраструктуре, СУБД, стандарты на программные и аппаратные средства, средства для управления инфраструктурой и для обеспечения безопасности.

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

Определение ИТ-стратегии и ИТ-архитектуры

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