пособие по архитектуре предприятия. пособие по архитектуре предприятия2. Пособие по дисциплине Архитектура предприятия Д. Р. Богданова, В. А. Котельников, Л. У. Минибаева Уфа 2015. 89с

• Название: Пособие по дисциплине Архитектура предприятия Д. Р. Богданова, В. А. Котельников, Л. У. Минибаева Уфа 2015. 89с
• Анкор: пособие по архитектуре предприятия
• Дата: 12.01.2021
• Размер: 1.76 Mb.
• Имя файла: пособие по архитектуре предприятия2.doc
• Тип: Пособие; #167343
• страница: 5 из 8

Вопросы

1. 
   Что такое «облако неопределенности» и где оно находится?
   
2. 
   Перечислите элементы архитектуры предприятия?
   
3. 
   Что такое архитектура в соответствии с определениями Gartner?
   
4. 
   От чего зависят архитектура ИТ и принципы ее построения?
   
5. 
   Каковы уровни принятия архитектурных решений?
   
6. 
   Перечислите уровни описания программной архитектуры?
   
7. 
   Каковы дополнительные преимущества эволюции представлений об архитектуре предприятия?
   
8. 
   Как происходила эволюция организационных принципов деятельности предприятия?
   
9. 
   Через какие процессы происходит применение ИТ для решения бизнес-проблем?
   
10. 
    Как связаны бизнес-процессы создания добавочной стоимости?
    

4. Лекция: Интегрированная концепция и уровни абстракции

Содержание

• 
  Интегрированная концепция архитектуры предприятия
  
• 
  Уровни абстракции (перспективы) в описании архитектуры предприятия
  
• 
  Архитектура и управление ИТ-портфелем
  

4.1 Интегрированная концепция архитектуры предприятия

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

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

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

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

Архитектура предприятия – это скорее процесс, чем некоторый статический предмет.

Пользователями архитектуры предприятия является достаточно обширная аудитория специалистов и руководителей:

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

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

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

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

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

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



Рис. 4.1.  Контекст и уровни абстракции архитектуры



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

• 
  перспектива (perspective) или уровень абстракции;
  
• 
  представление (view) или предметная область, домен архитектуры.
  

Большинство методик разделяет проблему описания архитектуры предприятия на некоторое количество представлений или предметных областей (доменов), таких как:

• 
  бизнес-архитектура – люди и процессы;
  
• 
  архитектура информации – данные, информация и знания;
  
• 
  архитектура прикладных систем;
  
• 
  технологическая архитектура.
  

Для отдельного представления архитектуры можно также использовать термин частная архитектура.

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

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

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




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

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

• 
  уровень контекста – ориентирован на бизнес-руководство;
  
• 
  концептуальный уровень или "Видение Общих Требований" – ориентирован на "владельцев" бизнес-процессов;
  
• 
  логический уровень – ориентирован на архитекторов и проектировщиков систем;
  
• 
  физический уровень – ориентирован на проектировщиков и разработчиков систем.
  

Рис. 4.3.  Представления (домены) и перспективы (уровни абстракции) описания Архитектуры

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

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

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

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

Несмотря на то, что имеется несколько предметных областей или представлений, все они описывают одно и то же – единую архитектуру предприятия. Ценность архитектуры предприятия состоит не в отдельных представлениях (предметных областях), а в связях, взаимодействии и зависимостях между ними.

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


Рис. 4.4.  Интегрированная концепция архитектуры предприятия
Архитектура предприятия никогда не является полностью завершенной. Нет такой магической структуры или модели бизнеса, при которой развитие не требовало бы постоянных изменений в продуктах, услугах, бизнес-моделях и обеспечивающей их инфраструктуре. Если мы принимаем факт, что архитектура предприятия является абстрактной моделью организации, тогда процесс создания архитектуры не может быть завершен полностью никогда. В частности, одним из направлений критики архитектурных подходов является то, что процесс разработки архитектуры слишком длительный и дорогой для того, чтобы применяться на практике. На самом деле, это является отражением стремления сделать архитектуру "идеально завершенной". Это чрезмерное стремление к завершенности и совершенству действительно может быть причиной "паралича анализа".

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

4.2 Уровни абстракции (перспективы) в описании архитектуры предприятия

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

Ниже приведены примеры вопросов, на которые должен давать ответ уровень контекста:

• 
  Каких целей хочет добиться организация?
  
• 
  Почему организация занимается таким бизнесом: видение, миссия и цели?
  
• 
  Каковы тенденции в индустрии, в которой работает организация?
  
• 
  Как организация расположена и где она работает географически?
  
• 
  Каковы факторы, определяющие достижение высоких результатов в бизнесе (value drivers)?
  
• 
  Каковы на самом высоком уровне классы информации, которыми оперирует организация?
  
• 
  Каковы функции этого бизнеса?
  
• 
  В каких областях сосредоточена ключевая компетенция организации?
  

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

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

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

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

• 
  Какие области бизнеса должны быть поддержаны информационными технологиями?
  
