Ведущие методологии построения архитектуры предприятия

Рис. 8. Матрица связей между бизнес-стратегиями, требованиями к информационным системам и технологической архитектуре

Таким образом, результатом первого этапа работ могут быть четыре документа:

список ключевых технологических тенденций;

список бизнес-стратегий;

список требований к информационным системам;

список требований к технологической архитектуре.

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

Концептуальная архитектура разрабатывается еще до создания других архитектурных доменов и основана на принципах, которые имеют несколько общих характеристик:

принципы представляют собой содержательные утверждения, которые касаются архитектурного процесса или содержания архитектуры;

принципы являются ограниченным числом точек стабильности, на которых строится архитектура;

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

В соответствии с методикой META Group результатом разработки принципов концептуальной архитектуры является выделение в технологической архитектуре (EWTA) набора доменов (предметных областей), которые объединяют группы связанных между собой технологий и компонент. При этом, можно выделить два различных типа доменов технологической архитектуры: базовые (технологии, которые используются практически каждой информационной системой: сети, аппаратное обеспечение, операционные системы, системы хранения, программное обеспечение промежуточного слоя, системы управления базами данных, технологии системного управления ИТ-ресурсами в распределенной среде, архитектура безопасности) и прикладные (более специфические с точки зрения использования бизнесом технологии: системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, Интернет-приложения, системы электронной коммерции, архитектура хранилищ данных, специализированное аппаратное обеспечение).

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

На рисунке 9 приведена структура описания каждого домена технологической архитектуры предприятия, согласно META Group.

Рис. 9. Структура описания доменов технологической архитектуры

Таким образом, документ, описывающий каждый домен технологической архитектуры, включает следующие компоненты:

Формулировка миссии домена: стратегические цели домена.

Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий.

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

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

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

Несоответствия между существующим состоянием домена технологической архитектуры и желаемым состоянием. Это служит основой для последующих работ группы, которая отвечает за данный домен архитектуры.

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

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

Взгляд на технологическую архитектуру с точки зрения предоставляемых ею инфраструктурных сервисов обусловлен распространением принципов сервис-ориентированной архитектуры. Это связано с описанием, например, сервисов презентации информации (порталы, настольные системы и пр.), сетевыми сервисами (LAN, WAN, удаленный доступ), сервисами безопасности (управление пользователями, доступ), сервисами хранения данных (SAN - Storage Area Network, файловые системы), сервисами баз данных (OLTP), интеграционными сервисами, платформенными сервисами, которые используются прикладными системами.

При этом архитектурные домены, шаблоны и сервисы обеспечивают наращивание уровней адаптируемости технологий предприятия:

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

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

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

При этом выделяется четыре группы сервисов по мере повышения уровня абстракции:

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

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

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

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

В результате получается технологическая модель предприятия, представленная на рис. 10.

Рис. 10. Технологическая модель предприятия

Заключение

методология архитектура корпоративный

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

Как было показано, эти методологии существенно отличаются друг от друга, как по целям, так и по подходам.

Во многих организациях царит атмосфера недоверия между бизнес- и ИТ-специалистами. Ни одна методология построения архитектуры предприятия не позволит устранить этот разрыв, пока руководство не возьмет на себя обязательство о проведении реформ. Это обязательство должно быть принято на высшем уровне организации. Методология не позволяет решить проблемы с людьми; она может только дать структуру, в рамках которой эти проблемы можно решить.

Преимущества, которые можно получить при успешном внедрении архитектуры предприятия, такие как: более эффективное использование информационных технологий, повышающее приспособляемость бизнеса; более тесное сотрудничество бизнес- и ИТ-подразделений; большая ориентированность на цели организации; высокий моральный дух, поскольку больше сотрудников теперь видят прямую связь между их трудом и успехом организации; сокращение количества отказов ИТ-систем; упрощение существующих ИТ-систем; Более высокая адаптируемость новых ИТ-систем; более тесная связь между ИТ-показателями и бизнес-требованиями.

Очевидно, что организация, эффективно работающая в этих ключевых областях, достигнет большего успеха, чем неэффективная организация. Это верно независимо от того, как оценивается успех: по материальным показателям, например по доходности или рентабельности, или нематериальным, например по степени удовлетворенности клиентов или текучести кадров.

Отправной точкой при построении архитектуры предприятия является критический самоанализ. Организация тратит слишком много денег на создание ИТ-систем, которые не приносят ожидаемой отдачи, ИТ-отдел способствует или препятствует развитию бизнеса, существует ли разногласие между бизнес- и ИТ-специалистами? И, наконец, самый, пожалуй, важный вопрос: взяла ли организация обязательство решить все эти проблемы, и если да, то принято ли это обязательство на высшем уровне? Если на все эти вопросы ответы утвердительны, то построение архитектуры предприятия - это путь развития организации.

Размещено на Allbest.ru