Когда проектный коллектив, вооруженный Rational Unified Process от IBM (RUP), получает проектное задание или требования определенного пользователя, то на пути к решению среди прочих артефактов проекта создаются бизнес-прецедент, документ "Видение" и спецификация требований к программному обеспечению. Эти промежуточные продукты и создающие их деятельности хорошо знают и в техническом, и в бизнес-сообществе. Однако способы, которые используются для концептуализации, расстановки приоритетов и выбора значимых для реализации в программе бизнес-проблем и пользователей, представляют собой весьма вариативные процессы в пределах отрасли. В этой статье рассматриваются степень зрелости и нарастающая важность роли инфраструктуры архитектуры предприятия для современных организаций разработчиков. Статья начинается сравнением дисциплины архитектуры предприятия с дисциплинами архитектуры решений и бизнес-архитектуры, по отношению к IBM Rational (RUP). Далее рассматривается, как инфраструктура Open Group Architecture Framework (TOGAF) выгодно расширяет границы архитектуры, установленные RUP, чтобы включить в процесс планирование бизнеса корпорации, ИТ-планирование, управление реализацией и другие виды деятельности. В завершение будет предложен способ применения TOGAF в сочетании с другими инфраструктурами архитектуры предприятия.
Сравнение различных архитектурных инфраструктур
Существует некоторое наложение областей действия между инфраструктурами разработки архитектуры предприятий, решений и бизнеса, в общепринятом их понимании. Итак, как они соотносятся между собой?
Инфраструктура архитектуры решений принимает различные формы. Специалисты по информационным технологиям уже привыкли иметь дело с Приложениями (Application), Данными (Data), Технологиями (Technology) и другими архитектурными формами (называемымм также предметными областями) в процессе разработки информационных систем и обслуживания проектов. Новые (и значительно более специализированные) формы архитектуры решений, такие, как Безопасность (Security) и Тестирование (Testin), тоже быстро стали основными формами. Наиболее узнаваемые предметные области архитектуры решений, их основные объекты и зависимости между ними показаны на рисунке 1.
Рисунок 1: Предметные области и объекты дисциплины архитектуры решений
Все предметные области архитектуры решений, показанные на рисунке 1, считаются "техническими", поскольку область их применения включает различные элементы технологии, такие, как программное обеспечение, данные и инфраструктура информационных технологий. С этими предметными областями обычно приходится иметь дело технологам - то есть, людям, которые имеют опыт в разработке систем, или администраторам в сфере ИТ.
Архитектура бизнеса как отдельная предметная область появилась в 1990-е годы, когда многие организации утвердили должность архитектора бизнеса, пытаясь оптимизировать свои бизнес-процессы.
Дисциплина "архитектура бизнеса" считается "относящейся к бизнесу"; она описывает, как он работает. Хотя вряд ли можно достичь согласия по поводу того, какие компоненты следует включить в инфраструктуру архитектуры бизнеса, принято считать, что значимыми аспектами в этой предметной области являются аспекты Процесс и Информация (Process and Information), Организация (Organization) и Производительность (Performance). Каждый из этих компонентов сам по себе очень важен и включает несколько предметных областей, как показано на рисунке 2.
Рисунок 2: компоненты и объекты предметной области архитектуры бизнеса
Компонент Процесс и Информация, вероятно, является основным для деятельностей архитектуры бизнеса, поскольку (среди прочего) он определяет, описывает и классифицирует бизнес-процессы и опорные структуры, которые составляют бизнес-модель организации. Этот компонент включает также группу связанных объектов, таких, как удобство применения и доступность. У каждой организации, конечно, есть различные бизнес-процессы, структуры, технологические потоки и т. д. Точно так же какая-либо организация может иметь что-то особенное в своей модели бизнес-процесса, то, что поднимает ее над конкуренцией, в то время как другие организации продолжают вести борьбу в этой отрасли.
Компонент Организация относится к структуре и конструированию методов работы, а также к стилю работы в организации. Объекты, которые взаимодействуют с этим компонентом, включают структуру организации, продукты и услуги, которые производит бизнес, бизнес-единицы их размещение и т. д.
Производительность бизнеса - это компонент, связанный с управлением, объединяющий объекты, которые определяют и измеряют эффективность организации. В него входят такие объекты, как производительность, бизнес-риски и другие связанные объекты.
Предметная область архитектуры предприятия
Прежде чем перейти к рассмотрению корпоративной архитектуры, давайте обрисуем проблему, которую эта дисциплина пытается решить. Большинство существующих методологий реализации включают методы создания решений для хорошо известных потребностей бизнеса. Эти методики, однако, не интересуются тем, как и почему появились эти потребности. Вместо этого они концентрируются на сравнительной важности удовлетворения данной потребности по сравнению с другими потребностями, которые может иметь организация. Для примера рассмотрим процесс RUP. Процесс представления RUP принимает решение о реализации в значительной степени на веру, причем ни один артефакт RUP прямо не связан с оценкой относительности срочности требования бизнеса, которая делается в процессе реализации решения.
В отличие от RUP и других дисциплин, которые концентрируются, главным образом, на реализации, основным интересом предметной области архитектуры предприятия является само предприятие - идентификация, спецификация и расстановка приоритетов требований бизнеса. Рассмотренные точки зрения и модели, взятые в контексте инфраструктуры архитектуры предприятия, решают определенный круг текущих и потенциальных проблем.
План-график архитектуры предприятия чаще всего содержит более одного предлагаемого решения (как показано на рисунке 3), в результате чего может возникнуть несколько одновременных реализаций.
Рисунок 3: Пример плана-графика архитектуры предприятия
Институт разработки архитектуры предприятий (Institute for Enterprise Architecture Development, IFEAD) обобщает основные руководящие принципы дисциплины архитектуры предприятия следующим образом: "Нет стратегических прогнозов - нет архитектуры предприятия." Другими словами, архитектура предприятия сегодня - это система бизнеса завтра. Важный аспект этого утверждения заключается в том, что архитектура предприятия - это целостная дисциплина, которая объединяет элементы бизнеса и технологии, исходя из общего стратегического прогноза предприятия (см. рисунок 4).
Рисунок 4: Элементы предметной области архитектуры предприятия
Хотя концепции архитектуры предприятия в ходу уже более двух десятилетий, дисциплина "Архитектура предприятия" появилась недавно. Это можно объяснить ускорением изменений рабочей среды в организациях всех размеров в большинстве отраслей. Конструктивность бизнеса и, в частности, способность инфраструктуры технологий своевременно реагировать на изменения, стали критически важными факторами.
Еще одним фактором, который способствовал растущему пониманию дисциплины архитектуры предприятия, был все более ужесточающийся законодательный климат последних лет, как в США, так и в других странах. Это заставило организации не только повысить ответственность и усовершенствовать методы отчетности, но также сделать соответствие законодательным требованиям жизненно важным требованием для каждого бизнес-процесса.
В ответ на повышение внимания к принципам архитектуры предприятия в последнее время появились надежные инфраструктуры архитектуры предприятий, такие, как TOGAF.
Те же объекты, но с другой точки зрения
Дисциплина архитектуры предприятия касается практически тех же объектов, что и дисциплина архитектуры решений, но в несколько другом разрезе и в совершенно другом контексте. Контекст архитектуры предприятия целостный, его перспектива организационная, тогда как архитектура решений зависит от реализации.
К тому же дисциплина архитектуры предприятия - это больше, чем супернабор предметных областей архитектуры решений. В то время как объекты архитектуры решений (см. рисунок 1) предназначены для применения в реализации решений, объекты архитектуры предприятия (показанные на рисунке 5) по большей части используются для анализа, планирования и управления архитектурой предприятия. Например, для разработчика архитектуры решений предметная область понятия "Приложения" может означать группу связанных компонентов и классов, тогда как для разработчика архитектуры предприятия оно может влечь за собой узел, выполняющий группу бизнес-процессов или предоставляющий диапазон сервисов.
Обратите внимание на то, что некоторые (обычно низкоуровневые) объекты дисциплины архитектуры решений не входят в область применения архитектуры предприятия (EA) и одновременно в нее добавлены некоторые дополнительные (по большей части высокоуровневые) объекты. Обратите также внимание на то, что ключевые объекты бизнес-архитектуры полностью включаются в дисциплину архитектуры предприятия.
Рисунок 5: Компоненты и объекты дисциплины архитектуры предприятий
Область применения архитектуры предприятия
Виды деятельности архитектуры предприятия начинаются задолго до начала проектов, управляемых архитектурой решений, и непрерывно продолжаются в течение всего срока жизни предприятия. Как непрерывный процесс, жизненный цикл архитектуры предприятия имеет одну точку входа, которая совпадает с созданием практики, а также несколько точек входов процессов, которые распределены по временному отрезку архитектуры предприятия. Как описывает рисунок 10, некоторые инфраструктуры EA вводят циклы, или итерации, которые следует планировать в соответствии с крупными фазами в разработке бизнеса организации. В этих инфраструктурах цикл состоит из нескольких фаз с несколькими подачами в деятельности архитектуры предприятия, особенно в начальных фазах цикла.
Входы в архитектуру предприятия могут отличаться в зависимости от способа создания и верификации идей преобразования предприятия; классификация этих входов предоставляет способ измерения зрелости практики архитектуры предприятия в данной организации. В некоторых случаях идея может быть побочным продуктом разговора в лифте между главным инженером и разработчиком архитектуры. В других - это согласованный ответ на запросы, поставленные планировщиками бизнеса, конечными пользователями или другими заинтересованными лицами. В наиболее зрелых организациях она будет выходом стратегического анализа архитектуры и процесса планирования, который также включает входные данные от только что упоминавшихся источников.
Рисунок 6: Входные данные процесса архитектуры предприятия
Разные деятельности архитектуры предприятия продолжаются до тех пор, пока предприятие функционирует и имеет перспективу. Кроме того, в организации всегда есть потребность в перспективе архитектуры предприятия, поэтому деятельности архитектуры предприятия никогда не должны прекращаться.
Новая роль - архитектор предприятия
Архитектор предприятия - интеллектуальный лидер, прогнозист и эксперт в своей отрасли. В большинстве компаний это новая роль, которая объединяет навыки менеджера проекта, архитектора решений и бизнес-аналитика с интуицией исполнителя.
Распространенное ограничение перспективы развития многих инженеров ИТ заключается в том, что они - сложившиеся программисты и обычно склонны к замкнутости. Хотя это, в общем-то, не является препятствием для разработки архитектуры и проектирования "коробочных" решений, в контексте разработки архитектуры предприятия эта черта менее желательна. Архитектору предприятия лучше быть экстравертом и уметь использовать профессиональные, рабочие и даже личные отношения с владельцами бизнеса, ведущими руководителями, коллегами и потребителями для интерпретации, архитектурного описания и помощи в формировании картины функционирования предприятия (см. рисунок 7).
Рисунок 7: Роль - архитектор предприятия
Должность архитектора предприятия часто сравнивают с должностью градостроителя. Напротив, должность архитектора зданий гораздо легче ассоциируется с ролью архитектора ИТ. Роль архитектора предприятия часто ставит навыки индукции детектива выше навыков дедукции строителя.
Однако высокоуровневая перспектива архитектора предприятия не означает, что эта роль отделяется от сообщества пользователей. Наоборот, архитектор предприятия должен оказывать клиентам помощь в понимании их потребностей (в противоположность желаниям) и работать с ними на всем протяжении реализации решения. В то же время архитектор предприятия должен уметь видеть свою предметную область на неком уровне абстракции, который не допускает прямого участия в практических аспектах реализации. Как сказал Дэвид Джексон (David Jackson) из IBM, архитектор предприятия должен уметь понимать проблемы и предметную область бизнеса и объяснять их техническим специалистам, а также уметь понять предметную область технологии и объяснить ее технические возможности специалистам по бизнесу."
Важно, чтобы архитектор предприятия играл главную роль в управлении архитектурой; эту функцию часто делят между разнородными бизнес- и техническими ролями или, что еще хуже, просто игнорируют. Управление архитектурой - это та интегрирующая технология, которая предоставляет и контекст, и инфраструктуру для всех деятельностей архитектуры предприятия и проекта.
Хотя в своей основе RUP не включает дисциплины архитектуры предприятия, процесс, безусловно, выиграет, если будет иметь хорошо определенное взаимодействие с архитектурой предприятия. Это продемонстрировано на рисунке 8, который подчеркивает серийный характер проектов реализации решений. Как видно из рисунка, типичная организация имеет один экземпляр непрерывно работающего процесса архитектуры предприятия и произвольное количество последовательных реализаций решений.
Рисунок 8: Сравнение RUP и жизненного цикла архитектуры предприятия
Стоит отметить, что были сделаны некоторые попытки расширить область применения RUP в направлении предприятия в целом. Самая последняя из таких попыток - это процесс Enterprise Unified Process, или EUP. EUP фокусируется не только на функции архитектуры предприятия; он предоставляет инфраструктуру для выполнения широкого диапазона деятельностей предприятия. EUP вводит семь новых дисциплин, в том числе дисциплину Архитектура предприятия, и более двадцати пяти новых ролей, а также предоставляет рекомендации для их адаптации. Ведется работа над интеграцией различных дисциплин EUP в ядро RUP.
Тем временем, сам RUP существенно эволюционировал по сравнению с первоначальным вариантом и теперь включает несколько процессов предприятия, в том числе, бизнес-моделирование и управление изменением, в числе своих основных дисциплин.
Реализация программы архитектуры предприятия
Относительная сложность реализации программы архитектуры предприятия зависит от таких факторов, как уровень решимости организации, доступность ресурсов и управления, размер и сложность бизнес-модели организации, а также гибкость организации. Правда заключается в том, что многие организации просто не способны одновременно реализовать программу архитектуры предприятия и управлять ею, поэтому будет лучше сконцентрироваться на менее перспективных методах улучшения процесса, которые выражают скорее эффекты, чем эффективность.
Существует два общих подхода к реализации архитектуры предприятия, которые примерно соотносимы с двумя разными видами доступных инфраструктур.
Первый подход проецирует организационные артефакты и процессы на метаструктуру инфраструктуры. Этот подход хорошо работает в организациях, которые преуспели в моделировании. Организации, предпочитающие такой подход, обычно выбирают схему Захмана или эквивалентную инфраструктуру. Одна из опасностей такого подхода заключается в том, что структура инфраструктуры может ограничивать творческую инициативу и вносить в процесс реализации архитектуры предприятия элемент бюрократизма. Еще одна проблема этого типа инфраструктуры явяется результатом серьезной нехватки инструкций по реализации.
Второй подход строится на убеждении, что программа архитектуры предприятия должна управляться процессами. Поскольку этот подход концентрируется, в первую очередь, на деятельностях, а не на артефактах, он может быть более простым для понимания и связи с существующей рабочей средой, а также методиками и методами решения.
Хотя оба подхода имеют свои за и против, можно выбрать компромиссное решение - использовать процесс, управляемый деятельностью, в целом, а в качестве опорной структуры или в целях анализа применять мета-инфраструктуру.
Пример контрольного списка реализации архитектуры предприятия
Здесь приводятся основные деятельности, которые должны иметь место в составе реализации архитектуры предприятия. Этот список должен помочь вам понять, что то, чем занимается архитектура предприятия, это:
- Изучение существующих бизнес-практик.
Понимание бизнес-модели организации и, как минимум, ее высокоуровневых процессов - это предусловие для начала реализации архитектуры предприятия; - Поговорите со старшим менеджером, это может помочь понять стратегическое направление.
Обычно у старших менеджеров есть ключ к интерпретации стратегического видения. Понимание стратегического видения важно для составления плана-графика архитектуры предприятия, поскольку этот артефакт способствует созданию будущих компонентов архитектурного задания; - Чтобы выявить срочные потребности, свяжитесь с бизнес-сообществом предприятия.
В то время, как старший менеджер может представлять себе будущее состояние организации, бизнес-сообщество больше знает о ее текущем состоянии. Ваша задача - получить эти факты и уравновесить их с набором ожиданий стратегического видения; - Постройте панорамное понимание существующей технологической среды.
Технология - это главная движущая сила бизнес-процессов (еще одной движущейся силой являются люди); это подразумевает, что вы не сможете двигаться вперед без надлежащего знания своего основного инструмента; - Составьте план-график модернизации.
Собрав даннные из раличных источников, создайте план-график, чтобы довести до сведения заинтересованных лиц - в том числе, старшего менеджера, ведущих специалистов по бизнесу и технологии - то, как вы намереваетесь действовать в отношении потребностей, которые они вам сообщили; - Поддерживайте актуальность архитектурной модели предприятия.
Не приходится и говорить о том, что после того, как вы составите план-график архитектуры предприятия и согласуете его с заинтересованными лицами, следует сделать все, что от вас зависит, чтобы он регулярно обновлялся.
Для только что описанных деятельностей, которые должны иметь место, обязательно составить строгие методические рекомендации. Методологии предприятия и инфраструктуры, которые существуют сегодня, значительно отличаются по диапазону проблем, которые они решают, и подходам, которые они используют. Вот некоторые из хорошо известных инфраструктур: TOGAF, EUP, инфраструктура архитектуры федерального предприятия (Federal Enterprise Architectural Framework, FEAF), инфраструктура архитектуры предприятия Гартнера (Gartner EA Framework), Инфраструктура архитектуры министерства обороны (Department of Defense Architecture Framework, DoDAF), методология планирования Спивака (Spewak EA Planning Methodology) и инфраструктура (схема) Захмана (Zachman Framework).
Если вы думаете, что организация, в которой вы работаете, имеет недостатки в каких-либо областях, обсуждавшихся в данной статье, нужно повысить их эффективность, или вы лично отвечаете за архитектуру предприятия, рекомендуется внимательно изучить какие-либо из этих методологий архитектуры.
Выбор инфраструктуры архитектуры предприятия
Когда приходит время выбрать методологию/инфраструктуру архитектуры предприятия, большинство из доступных параметров принимают форму частично построенных "решений", которые могут быть адаптированы к потребностям конкретной организации. В действительности, большинство из этих "решений-полуфабрикатов" либо невозможно повторно использовать на практике, либо требуют очень существенной адаптации, чтобы иметь хоть какую-либо ценность. Кроме того, серьезной проблемой адаптации любой из этих инфраструктур является то, что количество имеющихся руководств прискорбно мало, хотя уровень понимания деталей, который требуется для их воплощения, очень велик.
Большинство существующих инфраструктур (если не все) либо расширяют другие архитектуры, либо повторяют их для конкретных задач. Например, инфраструктура EUP является расширением RUP, она имитирует его подход к описанию рабочих потоков процесса и деятельностей, тогда как FEAF и Спивак наследуют инфраструктуру Захмана. TOGAF происходит от ранних, специализированных технических инфраструктур архитектуры предприятия, таких, как Technical Architecture Framework for Information Management (TAFIM), и создана в соответствии с рекомендациями ANSI для архитектуры предприятий (IEEE 1471-2000).
TOGAF - это инфраструктура архитектуры предприятия, которая появилась в последние два десятилетия с целью стать стандартом разработки архитектуры предприятия. Созданная членами консорциума Open Grouр, TOGAF не всегда воплощает целостную концепцию архитектуры предприятия. Сначала TOGAF включала только технические аспекты архитектуры (версии с 1 по 7), однако недавно в эту инфраструктуру была добавлена предметная область архитектуры бизнеса (версия 8, Enterprise Edition), в результате TOGAF быстро переместилась на передний план современных вариантов инфраструктур архитектуры предприятий.
Рисунок 9: Предметная область архитектуры TOGAF
На момент включения в TOGAF бизнес-архитектуры, эта инфраструктура уже имела солидную технологическую основу в виде своих предметных областей Приложения, Данные и Технология. Включение в TOGAF предметной области архитектуры бизнеса способствовало дальнейшему росту ее популярности, тогда как для других инфраструктур, у которых сначала не было архитектуры технологии, началось трудное время разработки этой предметной области. Например, EUP заимствовала подход, методы и нотацию (UML) RUP, тогда как Захман, Спивак и некоторые другие намеренно поддерживали высокий уровень абстракции, что негативно повлияло на их восприятие, поскольку они не смогли получить поддержку технического сообщества.
Главным компонентом TOGAF является метод разработки архитектуры (Architecture Development Method, метод ADM), процесс, который используется для адаптации и реализации архитектуры предприятия, специфичной для данной организации. Помимо метода ADM, TOGAF включает коллекцию связанных средств, известных как "Континуум предприятия" (Enterprise Continuum). TOGAF подразумевает, что континуум предприятия действует как коллекция компоновочных блоков (шаблонов), которая предоставляет коллективам, занимающимся архитектурой предприятия, соответствующие архитектуры, модели и процессы, из которых можно собирать готовые решения, как в детском конструкторе.
Метод разработки архитектуры TOGAF (ADM)
Метод разработки архитектуры TOGAF (ADM) предоставляет законченный набор инструкций для реализации и выполнения архитектуры предприятия в организации. Этот процесс состоит из нескольких последовательных фаз, замкнутых в цикл (см. рисунок 10).
Рисунок 10: Метод разработки архитектуры (ADM) TOGAF
Задача предварительной фазы (Preliminary Phase) - выявление заинтересованных в процессе реализации лиц и обсуждение с ними задач архитектуры предприятия. На этой фазе вырабатываются Руководящие принципы архитектуры (Architecture Guiding Principles), которые основываются на бизнес-принципах организации и описывают процессы и критерии для наблюдения за процессом реализации архитектуры предприятия.
Фаза А этого процесса предназначена для выражения видения архитектуры предприятия. Артефакт Видение архитектуры (Architecture Vision) использует движущие силы бизнеса, чтобы обозначить цель действий по созданию архитектуры предприятия и создать описания первого реза для базовой и целевой среды. Если задачи бизнеса не ясны, то часть задания этой фазы - помочь бизнесу идентифицировать свои главные задачи и соответствующие процессы, которые должна поддерживать архитектура предприятия. Документ Архитектурное задание (Statement of Architectural Work), который также создается в этой фазе, очерчивает область действия и условия архитектуры предприятия и представляет собой план архитектурного задания.
Фаза B предназначена для детальной разработки архитектуры предметной области бизнеса. И базовая, и целевая архитектура, которые очерчены в документе Видение архитектуры, детализируются, чтобы получить полезные входные данные для технического анализа. Моделирование бизнес-процессов, моделирование бизнес-объектов и моделирование прецедентов - вот лишь некоторые методики, которые используются для создания архитектуры бизнеса, которая, в свою очередь, включает анализ просчетов желательного состояния.
Фаза С связана с созданием архитектуры предметных областей Приложение и Данные (Информация). Эта фаза использует базовую и целевую архитектуры, которые были запущены в фазе А (Архитектурное представление) и результатах анализа просчетов (компонента архитектуры бизнеса), чтобы передать архитектурам данных и приложения информацию о текущей и проектной средах, в пределах области применения и в соответствии с планом, очерченным в Документе "Архитектурное задание".
Фаза D завершает работу над детализацией архитектуры цикла метода ADM созданием архитектуры технологии. Как и в предыдущих фазах, в качестве основы используется анализ просчетов и черновые варианты архитектур, так же, как и руководящие принципы архитектуры, выработанные в подготовительной фазе. В этой фазе для создания различных точек зрения активно используется нотация моделирования UML
Цель фазы Е - выяснить возможности, предлагаемые целевой архитектурой, и создать эскиз потенциального решения. Работа в этой фазе концентрируется вокруг применимости и практичности альтернатив реализации. На этой фазе создаются такие артефакты, как Стратегия реализации и миграции, Высокоуровневый план реализации и Список проектов, а также обновленная Архитектура приложения, которая выполняет функции программы, которую следует использовать в проекте реализации.
В фазе F расставляются приоритеты проектов реализации и выполняется детализированное планирование и анализ просчетов процесса миграции. В это задание входит оценка зависимостей между проектами и минимизация их итогового влияния на функции предприятия. В этой фазе обновляется Список проектов, детализируется План реализации, а Программа передается коллективам, занимающимся реализацией.
После утверждения спецификации проекта фокус перемещается на формулирование более конкретных условий и рекомендаций для каждого из проектов реализации. На протяжении фазы G устанавливается связь между упрвляющей архитектурой (TOGAF) и разрабатывающей организацией (которая может быть настроена при помощи RUP и Project Management Body of Knowledge (PMBOK), например, или каких-либо еще методологий управления проектом), а выбранные проекты реализуются под управлением формальной архитектуры. На выходе этой фазы мы имеем Архитектурные контракты, которые утверждаются организацией-разработчиком. Конечным выходом фазы G являются решения, совместимые с архитектурой.
В фазе H акцент переносится на управление изменением основой архитектуры, которая достигается поставкой реализованных решений. В этой фазе может быть создано Требование к архитектурному заданию, которое устанавливает цели для последующих циклов реализации архитектуры предприятия.
Континуум предприятия - это накопитель таких ресурсов, как модели, шаблоны решений и другие активы, которые могут использоваться как компоновочные блоки на всем процессе реализации и адаптации архитектуры предприятия. Континуум предприятия в целом аналогичен справочной библиотеке для практиков архитектуры и заинтересованных лиц.
Помимо метода ADM и Континуума предприятия, TOGAF предоставляет дополнительные ресурсы и ссылки, относящиеся к методам, технологиям и решениям, которые можно использовать для планирования и реализации архитектуры предприятия.
Можно ли отнести TOGAF к итеративным инфраструктурам?
Как видно из рисунка 10, TOGAF - итеративный процесс. Итерации TOGAF (которые гораздо чаще называются циклами) обычно отличаются большей длительностью, чем итерации RUP, и объединяют несколько фаз реализации и обслуживания архитектуры предприятия. Это не удивительно, так как область охвата архитектуры предприятия шире области охвата одного проекта RUP.
Управление требованиями и TOGAF
Как видно из рисунка 10, TOGAF - это процесс, буквально сосредоточенный на требованиях. Управление требованиями метода ADM работает с любыми видами требований, особенно с требованиями к направляющим механизмам бизнеса, участникам, а также требованиями новых функциональных возможностей и изменения. И последнее, хотя и не менее важное: поскольку архитектурные требования являются субъектами постоянного изменения, управление требованиями ведется на протяжении всего жизненного цикла реализации архитектуры предприятия.
В современной организации TOGAF приходится сосуществовать с другими методологиями, процессами и инфраструктурами. С некоторыми из них, например, с процессом RUP, у нее нет общих областей применения, в то время как с другими, например, EUP и инфраструктура (схема) Захмана, области применения пересекаются на некоторых отрезках жизненного цикла.
Иногда кажется, что TOGAF может быть альтернативой RUP, в тех случаях, когда на самом деле это не так. Хотя многие модели и объекты имеются в обеих инфраструктурах, их направления и задачи различны.
Принципиальная разница между TOGAF и RUP заключается в том, что RUP является процессом, управляемым архитектурой технологии, в то время как TOGAF управляется архитектурой бизнеса. В RUP, бизнес-требования собираются для того, чтобы спроектировать и поставить систему на основе программного обеспечения , тогда как в TOGAF технология рассматривается как способ реализовать бизнес-представление .
Целью RUP как методологии жизненного цикла разработки программного обеспечения (Software Development Life Cycle, SDLC) является своевременная и эффективная поддержка поставки приложений. Это контрастирует с целью TOGAF, которая заключается в поддержке реализации и обслуживания архитектуры предприятия. На рисунке 11 показаны области, в которых пересекаются жизненные циклы RUP и TOGAF.
Рисунок 11: жизненные циклы RUP и TOGAF
В процессе реализации TOGAF существует ясно обозначенная точка пересечения с RUP. Пересечение начинается в начале фазы F, когда архитектурный проект (модель приложения), архитектура бизнеса и высокоуровневые планы реализации передаются коллективам, воплощающим реализацию. Процесс передачи считается законченным, когда обе стороны соглашаются с областью применения реализации. В это же время подписываются архитектурные контракты, которые подробно описывают обязанности и принципы коллектива в управлении реализацией архитектуры. На рисунке 12 представлены детали перехода артефактов между TOGAF и RUP.
Рисунок 12: Артефакты переходят между TOGAF и RUP
TOGAF и инфраструктура Захмана
Хотя и TOGAF, и инфраструктура Захмана (ИЗ) принадлежат к категории "инфраструктур предприятия", они отличаются своими принципами, структурой и компетенцией.
В то время как ИЗ - это структурная (статичная) инфраструктура, которая наиболее эффективна при использовании в качестве модели анализа и классификации артефактов и метаанализа методологий и инфраструктур, TOGAF - это функциональная (динамичная) инфраструктура, которая включает также руководящие принципы эталонных моделей процесса их использования. Несмотря на фундаментальные отличия, существует обширный потенциал совместного использования этих двух инфраструктур.
- Используйте ИЗ в качестве словаря терминов и структуры представления для артефактов, а TOGAF - в качестве атрефакта процесса представления;
- Используйте ИЗ для настройки структур передачи артефактов между другими методологиями решений, такими, как RUP и/или Библиотека инфраструктуры ИТ (IT Infrastructure Library, ITIL), и TOGAF;
- Применяйте инфраструктуру Захмана для анализа просчетов существующего процесса предприятия и бизнес-модели в процессе или до реализации TOGAF;
- Используйте ИЗ для метаанализа TOGAF, который может способствовать идентификации слабых мест и возможностей взаимодействия с другими методологиями;
- Используйте ИЗ как средство разработки моделей архитектуры предприятия TOGAF (TOGAF фазы B-D). 10
Хотя и EUP, и TOGAF функционируют на уровне организации, их области действия различаются. Инфраструктура EUP, которая расширяет RUP до уровня предприятия, вводит семь новых дисциплин -- одна из них - Архитектура предприятия -- и предоставляет рекомендации по их реализации. Хотя большая часть дисциплин EUP функционирует на уровне организации и используется как входные данные для процессов архитектуры предприятия, EUP сам по себе не является инфраструктурой разработки архитектуры предприятия. (Хотя EUP может измениться в связи с будущими реализациями RUP.)
В противоположность EUP, TOGAF концентрируется только на дисциплине архитектуры предприятия. Она с самого начала задумывалась и создавалась как инфраструктура для реализации архитектуры предприятия.
Несмотря на перспективные различия между EUP и TOGAF, дисциплины, которые были введены EUP, оказались очень важными для реализации архитектуры предприятия. Например, Моделирование бизнеса предприятия (Enterprise Business Modeling) - это инструмент для архитектурных изменениий существующих бизнес-процессов, тогда как Управление портфелем (Portfolio Management) - необходимый инструмент архитектора предприятия, который можно использовать для анализа будущих и мониторинга (по EA - управления) текущих реализаций.
Возможные препятствия для реализации TOGAF
Метод ADM TOGAF не является законченным процессом; это инфраструктура, и, по сути, для каждой конкретной организации, требуется адаптация. Адаптация предполагает глубокое знание модели бизнеса и методологии - специалиста с такими качествами не всегда легко найти. Ситуация осложняется тем, что TOGAF v 8.0, Enterprise Edition - это сравнительно новый процесс с ограниченным количеством практических наработок.
Может оказаться непростой задачей уговорить заинтересованных лиц использовать TOGAF. Обычно для этого необходимо, чтобы какой-либо сотрудник, пользующийся уважением, уговорил руководство и других сотрудников добавить к знакомым им процессам и моделям TOGAF, или полностью заменить их на модели и процессы новой инфраструктуры.
Несмотря на недавние усовершенствования, инфраструктура TOGAF не так детализирована, как другие методологии, особенно в главной сфере взаимодействия бизнеса и технологии. Например, TOGAF не включает ни функций, подобных Rational Method Composer или MyRUP, ни такой комплексной библиотеки периодических изданий.
Зрелые организации, особенно те, которые в повседневной работе используют управление проектами и методологию жизненного цикла программного обеспечения (PMBOK, RUP, Scrum и ITIL) обычно добиваются большего успеха в реализации архитектуры предприятия. Можно порекомендовать сотрудникам организации перед тем, как включить в свой инструментарий TOGAF, хорошо изучить несколько методик, нотаций и методологий жизненного цикла программного обеспечения из тех, что показаны на рисунке 13.
Рисунок 13: План-график реализации TOGAF
Среди прочих потенциальных угроз успешной реализации TOGAF - отсутствие стандартного инструмента для фиксации и управления артефактами архитектуры предприятия и остутствие стандартной нотации.
Прежде всего организации следует решить, реализовать ли архитектуру предприятия в общем, реализация TOGAF в частности - это следующий этап в ее развитии. Часто организации, которые успешно и последовательно используют методологию жизненного цикла решений (например, RUP), расценивают реализацию архитектуры предприятия как следующую ступень своего развития.
Очень важно, чтобы концепция архитектуры предприятия не вводилась принудительно, по приказу руководства. Напротив, потребность в применении архитектуры предприятия должна органично вытекать из понимания возникающих сложностей, которые окружают управление бизнес-процессами и структурами в сочетании с инфраструктурой опорной технологии.
Если вы не уверены в том, что TOGAF вам подойдет, хорошо бы провести ее тест-драйв в вашей организации. В таком испытании может принять участие группа энтузиастов - архитекторов бизнеса и решений. Важно, задействовать специалистов из технической и бизнес-сферы, чтобы обеспечить равновесие интересов. Обратите также внимание на то, что для успеха реализации архитектуры предприятия необходима надежная поддержка коллектива организации. Эта поддержка может быть гарантирована путем включения в группу архитектуры предприятия членов коллектива исполнителей в качестве представителей, или закрепив за архитектором предприятия место в руководящем комитете организации.