архитектуры предприятия за границы RUP Быть или не быть...

© Copyright IBM Corporation 2007 Торговые маркиБыть или не быть TOGAF: распространение архитектурыпредприятия за границы RUP

Страница 1 из 21

Быть или не быть TOGAF: распространениеархитектуры предприятия за границы RUPВиталий Темненкоразработчик архитектурыWSIB

26.04.2007

Из журнала Rational Edge: В статье рассказывается об архитектуре предприятий,архитектуре решений и архитектуре бизнеса; эти дисциплины сравниваются сунифицированным процессом IBM Rational (RUP), даются рекомендации по ихсовместному использованию, пропагандируется применение Open Group ArchitectureFramework (TOGAF) в сочетании с процессом RUP для успешного продвиженияреализации архитектуры предприятия в организациях.

Когда проектный коллектив, вооруженный Rational Unified

Process от IBM ® (RUP®), получает проектное задание или требования определенногопользователя, то на пути к решению среди прочих артефактов проекта создаютсябизнес-прецедент, документ "Видение" и спецификация требований к программномуобеспечению. Эти промежуточные продукты и создающие их деятельности хорошознают и в техническом, и в бизнес-сообществе. Однако способы, которые используютсядля концептуализации, расстановки приоритетов и выбора значимых для реализации впрограмме бизнес-проблем и пользователей, представляют собой весьма вариативныепроцессы в пределах отрасли.

В этой статье рассматриваются степень зрелости и нарастающая важностьроли инфраструктуры архитектуры предприятия для современных организацийразработчиков. Статья начинается сравнением дисциплины архитектуры предприятияс дисциплинами архитектуры решений и бизнес-архитектуры, по отношению к RUP.Далее рассматривается, как инфраструктура Open Group Architecture Framework (TOGAF)выгодно расширяет границы архитектуры, установленные RUP, чтобы включить впроцесс планирование бизнеса корпорации, ИТ-планирование, управление реализацией и

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ru/ibm/trademarks/

developerWorks® ibm.com/developerWorks/ru/

Быть или не быть TOGAF: распространение архитектурыпредприятия за границы RUP


другие виды деятельности. В завершение будет предложен способ применения TOGAF всочетании с другими инфраструктурами архитектуры предприятия.

Сравнение различных архитектурных инфраструктурСуществует некоторое наложение областей действия между инфраструктурами разработкиархитектуры предприятий, решений и бизнеса, в общепринятом их понимании. Итак, как онисоотносятся между собой?

Архитектура решенийИнфраструктура архитектуры решений принимает различные формы. Специалисты поинформационным технологиям уже привыкли иметь дело с Приложениями (Application),Данными (Data), Технологиями (Technology) и другими архитектурными формами(называемымм также предметными областями) в процессе разработки информационныхсистем и обслуживания проектов. Новые (и значительно более специализированные)формы архитектуры решений, такие, как Безопасность (Security) и Тестирование (Testin),тоже быстро стали основными формами. Наиболее узнаваемые предметные областиархитектуры решений, их основные объекты и зависимости между ними показаны нарисунке 1.

Рисунок 1: Предметные области и объекты дисциплины архитектуры решений

Все предметные области архитектуры решений, показанные на рисунке 1, считаются"техническими", поскольку область их применения включает различные элементытехнологии, такие, как программное обеспечение, данные и инфраструктураинформационных технологий. С этими предметными областями обычно приходитсяиметь дело технологам - то есть, людям, которые имеют опыт в разработке систем, илиадминистраторам в сфере ИТ.

Архитектура бизнесаАрхитектура бизнеса как отдельная предметная область появилась в 1990-е годы, когдамногие организации утвердили должность архитектора бизнеса, пытаясь оптимизироватьсвои бизнес-процессы.

ibm.com/developerWorks/ru/ developerWorks®



