РефератПерспективы развития средств проектирования архитектуры предприятия

Содержание:

Введение

Эффективное планирование и реализация ИТ-стратегии сегодня связываются с использованием дисциплины Enterprise Architecture (Архитектура Предприятия - АП) и комплексного архитектурного подхода, а также со сквозным сервисно-ориентированным проектированием (ССП) - от бизнес-сервисов до технических ИТ-сервисов. На этом пути в результате последовательного, идущего как бы шаг за шагом процесса за последние 5-7 лет достигнуты действительно качественно новые рубежи, получены практически важные для бизнеса и для ИТ результаты. Однако результаты далеко не так просты, как это иногда представляют, и их освоение и применение с получением существенной пользы не так очевидно. Часто наблюдается досадная смесь рекламных заявлений, преувеличенных надежд и реальности. На практике существует ряд негативных факторов, во многих ситуациях сводящих полученные принципиально новые результаты к уровню появления очередной новинки или новой инструментальной "серебряной пули".

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

"Тихая революция" архитектуры предприятия: мировые итоги и тенденции

Одним из важнейших итогов последних лет в области стратегии использования ИТ и проектирования систем уровня предприятия стало выделение архитектурного подхода в качестве необходимого и приоритетного [1]. Происходит резкий рост числа предприятий (предприятий в смысле АП и международных стандартов), активно работающих с АП. Это касается предприятий всех масштабов и отраслей, коммерческих компаний и государственных органов - от отдельных агентств до международных организаций. Вопрос о том, что полномасштабное использование АП действительно дает принципиально новые возможности, практически уже не дискутируется (при этом продолжается изучение способов количественного измерения добавочной ценности, создаваемой применением АП). Заключение исследования распространения и применения дисциплины АП в мире (проведенного уже третий раз) включает в себя, в том числе, следующие выводы (см. [1]):

1.  АП используется не только в больших, но и малых организациях (от 100 до 1000 работающих) и на предприятиях всех отраслей, причем программы e-Government стимулируют развитие АП в частном секторе и наоборот.

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

3.  Организации, относящиеся к АП серьезно, имеют в штате позиции "Архитектора предприятия" и Архитекторов других областей своей деятельности, причем внешние консультанты-архитекторы могут играть роли "тренеров", "помогающих и дополняющих", но не заменяющих этих внутренних Архитекторов компаний - Заказчиков ИТ.

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

5.  Все больше организаций определяют свою собственную общую, "рамочную" (framework) схему АП вместо использования или простой адаптации существующих схем.

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

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

8.  OMG MDA и UML широко используются для моделирования ИС.

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

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

АП в России: положение и сценарий развития

Говоря о развитии и перспективах АП в России можно отметить, что уже цитированный анализ мирового применения АП в 2005 году показал:

 - около 8% организаций, охваченных исследованием в области АП, имели нахождение в России, где отмечается начало и рост применения АП;

-  по уровню реального интереса к АП Россия не вошла в группу первых 20 стран, оставшись позади Китая (14 место), Бразилии и Испании (19 и 20 места).

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

Можно предположить, что период заметного отставания России в этой области продлится не менее, а скорее более пяти лет, причем это отставание может быть преодолено (не в количественном, а хотя бы в идейном смысле) при выполнении нескольких условий:

- сложность создаваемых систем (как управленческих, так и ИТ) и проблемы преодоления этой сложности, заставят высшее руководство коммерческих компаний и органов государственной власти (как "в центре", так и "на местах") искать адекватные средства управления, в числе которых АП окажется неизбежно; проблемы управления предприятиями, включая предоставление услуг внешним заказчикам и внутренним подразделениям, будут решаться с учетом передового мирового опыта (lessons learned), полученного в сфере АП и ССП. понизится острота организационных проблем, которые возникают в коллективах при введении на предприятиях "архитектурных" должностных позиций и подразделений, университеты-лидеры незамедлительно начнут включать в учебные планы дисциплины, связанные с АП и ССП и разрабатывать соответствующие полноценные учебно-методические комплексы, причем не только для ИТ-специальностей, но и для экономических и управленческих специальностей (похоже, что этот процесс уже начался силами кафедр и УМО нескольких известных авторам университетов); не только на позиции архитекторов АП и CIO, но и на позиции директоров по развитию в организациях начнут приходить люди, имеющие достаточное образование в данной сфере (в том числе, полученное в режиме дополнительного образования и тренингов), а также имеющие индивидуальные способности к специфической архитектурной работе в данной области.

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

Факторы сложности АП - многомерность общих архитектурных схем АП

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

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

Среда и качества бизнес-сервисов

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

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

