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

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

Рис. 4.4. Интегрированная концепция архитектуры предприятия

Более подробно содержание каждой из предметных областей (представлений) интегрированной концепции архитектуры предприятия будет раскрыто в следующей лекции.

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

Итак, большинство методик описания архитектуры основаны на концепции, которую Стивен Спивак назвал "структурное мышление" (Framework Thinking) [3.20]. Структурное мышление является интересным принципом. Он требует от вас сознательного абстрагирования и упрощения проблемы в целях выполнения анализа. Наверное, каждый из нас в жизни сталкивался с объективно сложными ситуациями, когда сама эта сложность уменьшала наши возможности находить решения. Однако процесс "структурного мышления", с его разбиением целого на части и сознательным упрощением, позволял легче понимать, моделировать и решать, в конечном итоге, проблему.

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

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

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

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

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

Мы здесь затрагиваем темы, которые в дискуссиях между аналитиками получили отражение в таких терминах, как "минималистская архитектура" (Minimalist Architecture) или "достаточно хорошая архитектура" (Good Enough Arhictecture), которые мы рассмотрим в лекциях 10-12.

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

На самом деле то, что критическим образом определяет лучшее понимание всей модели предприятия — это связи между различными моделями (или артефактами), описывающими различные предметные области архитектуры. Отсутствие понимания взаимосвязей между различными артефактами архитектуры и неспособность явного описания таких взаимосвязей является одной из основных причин неудач проектов разработки архитектуры предприятия или практического использования таких методик, как модель Захмана. Мы отдельно рассмотрим модель Захмана в "Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF" , поскольку она сыграла и играет до сих пор важную методологическую роль, являясь как бы теоретической основой для большинства других концепций, используемых для описания архитектуры. Это означает, что на практике необходимо развивать адекватные подходы по группированию моделей и артефактов внутри архитектуры для того, чтобы обеспечить естественный фокус в этих работах и явное описание взаимосвязей.