Дисциплина "архитектура бизнеса" считается "относящейся к бизнесу"; она описывает,как он работает. Хотя вряд ли можно достичь согласия по поводу того, какие компонентыследует включить в инфраструктуру архитектуры бизнеса, принято считать, что значимымиаспектами в этой предметной области являются аспекты Процесс и Информация (Processand Information), Организация (Organization) и Производительность (Performance). Каждый изэтих компонентов сам по себе очень важен и включает несколько предметных областей, какпоказано на рисунке 2.

Рисунок 2: компоненты и объекты предметной области архитектуры бизнеса

Компонент Процесс и Информация, вероятно, является основным для деятельностейархитектуры бизнеса, поскольку (среди прочего) он определяет, описывает иклассифицирует бизнес-процессы и опорные структуры, которые составляют бизнес-модель организации. Этот компонент включает также группу связанных объектов, таких,как удобство применения и доступность. У каждой организации, конечно, есть различныебизнес-процессы, структуры, технологические потоки и т. д. Точно так же какая-либоорганизация может иметь что-то особенное в своей модели бизнес-процесса, то, чтоподнимает ее над конкуренцией, в то время как другие организации продолжают вестиборьбу в этой отрасли.

Компонент Организация относится к структуре и конструированию методов работы, а такжек стилю работы в организации. Объекты, которые взаимодействуют с этим компонентом,включают структуру организации, продукты и услуги, которые производит бизнес, бизнес-единицы их размещение и т. д.

Производительность бизнеса - это компонент, связанный с управлением, объединяющийобъекты, которые определяют и измеряют эффективность организации. В него входят такиеобъекты, как производительность, бизнес-риски и другие связанные объекты.

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




потребностей бизнеса. Эти методики, однако, не интересуются тем, как и почемупоявились эти потребности. Вместо этого они концентрируются на сравнительной важностиудовлетворения данной потребности по сравнению с другими потребностями, которыеможет иметь организация. Для примера рассмотрим процесс RUP. Процесс представленияRUP принимает решение о реализации в значительной степени на веру, причем ни одинартефакт RUP прямо не связан с оценкой относительности срочности требования бизнеса,которая делается в процессе реализации решения.

В отличие от RUP и других дисциплин, которые концентрируются, главным образом, нареализации, основным интересом предметной области архитектуры предприятия являетсясамо предприятие - идентификация, спецификация и расстановка приоритетов требованийбизнеса. Рассмотренные точки зрения и модели, взятые в контексте инфраструктурыархитектуры предприятия, решают определенный круг текущих и потенциальных проблем.

План-график архитектуры предприятия чаще всего содержит более одного предлагаемогорешения (как показано на рисунке 3), в результате чего может возникнуть несколькоодновременных реализаций.

Рисунок 3: Пример плана-графика архитектуры предприятия

Предприятие будущего

Институт разработки архитектуры предприятий (Institute for Enterprise ArchitectureDevelopment, IFEAD) обобщает основные руководящие принципы дисциплины архитектурыпредприятия следующим образом: "Нет стратегических прогнозов - нет архитектурыпредприятия." Другими словами, архитектура предприятия сегодня - это система бизнесазавтра. Важный аспект этого утверждения заключается в том, что архитектура предприятия- это целостная дисциплина, которая объединяет элементы бизнеса и технологии, исходя изобщего стратегического прогноза предприятия (см. рисунок 4).




Рисунок 4: Элементы предметной области архитектуры предприятия

Время пришло

Хотя концепции архитектуры предприятия в ходу уже более двух десятилетий, дисциплина"Архитектура предприятия" появилась недавно. Это можно объяснить ускорениемизменений рабочей среды в организациях всех размеров в большинстве отраслей.Конструктивность бизнеса и, в частности, способность инфраструктуры технологийсвоевременно реагировать на изменения, стали критически важными факторами.

Еще одним фактором, который способствовал растущему пониманию дисциплиныархитектуры предприятия, был все более ужесточающийся законодательный климатпоследних лет, как в США, так и в других странах. Это заставило организации не толькоповысить ответственность и усовершенствовать методы отчетности, но также сделатьсоответствие законодательным требованиям жизненно важным требованием для каждогобизнес-процесса.