Различение и определение в бизнес-сервисе непосредственного результата (output), конечного результата (outcome) и итогового воздействия (impact) является необходимым требованием для планирования и мониторинга эффективности и результативности бизнеса и инвестиций в сервисы, в том числе в ИТ-системы, их выполняющие и/или поддерживающие. Вместе с тем, также важны характеристики действия (процесса), вырабатывающего результат.

Возможности и проблемы дополнения правил проектирования эталонными моделями сервисов

Референсная модель для SOA, предлагаемая в драфте [3], задает абстрактные общие требования, необходимые для понимания того, как выделяются важнейшие сущности (entities) и связи между ними в сервис-ориентированной среде. Этого недостаточно для решении конкретных задач проектирования, поскольку для этого требуется выделить несколько точек зрения на сервисно-ориентированную среду, определить механизм согласования этих точек зрения между собой и предложить эталонные модели, которые будут использоваться для выработки конкретных проектных решений, применительно к выбранным точкам зрения.

Для показа возможностей и проблем поддержки отображений сервисов "верхних" уровней в сервисы более "нижних" уровней воспользуемся моделями BRM, SRM и TRM, разработанными для поддержки общей схемы АП в варианте FEAF.

Характеристики и возможности совокупности эталонных моделей FEAF таковы:

- сервисы являются базовым элементом каждой из моделей: BRM (Business Reference Model), SRM (Service Component Reference Model), TRM (Technical Reference Model),

- идея сквозной связи сервисов, представлена в схемах взаимосвязи указанных моделей в рамочной схеме АП FEAF и в модели FEA PRM (Performance Reference Model) [1],

- бизнес-сервисы вводятся в BRM, но на очень высоком уровне агрегации и обобщения сервисов (при этом конкретное наполнение в первую очередь этой модели ориентировано на бизнес-сервисы органов государственной власти),

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

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

В итоге, возникает схема проектирования, в которой:

- стандарт ИСО/МЭК 15288 используется для организации ССП в целом: сквозного сервисного проектирования на пространстве от бизнес-сервисов до базовых технических ИТ-сервисов; при этом он не охватывает стадию проектирования сервисного предприятия SOE в смысле, описанном выше, из-за чего эту стадию надо включать дополнительно [4],

- "недосказанности" этого стандарта возмещаются возможностями использования согласованных совокупностей моделей сервисов в эталонных архитектурных сервисных моделях (например, моделях FEA),

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

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

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

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

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

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

Заключение

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

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

В настоящее время даже для сравнительно узких предметных областей отсутствуют обоснованные критерии и однозначные правила выделения на предприятии базового набора бизнес-сервисов и определения их характеристик. Анализ многообразия стилей управления на предприятиях показывает, что сервисная трансформация предприятия далеко не всегда нужна и даже не всегда возможна или полезна. Могут существовать предприятия (подразделения организаций), для которых как минимум SOE, а возможно и SOAнерационально или даже вредно.

Анализ содержания действительно крупных зарубежных ИТ-проектов и программ развития последних лет показывает, что все они также в существенной мере выполняются согласно описанным принципам дисциплины "Архитектура предприятия" (Enterprise Architecture). Крупные военные программы (DoD, NATO) и программы «электронных правительств» показывают, что на начальном этапе агентства, ведомства или правительства в целом формируют представительный набор бизнес-сервисов и эталонных моделей, а также выделяют относительно независимые архитектурные эшелоны, в пределах которых ССП может иметь свои отличительные особенности. В рамках эталонных моделей формируются независимые системы бизнес-, прикладных и технических сервисов, а также правила, по которым сервисы этих трех уровней ставятся друг другу в соответствие. Причем, стандартные эталонные модели, например, ISO 14252, ISO 10746, используются наряду с оригинальными моделями.

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

Список литературы:

1. ISO/IEC 15288:2002 "Systems engineering – System life cycle processes".
2. ISO 15704:2000 "Requirements for enterprise-reference architectures and methodologies"
3.   ГОСТ Р ИСО/МЭК ТО 10000 – 1 – 99. Информационная технология. Основы и таксономия международных функциональных стандартов. Общие положения и основы документирования.
4. Кознов, Д. В. Особенности проектов в области разработки корпоративной архитектуры предприятий / Д. В. Кознов, М. Ю. Арзуманян, Ю. В. Орлов, М. А. Деревянко, К. Ю. Романовский, А. А. Сидорина // Бизнес-информатика. — 2017. — № 4(34).
5. Зеленков, Ю. А. Методология формирования ИТ-стратегии организации на основе ее бизнес-модели / Ю. А. Зеленков // Стратегии бизнеса. — 2016. — № 5(7).