Как и во многих компаниях средних размеров, в нашей организации в какой-то момент осознали, что имеющиеся ИТ-системы стали сильно бить по бюджету и ситуацию пора взять под контроль. У нас было без малого тысяча приложений (в основном уровня отделов), в том числе несколько сотен разработанных на базе проектов с открытым кодом, и два-три десятка таких, в создание которых вложили по несколько миллионов.
Из-за отсутствия систематизированного планирования архитектуры сложилась знакомая многим ситуация, когда ИТ-среда превратилась в «спагетти»: ее было сложно сопровождать, а управлять ею – еще сложнее. Поэтому в организации решили учредить должность архитектора предприятия. На эту должность назначили меня.
Не имея соответствующего опыта, я решил заняться самообучением. Единственная подходящая книга, попавшаяся мне, называлась «Архитектура предприятия как стратегия», но она была написана с расчетом на высокий уровень организационной зрелости и активное вовлечение членов высшего руководства. Кроме того, стандарты корпоративной архитектуры оказались чересчур сложными и давали мало практических рекомендаций. Даже звонок в одну из ведущих консалтинговых компаний мало что добавил – удалось выяснить только стандартные описания должностей сотрудников отдела по корпоративной архитектуре, который у нас состоял только из меня.
Выходило, что на реализацию традиционных стандартов архитектуры предприятия потребуется немало времени и серьезные ресурсы, а в нашем случае их не хватало. Но сдаваться было нельзя. Проблемы были налицо, и их надо было решать.
Пришлось разобраться в сложившейся у нас ситуации – подтвердилось наличие массы изолированных узкоспециальных решений с существенным объемом дублирующейся функциональности.
Стало ясно: потребуется система норм в качестве опоры для принятия решений. Поэтому был разработан и опубликован набор архитектурных принципов, уместившийся на четырех страницах. Многие из этих принципов были очевидными – например, «применение корпоративных решений и технологических стандартов» и «многократное использование, позволяющее избежать дублирования и чрезмерной технической сложности».
Затем пришлось выяснить, нельзя ли внедрить какую-то поддерживающую среду, чтобы эти принципы не остались только на бумаге. Мы пришли к выводу, что понадобится платформа интеграции приложений на основе сервис-ориентированной архитектуры (с сервисной шиной предприятия, реестром, сервисами управления API, аутентификации и т. п.). Такая платформа позволила бы строить приложения, работающие с единым набором совместно используемых сервисов и источников данных.
С технической точки зрения стояла задача избавиться от чрезмерной сложности на уровне отдельных приложений, а с точки зрения бизнеса – снизить затраты и ускорить выпуск новых приложений.
Чтобы избежать длительного формального процесса закупки платформы интеграции приложений, который мог бы занять год, вручную провели сравнительную оценку доступных платформ с открытым кодом и выбрали ту, которая удовлетворяла нашим требованиям и сопровождалась коммерческими услугами поддержки.
Мы воспользовались этими услугами и привлекли внешних технических консультантов, стремясь ускорить сборку среды. В результате за полгода мы получили стабильную платформу и построили на ее основе ряд прототипов. К примеру, мы продемонстрировали начальству несложное приложение для запроса, утверждения и учета командировок, которое через платформу работало с данными планирования, бухгалтерии и отчетов, хранимыми в трех разных, сложных в программировании системах.
После строительства платформы нужно было решить вопрос с получением поддержки со стороны бизнес-отделов, владеющих основными ИТ-системами, особенно теми, которые работали независимо от остальных. В сложных переговорах с бизнесом нам помогли бы внешние консультанты, выступающие в роли нейтральных посредников. Поэтому мы наняли независимого архитектора предприятия, он провел ревизию архитектуры наших основных систем и порекомендовал дальнейшие действия.
Затем прошла серия семинаров, на них мы пригласили представителей бизнес-подразделений. Так мы выяснили, какие вопросы волнуют бизнес, и выявили ряд непредвиденных приоритетных задач: например, оказалось, что нам нужна система управления справочной информацией.
После детального знакомства с проблемой «спагетти» в бизнес-подразделениях признали необходимость перемен. Составленный итоговый отчет получил полную поддержку руководства, началось планирование реализации.
Как признали сами бизнес-руководители, отсутствие согласованной ИТ-архитектуры было серьезной помехой на протяжении двадцати с лишним лет. Мы настолько полно осветили ситуацию для заинтересованных лиц, что руководителям не оставалось ничего, кроме как дать добро на перемены. Обошлось без формирования начальственных комитетов и внедрения сложных архитектурных каркасов.
ИТ-службе в организации стали больше доверять, и сейчас именно к нам обращаются, когда речь заходит о новых переменах.
Означает ли это, что можно сдуть пыль с моей копии «Архитектуры предприятия как стратегии» и записаться на учебный курс по стандарту TOGAF или фреймворку Захмана? Нет, ведь нам необходимо идти дальше. После внедрения базовой среды для предоставления корпоративных ИТ-сервисов мы сформировали отдел по цифровой стратегии, который будет развивать платформенный подход и пропагандировать реализацию основанных на ИТ проектов в развивающихся странах. А это значит, что ИТ будут вносить больший вклад в деятельность миссии ООН по борьбе с голодом во всем мире.
Для меня же «цифровая стратегия» стала новым витком развития архитектуры предприятия, более понятным для бизнеса благодаря отсутствию всех этих пугающих аббревиатур из мира ИТ, а потому пользующимся большей поддержкой.
– Paul Whimpenny, Senior Officer for Digital Strategy in the IT Division of the Food and Agriculture Organization of the United Nations. A pragmatic approach to Enterprise Architecture. Network World. October 4, 2016