В ответ на повышение внимания к принципам архитектуры предприятия в последнее времяпоявились надежные инфраструктуры архитектуры предприятий, такие, как TOGAF.

Те же объекты, но с другой точки зрения

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

К тому же дисциплина архитектуры предприятия - это больше, чем супернабор предметныхобластей архитектуры решений. В то время как объекты архитектуры решений (см.рисунок 1) предназначены для применения в реализации решений, объекты архитектурыпредприятия (показанные на рисунке 5) по большей части используются для анализа,планирования и управления архитектурой предприятия. Например, для разработчикаархитектуры решений предметная область понятия "Приложения" может означать группусвязанных компонентов и классов, тогда как для разработчика архитектуры предприятия ономожет влечь за собой узел, выполняющий группу бизнес-процессов или предоставляющийдиапазон сервисов.




Обратите внимание на то, что некоторые (обычно низкоуровневые) объекты дисциплиныархитектуры решений не входят в область применения архитектуры предприятия(EA) и одновременно в нее добавлены некоторые дополнительные (по большей частивысокоуровневые) объекты. Обратите также внимание на то, что ключевые объекты бизнес-архитектуры полностью включаются в дисциплину архитектуры предприятия.

Рисунок 5: Компоненты и объекты дисциплины архитектуры предприятий

Область применения архитектуры предприятия

Виды деятельности архитектуры предприятия начинаются задолго до начала проектов,управляемых архитектурой решений, и непрерывно продолжаются в течение всего срокажизни предприятия. Как непрерывный процесс, жизненный цикл архитектуры предприятияимеет одну точку входа, которая совпадает с созданием практики, а также несколько точеквходов процессов, которые распределены по временному отрезку архитектуры предприятия.Как описывает рисунок 10, некоторые инфраструктуры EA вводят циклы, или итерации,которые следует планировать в соответствии с крупными фазами в разработке бизнесаорганизации. В этих инфраструктурах цикл состоит из нескольких фаз с несколькимиподачами в деятельности архитектуры предприятия, особенно в начальных фазах цикла.

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




Рисунок 6: Входные данные процесса архитектуры предприятия

Разные деятельности архитектуры предприятия продолжаются до тех пор, пока предприятиефункционирует и имеет перспективу. Кроме того, в организации всегда есть потребность вперспективе архитектуры предприятия, поэтому деятельности архитектуры предприятияникогда не должны прекращаться.

Новая роль - архитектор предприятия

Архитектор предприятия - интеллектуальный лидер, прогнозист и эксперт в своей отрасли.В большинстве компаний это новая роль, которая объединяет навыки менеджера проекта,архитектора решений и бизнес-аналитика с интуицией исполнителя.

Распространенное ограничение перспективы развития многих инженеров ИТ заключаетсяв том, что они - сложившиеся программисты и обычно склонны к замкнутости. Хотя это,в общем-то, не является препятствием для разработки архитектуры и проектирования"коробочных" решений, в контексте разработки архитектуры предприятия эта черта менеежелательна. Архитектору предприятия лучше быть экстравертом и уметь использоватьпрофессиональные, рабочие и даже личные отношения с владельцами бизнеса, ведущимируководителями, коллегами и потребителями для интерпретации, архитектурного описания ипомощи в формировании картины функционирования предприятия (см. рисунок 7).




Рисунок 7: Роль - архитектор предприятия

Должность архитектора предприятия часто сравнивают с должностью градостроителя.Напротив, должность архитектора зданий гораздо легче ассоциируется с ролью архитектораИТ. Роль архитектора предприятия часто ставит навыки индукции детектива выше навыковдедукции строителя.

Однако высокоуровневая перспектива архитектора предприятия не означает, что эта рольотделяется от сообщества пользователей. Наоборот, архитектор предприятия долженоказывать клиентам помощь в понимании их потребностей (в противоположность желаниям)и работать с ними на всем протяжении реализации решения. В то же время архитекторпредприятия должен уметь видеть свою предметную область на неком уровне абстракции,который не допускает прямого участия в практических аспектах реализации. Как сказалДэвид Джексон (David Jackson) из IBM, архитектор предприятия должен уметь пониматьпроблемы и предметную область бизнеса и объяснять их техническим специалистам,а также уметь понять предметную область технологии и объяснить ее технические

