V Международная практическая конференция "Стандарты в проектах современных информационных систем"
Батоврин Виктор Константинович, зав. кафедрой ИС МИРЭА, ведущий консультант Фонда ФОСТАС, Москва e-mail:batovrin@mirea.ru
Зиндер Евгений Захарович, президент Фонда ФОСТАС, директор аналитического бюро "Группа-24", Москва e-mail:ezinder@fostas.ru
http://www.fostas.ru/library/show_section.php?id=71
Могут существовать и другие схемы отображения сервисов (не обязательно выраженные в сквозной "сервисной" терминологии), они могут быть более конкретны, предполагать большую степень готовности применяемых модельных заготовок и правил отображения. Тем не менее, использование любой формы представления таких взаимосвязей с указанием конкретных видов сервисов начинает накладывать ограничения на проектирование, на выбор конструктивных элементов нижних уровней для реализации более "верхних", логических архитектурных элементов, а также "верхних" в смысле АП.
Батоврин Виктор Константинович, зав. кафедрой ИС МИРЭА, ведущий консультант Фонда ФОСТАС, Москва e-mail:batovrin@mirea.ru
Зиндер Евгений Захарович, президент Фонда ФОСТАС, директор аналитического бюро "Группа-24", Москва e-mail:ezinder@fostas.ru
http://www.fostas.ru/library/show_section.php?id=71
Аннотация
Эффективное планирование и реализация ИТ-стратегии сегодня связываются с использованием архитектурного подхода и сквозным сервисно-ориентированным проектированием (ССП) - от бизнес-сервисов до технических ИТ-сервисов. На этом пути за последние 5-7 лет достигнуты действительно качественно новые рубежи, на этих рубежах получены практически важные для бизнеса и для ИТ результаты. Однако результаты далеко не так просты, как это иногда представляют, и их освоение не так очевидно. Наблюдается смесь рекламных заявлений, преувеличенных надежд и реальности. Такие факторы связаны с неадекватными упрощениями архитектурного подхода, с частичным выполнением процесса ССП, с подменой ССП "внедрением" сервисно-ориентированной архитектуры ИС (SOA), применением SOA за рамками ее уместного использования. Для России типична подмена комплексной архитектуры предприятия (АП) т.н. "системной архитектурой" и недооценка роли архитектора предприятия-Заказчика. В связи с этим в докладе представлены итоги глобального анализа состояния и тенденций применения АП в мире, включая Россию.
При применении ССП есть проблемы в области непосредственного проектирования и реализации ИС, связанные с недостаточным обеспечением проектировщиков методиками определения бизнес-сервисов, их отображения на конкретные прикладные и базовые ИТ-сервисы. В связи с этим в докладе анализируются основные объекты и работы ССП - начиная с определения бизнес-сервисов и проектирования сервисно-ориентированного предприятия, намечаются границы применимости сервисного подхода.
Показываются возможности и границы использования разработанных за последние 5-7 лет рамочных стандартов проектирования и известных эталонных архитектурных моделей, ориентированных на представление сервисов разных уровней.
Введение
Эффективное планирование и реализация ИТ-стратегии сегодня связываются с использованием дисциплины Enterprise Architecture (Архитектура Предприятия - АП) и комплексного архитектурного подхода, а также со сквозным сервисно-ориентированным проектированием (ССП) - от бизнес-сервисов до технических ИТ-сервисов. На этом пути в результате последовательного, идущего как бы шаг за шагом процесса за последние 5-7 лет достигнуты действительно качественно новые рубежи, получены практически важные для бизнеса и для ИТ результаты. Однако результаты далеко не так просты, как это иногда представляют, и их освоение и применение с получением существенной пользы не так очевидно. Часто наблюдается досадная смесь рекламных заявлений, преувеличенных надежд и реальности. На практике существует ряд негативных факторов, во многих ситуациях сводящих полученные принципиально новые результаты к уровню появления очередной новинки или новой инструментальной "серебряной пули".
Возможно, наиболее часто звучащими сегодня словами являются "сервис", "сервисно-ориентированное проектирование", "сервисно-ориентированная архитектура" (SOA). Действительно, сквозное сервисно-ориентированное проектирование (ССП), начинающееся с сервисов, как их понимает, например, бизнес и рядовой пользователь услуг бизнеса, во многом завоевало свои позиции. Однако это приносит как целый ряд новых как возможностей, так и не всегда очевидных проблем и требований в деле эффективного проектирования систем. Полноценное использование возможностей требует выполнения достаточно сильных преобразований, которые в первую очередь затрагивают не столько ИТ, сколько само предприятие, требуя перевода его устройства на другой уровень внутренней организации. Однако, эта "тихая революция" часто затеняется выходящими на первый план более "шумными", но частными явлениями (в том числе, распространением такого близкого по духу к ССП и важного явления, как SOA).
В докладе показывается, как связано проектирование сервисно-ориентированой системы - от предприятия в целом до ее ИТ - с современным пониманием сервиса и сквозным последовательным проведением сервисного подхода на всем пути архитектурного проектирования и перехода к реализации систем. Анализируются возможности совместного применения базовых процессных стандартов проектирования (на примере ИСО 15288) и эталонных моделей разных типов для выстраивания целостного подхода к проектированию, не зависящего от конкретной технологии реализации. Показываются границы такого применения, за которыми лежат задачи сервисного проектирования бизнеса, а также конкретные методики проектирования автоматизированных систем, которые могут учитывать характеристики предметной области, упрощая проблемы принятия решений, стоящие перед проектировщиками.
Однако существо дела требует начинать изложение итогов и перспектив вовсе не с сервисного подхода как такового. Попытка изложить итоги и перспективы в области действительно сквозного сервисно-ориентированного проектирования, натолкнулась на то, что с нужной обоснованностью и хотя бы минимальной глубиной это невозможно сделать вне рамок дисциплины Enterprise Architecture (ЕА) - комплексной Архитектуры Предприятия (АП). Это так, поскольку именно АП и соответствующий архитектурный подход дают фундамент для полноценного сквозного сервисно-ориентированного проектирования - от бизнес-сервисов до базовых ИТ-сервисов с учетом окружения тех и других. При этом АП и сквозное сервисно-ориентированное проектирование настолько взаимосвязаны, что "тихая революция" в развитии и применении АП происходила совместно с развитием сквозного сервисно-ориентированного проектирования, в том числе под влиянием ССП и все большей сервисной ориентации самих предприятий.
"Тихая революция" архитектуры предприятия: мировые итоги и тенденции
Одним из важнейших итогов последних лет в области стратегии использования ИТ и проектирования систем уровня предприятия стало выделение архитектурного подхода в качестве необходимого и приоритетного [1]. Происходит резкий рост числа предприятий (предприятий в смысле АП и международных стандартов), активно работающих с АП. Это касается предприятий всех масштабов и отраслей, коммерческих компаний и государственных органов - от отдельных агентств до международных организаций. Вопрос о том, что полномасштабное использование АП действительно дает принципиально новые возможности, практически уже не дискутируется (при этом продолжается изучение способов количественного измерения добавочной ценности, создаваемой применением АП). Заключение исследования распространения и применения дисциплины АП в мире (проведенного уже третий раз) включает в себя, в том числе, следующие выводы (см. [1]):
1. АП используется не только в больших, но и малых организациях (от 100 до 1000 работающих) и на предприятиях всех отраслей, причем программы e-Government стимулируют развитие АП в частном секторе и наоборот.
2. АП используется не как "системная архитектура" в смысле архитектуры информационных систем (ИС), но как инструмент стратегического управления; при этом из инструмента ИТ-директора и CIO, используемого только для планирования ИТ и создания ИС, она стала инструментом и областью ответственности Советов Директоров, применяемым, в том числе, для планирования изменений в организации.
3. Организации, относящиеся к АП серьезно, имеют в штате позиции "Архитектора предприятия" и Архитекторов других областей своей деятельности, причем внешние консультанты-архитекторы могут играть роли "тренеров", "помогающих и дополняющих", но не заменяющих этих внутренних Архитекторов компаний - Заказчиков ИТ.
4. Разворачивание АП как профессиональной дисциплины все еще продолжается, продолжается сдвиг от технологических вопросов к обще-деловому спектру проблем, растут потребности в образовании и тренинге в области АП.
5. Все больше организаций определяют свою собственную общую, "рамочную" (framework) схему АП вместо использования или простой адаптации существующих схем.
6. При работе с АП в большинстве случаев продолжают использоваться простейшие "настольные" инструменты (типа офисного пакета или графического дизайнера), хотя использование сложных репозиториев АП растет.
7. В части архитектурной работы с бизнес-процессами широко используются принятые техники моделирования бизнес-процессов, при этом BPML является стандартом.
8. OMG MDA и UML широко используются для моделирования ИС.
Что касается п. 4 этих выводов, надо заметить, что в США (где использование АП наиболее распространилось) уже имеет некоторую историю углубленное преподавание АП, включая изучение сложных многомерных общих схем АП. Это важно отметить в связи с п. 5 выводов по следующей причине.
Устройство общих схем (frameworks) АП достаточно сложно, достаточно полная схема АП по своей сути является многомерной структурой, в которой можно выделить до 6-ти и более относительно независимых измерений. В связи с этим ежедневная практическая работа и, в особенности, необходимость демонстрации АП бизнес-менеджерам требуют внешне упрощенных представлений. По этой причине организации с разной профессиональной культурой будут разрабатывать близкие им упрощенные варианты схем АП. Однако понимание зависимостей, скрытых в этих упрощенных представлениях, работа с этими зависимостями требуют от архитекторов образования в данной области на глубоком, желательно "классическом университетском" уровне.
Одним из важных итогов и одновременно одной из тенденций развития АП является появление сервисно-ориентированной АП (не путать с SOA). Она отличается фокусированием АП в целом и ее элементов на предоставление услуг (сервисов) и на работе с сервисами как с центральным архитектурным элементом. Заметим, что такая АП существенно шире, чем SOA, она охватывает сервисное осмысление и представление бизнеса как такового, а также некоторые сервисные структуры вычислительных ресурсов – SOC (Services Oriented Computing). Вместе с тем, сервисно-ориентированная АП может рассматриваться как одно из упрощений ЕА, достигаемое за счет достаточно сильного упрощения некоторых архитектурных аспектов и измерений, в том числе, выходящих за рамки текущего понимания сервисного подхода.
АП в России: положение и сценарий развития
Говоря о развитии и перспективах АП в России можно отметить, что уже цитированный анализ мирового применения АП в 2005 году показал:
около 8% организаций, охваченных исследованием в области АП, имели нахождение в России, где отмечается начало и рост применения АП;
по уровню реального интереса к АП Россия не вошла в группу первых 20 стран, оставшись позади Китая (14 место), Бразилии и Испании (19 и 20 места).
Из российской практики известны и другие тенденции, сводящие попытки использования АП к частным, ограниченным областям (ИТ-архитектура, "системная архитектура"). Должности и подразделения, в названиях которых есть слово "архитектура", стали появляться, но не наполняются полноценным содержанием АП. Контакты с представителями соответствующих должностных позиций и подразделений в компаниях показывают, что абсолютное большинство из них находится ниже того барьера, за которым начинается переход от работы с технологической архитектурой к работе с АП как с комплексной архитектурой. В качестве одного из типичных примеров можно назвать известные попытки официально подменить комплексную Архитектуру Электронного Правительства или Электронного Государства в России чем-то, названным "АПО" - Архитектурой Программного Обеспечения.
Можно предположить, что период заметного отставания России в этой области продлится не менее, а скорее более пяти лет, причем это отставание может быть преодолено (не в количественном, а хотя бы в идейном смысле) при выполнении нескольких условий:
1. сложность создаваемых систем (как управленческих, так и ИТ) и проблемы преодоления этой сложности, заставят высшее руководство коммерческих компаний и органов государственной власти (как "в центре", так и "на местах") искать адекватные средства управления, в числе которых АП окажется неизбежно;
2. проблемы управления предприятиями, включая предоставление услуг внешним заказчикам и внутренним подразделениям, будут решаться с учетом передового мирового опыта (lessons learned), полученного в сфере АП и ССП.
3. понизится острота организационных проблем, которые возникают в коллективах при введении на предприятиях "архитектурных" должностных позиций и подразделений,
4. университеты-лидеры незамедлительно начнут включать в учебные планы дисциплины, связанные с АП и ССП и разрабатывать соответствующие полноценные учебно-методические комплексы, причем не только для ИТ-специальностей, но и для экономических и управленческих специальностей (похоже, что этот процесс уже начался силами кафедр и УМО нескольких известных авторам университетов);
5. не только на позиции архитекторов АП и CIO, но и на позиции директоров по развитию в организациях начнут приходить люди, имеющие достаточное образование в данной сфере (в том числе, полученное в режиме дополнительного образования и тренингов), а также имеющие индивидуальные способности к специфической архитектурной работе в данной области.
Добавить оптимизма может тот факт, что для разворачивания АП в пределах конкретной организации нет необходимости ждать, когда указанные проблемы будут решены в масштабах страны. Соответствующие действия могут быть подготовлены и выполнены в течение нескольких месяцев.
Факторы сложности АП - многомерность общих архитектурных схем АП
Возможно, наиболее сложными при внедрении АП являются проблемы человеческого фактора, а именно: преодоление консерватизма как традиционных управленцев, так и ИТ-специалистов, которым, во-первых, надо оперировать новыми понятиями, во-вторых, мыслить, выходя за границы своих обычных представлений о целях и масштабах выполняемой работы, в-третьих, уметь работать "на равных" за общим столом. Надо принимать во внимание и условно технические проблемы, в частности, необходимость в формировании общего профессионального языка и соответствующего словаря. Однако последние проблемы вполне решаемы, примером может служить словарь терминов в области АП и e-Government, разработанный Фондом ФОСТАС, который, например, уже взят на вооружение Сообществом ИТ-директоров Украины в качестве ядра для создаваемого АП глоссария.
Существуют и объективные причины, усложняющие широкое внедрение достаточно развитых общих схем (рамочных схем, frameworks) АП. Важнейшая заключается в том, что многим специалистам нелегко свободно работать даже с трехмерными структурами, а при работе с АП объективно может присутствовать шесть и более актуальных измерений, которые должны быть гармонизированы между собой и с процессами в системе.
Измерения архитектурной схемы, которые включаются в различные рамочные схемы, составляют следующий, не являющийся исчерпывающим список архитектурных "осей":
1. ось "архитектурных аспектов" предприятия или системы (соответствует столбцам матрицы Захмана),
2. ось "представлений" предприятия или системы (соответствует строкам матрицы Захмана),
3. ось времени развития архитектуры предприятия или системы (стадия проектного цикла, стадия ЖЦ системы, витки развития предприятия и этапы этих витков),
4. ось обобщения/конкретизации архитектурных блоков и элементов,
5. ось агрегации/детализации архитектурных блоков и элементов,
6. ось прикладного сегментирования схемы (как, например, в сегментном подходе FEAF).
Измерения, указанные в этом списке, можно обнаружить в схемах, базирующихся и на международных стандартах (ISO 15704 GERAM, CEN ISO 19439), и на стандартах де-факто (в первую очередь - схема Захмана, но также схема FEAF и ряд других), и на схемах включаемых в известные компьютерные системы моделирования (например, такие, как ARIS)
Для свободной работы с этим набором измерений нужен не столько программный инструментарий, сколько соответствующий склад мышления и тренированный навык. Отсутствие таковых является источником многих недоразумений, возникающих при произвольной трактовке соответствующих измерений и связей между ними. При этом известно, что работа с объектами даже только во взаимосвязанных измерениях обобщения и агрегации уже является достаточно сложной для человека.
Однако, подобными осями актуальные измерения архитектурных моделей не исчерпываются. Так, в сложных системах, подобных системам предприятий с диверсифицированным бизнесом и с десятками тысяч человек персонала, для повышения эффективности анализа и синтеза архитектурных решений рассматривают многоуровневые иерархические структуры типа страт или эшелонов, впервые предложенные в теории систем [15]. В реальных проектах число таких архитектурных эшелонов, на которых формируются сравнительно независимые решения, достигает 4-6. При этом уже для верхних эшелонов характерно использование всего арсенала проектирования от технических эталонных моделей до моделей бизнес-процессов, причем на разных эшелонах модели аналогичного назначения могут не совпадать по функционально-структурным характеристикам.
Бизнес-сервисы (услуги)
"Сервисная ориентация представляет собой такое идеальное видение мира, в котором ресурсы четко разделены и последовательно представлены в терминах сервисов".
J. Schekkerman. "Structuring the Enterprise
The Differences between Hype, Hope and Reality?"IFEAD publishing, 2006.
The Differences between Hype, Hope and Reality?"IFEAD publishing, 2006.
Идеология сервисного подхода возникла и закрепилась в системном проектировании по существу, причем эта идеология охватывает все пространство служб, реализуемых в системе. Для архитекторов ИТ-систем этот процесс, возможно, начался с развитием эталонных моделей открытых систем и работ по функциональной стандартизации (профилированию), в которых, по-видимому, впервые применительно к области ИТ, последовательно решалась задача выбора базовых стандартов, обеспечивающих поддержание функциональных возможностей системы, необходимых для реализации определенного сервиса или набора сервисов. Эта идеология даже только для "программно-насыщенных" ИС предусматривает рассмотрение сервисов и других архитектурных элементов в увязке с различными точками зрения на архитектуру системы (например, в терминах IEEE 1471 или TOGAF - в увязке деловой, операционной, технической - "инженерной" или собственно системной точек зрения, и т.д.).
Для сегодняшнего состояния дел в этой области существенно, что современные подходы и стандарты системного проектирования понимают систему, в том числе, и как предприятие (обобщенное) и предусматривают применение сервисной идеологии в той или иной форме с самых первых шагов проектирования предприятия, а также его ИС. При этом первыми и определяющими обычно являются шаги определения бизнес-сервисов самого высокого уровня рассмотрения (а также других бизнес-объектов и внешней деловой среды).
Так, стандарт ISO/IEC 15288 начинает анализ и проектирование системы с выяснения потребностей заинтересованных лиц (ЗЛ), выраженных в "необходимых им сервисах". В контексте проектирования АП речь идет, по сути, о бизнес-сервисах как о продуктах особого рода. (Слово бизнес понимается здесь и далее в наиболее общем смысле, то есть как любое дело, распространяющееся на все виды деятельности людей и не обязательно связанное с извлечением прибыли.) Это особенно важно, поскольку побуждает смотреть на систему не как на ИС в узком ее смысле, а как на автоматизированное предприятие (подразделение, организацию, объединение или кооперацию организаций или их подразделений). Однако отметим наличие и в самих стандартах многих "недосказанностей". Так, тот же стандарт ISO/IEC 15288 не говорит ничего про то, как с бизнес-сервисами связываются сервисы других типов, а выявление потребностей ЗЛ в терминах сервисов не предполагает или в недостаточном объеме предполагает решение специфической проектной задачи преобразования самого предприятия к сервисной форме.
В связи с этим надо уточнить трактовку услуги или сервиса как понятия - по крайней мере, для использования в ССП и в сервисно-ориентированной АП (которая существенно шире SOA). При этом наибольшее внимание мы будем уделять т.н. бизнес-сервисам и вопросам перехода от них к прикладным сервисам ИС.
В отечественной языковой практике, нормативно-правовой, нормативно-методической и технической документации наблюдается большое многообразие трактовок понятия услуги, в частности, услуга может рассматриваться в словарном понимании этого слова или как обязательно платная, иногда - только коммерческая деятельность, как государственная услуга в современной трактовке правительственных документов, как техническая служба в смысле терминологии "открытых систем", как программный сервис прикладной ИС, как Веб-сервис, как сервис СУБД или ОС, и т.п.
При этом многообразие типов сервисов в русскоязычной практике часто пытаются решать, приписывая разный смысл словам услуга, служба и сервис. В этом не было бы беды, если бы проблему различения сервисов разных типов можно было решить так просто или хотя бы предлагаемое таким образом разделение трактовок было стабильным, закрепленным постоянно, а также, если бы не возникали постоянные противоречия при использовании англоязычных источников и, особенно, их переводов. Дело в том, что в тех англоязычных документах, которые чаще всего рассматриваются в качестве исходных (в том числе, в стандартах) используется единственное слово "service". Однако часто приходится наблюдать нарушающие аутентичность переводы этого исходного слова самыми разными, часто несистематизированными и произвольными способами, причем даже в пределах одного документа. Проистекающая от этого путаница в русскоязычных текстах зачастую лишает смысла такой перевод, да и многие оригинальные русскоязычные тексты, которые пишутся с учетом того, что происходит в мировой практике.
Во избежание подобных последствий начиная со следующего раздела здесь употребляется единственное слово "сервис". (Конечно, этим не делается попытка искоренения из ИТ-обихода слов "услуга" и "служба" как таковых.)
Для выбора трактовки в ССП рассмотрим три толкования слова "услуга": общенормативное толкование в русском языке, термин service в ISO 9000:2005 и тот же термин в рамках архитектурного подхода IFEAD и ряда других организаций.
Современная редакция толкового словаря Ушакова первым значением определяет услугу как ДЕЙСТВИЕ, приносящее пользу другому.
По ISO 9000 service - это РЕЗУЛЬТАТ действия. При этом сервис самостоятельно не определяется, но вводится как одна из разновидностей ПРОДУКТА (product), возможно запрошенного заказчиком, хотя явного указания на это нет, но всегда предоставляемого поставщиком заказчику. Для этой разновидности продукта говорится, что в общем случае результат действия носит "нематериальный" (intangible) характер. Однако, трактовка сервиса-услуги именно как результата действия (данная не в определении как таковом, а в примечаниях к определению термина product) даже в рамках этого стандарта не совсем однозначна, т.к. в пояснениях к стандарту service - это в одних случаях транспортировка (процесс), а в других - данное продавцом объяснение (результат).
В трактовке IFEAD (более близкой Ушакову, чем ISO 9000), см. [2], service - это осуществление хорошо определенной деловой функциональности, которая действует независимо от состояния любого другого сервиса, определенного в системе. Сервисы имеют хорошо определенный набор интерфейсов и действуют через предопределенный контракт (Примеч.: т.е. посредством строгого выполнения некоторых соглашений) между клиентом сервиса и самим сервисом. Сервис - это единица работы, выполненной поставщиком сервиса ("сервис-провайдером") для того, чтобы достигнуть желаемых конечных результатов для потребителя сервиса. И поставщик и потребитель - роли, которые играют организационные единицы или программные агенты от имени их владельцев.
С учетом изложенного надо сказать, что сервис (услуга) как результат по сути неотделим от действия (работы, осуществления функциональности), а сервис (услуга) как действие по сути неотделим от результата (пользы, желаемого конечного результата). По указанным выше причинам на архитектурном уровне проектирования сервис (услугу) на наш взгляд целесообразно трактовать следующим образом:
1. необходимо отделить сервис от его описания (по аналогии со стандартом IEEE 1471-2000),
2. описание (модель) сервиса следует рассматривать как комплексный объект, включающий в себя хорошо определенные действие (без требований к детализации внутреннего устройства функций, обеспечивающих действие), правила инициации этого действия и его непосредственный результат, вырабатываемый для получения конечного итога, желаемого потребителем сервиса.
Итак, в данной работе и в ССП принимается вариант более близкий к Ушакову и к IFEAD, поскольку он
1. ближе к реальной практике словоупотребления не только в русском языке, но и в нормативно-методических, методических и технических документах других стран,
2. ближе к содержанию, вкладываемому в термин "service" во многих эталонных архитектурных моделях.
Наконец, учитывая многозначность ситуации, укажем, что результат в сервисе как в комплексе имеет весьма важное и, возможно, превалирующее над действием значение. Более того, при архитектурном проектировании способ выполнения действия практически всегда игнорируется (определяются только интерфейсы), что позволяет применять любой способ непосредственного получения результата, лишь бы получить его (результат) быстрее и лучше.
Вместе с тем, большое внимание уделяется доставке сервиса (service delivery) клиенту (заказчику) и доступу к сервису (service access), причем действия по доставке результата и организации доступу к нему также могут рассматриваться как сервис.
Актуальность рассмотренных вопросов подтверждается тем, что и в начатой разработке эталонной модели сервисно-ориентированной архитектуры SOA [13] проблема понятия сервиса рассматривается отдельно.
Среда и качества бизнес-сервисов
К сервисам имеют отношение также некоторые характеристики внешней среды, с которыми может быть связана реальная выполнимость сервиса и достижение для его потребителя желаемых конечных результатов. Например, реальность, требующая учета при планировании сервисов, может состоять в том, что сервис предоставляется, например, сервис-провайдером, но блокируется в каналах доставки, или сервис предоставляется, но в среде, в которой использование результатов приносит вред вместо ожидаемой пользы. Возможны и другие конфликтные ситуации, существующие в реальной бизнес-среде, отличающейся от идеальной сервисно-ориентированной абстракции.
Независимость сервиса, его определение через интерфейсы и другие его системные свойства, которые выделяют в современном системном сервисном подходе, весьма важны в ССП, но на бизнес-уровне также являются идеализацией, границы разумного применения которой должен определять бизнес.
Различение и определение в бизнес-сервисе непосредственного результата (output), конечного результата (outcome) и итогового воздействия (impact) является необходимым требованием для планирования и мониторинга эффективности и результативности бизнеса и инвестиций в сервисы, в том числе в ИТ-системы, их выполняющие и/или поддерживающие. Вместе с тем, также важны характеристики действия (процесса), вырабатывающего результат.
Пример: сервис (государственная услуга) по выдаче гражданину иностранного паспорта. Для нее нужно определять и оценивать:
1. непосредственный результат (выход) услуги: например, т.н. "заграничный" паспорт, полученный гражданином в результате оказания ему государственной услуги ПВС ФМС РФ или МИД РФ (тут видно, что на самом деле за одной государственной услугой скрывается несколько реально различных услуг); описываются и оцениваются КАЧЕСТВА непосредственного результата («выхода процесса»): правильность указания персональной информации и других паспортных данных, вероятность скрытого брака, параметры соответствия требованиям стран, в которых паспорт должен признаваться, характеристики защищенности (физической, информационной), вероятность физической несовместимости с устройствами чтения (особенно за рубежом) и др.
2. характеристики действия, например, время, за которое услуга оказывается, удобство запуска действия (процесса), возможность контроля потребителя за ходом процесса, охват действием и доступом к нему разных групп населения и территорий, процент рекламаций к выполнению действия (вызванных разными причинами, например, доставкой не по адресу), и др.
3. конечный результат: планируемый эффект, достигаемый потребителем услуги и другими ЗЛ за счет получения и использования непосредственного результата услуги. Например, успешная реализация гражданином своих прав, получение им новых возможностей, получение пользы людьми, пригласившими гражданина в другую страну, и др. То есть описывается и оценивается ЦЕННОСТЬ конечного результата.
Есть и итоговое воздействие, например, экономические, социально-экономические и политические эффекты, которые должны быть определены. В используемом примере - укрепление доверия между народами и государствами (измеряется индексом доверия), установление и укрепление общечеловеческих свобод, ускорение культурного и научного развития стран и граждан, и др.
ССП и сервисно-ориентированное предприятие (SOE). Ограничения подхода
В связи с важностью решения о трактовке понятия сервис (в обобщенном смысле и для бизнес-сервиса) необходимо определить условия, источник и ограничения на возникновение бизнес-сервисов в ССП. Естественно, рассматривается в определенном смысле идеализированная по сравнению с реальным бизнесом картина проектирования, определяемая методиками и стандартами.
В ССП бизнес-сервисы рассматриваются в первую очередь как часть хорошо и особым образом организованного предприятия - сервисно-ориентированного (SOE, Service Oriented Enterprise). Причем, такая организация предприятия в качестве обязательного начального условия не выдвигается, а для того, чтобы она могла возникнуть, выполняется набор специальных мероприятий, в том числе:
1) Адаптация сервисной парадигмы к конкретному предприятию. Предприятия различаются по степени связности работ и жесткости регламентов функционирования подразделений, в том числе - их совместного функционирования. Предприятие может быть очень компактным и работать полностью на самообеспечении или же быть виртуальным предприятием. Жесткость изоляции сервисов и другие их свойства могут в той или иной степени адаптироваться под предприятие.
2) Трансформация предприятия (его значительной части) в сервисно-ориентированное предприятие. Главные требования: независимость (изолированность) бизнес-сервисов, ориентация на измеримые результаты сервисов. В аспекте профессиональной и производственной культуры трансформация рассматривается как обеспечение одного из воплощений клиенто-ориентированности предприятия. По сути организации деятельности с этим связана горизонтальная ориентация процессов, а также легкое связывание бизнес-сервисов между собой. Слабая связанность сервисов, столь важная в SOA, может использоваться для перевода части бизнеса на аутсорсинг или упрощения возможности такого перехода.
3) Формализация бизнес-сервисов и достижение определенного уровня абстракции и агрегации в описании моделей бизнес-сервисов. Целесообразно сохранение этого уровня в пределах всего предприятия, что иногда доводится до принципа: компоненты бизнес-сервиса не являются бизнес-сервисами. Это необходимо для обеспечения изолированности сервисов и для сохранения целостной и однородной, то есть достаточно прозрачной и устойчивой к изменениям картины взаимодействия сервисов. Желательно представление таким образом всех функций/процессов предприятия (его достаточно крупной части).
Если трансформация предприятия и его бизнес-архитектуры в SOE будет оценена как целесообразная, формализация бизнес-сервисов может включать в себя "задел" для выполнения работ по их отображению на уровень прикладных сервисов. Для этого целесообразен акцент на организации информационных потоков, на природе и характеристиках сущностей (entities), участвующих в формировании сервисов и на взаимодействии между ними.
Отметим, что в настоящее время даже для сравнительно узких предметных областей отсутствуют обоснованные критерии и однозначные правила выделения на предприятии базового набора бизнес-сервисов и определения их характеристик (в том числе грануляции, "размера" связанных с ними действий). При осуществленной ориентации предприятия на процессный подход обычно используется подход декомпозиции сверху-вниз. Базовые бизнес-процессы (процессы "верхнего уровня детализации") подвергаются нескольким шагам декомпозиции на более простые бизнес-процессы (бизнес-процедуры), с достаточной для адаптированной парадигмы сервисного подхода степенью изолированности и грануляции. Коренные причины неоднозначности в выделении сервисов аналогичны тем, что порождают неоднозначность выделения самих бизнес-процессов. Однако к ним на каждом шаге добавляются неоднозначности, порождаемые недетерминированными решениями по декомпозиции и неопределенностью будущих требований к грануляции бизнес-сервисов.
Важно, что полученное решение может корректироваться в ходе поиска прикладных сервисов ИС, наилучшим образом поддерживающих информационный аспект бизнес-сервиса.
Практика показывает, что для определения степени грануляции и взаимосвязей между бизнес-сервисами, а в результате, их набора на предприятии методик общего плана недостаточно, целесообразно предлагать специальные методы анализа и синтеза сервисной бизнес-архитектуры для отдельных видов организаций, например, для формирования сервисного представления больших объединений и холдингов.
Следует учитывать, что сервисная трансформация предприятия далеко не всегда нужна и даже не всегда возможна или полезна. Например, при реальных ограничениях предприятия на бизнес-ресурсы обеспечивать независимость, изоляцию бизнес-сервисов друг от друга, как это рекомендуется рядом методик, далеко не всегда возможно. К этому же может привести, например, наличие некоторых сервисов или требований к их выполнению с наивысшим приоритетом, требующим изъятия ресурсов у других сервисов. Требования соблюдения жестких графиков выполнения тех или иных преопределенных комплексов строго взаимосвязанных работ, может лишать смысла изоляцию таких работ, и т.п. Могут существовать предприятия (подразделения организаций), для которых как минимум SOE, а возможно и SOA нерационально или даже вредно. Однозначной общей рекомендации (по крайней мере, на данном периоде развития и бизнеса и ИТ) без учета конкретных особенностей предприятия давать в этом вопросе нельзя. Стоит учитывать наличие больших участков бизнес-структур, отличающихся между собой по характеру производства и стилю управления, например, жесткой дисциплиной, большими детерминизмом и консервативностью процессов. Либо, напротив, большими требованиями к взаимовыручке и требованиями к изменению работ по ходу их выполнения. В конкретных условиях переход на сервисную ориентацию может губительно сказаться на предприятии.
Описанные выше работы по анализу целесообразности SOE и по формированию SOE целесообразно включать в первые стадии проектирования в стиле ССП. В зависимости от результатов их выполнения следует принимать решение о целесообразности построения ИС масштаба предприятия на принципах SOA с использованием соответствующих стандартов и базовых технологий.
От бизнес-сервисов к прикладным и техническим сервисам: проблемы и рамочные стандарты
Дальнейшее изложение не будет повторять достаточно широко тиражируемые материалы по развитию SOA и SOC (Service Oriented Computing). Его задача - показать наиболее принципиальные проблемы ССП и возможности его поддержки существующими стандартами, включая признанные эталонные архитектурные модели, имеющие сервисную ориентацию.
Для решения задачи определения взаимосвязей между бизнес- и прикладными сервисами приходится предлагать специальные методы анализа и синтеза "сквозной" сервисной архитектуры. Эта работа для больших организаций, как правило, весьма объемна и сложна. Примером может служить набор нормативных документов министерства обороны США по основам архитектурного проектирования (DoD Architecture Framework), где вопросам связывания между собой сервисов различных типов и уровней посвящено несколько сот страниц.
Считается принятым, что развитые архитектурные схемы явно или неявно предполагают наличие как минимум двух типов функциональных компонентов, играющих роль сервисов как "компьютерных" архитектурных элементов: набор разновидностей
(а) прикладных сервисов ИС и
(б) базовых ИТ-сервисов (технических сервисов).
При этом существенно, что сервисы этих архитектурных слоев не являются ни конкретизацией/обобщением, ни непосредственной агрегацией/детализацией друг друга.
Сквозной принцип ССП предполагает проектирование, основанное на отображении бизнес-сервисов в прикладные сервисы ИС, с дальнейшим отображением прикладных сервисов в базовые ИТ-сервисы. При этом требуется искать такие отображения, которые позволяют спроектировать эффективную в заданном смысле архитектуру ИС и затем реализовать ее с получением эффективной действующей ИС. Поэтому прикладные и базовые ИТ-сервисы обычно структурируются на множество видов и подвидов сервисов разного назначения, составляющих достаточно богатый выбор архитектурных элементов соответствующего архитектурного слоя. Из этого набора сервисов-элементов в основном и выбираются те, в которые производится отображение.
Конечно, ССП предполагает использование в проектировании методов отображения не только "сверху вниз", но и "снизу вверх". Более того, такое направление проектирования может существенно влиять на выбор границ и устройства бизнес-сервисов. Иногда такая обратная связь от ИТ к бизнес-процедурам и процессам позволяет революционно улучшить характеристики бизнес-процессов. Наиболее ярким примером является идентификация, выбор и всестороннее определение бизнес-сервисов в области электронного бизнеса и электронного правительства. Однако обратная связь может также приводить к движению по пути наименьшего сопротивления. Мотивацией при этом выступает стремление к устройству таких бизнес-сервисов, реализация которых на нижних уровнях архитектуры (прикладном/системном, техническом) может быть легко (очевидным образом) осуществлена с помощью сервисов этих уровней. Известными результатами являются сервисы электронного правительства, практически не востребованные гражданами и предприятиями.
Во всяком случае, для формирования SOA целесообразно опираться на перенос центра тяжести при рассмотрении бизнес-сервисов с компьютинга и технических коммуникаций на организацию информационных потоков, на природу и характеристики сущностей (entities), участвующих в формировании сервисов, и на взаимодействие между ними. И не терять прослеживание к непосредственным и конечным результатам соответствующего бизнес-сервиса.
Для фиксации проблем отображения бизнес-сервисов в архитектурный слой прикладных сервисов необходимо кратко показать отличия в понимании термина сервис в этом слое.
В соответствии с Web Services Glossary сервис (в общей трактовке этого глоссария, а не, например, Веб-сервис только) понимается как
"абстрактный ресурс, который предоставляет возможность выполнения задач, которые формируют согласованную функциональность с точки зрения сущностей провайдеров и тех, кто запрашивает [этот сервис]. Для того, чтобы быть выполненным, сервис должен быть реализован агентом конкретного провайдера".
Это не только абстрактное, но и не очень конструктивное определение.
В соответствии с определением [13] под сервисом понимается
"механизм, который позволяет получить доступ к набору из одной или нескольких возможностей, с предоставлением этого доступа посредством установленных интерфейсов и с использованием согласованной политики и ограничений, специфицированных в описании сервиса". (Примеч.: эта редакция драфта модели SOA содержит определение, существенно измененное по сравнению с предыдущей версией.)
Это определение также достаточно абстрактно, оно не содержит в явном виде указаний на использование программ или иных ИТ-средств. Кроме того, документ рассматривает производителя услуги сервис-провайдера, как абстрактную сущность (entity), природа которой может быть любой, причем эта сущность должна быть способна к независимому функционированию. Последнее требование на техническом уровне далеко не всегда выполнимо. Тем не менее, приведенное определение позволяет начинать переход от бизнес-сервисов к прикладным сервисам информационных систем.
Надо учитывать, что бизнес-сервис
- инициируется или выполняется проактивно по любому каналу, не обязательно связанному с ИТ,
- может состоять полностью или частично из неавтоматизированных операций и интерфейсов,
- при своем выполнении оперирует как информационными, так и любыми иными ресурсами (людскими, материальными средствами, финансовыми, энергетическими),
- коммуницирует с получателем сервиса самыми разнообразными способами и в самые разные моменты (например, непосредственный результат бизнес-сервиса может заключаться в получении клиентом устной консультации обязательно в приватной беседе с поставщиком сервиса).
Таким образом, для отображения бизнес-сервиса на прикладные сервисы ИС необходимо
- рассмотреть варианты доставки бизнес-сервиса клиенту и выбрать адекватные способы доставки информационного продукта или сведений о нем на уровне прикладных сервисов ИС (в том случае, если непосредственный результат бизнес-сервиса может быть доставлен таким образом),
- перейти от рассмотрения бизнес-сервиса как "черного ящика" к рассмотрению вариантов внутреннего устройства реализующего этот сервис действия (бизнес-процесса, бизнес-процедуры) и выделить совокупности автоматизируемых действий пользователя и оператора,
- в автоматизируемых действиях пользователя и оператора выделить функции, выполняемые компьютерной частью ИС (возможно, в диалоге с пользователем и/или оператором ИС),
- определить способ выполнения этих функций ИС за счет выполнения таких процедур (использующих программные, информационные и коммуникационные ресурсы), которые либо имеются в наличии, либо будут созданы заново.
(Очевидно, что на всех шагах этого перехода постоянно приходится решать архитектурные задачи, не имеющие однозначного решения.)
В соответствии с рекомендациями стандарта ISO/IEC 15288 также предусмотрены отображения [бизнес-]сервисов, определенных с точки зрения ЗЛ, в "функции системы", и отображения [бизнес-]сервисов и функций ИС в архитектурные "системные элементы".
ISO/IEC 15288 не называет функции системы и системные элементы сервисами, и это оправдано, чтобы стандарт не был связан только с сервисным подходом. Тем не менее, понятно, что при применении этого стандарта для проектирования компьютеризованных предприятий и их ИС по сути описываются прикладные сервисы (то есть сервисы обработки бизнес-информации, необходимой для поддержания бизнес-сервисов), а также элементы, предоставляющие прикладным сервисам сервисы базовых ИТ ("технические службы"), реализуемые в соответствии с выбранными техническими стандартами и спецификациями.
Таким образом, стандарт по сути определяет процесс проектирования как обобщенный процесс, работы которого могут выполняться в любом стиле, например, в сквозном сервисном стиле, в том числе, в стиле SOA. Однако отсутствие указаний на способ установления отображений и существенная неоднозначность этих отображений заставляют искать помощи, которая может быть получена за счет использования хорошо проработанных эталонных моделей прикладных и технических сервисов разных видов.
Возможности и проблемы дополнения правил проектирования эталонными моделями сервисов
Референсная модель для SOA, предлагаемая в драфте [13], задает абстрактные общие требования, необходимые для понимания того, как выделяются важнейшие сущности (entities) и связи между ними в сервис-ориентированной среде. Этого недостаточно для решении конкретных задач проектирования, поскольку для этого требуется выделить несколько точек зрения на сервисно-ориентированную среду, определить механизм согласования этих точек зрения между собой и предложить эталонные модели, которые будут использоваться для выработки конкретных проектных решений, применительно к выбранным точкам зрения.
Для показа возможностей и проблем поддержки отображений сервисов "верхних" уровней в сервисы более "нижних" уровней воспользуемся моделями BRM, SRM и TRM, разработанными для поддержки общей схемы АП в варианте FEAF [10].
Характеристики и возможности совокупности эталонных моделей FEAF таковы:
- сервисы являются базовым элементом каждой из моделей: BRM (Business Reference Model), SRM (Service Component Reference Model), TRM (Technical Reference Model),
- идея сквозной связи сервисов, представлена в схемах взаимосвязи указанных моделей в рамочной схеме АП FEAF и в модели FEA PRM (Performance Reference Model),
- бизнес-сервисы вводятся в BRM, но на очень высоком уровне агрегации и обобщения сервисов (при этом конкретное наполнение в первую очередь этой модели ориентировано на бизнес-сервисы органов государственной власти),
- если бизнес-сервисы BRM представить как "вертикальные" отраслевые функции, то прикладные сервисы SRM можно представить коллекцией прикладных сервисов, расположенной в горизонтальной плоскости (см. рисунок), ортогональных бизнес-сервисам в том смысле, что практически каждый прикладной сервис может использоваться при реализации любого бизнес-сервиса (в том числе, не относящегося к сервисам органов власти),
- аналогичным образом, FEA TRM представляет стандартизированную таксономию технических сервисов, спецификаций и технологий, которая ортогональна как прикладным, так и бизнес-сервисам в том смысле, что практически технический сервис может использоваться при реализации любого бизнес- и прикладного сервиса.
В итоге, возникает схема проектирования, в которой
- стандарт ИСО/МЭК 15288 используется для организации ССП в целом: сквозного сервисного проектирования на пространстве от бизнес-сервисов до базовых технических ИТ-сервисов; при этом он не охватывает стадию проектирования сервисного предприятия SOE в смысле, описанном выше, из-за чего эту стадию надо включать дополнительно,
- "недосказанности" этого стандарта возмещаются возможностями использования согласованных совокупностей моделей сервисов в эталонных архитектурных сервисных моделях (например, моделях FEA),
- возникает концепция трехмерной (как минимум) схемы взаимосвязей сервисов, которые можно использовать в проектировании; эта схема может быть представлена как совокупность двух (или более) двумерных матриц, что проще в использовании, чем трехмерная схема,
- схема взаимосвязи сервисов используется при выборе отдельных архитектурных решений и элементов, а также для установления горизонтальных и вертикальных связей между ними,
- несмотря на "регулярный", почти итерационный способ изложения сквозного сервисно-ориентированного подхода, каждый следующий шаг отображения сервисов описывается отдельно, так как имеет существенные особенности,
- рекомендации по выбору элементов остаются "эталонными" в смысле большой обобщенности, этим определяется граница прямого применения рамочных стандартов и архитектурных моделей.
Последущий шаг доставки "сервиса конкретных рекомендаций проектировщику ИС" может быть сделан в рамках специализированных отраслевых методик или стандартов организаций. В них степень неоднозначности отображений может быть ограничена методикой, оставляющей больше или меньше пространства для "самостоятельного творчества".
Заключение
За последние 3-5 лет в мире в области стратегии использования ИТ и проектирования систем уровня предприятия произошел переход к широкому практическому использованию дисциплины "Архитектура Предприятия" (АП, Enterprise Architecture) на качественно новом уровне рассмотрения действительно комплексной архитектуры, не ориентированной только на ИТ. Это касается предприятий всех масштабов и отраслей, коммерческих компаний и государственных органов. АП используется не как "системная" и/или "ИТ-архитектура" (в смысле архитектуры информационных систем, ИТ-инфраструктуры и т.п.), но как инструмент стратегического управления предприятием. При этом из инструмента ИТ-директора и CIO она стала инструментом и областью ответственности Советов Директоров, применяемым, в том числе, для планирования изменений в организации.
Все больше организаций имеют в штате позиции "Архитектора предприятия" и Архитекторов других областей своей деятельности. Внешние специалисты могут при этом играть роли "тренеров", "помогающих и дополняющих" консультантов, но не заменяющих этих внутренних Архитекторов компаний - Заказчиков ИТ. Все больше организаций определяют собственную "рамочную" (framework) схему АП вместо использования или простой адаптации существующих схем. Отчасти это связано с объективно высокой сложностью архитектурных моделей. Эта высокая сложность архитектурных моделей требует от архитекторов образования в данной области на глубоком, желательно "классическом университетском" уровне.
Говоря о развитии и перспективах АП в России можно отметить, что уже цитированный анализ мирового применения АП в 2005 году показал следующее:
несмотря на отмечающееся начало и рост применения АП по уровню реального интереса к АП Россия не вошла в группу первых 20 стран, оставшись позади Китая (14 место), Бразилии и Испании (19 и 20 места).
Наблюдающиеся попытки использования АП сводятся к частным, ограниченным областям (ИТ-архитектура, "системная архитектура"). Должности и подразделения, в названиях которых есть слово "архитектура", стали появляться, но еще не наполняются полноценным содержанием АП. Можно предположить, что период заметного отставания России в этой области продлится не менее, а скорее более пяти лет. Это отставание может быть преодолено (хотя бы в идейном смысле) при выполнении нескольких условий, одним из которых является активное развитие в университетах дисциплины АП для экономических и управленческих специальностей. Добавить оптимизма может тот факт, что для разворачивания АП в пределах конкретной организации нет необходимости ждать, когда указанные проблемы будут решены в масштабах страны. Соответствующие действия могут быть подготовлены и выполнены в течение нескольких месяцев.
Одной из актуальных разновидностей архитектурного проектирования является "Сквозное Сервисно-ориентированное Проектирование" (ССП), охватывающее гораздо большую область, чем сильно рекламируемый сегодня подход SOA. ССП может опираться на современные подходы и стандарты системного проектирования, которые понимают систему, в том числе, как предприятие (обобщенное) и предусматривают применение сервисной идеологии в той или иной форме с самых первых шагов проектирования предприятия, а также его ИС. В ССП бизнес-сервисы рассматриваются в первую очередь как часть хорошо и особым образом организованного предприятия - сервисно-ориентированного (SOE, Service Oriented Enterprise).
В настоящее время даже для сравнительно узких предметных областей отсутствуют обоснованные критерии и однозначные правила выделения на предприятии базового набора бизнес-сервисов и определения их характеристик. Анализ многообразия стилей управления на предприятиях показывает, что сервисная трансформация предприятия далеко не всегда нужна и даже не всегда возможна или полезна. Могут существовать предприятия (подразделения организаций), для которых как минимум SOE, а возможно и SOA нерационально или даже вредно.
Несмотря на то, что идеология сквозного сервисного проектирования (ССП) предприятия и его ИС еще не вышла на высокий уровень зрелости, она еще 4-6 лет тому назад в явном виде нашла отражение в нескольких рамочных стандартах, а также в идее профилирования, что, быть может, еще не до конца осознано проектировщиками. Наиболее ярким примером этого отражения являются стандарт ISO/IEC 15288 [3], стандарт ISO 15704 [4], а также стандарт ISO/IEC TR 10000. Эта идеология опирается на многие концепции организационного и процессного проектирования предприятий, а также использования базовых ИТ-стандартов, ее методы требуют начинать работу с анализа возможности и целесообразности построения сервисно-ориентированного предприятия (что принципиально выходит за рамки SOA) и сопоставлять функциональные возможности со специфицированными ИТ-решениями.
Вместе с тем, эта идеология, равно как и идеология стратегического планирования ИТ и проектирования комплексов ИС на предприятиях, в объединениях и в отраслях, в явном виде использует все возможности, предусмотренные современным архитектурным подходом.
Для организации ССП в целом с успехом может быть использован стандарт ИСО/МЭК 15288, в котором сквозное сервисное проектирование по сути предполагается на пространстве от бизнес-сервисов до базовых технических ИТ-сервисов; при этом он не охватывает стадию проектирования сервисного предприятия SOE, из-за чего эту стадию надо включать дополнительно. "Недосказанности" этого стандарта возмещаются возможностями использования согласованных совокупностей моделей сервисов в эталонных архитектурных сервисных моделях (например, моделях FEA). При анализе моделей сервисов разных типов и способов их отображения друг в друга возникает концепция трехмерной (как минимум) схемы взаимосвязей сервисов, которые можно использовать в проектировании; эта схема может быть представлена как совокупность двух (или более) двумерных матриц, что проще в использовании, чем трехмерная схема.
Анализ содержания действительно крупных зарубежных ИТ-проектов и программ развития последних лет показывает, что все они также в существенной мере выполняются согласно описанным принципам дисциплины "Архитектура предприятия" (Enterprise Architecture). Крупные военные программы (DoD, NATO) [8, 9] и программы «электронных правительств» [10-11] показывают, что на начальном этапе агентства, ведомства или правительства в целом формируют представительный набор бизнес-сервисов и эталонных моделей, а также выделяют относительно независимые архитектурные эшелоны, в пределах которых ССП может иметь свои отличительные особенности. В рамках эталонных моделей формируются независимые системы бизнес-, прикладных и технических сервисов, а также правила, по которым сервисы этих трех уровней ставятся друг другу в соответствие. Причем, стандартные эталонные модели, например, ISO 14252, ISO 10746, используются наряду с оригинальными моделями. При выборе технических сервисов во всех проектах большое внимание уделяется использованию открытых стандартов и спецификаций и закреплению правил их отбора и актуализации. В военных проектах, как более формализованных, на уровне технических служб помимо закрепления базовых ИТ-стандартов и спецификаций дополнительно закрепляются функциональные стандарты (профили), в которых отражаются особенности использования базовых стандартов при реализации прикладных сервисов.
Литература:
1. Trends in Enterprise Architecture 2005: How are Organizations Progressing? IFEAD Report of the Third Measurement, December 2005.
2. J. Schekkerman. "Structuring the Enterprise
3. ISO/IEC 15288:2002 "Systems engineering – System life cycle processes".
4. ISO 15704:2000 "Requirements for enterprise-reference architectures and methodologies"
5. International Organization for Standardization and European Committee for Standardization. ISO/CEN FDIS 19439 ISO/CEN parallel enquiry draft prEN ISO 19439 – Enterprise Integration – Framework for Enterprise Modelling. Brussels and Geneva, 2003.
6. J. F. Sowa. Knowledge Representation: Logical, Philosophical, and Conceptual Foundations, Brooks Cole Publishing., Pacific Grove , CA
7. J. F. Sowa and J. A. Zachman. Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3), 1992.
8. DoD Architecture Framework Working Group. DoD Architecture Framework Version 1.0. Deskbook. 30 August 2003
9. NATO C3 Technical Architecture, version 5.1, v.1-v.5. ISSC NATO Open Systems Working Group. March 2004.
10. E-Gov Enterprise
12. Standards and Architecture for e-government Applications. SAGA. Version 2.0. KBSt Publication Series ISSN 0179-7263, Vol. 59, December 2003.
13. OASIS Reference Model for Service Oriented Architecture. Committee Draft 1.0, 7 February 2006.
14. ГОСТ Р ИСО/МЭК ТО 10000 – 1 – 99. Информационная технология. Основы и таксономия международных функциональных стандартов. Общие положения и основы документирования.
15. Месарович М., Мако Д., Такахара И. Теория иерархических многоуровневых систем. – М.: Мир, 1973.
Комментариев нет:
Отправить комментарий