В этой статье пойдёт речь о международном стандарте TOGAF (The Open Group Architecture Framework) в области системной архитектуры предприятия. TOGAF 9.1 занимает почти 700 страниц, поэтому здесь мы сможем рассмотреть только введение. Без исторического вступления, без объяснений, что такое Open Group, и рассуждений о пользе и трудностях практического применения стандартов — со всем этим разберётесь без меня — перейду сразу к делу.
Краткий обзор
На первых страницах стандарта приводится Executive Overview, в котором, судя по всему, даются ответы на возможные вопросы со стороны топ-менеджмента.
Что такое предприятие (enterprise)?
В соответствии с TOGAF термин «предприятие» имеет широкую трактовку. Предприятием называется одна или несколько организаций с общими целями. В этом смысле предприятием может считаться как целая корпорация, так и её подразделение; как государственное учреждение, так и коммерческая фирма или, например, несколько фирм с общими владельцами.
Что такое архитектура предприятия?
Основные термины в стандарте TOGAF взяты из стандарта ISO 42010 «Программная инженерия — Описание архитектуры». В соответствии с ISO 42010 архитектура представляет собой: «фундаментальную организацию системы, состоящую из компонент, их отношениях друг к другу и окружающей среде, а также принципов, определяющих проектирование и развитие системы». В этом смысле TOGAF рассматривает организацию как систему.
В тоже время TOGAF вводит для архитектуры и более частное определение, которое применяется в своём контексте. В соответствии с ним: « архитектура — это формальное описание системы или детальные план системы на уровне компонент, на основании которого осуществляется реализация системы».
Зачем нужно заниматься архитектурой предприятия?
Во введении к TOGAF приводится много лозунгов про эффективность бизнеса и ИТ. Но главным образом, всё сводится к тому, что архитектура обеспечивает стратегический контекст развитию ИТ в ответ на требования бизнеса. Другими словами, если есть архитектура, то развитие ИТ происходит не спонтанно, например, по желанию некоторых руководителей или в соответствии с модой, навязываемой вендорами, но вся эта деятельность целиком подчинена бизнесу и его стратегическим интересам. В этом смысле архитектура похожа на ИТ–стратегию, с той лишь разницей, что архитектура является более детальным представлением деятельности, чем стратегия.
Что же заставит меня («капитана бизнеса») заниматься архитектурой предприятия?
Когда деятельность предприятия, особенно небольшого, налажена и устраивает всех, то вряд ли менеджмент будет всерьёз заниматься её анализом и строить архитектуру. Однако если Ваш бизнес сильно зависит от ИТ, или вы готовитесь к серьёзным изменениям, или решили провести радикальную модернизацию инфраструктуры (например, перейти в «облако»), то это может подвигнуть вас на проработку архитектуры. Впрочем, даже небольшие изменения, но в большом и сложном предприятии, могут оказаться непосильными без всестороннего видения, которое обеспечивает архитектура. Без архитектуры необходимые изменения будут откладываться в долгий ящик, что может, в конечном счёте, сделать компанию неконкурентоспособной.
Какие задачи ставятся архитектору на уровне предприятия?
- Формализация выявленных проблем и заявленных требований к ИТ со стороны бизнеса. Отмечу, что выявлением проблем и установкой требований должен заниматься менеджмент.
- Разработка архитектурных представлений (уровней), которые бы показывали, как решаются конкретные задачи и как обеспечивается реализация требований.
- Определение точек разногласия различных заинтересованных сторон и разработка компромиссных предложений.
Почему в качестве основы для разработки архитектуры предприятия мне нужно выбрать именно TOGAF?
Разработка и поддержание архитектуры предприятия представляет собой технически сложный процесс и охватывает различные стороны, имеющие собственные точки зрения и интересы. В этой ситуации TOGAF может создать авторитетную основу для внутрикорпоративной стандартизации и снижения проектных рисков при разработке архитектуры. В создании TOGAF принимали участие более 300 участников форума Open Group из ведущих компаний в сфере ИТ (в большинстве, конечно, американских компаний). В результате TOGAF представляет собой набор «лучших мировых практик», которые позволяют сделать работоспособную и экономически эффективную архитектуру предприятия, ориентированную на потребности бизнеса.
Как относиться к подобной аргументации — решайте сами.
Домены архитектуры
TOGAF является руководящей основой (framework) для разработки и поддержания архитектуры. В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов:
- Бизнес архитектура — определяет стратегию предприятия, структуру управления и ключевые бизнес процессы.
- Архитектура данных — описывает логическую и физическую структуру данных организации, а также структуру корпоративных ресурсов для управления данными.
- Архитектура приложений — служит своеобразной картой всех используемых корпоративных приложений и определяет следующие аспекты:
- участие каждого из приложений в бизнес процессах компании;
- взаимодействие приложений друг с другом и внешними сервисами.
- Технологическая архитектура — определяет структуру и логику программного обеспечения и аппаратной среды, необходимых для работы бизнес приложений и доступа к нужным данным. Этот уровень включает всю поддерживающую инфраструктуру: сети, сервера, процессинг и т. п.
Архитектор уровня предприятия должен успешно работать в каждом из этих доменов.
Метод разработки архитектуры
TOGAF основан на итеративной процессной модели, которая предусматривает повторное использование имеющихся архитектурных компонент. TOGAF включает методологию разработки архитектуры под названием Architecture Development Method (ADM). В соответствии с ADM разработка системной архитектуры состоит из следующих фаз:
Architecture Development Method
- Предварительная фаза предусматривает подготовку условий для разработки архитектуры, включая адаптацию TOGAF к реальной среде, и определение основных принципов, на которых будет строиться разработка архитектуры.
- Фаза A: Видение архитектуры представляет собой начальную фазу цикла разработки архитектуры. Фаза включает планирование основных мероприятий, определение заинтересованных сторон, создание «Архитектурного видения» и утверждение это видения у руководства.
- Фаза B: Бизнес архитектура предусматривает разработку архитектуры деятельности предприятия в соответствии с ранее утвержденным видением.
- Фаза C: Архитектура информационных систем
- Фаза D: Технологическая архитектура
- Фаза E: Возможности и решения. Фаза определяет разрыв между текущей архитектурой и целевой, а также устанавливает набор возможных средств для достижения целевой архитектуры. В основе данной фазы лежит знакомый многим SWOT–анализ. В качестве средств достижения целей могут инициироваться различные проекты и программы.
- Фаза F: Планирование перехода определяет мероприятия для перехода из текущего состояния архитектуры в целевое. Фаза предусматривает разработку «Плана реализации и перехода», детализированного до уровня пакетов работ, которым можно дать стоимостную оценку и, в конечном счёте, оценить проектные параметры (объём, сроки, стоимость) всего перехода в целом.
- Фаза G: Управление реализацией обеспечивает архитектурный надзор в процесс перехода от текущего состояния к целевому.
- Фаза H: Управление изменениями в архитектуре. Для того чтобы обеспечить достижение изначальных целей в меняющихся условиях, необходимо управлять всеми изменениями, которые вносятся в целевую архитектуру.
- Управление требованиями — это процесс, который охватывает все этапы разработки архитектуры и обеспечивает целостность всего проекта.
Следующая статья будет посвящена структурным элементам TOGAF
Обзор подготовлен с использованием материалов стандарта TOGAF версии 9.1
Комментариев нет :
Отправить комментарий