ЛЕКЦИЯ 8 45 страница

Устройство общих схем (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

Дата добавления: 2015-04-25