ЛЕКЦИЯ 8 35 страница

Не смотря на большую проработанность данной методологии по сравнению с моделью Захмана, надо понимать, что подход TOGAF имеет и ряд недостатков. Метод ADM не является законченным процессом; это инфраструктура, и, по сути, для каждой конкретной организации, требуется адаптация. Адаптация предполагает глубокое знание модели бизнеса и методологии - специалиста с такими качествами не всегда легко найти. Ситуация осложняется тем, что даже не последняя версия TOGAF версия 8.0, Enterprise Edition (2006) и новая версия 9 (2009)- это сравнительно новый подход с ограниченным количеством практических наработок.

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

Несмотря на недавние усовершенствования и выход новой версии, инфраструктура TOGAF не так детализирована, как другие методологии, особенно в главной сфере взаимодействия бизнеса и технологии. Например, TOGAF не включает ни функций, подобных Rational Method Composer или MyRUP, ни такой комплексной библиотеки периодических изданий.

Зрелые организации, особенно те, которые в повседневной работе используют управление проектами и методологию жизненного цикла программного обеспечения (PMBOK, RUP, Scrum и ITIL) обычно добиваются большего успеха в реализации архитектуры предприятия. Можно порекомендовать сотрудникам организации перед тем, как включить в свой инструментарий TOGAF, хорошо изучить несколько методик, нотаций и методологий жизненного цикла программного обеспечения из тех, что показаны на рисунке 2.10.

Рис. 2.10. Применение методики TOGAF для «зрелой» организации

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

2.3. Модели архитектуры предприятия, разработанные в корпоративной среде

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

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

При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы раз-работки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (МSM), которые будут рас-смотрены ниже.

Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов:

· MSF - «Как правильно создавать ИТ-системы?»

· MSA - «Как правильно создавать технологическую инфраструктуру?»

· MOF - «Как правильно эксплуатировать технологическую инфраструктуру?»

· MSM - «Как правильно строить процессы управления технологической ин-фраструктурой?»

Методики Microsoft сосредоточены, в основном, на системном уровне - уровне архитектуры прикладных систем и обеспечивающей инфраст-руктуры (это не методики описания архитектуры предприятия как таковые). Поэтому в этой более «узкой» области полезными являются приведенные соотношения между различными перспективами описания системы и моделями, используемыми для описания на соответствующем уровне абстракции так, как показано на рис. 2.11 [(А. Данилин, 2005)].

Рис. 2.11. Соотношение между уровня абстракции и различными моделями

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

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

Дата добавления: 2015-04-25