Применение архитектурных подходов в сфере информационных технологий

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

Подводя итог рассмотрению данного стандарта, можно сделать вывод о том, что стандарт предъявляет требования к моделям предприятий и методологиям моделирования, но не является описанием какой-либо одной или нескольких методологий.

Одним из важнейших итогов последних лет в области стратегии использования ИТ и проектирования систем уровня предприятия стало выделение архитектурного подхода в качестве необходимого и приоритетного [ (Trends in Enterprise Architecture 2005: How are Organizations Progressing? IFEAD Report of the Third Measurement, 2005)]. Происходит резкий рост числа предприятий (предприятий в смысле АП и международных стандартов), активно работающих с АП. Это касается предприятий всех масштабов и отраслей, коммерческих компаний и государственных органов - от отдельных агентств до международных организаций. Вопрос о том, что полномасштабное использование АП действительно дает принципиально новые возможности, практически уже не дискутируется (при этом продолжается изучение способов количественного измерения добавочной ценности, создаваемой применением АП). Заключение исследования распространения и применения дисциплины АП в мире (проведенного уже третий раз) включает в себя, в том числе, следующие выводы (см. [ (Trends in Enterprise Architecture 2005: How are Organizations Progressing? IFEAD Report of the Third Measurement, 2005)]):

• АП используется не только в больших, но и малых организациях (от 100 до 1000 работающих) и на предприятиях всех отраслей, причем программы e-Government стимулируют развитие АП в частном секторе и наоборот.
• АП используется не как "системная архитектура" в смысле архитектуры информационных систем (ИС), но как инструмент стратегического управления; при этом из инструмента ИТ-директора и CIO, используемого только для планирования ИТ и создания ИС, она стала инструментом и областью ответственности Советов Директоров, применяемым, в том числе, для планирования изменений в организации.
• Организации, относящиеся к АП серьезно, имеют в штате позиции "Архитектора предприятия" и Архитекторов других областей своей деятельности, причем внешние консультанты-архитекторы могут играть роли "тренеров", "помогающих и дополняющих", но не заменяющих этих внутренних Архитекторов компаний - Заказчиков ИТ.
• Разворачивание АП как профессиональной дисциплины все еще продолжается,  продолжается сдвиг от технологических вопросов к обще-деловому спектру проблем, растут потребности в образовании и тренинге в области АП.
• Все больше организаций определяют свою собственную общую, "рамочную" (framework) схему АП вместо использования или простой адаптации существующих схем.
• При работе с АП в большинстве случаев продолжают использоваться простейшие "настольные" инструменты (типа офисного пакета или графического дизайнера), хотя использование сложных репозиториев АП растет.
• В части архитектурной работы с бизнес-процессами широко используются принятые техники моделирования бизнес-процессов, при этом BPML является стандартом.
• OMG MDA и UML широко используются для моделирования ИС.

Что касается п. 4 этих выводов, надо заметить, что в США (где использование АП наиболее распространилось) уже имеет некоторую историю углубленное преподавание АП, включая изучение сложных многомерных общих схем АП. Это важно отметить в связи с п. 5 выводов по следующей причине.

Устройство общих схем (frameworks) АП достаточно сложно, достаточно полная схема АП по своей сути является многомерной структурой, в которой можно выделить до 6-ти и более относительно независимых измерений. В связи с этим ежедневная практическая работа и, в особенности, необходимость демонстрации АП бизнес-менеджерам требуют внешне упрощенных представлений. По этой причине организации с разной профессиональной культурой будут разрабатывать близкие им упрощенные варианты схем АП. Однако понимание зависимостей, скрытых в этих упрощенных представлениях, работа с этими зависимостями требуют от архитекторов образования в данной области на глубоком, желательно "классическом университетском" уровне.

Одним из важных итогов и одновременно одной из тенденций развития АП является появление сервисно-ориентированной АП (не путать с SOA). Она отличается фокусированием АП в целом и ее элементов на предоставление услуг (сервисов) и на работе с сервисами как с центральным архитектурным элементом. Заметим, что такая АП существенно шире, чем SOA, она охватывает сервисное осмысление и представление бизнеса как такового, а также некоторые сервисные структуры вычислительных ресурсов – SOC (Services Oriented Computing). Вместе с тем, сервисно-ориентированная АП может рассматриваться как одно из упрощений ЕА, достигаемое за счет достаточно сильного упрощения некоторых архитектурных аспектов и измерений, в том числе, выходящих за рамки текущего понимания сервисного подхода. 

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

Возможно, наиболее сложными при внедрении АП являются проблемы человеческого фактора, а именно: преодоление консерватизма как традиционных управленцев, так и ИТ-специалистов, которым, во-первых, надо оперировать новыми понятиями, во-вторых, мыслить, выходя за границы своих обычных представлений о целях и масштабах выполняемой работы, в-третьих, уметь работать "на равных" за общим столом. Надо принимать во внимание и условно технические проблемы, в частности, необходимость в формировании общего профессионального языка и соответствующего словаря. Однако последние проблемы вполне решаемы, примером может служить словарь терминов в области АП и e-Government, разработанный Фондом ФОСТАС, который, например, уже взят на вооружение Сообществом ИТ-директоров Украины в качестве ядра для создаваемого АП глоссария.

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

