Построение ИТ-архитектуры предприятия

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

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

IT-архитекторов в российских вузах не готовят, такие специалисты «вырастают», в основном, из инженеров и системных администраторов. Получить востребованные знания в сфере моделирования архитектуры IT и предприятия, включая популярный графический язык Archimate, разработанный специально для моделирования архитектуры сможете, отправив заявку на обучение в CORS Academy на уникальный курс «Моделирование архитектуры IT и предприятия. Archimate».

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

Концепция архитектуры предприятия появилась еще в 1987 году. До этого термин «архитектура» уже применялся в информационных технологиях, но в контексте аппаратных и программно-аппаратных комплексов.

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

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

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

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

· Фреймворк Захмана – первый и самый известный фреймворк.

· FEAF - разработанный в США для правительственных нужд фреймворк.

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

· EAF- фреймворк, разработанный на основе TOGAF компанией SAP.

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

Методология архитектуры предприятия

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

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

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

К общим компонентам архитектуры предприятия относятся миссия, стратегия, функции, организационная структура, бизнес-процессы, проекты, инфраструктура, информационная система.

Миссия — определяет видение способа получения эффективных результатов деятельности предприятия.

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

Функции — определенный набор действий предприятия для получения качественного продукта.

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

Бизнес-процессы — модель действий по созданию продукта, его поставке и реализации.

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

Инфраструктура — материальные и нематериальные элементы, используемые для реализации бизнес-процессов.

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

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

Цель и задачи архитектуры предприятия

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

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

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

Если приложения и технологии подключаются только на последнем шаге, то что же в этом такого сложного? И как архитектор влияет на деятельность компании?

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

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

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

А желтым – объекты, относящиеся к технологиям.

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

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

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

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

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

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

Суммируем эти цели архитектуры предприятия. Что достигает компания, используя архитектуру?

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

При этом учитывается ИТ-стратегия компании и возможные инвестиции.

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

Зоны работы архитектора

Давайте рассмотрим четыре типичные сферы деятельности предприятия.

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

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

Третье направление – это управление информационными технологиями.

И четвертое направление – это оптимизация процессов и синхронизация требований бизнеса и возможностей информационных технологий.

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

Рассмотрим работу архитектора применительно ко всем этим четырем направлениям деятельности.

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

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

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

Например, сейчас очень актуальна RPA (Robotic process automation), это одна из технологий автоматизации бизнес-процессов. Роботизацию применяют для рутинных задач, которые выполняются четко по инструкции (алгоритму). Это позволяет повысить скорость обработки информации, снизить частоту ошибок, связанных с человеческим фактором — например, с невнимательностью при переносе данных.

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

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

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

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

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

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

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

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

Разработка инноваций – это процесс с определенными этапами.

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

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

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

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

То есть достигаем мы пика при принятии решения, как именно мы будем действовать.

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

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

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

Если у нас нет единой цели, мы не сможем ничего согласовать. После этого у нас возникает Заявка на архитектуру (Statement of Architecture Act). Эта заявка определяет объем работ, а также роли и ответственность за принятие решения в рамках этих работ.

В отличие от Матрицы заинтересованных сторон (Stakeholder Matrix), она описывает все предприятие в целом, кто за что отвечает, а в заявке на архитектурные работы мы уже перечисляем только тех лиц, которые будут принимать участие в данном конкретном проекте.

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

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

Диаграмма распределения ПО (Software Distribution Diagram) определяет конкретные приложения и среды, на которых будет выполнена реализация. И в конце, итогом работы является Архитектурный план работ (Architecture Roadmap). Это поэтапный план перехода от текущего состояния к целевому.

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

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

Узнать подробнее, что еще хотят заказчики от архитектора, а также изучить нотацию языка ArchiMate 3.2 и возможности его широкого применения для моделирования архитектуры предприятия и IT- архитектуры сможете,записавшись на обучение в CORS Academy.

На курсе вас научат:

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

© Илья Отькало

Подписывайтесь:

Канал руководителей IT компаний и подразделений, CIO, СDO, CDTO https://t.me/cio_channel

CIO. Сообщество IT руководителей https://vk.com/cio_club

информационно-развлекательные каналы GoodIT:

ВКонтакте: https://vk.com/goodit_channel

0
Комментарии
-3 комментариев
Раскрывать всегда