• 
  Какая общая бизнес-архитектура (например, "фронт-офис", "мид-офис", "бэк-офис") будет использоваться?
  
• 
  Как системы будут соотноситься с организационными структурами и бизнес-архитектурой, насколько информационные системы отдельных департаментов будут консолидированы в единый набор ключевых прикладных систем?
  
• 
  Как выглядят бизнес-процессы, которые обеспечивают создание продуктов и оказание услуг?
  
• 
  Какая информация требуется для каждого бизнес-процесса и как эта информация может повторно использоваться?
  
• 
  Организован ли бизнес организации в централизованном или децентрализованном виде?
  
• 
  Какой уровень делегирования полномочий должны обеспечивать системы?
  
• 
  Какие существуют общие принципы по использованию технологий, характерные для индустрии, в которой работает организация, и типы оказываемых услуг?
  
• 
  Какие вопросы по надзору и руководству использованием технологий должны быть рассмотрены на данном этапе?
  

В качестве методов, которые используются для построения бизнес-моделей на этапе концептуального проектирования, могут быть, например, такие инструменты языка UML как Варианты Использования (Use Cases), диаграммы деятельности и другие методы проектирования процессов.

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

На этом уровне даются ответы на следующие вопросы:

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

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

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

• 
  Как должны быть сгруппированы логические компоненты (например, должен ли использоваться единый каталог пользователей для обеспечения единого сервиса регистрации, независимо от используемых каналов взаимодействия)?
  
• 
  Как логические компоненты будут распределены между различными системами (будут ли эти компоненты реализованы в виде web-сервисов)?
  
• 
  Как единый брокер или шина интеграции будет обеспечивать различные бизнес-системы, или как средства обеспечения совместной работы будут использоваться помимо баз данных и средств интеграции для того, чтобы обеспечить работу виртуальных групп сотрудников?
  

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

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

Примеры вопросов, на которые отвечают на данном уровне абстракции, следующие:

• 
  Каковы функциональные спецификации каждой прикладной системы?
  
• 
  Будет ли организация разрабатывать специализированные приложения или покупать стандартные?
  
• 
  Каковы критерии выбора и как будут оцениваться различные инициативы по реализации систем?
  
• 
  Как данные будут представлены на физическом уровне?
  

Уровень реализации, самый нижний уровень или перспектива в описании архитектуры системы формулируется уже разработчиками системы в терминах использования тех или иных продуктов конкретных поставщиков. На уровнях физической архитектуры и уровне реализации для ускорения цикла разработки, повышения качества разрабатываемых систем (за счет использования проверенных решений) и уменьшения рисков проекта могут использоваться такие концепции и архитектурные модели, как, например, Microsoft Systems Architecture (MSA).

Таблица 4.1 Пример рассмотрения системы на различных уровнях абстракции

Перспектив	Уровень детализации
Контекст	Компания представляется в виде "черного ящика" и является центральным "действующим лицом" (актором). Бизнес моделируется с точки зрения внешних для бизнеса акторов. Моделируются только бизнес-взаимодействия, средства игнорируются.
Концептуальный	Моделируются потоки работ бизнес-процессов, идентифицированных на концептуальном уровне. Система, реализующая процессы, является центральным актором в форме "черного ящика". Бизнес-процессы моделируются с точки зрения внешних для системы акторов. Рассматриваются средства коммуникаций, используемые для выполнения транзакций.
Логический	Моделируется внутренняя архитектура системы. Основные компоненты системы являются основными факторами. Поведение системы моделируется с точки зрения внутренних для системы "черных ящиков".
Физический	•Моделируется физическая структура реализации системы

4.3 Архитектура и управление ИТ-портфелем

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

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

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

В связи с этим описание желаемого состояния архитектуры ИТ обеспечивает представление о необходимых инвестициях в технологии и навыки ИТ-персонала.

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

• 
  стратегия и планирование на уровне предприятия.
  
• 
  архитектура предприятия.
  
• 
  управление ИТ-программами и проектами.
  

ИТ-программы и проекты – это основной механизм реализации архитектуры в рамках выбранной стратегии. Дисциплина управления ИТ-программами и проектами связана с навыками управления портфелем взаимосвязанных программ и проектов на корпоративном уровне, с управлением процессами, финансовыми и человеческими ресурсами, которые требуются для реализации проектов, с управлением графиками реализации проектов и т.д. Управление ИТ-программами и проектами и архитектура предприятия взаимно дополняют друг друга, обеспечивая, в конечном итоге, интеграцию различных процессов, связанных с использованием ИТ на предприятии. При этом сутью управления программами/проектами является реализация, в то время как архитектура обеспечивает основу для выработки стратегии.

Процессы выработки стратегии и планирование обеспечивают основу для отбора, управления и оценки ИТ-ресурсов и проектов.



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

В связи с этим соотношение между сегодняшним состоянием архитектуры предприятия (архитектура "как есть"), будущим желаемым состоянием архитектуры (архитектура "как должно быть"), портфелем ИТ-активов и портфелем ИТ-проектов можно также условно отобразить в виде следующей схемы:




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