За последние 3-5 лет в мире в области стратегии использования ИТ и проектирования систем уровня предприятия произошел переход к широкому практическому использованию дисциплины "Архитектура Предприятия" на качественно новом уровне рассмотрения действительно комплексной архитектуры, не ориентированной только на ИТ. Это касается предприятий всех масштабов и отраслей, коммерческих компаний и государственных органов. АП используется не как "системная" и/или "ИТ-архитектура" (в смысле архитектуры информационных систем, ИТ-инфраструктуры и т.п.), но как инструмент стратегического управления предприятием. При этом из инструмента ИТ-директора и CIO она стала инструментом и областью ответственности Советов Директоров, применяемым, в том числе, для планирования изменений в организации.

 

 

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Defining Architecture for IT: А Framework of Frameworks. (2002). Gartner.
2. Enterprise Solution Patterns Using Microsoft .NET. (06 2003 r.). Получено 1 06 2011 r., из http://msdn.microsoft.com: http://msdn.microsoft.com/en-us/library/ff647095.aspx
3. Introduction to Service-Oriented Architecture. (2003). Gartner.
4. J.Schekkerman. (2004). Enterprise Architecture Validation, ,Revised Version.
5. Microsoft Application Architecture Guide, 2nd Edition. (2009). Получено 01 10 2011 r., из http://msdn.microsoft.com: http://msdn.microsoft.com/en-us/library/dd673617.aspx
6. Monin, B. (2007). SAFE House, Book. Получено 01 10 2011 r., из http://www.safe-house.org: http://www.safe-house.org/SH-Book/safe-house-book.htm
7. Platt, M. (07 2002 r.). Microsoft Architecture Overview. Получено 01 10 2011 r., из http://msdn.microsoft.com: http://msdn.microsoft.com/en-us/library/ms978007.aspx
8. Rechtin, E. (1991). Systems Architecting, Creating and Building Complex Systems. Prentice-Hall.
9. The Pillars of Enterprise Architecture Terminology. (2002). Giga.
10. А. Данилин, А. С. (2005). Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия. Москва.
11. Аншина, М. (2008). Из чего сделана архитектура предприятия? Открытые системы , http://www.osp.ru/os/2008/08/5661468/.
12. Галактионов, В. И. (2002). Системная архитектура и ее место в архитектуре предприятия. Директор информационной службы , №5.
13. М. Ибрагим, Г. (25 03 2008 r.). Сервис-ориентированная архитектура и архитектура предприятия: Часть 1. Взаимодействие SOA и EA. Получено 6 10 2011 r., из Сайт компании IBM: http://www.ibm.com/developerworks/ru/library/ws-soa-enterprise1/index.html
14. Р.Сешнс. (05 2007 r.). http://msdn.microsoft.com/. Получено 10 10 2011 r., из Сравнение четырех ведущих методологий построения архитектуры предприятия: http://msdn.microsoft.com/ru-ru/library/ee914379.aspx
15. ГОСТ Р ИСО 15704-2008. Промышленные автоматизированные системы. Требования к стандартным архитектурам предприятия и методологиям. М.: Стандартинформ, 2010.
16. Mullender, M. and M. Burner Application Architecture: Conceptual View, 2003
17. Burbeck, S. The Tao of E-Business Services, 2004, IBM

 

 

 

 

 

 

ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ

Cистемная архитектура, 19

Архитектура информационной системы, 18

Архитектура информационных технологий (ИТ), 13, 19

Архитектура предприятия, 14, 24

методики построения

ADM, 86

методологии

TOGAF, 85

Архитектура федеральной организации, 24, 70

ИСО 15704, 26

модель FEAF, 63

модель GERAM, 26

модель IBM, 98

модель Захмана, 80

подход Gartner, 100

подход Microsoft, 91

методологии, 24

подходы к разработке, 39

стадии зрелости, 76

эволюция понятия, 22

Архитектура прикладных систем, 16

Архитектура приложений, 20

Архитектура программного обеспечения (Software Architecture). См. Программная архитектура

Архитектура систем  (System Architecture). См. Системная архитектура

Архитектура уровня отдельных проектов, 16

Архитектурные  шаблоны, 93

Архитектурные концепции, 93

Домен архитектуры, 11, 62

Зрелая архитектура предприятия, 102

ИТ-архитектура, 23, См. Архитектура ИТ

Континуум предприятия, 87

Корпоративная архитектура. См. Архитектура предприятия

Описание архитектуры (architecture description), 18

План миграции, 36

Предметные области архитектуры. См. Домен архитектуры

Программная архитектура, 19

Концептуальная архитектура, 20

Логическая архитектура, 20

Уровни описания, 20

Физическая реализация, 20

Проектно-ориентированная перспектива архитектуры, 58

Рамочная модель (framework), 14

рхитектура предприятия

модели

ИСО 15704, 26

Сервис-ориентированная архитектура (Service-oriented Architecture, SOA), 5

Системная архитектура, 104

Справочная (эталонная) модель, 68

Стандартная архитектура предприятия, 104

Стратегическая архитектура, 102

Тактическая архитектура, 102

Тактическая архитектура предприятия, 102