возможности специалистам по бизнесу."1

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

Архитектура предприятия и RUPХотя в своей основе RUP не включает дисциплины архитектуры предприятия, процесс,безусловно, выиграет, если будет иметь хорошо определенное взаимодействие сархитектурой предприятия. Это продемонстрировано на рисунке 8, который подчеркивает




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

Рисунок 8: Сравнение RUP и жизненного цикла архитектуры предприятия

Стоит отметить, что были сделаны некоторые попытки расширить область примененияRUP в направлении предприятия в целом. Самая последняя из таких попыток - это процесс

Enterprise Unified Process, или EUP.2 EUP фокусируется не только на функции архитектурыпредприятия; он предоставляет инфраструктуру для выполнения широкого диапазонадеятельностей предприятия. EUP вводит семь новых дисциплин, в том числе дисциплинуАрхитектура предприятия, и более двадцати пяти новых ролей, а также предоставляетрекомендации для их адаптации. Ведется работа над интеграцией различных дисциплинEUP в ядро RUP.

Тем временем, сам RUP существенно эволюционировал по сравнению с первоначальнымвариантом и теперь включает несколько процессов предприятия, в том числе, бизнес-моделирование и управление изменением, в числе своих основных дисциплин.

Реализация программы архитектуры предприятия

Относительная сложность реализации программы архитектуры предприятия зависитот таких факторов, как уровень решимости организации, доступность ресурсов иуправления, размер и сложность бизнес-модели организации, а также гибкость организации.Правда заключается в том, что многие организации просто не способны одновременнореализовать программу архитектуры предприятия и управлять ею, поэтому будет лучшесконцентрироваться на менее перспективных методах улучшения процесса, которые

выражают скорее эффекты, чем эффективность.3

Существует два общих подхода к реализации архитектуры предприятия, которые примерносоотносимы с двумя разными видами доступных инфраструктур.




Первый подход проецирует организационные артефакты и процессы на метаструктуруинфраструктуры. Этот подход хорошо работает в организациях, которые преуспелив моделировании. Организации, предпочитающие такой подход, обычно выбираютсхему Захмана или эквивалентную инфраструктуру. Одна из опасностей такого подходазаключается в том, что структура инфраструктуры может ограничивать творческуюинициативу и вносить в процесс реализации архитектуры предприятия элементбюрократизма. Еще одна проблема этого типа инфраструктуры явяется результатомсерьезной нехватки инструкций по реализации.

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

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

Пример контрольного списка реализации архитектуры предприятия

Здесь приводятся основные деятельности, которые должны иметь место в составереализации архитектуры предприятия. Этот список должен помочь вам понять, что то, чемзанимается архитектура предприятия, это:

• Изучение существующих бизнес-практик.Понимание бизнес-модели организации и, как минимум, ее высокоуровневых процессов- это предусловие для начала реализации архитектуры предприятия;

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

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

• Постройте панорамное понимание существующей технологической среды.Технология - это главная движущая сила бизнес-процессов (еще одной движущейсясилой являются люди); это подразумевает, что вы не сможете двигаться вперед безнадлежащего знания своего основного инструмента;

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




специалистов по бизнесу и технологии - то, как вы намереваетесь действовать вотношении потребностей, которые они вам сообщили;

• Поддерживайте актуальность архитектурной модели предприятия.Не приходится и говорить о том, что после того, как вы составите план-графикархитектуры предприятия и согласуете его с заинтересованными лицами, следуетсделать все, что от вас зависит, чтобы он регулярно обновлялся.

