Файл: РефератПерспективы развития средств проектирования архитектуры предприятия.pdf

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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