Архитекторам - на заметку (а лучше - для штудирования)
System Architect, Solution Architect, Product Architect - слова ласкающие слух многих разработчиков ;) К сожалению, многоопытность не всегда избавляет от изобретения велосипеда. Конечно, хотелось бы учиться на чужих ошибках. Так называемые "лучшие практики" (best practices) и "шаблоны проектирования" (design patterns, не забывая об antipatterns - как типовых "граблях") являются одними из таких инструментов. Отсюда и интерес ко всяческого рода фреймворкам. Но не только. Нахождение общего языка всегда была головной болью ИТ. А стандарты и практики с патернами дают общий глоссарий такого языка.
У менеджеров проектов есть PMBOK и PRINCE2, у инженеров в области ПО - SWEBOK, у ИТ -менеджеров - COBIT и ITIL, у процессных специалистов - CMMI. На что же опереться архитектору? Да, есть RUP и EUP, уделяющие специальное внимание архитектуре, UML как средство описания, Zachman Framework , да тот же ANSI/IEEE 1471 и ... все, что ли? - "так думают многие и ошибаются" ;). Есть существенно более фундаментальные источники. Причем, становящиеся все более значимыми, как ни странно, на волне SOA - концепции, идеологически охватывающей совокупный взгляд на бизнес- и ИТ-архитектуру. Вот эти ключевые фреймворки (как показал мой опыт общения, не претендующий на статистически верный, но часто меня расстраивающий - далеко не все, кто по должности является архитектором, даже слышали о них):
У менеджеров проектов есть PMBOK и PRINCE2, у инженеров в области ПО - SWEBOK, у ИТ -менеджеров - COBIT и ITIL, у процессных специалистов - CMMI. На что же опереться архитектору? Да, есть RUP и EUP, уделяющие специальное внимание архитектуре, UML как средство описания, Zachman Framework , да тот же ANSI/IEEE 1471 и ... все, что ли? - "так думают многие и ошибаются" ;). Есть существенно более фундаментальные источники. Причем, становящиеся все более значимыми, как ни странно, на волне SOA - концепции, идеологически охватывающей совокупный взгляд на бизнес- и ИТ-архитектуру. Вот эти ключевые фреймворки (как показал мой опыт общения, не претендующий на статистически верный, но часто меня расстраивающий - далеко не все, кто по должности является архитектором, даже слышали о них):
- Основной и наиболее зрелый архитектурный фреймворк:
The Open Group TOGAF (The Open Group Architecture Framework) - DoDAF (US Department of Defense Architecture Framework):
Volume I: Definitions and Guidelines
Volume II: Product Descriptions - MODAF (UK Ministry of Defence Architectural Framework)
Ярлыки: Enterprise Architecture, SOA
Автор: Сергей Орлик в
13.8.07
Комментарии: 4:
Сергей, есть ещё недописанный Enterprise Architecture Body of Knowledge (EABOK).
Попрошу не путать!
Все перечисленные фреймворки (а кроме перечисленным можно назвать TEAF, FEAF, C4ISR) относятся к Enterprise Architecture - а Enterparise Architect - это отнюдь не System Architect и не Solution Architect. Так что RUP и Zachman - вообще из разной оперы. Zachman как разиз тех "более фундаментальных источников".
Во вторых, кто это назначил TOGAF "основным и наиболее зрелым" среди Enterpsise Architecture фреймворков? Open Group? Отнюдь. Я вот считаю, что Zachman, появившийся в далеком 1980-м, намного более зрелый.
Спасибо за комментарий. Я стараюсь не путать, но мне скорее хотелось подчеркнуть именно сам факт того, что архитекторам часто не хватает знаний матчасти ;) Что касается Zachman Framework (далее ZF) и TOGAF - один из моих аргументов состоит в том, что в развитие ZF вложено существенно меньше ресурсов, чем в TOGAF/DoDAF. В данном случае я убежден, что количество переходит в качество, при том что и качество ресурсов, участвующих в работе The Open Group отнюдь не самое последнее в индустрии.
Конечно, никто не назначал TOGAF более зрелым и значимым. Это мое личное мнение. Степень проработанности ZF (по сравнению с TOGAF/DoDAF) за рамки чисто концептуального взгляда мне кажется недостаточной. И это опять-таки мое мнение.
С уважением,
- Сергей
P.S. Коллеги, буду все-таки крайне признателен за неанонимность комментариев. Всегда приятнее обсуждать интересные вопросы с не менее интереcными людьми открыто - на то она и площадка для обсуждения, на то они и комментарии. В то же самое время, боюсь показаться мнительным, но анонимность, с моей точки зрения, является первым признаком неготовности защищать свою позицию с позиции аргументов, а не эмоций, при этом озвучивая ее в достаточно активной (если не сказать агрессивной манере). Соответственно, я оставляю за собой право удалять анонимные комментарии или перейти к их модерированию в качестве пусть не самого лучшего, но всеже мотиватора открытого обсуждения ;)
Приветсвую всех! Интересная тема :-). Хотелось бы один камешек в огород ZF и в пользу TOGAF таки бросить. Ровно как и позволить себе прокомментировать некоторые statements герра Анонима ...
1. В свое время, в бытность работы в ВТБ, там тоже ставился вопрос о EA и звучал ZF, но когда рабочая группа (в которую я имел честь входить) стала искать МЕТОДИЧЕСКИЕ материалы по этой теме ... то оказалось, что их в свободном доступе НЕТ. Кроме собственно картинки самого ZF :-).
2. Работая в составе команды по разработки ИТ-стратегии для одного крупного российского холдинга, в частности по тематике EA, с интересом отметил, что одна из отечественных консалтинговых фирм, внедряющая повсеместно ERP разных вендоров, которая участвует в этом проекте на ряду с западными консалтинговыми компаниями, тоже активно стала обсуждать тему ZF. И тоже НИЧЕГО кроме этой картинки, не смогла ТОЛКОМ пояснить, а когда их попросили предоставить методику ... вобщем она до сих пор не представлена :-). Результат -- за основу взят TOGAF, т.к. в нем как минимум есть определения архитектур, есть описание ADM (собственно того что нужно делать чтобы разрабатывать ту самую EA).
Более того, в том же TOGAF перечислены основные skills, для ролей при разработке EA, которые при соответствующей адаптации вполне usable. Этого нет в ZF и в помине.
Кроме этого ... хотел бы возразить, что System Architecture ни как не соотноситься с EA. Если почитать литературу и собственно фреймворки, то можно встретить например обобщение -- когда под объединением Архитектуры приложений, Архитектуры данных, Технологической архитектуры используют термин "ИТ-архитектура" или "Системная архитектура". Так что уже таки связь есть :-).
RUP не претендует на уровень EA, это "уровень", лежащий под Архитектурой приложений. Собственно фреймворк для разработки тех самых приложений. Если хотите, то RUP с определенной степенью апроксимации можно рассматривать как отображение EA на конкретне приложения. И естсественно, EA может накладывать свои ограничения проектирования на Программную архитектуру конкретного приложения. И если обратить внимание на состав дисциплин RUP, то там можно увидеть и Business modelling и требования и ту же архитектуру (программную) ... не правда ли возникают определенный ассоциации с принципами EA и тема "отображения" становиться не такой уж притянутой :-).
А уж если посмотреть на практику ... как например во многих отчественных организациях, заводах, где вся совокупность информационных систем рассматривается как Единая система (суперсистема), а отдельные приложения -- как подсистемы ... то лишний раз наводит на мысль о практической близости (или точнее ВЛОЖЕННОСТИ) понятий Системной архитектуры и EA.
Юрий Булуй aka byur
Отправить комментарий
Подпишитесь на каналы Комментарии к сообщению [Atom]
<< Главная страница