Для только что описанных деятельностей, которые должны иметь место, обязательносоставить строгие методические рекомендации. Методологии предприятия иинфраструктуры, которые существуют сегодня, значительно отличаются по диапазонупроблем, которые они решают, и подходам, которые они используют. Вот некоторые изхорошо известных инфраструктур: TOGAF, EUP, инфраструктура архитектуры федеральногопредприятия (Federal Enterprise Architectural Framework, FEAF), инфраструктура архитектуры

предприятия Гартнера (Gartner EA Framework),4 Инфраструктура архитектуры министерстваобороны (Department of Defense Architecture Framework, DoDAF), методология планированияСпивака (Spewak EA Planning Methodology) и инфраструктура (схема) Захмана (ZachmanFramework).

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

Выбор инфраструктуры архитектуры предприятияКогда приходит время выбрать методологию/инфраструктуру архитектуры предприятия,большинство из доступных параметров принимают форму частично построенных"решений", которые могут быть адаптированы к потребностям конкретной организации.В действительности, большинство из этих "решений-полуфабрикатов" либо невозможноповторно использовать на практике, либо требуют очень существенной адаптации, чтобыиметь хоть какую-либо ценность. Кроме того, серьезной проблемой адаптации любой из этихинфраструктур является то, что количество имеющихся руководств прискорбно мало, хотяуровень понимания деталей, который требуется для их воплощения, очень велик.

Большинство существующих инфраструктур (если не все) либо расширяют другиеархитектуры, либо повторяют их для конкретных задач. Например, инфраструктураEUP является расширением RUP, она имитирует его подход к описанию рабочихпотоков процесса и деятельностей, тогда как FEAF и Спивак наследуют инфраструктуруЗахмана. TOGAF происходит от ранних, специализированных технических инфраструктурархитектуры предприятия, таких, как Technical Architecture Framework for InformationManagement (TAFIM), и создана в соответствии с рекомендациями ANSI для архитектурыпредприятий (IEEE 1471-2000).

Введение в TOGAFTOGAF5 - это инфраструктура архитектуры предприятия, которая появилась в последниедва десятилетия с целью стать стандартом разработки архитектуры предприятия. Созданная




членами консорциума Open Grouр, TOGAF не всегда воплощает целостную концепциюархитектуры предприятия. Сначала TOGAF включала только технические аспектыархитектуры (версии с 1 по 7), однако недавно в эту инфраструктуру была добавленапредметная область архитектуры бизнеса (версия 8, Enterprise Edition), в результатеTOGAF быстро переместилась на передний план современных вариантов инфраструктурархитектуры предприятий.

Рисунок 9: Предметная область архитектуры TOGAF

На момент включения в TOGAF бизнес-архитектуры, эта инфраструктура уже имеласолидную технологическую основу в виде своих предметных областей Приложения,Данные и Технология. Включение в TOGAF предметной области архитектуры бизнесаспособствовало дальнейшему росту ее популярности, тогда как для других инфраструктур, укоторых сначала не было архитектуры технологии, началось трудное время разработки этойпредметной области. Например, EUP заимствовала подход, методы и нотацию (UML) RUP,тогда как Захман, Спивак и некоторые другие намеренно поддерживали высокий уровеньабстракции, что негативно повлияло на их восприятие, поскольку они не смогли получитьподдержку технического сообщества.

Компоненты TOGAFГлавным компонентом TOGAF является метод разработки архитектуры (ArchitectureDevelopment 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 и ProjectManagement Body of Knowledge (PMBOK), например, или каких-либо еще методологийуправления проектом), а выбранные проекты реализуются под управлением формальнойархитектуры. На выходе этой фазы мы имеем Архитектурные контракты, которыеутверждаются организацией-разработчиком. Конечным выходом фазы G являются решения,совместимые с архитектурой.

В фазе H акцент переносится на управление изменением основой архитектуры, котораядостигается поставкой реализованных решений. В этой фазе может быть созданоТребование к архитектурному заданию, которое устанавливает цели для последующихциклов реализации архитектуры предприятия.




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

