Материал подготовлен для будущих студентов курса "Archimate".
Используя понятие объекта управления, я пытаюсь разложить понятие управления корпоративной архитектурой на отдельные объекты управления и взаимосвязи между ними. В прошлом материале мы разбирались с объектами управления на уровне бизнес‑архитектуры, теперь переходим на слой информационных технологий. Статья не претендует на полноту, это лишь мое мнение, правда основанное на некотором опыте в этой теме.
Что такое ИТ‑ландшафт
Сначала попробуем определиться с термином ИТ‑ландшафт, который можно часто встретить в публикациях, в самом простом варианте ИТ‑ландшафт — это совокупность всех информационных систем и технологий, которые применяются в организации. Совершенно логично, что ИТ‑ландшафт каждой организации уникален и зависит от её размера, бизнес‑модели, отрасли и принятых ранее решений.
Например, крупный банк с распределённой структурой будет иметь куда более сложный ИТ ландшафт, чем маленькая компания с минимальной автоматизацией. Кстати, в современной практике управление ИТ‑ландшафтом является ключевой задачей корпоративной архитектуры, поэтому давайте разбираться дальше.
Объект управления: приложение
Итак, рассмотрим ИТ‑ландшафт через определение объектов управления, и первым объектом берем информационную систему. Что такое объект управления можно прочитать по ссылке.
Поищем в законодательстве, согласно Федеральному закону РФ № 149-ФЗ «Об информации, информационных технологиях и о защите информации», информационная система — это совокупность содержащейся в базах данных информации и обеспечивающих её обработку информационных технологий и технических средств. Итак, на уровне законодательства под информационной системой понимается фактически часть ИТ‑ландшафта, тут все, и устройства, и развернутое на них программное обеспечение, и данные которые обрабатываются.
Заглянем в спецификацию языка ArchiMate, в ней можно увидеть слой приложений, который позволяет моделировать прикладные системы и приложения, которые поддерживают бизнес‑процессы, их функциональность и взаимосвязи. Отдельно в спецификации определяется компонент приложения, как инкапсуляция функциональности приложения, обусловленная структурой реализации, при этом структура реализации является модульной, и модули могут заменяться.
Поискав еще на просторах интернета мне больше всего приглянулось такое определение приложения — это программное обеспечение (от себя добавлю, что оно должно быть развернуто на ИТ‑инфраструктуре), предоставляющее ИТ‑функции, необходимые для предоставления ИТ‑ услуги.
Для того, чтобы не противоречить законодательству, можно внутри компании вместо термина информационная система применять термин автоматизированная система, или приложение. В рамках данной статьи предлагаю считать синонимами понятия информационной системы, автоматизированной системы и приложения.
В результате я использую следующее определение — приложение — это объект управления в ИТ‑ландшафте, представляющий собой набор программного обеспечения, развернутого на ИТ‑инфраструктуре, реализующего логически связанный набор ИТ‑функций. Не беспокойтесь, определения программного обеспечения и ИТ‑функции будет дано позже.
С учетом того, что приложение, например, 1С, может быть достаточно масштабным практикуется иерархическая декомпозиция приложения на подсистемы, модули и далее, что, кстати, также должно быть зафиксировано в реестре приложений, о котором мы и поговорим далее.
Реестр приложений
С учетом того, что приложений в крупной организации может быть множество, этим «хозяйством» нужно как‑то управлять, и для начала нужно обеспечить их учет в едином реестре, и даже электронные таблицы на начальном этапе подойдут. В этом реестре приложений у каждой записи есть множество атрибутов, например, ответственный за приложение, статус приложения (целевое или нет), и другие атрибуты, рассмотрение которых тянет на отдельную статью.
С учетом того, что в таком реестре крупной организации может быть несколько сотен приложений, то нужно их разложить по «полочкам», как для удобства поиска, так и для аналитических задач, то есть нужен классификатор приложений.
При том, что приложения имеют различную функциональность, логично распределить их по функциональным доменам, что бы выделенный корпоративный архитектор «надзирал» за набором приложений близких по функциональности. И да, классификаторов приложений может быть несколько в организации, каждый под свои задачи.
Теперь про целевой ИТ‑ландшафт в части приложений
Исходя из общего понимания термина управления, можно предположить, что управление ИТ‑ландшафтом подразумевает определение его текущего состояния, формирование целевого состояния, и далее на основании выявленных разрывов между целевым и текущим состоянием, определение плана перехода из текущего состояния в целевое.
Вспоминается фраза одного из руководителей департамента корпоративной архитектуры, что плох тот корпоративный архитектор, который не создал целевой ИТ‑ландшафт. Переход к целевому ИТ‑ландшафту в части приложений — это стратегическое изменение, которое вызвано множеством внешних и внутренних факторов, которые мы назовем драйверами изменения.
Для начала определимся с драйверами изменений для приложений, и в первую очередь это бизнес‑требования в части необходимости автоматизации новых функциональных областей. Помимо этого, бизнес часто хочет сократить время внесения изменений в приложения, или снизать затраты на поддержку приложений.
Драйверами могут быть и законодательные требования, например, запрет к использованию отечественного программного обеспечения. Драйвера могут рождаться и внутри организации, например, необходимость отказа от приложений, построенных на устаревших технологиях.
С учетом всех драйверов, влияющих на ИТ‑ландшафт, для каждого приложения определяется его будущее в организации — целевое приложение или нет, при этом может быть определена крайняя дата отказа от приложения. И да, это упрощенный взгляд, на практике нужно анализировать существующие взаимные зависимости, как на уроне приложений, так и между приложениями и объектами бизнес‑архитектуры, а также технической архитектуры.
Объект управления: программное обеспечение
Пришло время определить следующий объект управления — программное обеспечение. В одном из стандартов можно встретить, что это совокупность программ системы обработки информации и документов, необходимых для эксплуатации этих программ.
В отличие от приложения, которое развернуто на ИТ инфраструктуре и предоставляет пользователям функциональность, программное обеспечение — это то, на основании чего создается приложение. В самом простом случае, это может быть та‑же самая 1С, которая при инсталляции и запуске внутри компании становится приложением. Но если мы в организации собираем приложение из разных компонентов, то программным обеспечением станет каждый отдельный компонент, например, оркестратор процесса, база данных и так далее.
Возникает логичный вопрос, что, если мы управляем приложениями, зачем нам управлять программным обеспечением, собирая его в реестр, и назначая ответственных. Все просто, причиной внимания к этому объекту ИТ‑ландшафта стало импортозамещение в рамках которого нужно определить для всего программного обеспечения, применяемого в организации возможность и условия его использования.
И кстати, от объекта программное обеспечения можно и нужно протянуть связь к еще одному объекту управления — лицензиям на программное обеспечение, но этот объект я оставлю за рамками данного материала.
Про единый реестр российских программ для электронных вычислительных машин и баз данных я не буду здесь расписывать, но если используемого программного обеспечения нет в этом реестре и данное ПО не является свободно‑распространяемыми с открытым исходным кодом, то для некоторых организаций это может стать существенной проблемой.
Объект управления: ИТ‑функция
По‑хорошему, приложение — это контейнер для ИТ‑функций, предоставляемых пользователю или другим приложениям. Для аналогии, я часто сравниваю приложение с подразделением, которое в организации предоставляет определенный перечень функций для потребителей. Что бы избежать дублирования функций в подразделениях в HR подразделении часто используется организационно‑функциональная модель, аналогичный подход можно использовать и в ИТ.
Заглянем в спецификацию ArchiMate, там зафиксировано, что функция приложения (ИТ‑функция) — это автоматизированное поведение, которое может осуществляться компонентом приложения.
Избежать дублирования функционала в разных приложениях можно, если создать реестр ИТ‑функций и связать его с приложениями, подсистемами или модулями, тогда станет «видно», что одна ИТ‑функция была реализована в нескольких приложениях, что показывает дублирование, а значит требует дополнительного анализа и решений.
ИТ‑функция в качестве объекта управления, может быть полезна и для понимания какая функциональность приложения востребована потребителями, а какая нет. Может быть кто‑то помнит SAP Transaction Monitor, в котором можно было понять востребованность тех или иных функций SAP.
Объект управления: ИТ‑услуга
Наведя резкость на приложения, программное обеспечение и ИТ‑функции, мы совсем забыли про ITSM, где Service (Услуга) — это средство доставки ценности клиентам путём содействия достижению желаемых результатов. По мне так слишком общее определение, поэтому поищем еще определение ИТ‑услуги (сервиса).
Я еще нашел такое определение — ИТ‑услуга (информационно‑технологическая услуга) — это услуга, предоставляемая организациям для поддержки информационных технологий и ИТ‑инфраструктуры, при этом ИТ‑услуги могут охватывать различные аспекты ИТ, включая разработку программного обеспечения, облачные сервисы, сетевую инфраструктуру, безопасность информации, техническую поддержку �� многое другое. Фактически ИТ‑услуга это то, что предоставляется клиенту, вспомнился каталог ИТ‑услуг, соглашение об уровне сервиса и другие артефакты ITIL.
Посмотрим, что про услугу написано в ArchiMate — сервис приложения (можно сказать, что ИТ‑услуга) — это явно определенное, представляемое вовне поведение приложения. Бинго! То есть ИТ‑услуга — это набор одной или более ИТ‑функций, которые используются потребителями.
Может ли приложение предоставлять несколько ИТ‑услуг? Да конечно, ИТ‑услуга — это самый «мягкий» объект управления корпоративной архитектуры с точки зрения границ, и если есть у нас потребитель или скорее группа потребителей, то мы можем сделать для них специализированную ИТ‑услугу, с процессом подключения к ней, согласованным уровнем сервиса, поддержкой и тарификацией, поэтому можно связать ИТ‑услугу либо с ИТ‑функциями, если они определены, либо с приложением или его частью которое обеспечивают именно эту ИТ‑услугу. Т.е. ИТ‑услуга может предоставляться приложением, его подсистемой или даже модулем.
В качестве заключения хочу отметить, что объектов управления в ИТ‑ландшафте сильно больше, но надеюсь, что данная статья хоть немного приоткрыла для вас эту тему.
Курс по ArchiMate от Отус как раз про то, как связать требования бизнеса, приложения и технологический слой в единую модель, чтобы видеть зависимости, узкие места и путь к целевому состоянию не на уровне интуиции, а предметно. Перед тем как идти на курс: 10–15 минут входного теста дадут понимание уровня и рекомендации по темам. Пройти тест
Для знакомства с форматом обучения и экспертами приходите на бесплатные уроки:
1 апреля в 19:00. «ArchiMate: как быстро собрать понятную схему и не утонуть в настройках». Записаться
14 апреля в 19:00. «Архитектурный контроль в ArchiMate: как перестать рисовать схемы и начать управлять изменениями через репозиторий». Записаться
