Что такое корпоративная архитектура и зачем она ИТ-службе

Зачем управление корпоративной архитектурой

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

ITIL перечисляет уровни, на которых работает практика: архитектура бизнеса, архитектура продуктов и услугУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation, архитектура информационных систем вместе с данными и приложениями, технологическая архитектура и архитектура среды 1. Разброс уровней объясняет, почему в двух соседних компаниях под словом «архитектор» понимают разных людей.

У практики три задачи 1:

• текущая архитектура понята и сопоставлена со стратегией;
• целевая архитектура определена и согласована;
• организация постоянно движется от первой ко второй.

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

Когда практика работает

Три вопроса, ответы на которые видны по тому, как принимаются решения о новых системах.

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

Есть согласованная картина того, куда идём. Как проверить: целевое устройство описано и пересматривается, когда меняется стратегия 1.

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

Что входит и что рядом

Архитектура и учёт конфигураций: карта и фотография

В разговоре эти два понятия сливаются, а в работе они смотрят в разные стороны во времени.

Учёт конфигураций отвечает на вопрос «что стоит сейчас»: элементы, версии, связи, состояния. Это фотография.

Архитектура отвечает на вопросы «как это устроено по замыслу» и «как должно быть устроено через три года». Это карта и маршрут.

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

Что на входе и что на выходе

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

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

Важнее обратный ход. Без правил, дошедших до проектирования, изменений и закупок, архитектура остаётся картинкой в презентации.

Целевая архитектура и путь к ней

Целевая архитектура и дорожная карта работают только вместе 1.

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

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

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

Отдельная беда — наследие: старые решения могут долго сосуществовать с новыми, и переход всегда подчинён решениям по портфелю и расстановке приоритетов 1. Это отрезвляющая мысль для планов вида «за год всё переведём».

Как это работает

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

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение

Две строки этой таблицы стоит развернуть.

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

Пятый шаг встроен в чужие потоки. Практика участвует в каждом потоке создания ценностиПоток создания ценностиПоследовательность шагов, которыми организация создаёт и доставляет услугу потребителю.ITIL 4, книга ITIL Foundation, где появляются новые части, новые сторонние услуги или изменения, затрагивающие устройство 1. То есть контроль живёт не на отдельном совещании, а внутри проектирования и изменений.

Что с чем путают

Архитектура и проектирование услуги. Архитектура задаёт правила и целевое устройство для всех; проектирование применяет их к конкретной услуге 1.

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

Целевая архитектура и план закупок. План закупок — следствие. Целевая картина отвечает на вопрос, почему покупаем именно это и что оно заменяет.

Архитектор и главный инженер. От архитектора ждут владения архитектурными сводами; ITIL называет TOGAF и Zachman 1. Это отдельная профессия со своим языком, а не старший системный администратор.

Кто участвует

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

Как измерять

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

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

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

Второму условию служат три 1:

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

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

У каждого показателя два измерения: число и последствия. ITIL 4 почти нигде не пишет просто «число» — почти везде «число и последствия» 1. Для архитектуры разница велика: десять мелких отступлений от целевой картины и одно, из-за которого две системы больше не могут обмениваться данными, — в счётчике неразличимы, а по последствиям это разные годы работы.

Зрелость управления архитектурой

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Есть только текущая картина. Схемы того, что стоит, нарисованы; куда идём — не описано.

Целевая картина устарела вместе со стратегией. ITIL прямо требует пересматривать её, когда меняется стратегия 1.

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

Контроль стоит после закупки. Архитектора зовут, когда договор подписан, и остаётся только объяснить, почему теперь так.

Дорожную карту не финансируют. Начинания описаны, денег и очереди под них нет — переход подчинён решениям по портфелю 1.

Наследие игнорируют. План предполагает, что старые системы исчезнут сами; на деле они сосуществуют с новыми годами 1.

Что говорят своды

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

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

TOGAF, ArchiMate и Zachman описывают предмет несравнимо подробнее, и ITIL прямо отсылает к ним как к ожидаемой квалификации архитектора 1. Все три разобраны у нас: TOGAF — как строят архитектуру по шагам, ArchiMate — на каком языке её рисуют, Zachman — как раскладывают описание по клеткам.

ГОСТ Р ИСО/МЭК 20000-1 отдельного требования к архитектуре не содержит: он говорит о планировании и проектировании сервисов 2.

COBIT выделяет управление архитектурой отдельной целью домена согласования и планирования 3.

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

Где описано

Что почитать дальше

Три соседние практики, с которыми архитектура работает вплотную: SDSПроектирование услуги — где правила превращаются в замысел услуги, PRTУправление портфелем — где решают, какие начинания финансировать, CHNКонтроль изменений — где проверяют, что изменение не ломает устройство.