Помимо метода ADM и Континуума предприятия, TOGAF предоставляет дополнительныересурсы и ссылки, относящиеся к методам, технологиям и решениям, которые можноиспользовать для планирования и реализации архитектуры предприятия.

Можно ли отнести TOGAF к итеративным инфраструктурам?Как видно из рисунка 10, TOGAF - итеративный процесс. Итерации TOGAF (которые гораздочаще называются циклами) обычно отличаются большей длительностью, чем итерации RUP,и объединяют несколько фаз реализации и обслуживания архитектуры предприятия. Это неудивительно, так как область охвата архитектуры предприятия шире области охвата одногопроекта RUP.

Управление требованиями и TOGAFКак видно из рисунка 10, TOGAF - это процесс, буквально сосредоточенный на требованиях.Управление требованиями метода ADM работает с любыми видами требований, особеннос требованиями к направляющим механизмам бизнеса, участникам, а также требованияминовых функциональных возможностей и изменения. И последнее, хотя и не менее важное:поскольку архитектурные требования являются субъектами постоянного изменения,управление требованиями ведется на протяжении всего жизненного цикла реализацииархитектуры предприятия.

TOGAF и другие методологииВ современной организации TOGAF приходится сосуществовать с другими методологиями,процессами и инфраструктурами. С некоторыми из них, например, с процессом RUP,у нее нет общих областей применения, в то время как с другими, например, EUP иинфраструктура (схема) Захмана, области применения пересекаются на некоторых отрезкахжизненного цикла.

Где TOGAF встречается с RUPИногда кажется, что 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 - в качестве атрефакта процесса представления;9

• Используйте ИЗ для настройки структур передачи артефактов между другимиметодологиями решений, такими, как RUP и/или Библиотека инфраструктуры ИТ (ITInfrastructure Library, ITIL), и TOGAF;

• Применяйте инфраструктуру Захмана для анализа просчетов существующего процессапредприятия и бизнес-модели в процессе или до реализации TOGAF;

• Используйте ИЗ для метаанализа TOGAF, который может способствоватьидентификации слабых мест и возможностей взаимодействия с другимиметодологиями;

• Используйте ИЗ как средство разработки моделей архитектуры предприятия TOGAF

(TOGAF фазы B-D).10

TOGAF и EUPХотя и 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 MethodComposer или MyRUP, ни такой комплексной библиотеки периодических изданий.

Зрелые организации, особенно те, которые в повседневной работе используют управлениепроектами и методологию жизненного цикла программного обеспечения (PMBOK, RUP,Scrum и ITIL) обычно добиваются большего успеха в реализации архитектуры предприятия.Можно порекомендовать сотрудникам организации перед тем, как включить в свойинструментарий TOGAF, хорошо изучить несколько методик, нотаций и методологийжизненного цикла программного обеспечения из тех, что показаны на рисунке 13.




Рисунок 13: План-график реализации TOGAF

Среди прочих потенциальных угроз успешной реализации TOGAF - отсутствие стандартногоинструмента для фиксации и управления артефактами архитектуры предприятия и

остутствие стандартной нотации.8

Быть или не быть TOGAF?Прежде всего организации следует решить, реализовать ли архитектуру предприятияв общем, реализация TOGAF в частности - это следующий этап в ее развитии. Частоорганизации, которые успешно и последовательно используют методологию жизненногоцикла решений (например, RUP), расценивают реализацию архитектуры предприятия какследующую ступень своего развития.

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

технологии.9

Если вы не уверены в том, что TOGAF вам подойдет, хорошо бы провести ее тест-драйвв вашей организации. В таком испытании может принять участие группа энтузиастов -архитекторов бизнеса и решений. Важно, задействовать специалистов из техническойи бизнес-сферы, чтобы обеспечить равновесие интересов. Обратите также вниманиена то, что для успеха реализации архитектуры предприятия необходима надежнаяподдержка коллектива организации. Эта поддержка может быть гарантирована путемвключения в группу архитектуры предприятия членов коллектива исполнителей в качествепредставителей, или закрепив за архитектором предприятия место в руководящем комитетеорганизации.

