Руководство по разбиению определяет полезность методологии в эффективном разбиении предприятия на отделы, что весьма важно при управлении сложностью.
Наличие каталога определяет, насколько эффективно методология позволяет создать каталог архитектурных активов, которые можно будет использовать в дальнейшем.
Нейтральность по отношению к поставщикам услуг определяет вероятность того, что при внедрении методологии вы окажетесь привязанными к конкретной консалтинговой организации. Высокая оценка означает низкую степень привязки к конкретной организации.
Доступность информации определяет количество и качество бесплатных или относительно недорогих материалов по данной методологии.
ремя окупаемости инвестиций определяет продолжительность периода, в течение которого вы будете использовать данную методологию, прежде чем сможете построить на ее основе решения, обеспечивающие высокую ценность бизнеса.
Построение Архитектуры Предприятия может быть выполнено с применением различных методов и практик. В данной книге мы вкратце рассмотрим несколько и сфокусируем свое внимание на одной из них:
•«Zahman Framework» – наиболее ранняя и известная методология. Идеально подходит для «классификации» элементов архитектуры.
•«TOGAF (The Open Group Architecture Framework)». Методология получила широкую известность и распространение, во многом за счет открытости. Представляет из себя каркас «построения процессов».
•«Gartner» – методология экспертного анализа с использованием «лучших» практик.
•«FEAF» – методология построения архитектуры, использующая «сервис ориентированный» подход.
При построении ИТ Архитектуры Предприятия необходимо выделить следующие состояния архитектуры организации:
•Текущее состояние «As-is» или «Baseline Architecture».
•Переходное состояние «Transition Architecture».
•Будущее состояние «To-be» или «Target Architecture».
•План перехода «Enterprise Architecture Management Plan & Roadmap»
В общем случае Архитектура Предприятия представляет из себя план перехода от «Текущего» к «Будущему» состоянию организации. Архитектурный проект длится несколько лет и инициирует множество ИТ проектов. Эти проекты будут разной продолжительности, у них разные даты начала и окончания. Их нужно сгруппировать таким образом, чтобы изменения в бизнесе и ИТ происходили в нужное время, с минимальными рисками и без проблем с совместимостью. То есть архитектура может переходить из одного работоспособного состояния в другое несколько раз за время архитектурного проекта. Промежуточное состояния называют «переходной архитектурой» (Transition Architecture).