Управление архитектурой предприятия в контексте TOGAF по алгоритму ADM

Цель работы – провести анализ особенностей построения архитектуры предприятия в соответствии с методики TOGAF.

В последних версиях методологии была включена предметная область архитектуры бизнеса в результате чего, методология обрела своих сподвижников. Когда в методологию TOGAF была включена бизнес-архитектура, и с учетом того, что она уже имела лучшую технологическую основу в виде собственных предметных областей, это способствовало дальнейшему росту ее популярности, в отличие от других инфраструктур, не имеющих в проектах архитектуры технологии.
Концепция Захмана, Спивака и других участников этого подхода с высоким уровнем абстракции при проектировании архитектуры предприятия не смогла получить поддержку технического сообщества.
Архитектура предприятия в модели TOGAF подразделяется на следующие блоки [5]:
1. Бизнес-архитектура. Описывает организационную структуру, бизнес-процессы и деятельность организации с учетом установленных показателей эффективности.
2. Информационная архитектура. Определяет информационные потоки процессов организации, методов сбора, обработки, предоставления и хранения информации.
3. Архитектура приложений. Определяет, какие приложения используются и должны использоваться для управления данными и поддержки бизнес-функций, и реализует объекты информационной архитектуры в прикладных системах.
4. Техническая архитектура. Определяет, какие аппаратные и программные средства необходимы для обеспечения работоспособности всего конгломерата прикладных систем в соответствии с операционными требованиями (надежность, производительность и т. п.).
Еще одним методом развития архитектуры TOGAF является метод разработки архитектуры (Architecture Development Method, ADM) – описывающий шаг за шагом подход к разработке архитектуры предприятия для удовлетворения бизнеса и ИТ-потребности организации [6].
Особенность модели TOGAF заключается в том, что предприятие рассматривается как континуум архитектур (Enterprise Continuum) [6], состоящий из набора готовых моделей, которые максимально обобщены и сгруппированы по уникальным или специальным направлениям (рис. 2). Процесс создания архитектуры предприятия рассматривается как переход от общей архитектуры к специализированной, что дает методика разработки архитектуры в модели TOGAF.
Благодаря использованию наиболее обобщенных архитектур (фундаментальных) в модели TOGAF теоретически построение архитектуры предприятия могут использовать практически любые ИТ-организации в мире.
Следующий уровень специализации в модели TOGAF представлен общесистемными архитектурами, принципы которых прослеживаются во многих предприятиях, но не ко всем применимы. Предприятия, ведущие свою деятельность в узкой моносфере, представлены в модели TOGAF отраслевыми архитектурами. Самый высокий уровень специализации в модели TOGAF называется архитектурами организаций, к ним относят архитектуры отдельных предприятий, которые невозможно классифицировать ни по одному из видов архитектур.
Модель TOGAF подразумевает, что континуум предприятия действует как коллекция компоновочных блоков (шаблонов), которая предоставляет коллективам, занимающимся архитектурой предприятия, соответствующие архитектуры, модели и процессы, из которых можно собирать готовые решения. Континуум предприятия является накопителем таких ресурсов, как модели, шаблоны решений и другие активы, которые могут использоваться как компоновочные блоки на всем процессе реализации и адаптации архитектуры предприятия.
Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Поскольку эта интеграционная архитектура сильно зависит от принимаемых решений в остальных областях, то в рамках TOGAF в необходимой степени рассматриваются и эти смежные области.
Метод разработки архитектуры TOGAF (ADM) предоставляет законченный набор инструкций для реализации и выполнения архитектуры предприятия в организации. Этот процесс состоит из нескольких последовательных фаз, замкнутых в цикл. Несмотря на большую проработанность данной методологии по сравнению с моделью Захмана, надо понимать, что подход TOGAF имеет и ряд недостатков.
Метод ADM не является законченным процессом; это инфраструктура, которая для каждой организации требует адаптации. Руководство предприятия не всегда готово к знакомым им процессам добавить что-то кардинально новое или полностью заменить их на модели и процессы новой инфраструктуры. Архитектурный подход к построению ИС по модели TOGAF получил развитие на предприятиях различных отраслей промышленности, как один из эффективных инструментов повышения качества управления с привлечением оптимизированной ИТ-инфраструктурой.
В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана.
Общая структура TOGAF показана на рис. 1.1.

Рассматривается применение архитектурного подхода к развитию информационной системы организации. Рассмотрена концепция архитектурного подхода, методологии разработки архитектуры предприятия «сверху-вниз» и «снизу-вверх», определены преимущества и недостатки этих подходов. Рассмотрено применение методологии TOGAF к построению архитектуры предприятия, нацеленной на достижение поставленных стратегических целей при поддержке оптимизированной информационно-коммуникационной инфраструктуры, особенности модели применения данной модели. Установлена применимость архитектурного подхода к развитию информационной системы крупного предприятия с развитой филиальной сетью.
Постановка бизнес-требований к деятельности компании невозможна без детального представления о ней. Этой цели служит бизнес-моделирование. Структура бизнес-модели предложенная Александром Остервальдером позволяет получить представления о бизнес-миссии объекта исследования и выявить основные заинтересованные лица и ресурсы для реализации бизнес-стратегии. В стандартах TOGAF и методе ADM этап бизнес-анализа осуществляется на «Предварительной фазе», визуализация на графическом языке ArchiMate заключается в проектировании бизнес-модели Остервальдера.
Выявление заинтересованных лиц и факторов, влияющих на состояние их удовлетворенности с помощью бизнес-модели, позволяет перейти к постановке бизнес-требований стейкхолдеров (визуализация ArchiMate -Мотивационное расширение, Фаза А «Видение архитектуры» в ADM).
Эти требования, применительно к объекту исследования заключаются в следующем:
- внедрить элементы электронного маркетинга в работе с клиентами на территории РФ (онлайн-рассылка, электронный каталог);
- автоматизировать все процессы, которые могут быть автоматизированны;
- добавить элементы электронной коммерции в существующие сервисы (сервис самостоятельного размещения и отслеживания исполнениям заказов);
- автоматизировать учет логистических затрат;
- внедрить системы отчетности и контроля над сотрудниками отдела продаж и дилерами (мониторинг телефонной активности, трейкинг служебного транспорта);
организовать оперативный мониторинг взаиморасчётов с дебиторами.
На данном этапе исследования открытым остается вопрос как именно реализовывать поставленные требования. Становится очевидным, что без анализа «внутреннего устройства» операционной деятельности Сбытовой Компании и внутренних бизнес-процессов невозможно выявить «узкие места» и разработать требования к поддерживающей инфраструктуре ликвидирующие их.