БлагодарностиХочу выразить благодарность Джейсону Аппелу (Jason Uppal), сертифицированному OpegGroup по TOGAF ведущему архитектору # 1, который заинтересовал меня этой темой,а также Дэвиду Бентли (David Bentley) и Джону Ридингу (John Reading) за поддержку иобратную связь.




Примечания1 См. http://www.ibm.com/developerworks/library/ar-togaf1/.

2 Инфраструктура Enterprise Unified Process (EUP) - главный источник информацииоб архитектуре предприятия. Посетите официальный Web-сайт EUP по адресу http://www.enterpriseunifiedprocess.com/, чтобы получить дополнительную информацию обинфраструктуре EUP.

3 Недавно опубликованная статья автора "UML, RUP, and the Zachman Framework: Bettertogether" (UML, RUP и инфраструктура Захмана - вместе лучше) (http://www.ibm.com/developerworks/rational/library/nov06/temnenco/index.html) предлагает инновационные методыобъединения самых важных методологий, которые появились в прошедшее десятилетие.

4 См. http://www.gartner.com/DisplayDocument?doc_cd=130855&ref=g_fromdoc.

5 Web-сайт Open Group (http://www.opengroup.org/togaf/) - самый комплексный источникинформации об инфраструктуре TOGAF.

6 Дополнительную информацию по этому и следующему пункту можно найти в статье "UML,RUP, and the Zachman Framework: Better together" (UML, RUP и инфраструктура Захмана -вместе лучше).

7 В статье "ADM and the Zachman Framework" (Метод ADM и инфраструктура Захмана) (http://www.opengroup.org/architecture/togaf8-doc/arch/chap39.html) приводится сопоставлениеметода разработки архитектуры (ADM) TOGAF с инфраструктурой Захмана.

8 По адресу http://www.agilemodeling.com/essays/realisticUML.htm можно ознакомиться смыслями Скота Амблера (Scott Ambler) по поводу того, достаточно ли нотации UML дляцелей моделирования решений и предприятия.

http://www.ibm.com/developerworks/library/ar-togaf1/

http://www.enterpriseunifiedprocess.com/

http://www.enterpriseunifiedprocess.com/

http://www.ibm.com/developerworks/rational/library/nov06/temnenco/index.html

http://www.ibm.com/developerworks/rational/library/nov06/temnenco/index.html

http://www.gartner.com/DisplayDocument?doc_cd=130855&ref=g_fromdoc

http://www.opengroup.org/togaf/

http://www.opengroup.org/architecture/togaf8-doc/arch/chap39.html

http://www.opengroup.org/architecture/togaf8-doc/arch/chap39.html

http://www.agilemodeling.com/essays/realisticUML.htm




Об авторе

Виталий Темненко

Виталий Темненко (Vitalie Temnenco) - разработчик архитектуры из Онтарио(Комитет безопасности и страхования на рабочем месте правительства Канады),где он занимается обучением разработке архитектуры в проектах реализациии оказывает коллективам помощь во внедрении RUP и в разработке концепцийархитектуры предприятия. Его профессиональный опыт включает разработкуархитектуры и построение решений для клиентов в различных сферах бизнеса,таких, как банковский бизнес, финансы, страхование, розничная торговля ителекоммуникации. Сейчас он обучает клиентов эффективно использоватьUML и RUP для анализа систем и бизнеса, а также проектировать новыесистемы. В свободное время Виталий пишет статьи о редких, нестандартныхи инновационных вариантах применения методологий, инфраструктур итехнологий. С ним можно связаться по электронной почте: [email protected]

© Copyright IBM Corporation 2007(www.ibm.com/legal/copytrade.shtml)Торговые марки(www.ibm.com/developerworks/ru/ibm/trademarks/)

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/developerworks/ru/ibm/trademarks/

Date post:	13-Jul-2020
Category:	Documents
Upload:	others
View:	18 times
Download:	0 times

архитектуры предприятия за границы RUP Быть или не быть...

Documents