Автор работы: Пользователь скрыл имя, 02 Июля 2015 в 12:25, реферат
Архитектура предприятия выделилась в отдельную дисциплину чуть более 20 лет тому назад и в настоящее время является одной из ключевых функций как корпоративного, так и проектного менеджмента, основным средством достижения и поддержания конкурентоспособности любого предприятия или организации, особенно в сфере ИТ.
В модели TOGAF мир архитектуры предприятия рассматривается как континуум архитектур (Enterprise Continuum) то есть некоторый набор готовых моделей, от максимально обобщенных до максимально специализированных. Процесс создания конкретной архитектуры предприятия, рассматривается как переход от общей архитектуры к специализированной. Методика разработки архитектуры в модели TOGAF представляет собой процесс осуществления такого перехода.
В модели TOGAF наиболее обобщенные архитектуры называются фундаментальными. Эти принципы построения архитектуры теоретически могут использоваться практически любой ИТ-организацией в мире. Следующий уровень специализации в модели TOGAF представлен общесистемными архитектурами. Эти принципы прослеживаются во многих - возможно, не во всех типах предприятий. Следующий уровень специализации в модели TOGAF называется отраслевыми архитектурами. Эти принципы характерны для предприятий, занятых в одной сфере деятельности. Самый высокий уровень специализации в модели TOGAF называется архитектурами организаций. Это архитектуры конкретных предприятий.
На рис. 2.8 структурно показана суть методики подхода TOGAF.
Рис. 2.8. Континуум предприятия и методика разработки
TOGAF подразумевает, что континуум предприятия действует как коллекция компоновочных блоков (шаблонов), которая предоставляет коллективам, занимающимся архитектурой предприятия, соответствующие архитектуры, модели и процессы, из которых можно собирать готовые решения, как в детском конструкторе.
Континуум предприятия, накопитель таких ресурсов, как модели, шаблоны решений и другие активы, которые могут использоваться как компоновочные блоки на всем процессе реализации и адаптации архитектуры предприятия.
Метод разработки архитектуры TOGAF (ADM) предоставляет законченный набор инструкций для реализации и выполнения архитектуры предприятия в организации. Этот процесс состоит из нескольких последовательных фаз, замкнутых в цикл (рис. 2.9).
Задача предварительной фазы (Preliminary Phase, ее на рисунке нет) - выявление заинтересованных в процессе реализации лиц и обсуждение с ними задач архитектуры предприятия. На этой фазе вырабатываются Руководящие принципы архитектуры (Architecture Guiding Principles), которые основываются на бизнес-принципах организации и описывают процессы и критерии для наблюдения за процессом реализации архитектуры предприятия.
Рис. 2.9. Методика ADM
Фаза А этого процесса предназначена для выражения видения архитектуры предприятия. Артефакт Видение архитектуры (Architecture Vision) использует движущие силы бизнеса, чтобы обозначить цель действий по созданию архитектуры предприятия и создать описания первого реза для базовой и целевой среды. Если задачи бизнеса не ясны, то часть задания этой фазы - помочь бизнесу идентифицировать свои главные задачи и соответствующие процессы, которые должна поддерживать архитектура предприятия. Документ Архитектурное задание (Statement of Architectural Work), который также создается в этой фазе, очерчивает область действия и условия архитектуры предприятия и представляет собой план архитектурного задания.
Фаза B предназначена для детальной разработки архитектуры предметной области бизнеса. И базовая, и целевая архитектура, которые очерчены в документе Видение архитектуры, детализируются, чтобы получить полезные входные данные для технического анализа. Моделирование бизнес-процессов, моделирование бизнес-объектов и моделирование прецедентов - вот лишь некоторые методики, которые используются для создания архитектуры бизнеса, которая, в свою очередь, включает анализ просчетов желательного состояния.
Фаза С связана с созданием архитектуры предметных областей Приложение и Данные (Информация). Эта фаза использует базовую и целевую архитектуры, которые были запущены в фазе А (Архитектурное представление) и результатах анализа просчетов (компонента архитектуры бизнеса), чтобы передать архитектурам данных и приложения информацию о текущей и проектной средах, в пределах области применения и в соответствии с планом, очерченным в Документе "Архитектурное задание".
Фаза D завершает работу над детализацией архитектуры цикла метода ADM созданием архитектуры технологии. Как и в предыдущих фазах, в качестве основы используется анализ просчетов и черновые варианты архитектур, так же, как и руководящие принципы архитектуры, выработанные в подготовительной фазе. В этой фазе для создания различных точек зрения активно используется нотация моделирования UML.
Цель фазы Е - выяснить возможности, предлагаемые целевой архитектурой, и создать эскиз потенциального решения. Работа в этой фазе концентрируется вокруг применимости и практичности альтернатив реализации. На этой фазе создаются такие артефакты, как Стратегия реализации и миграции, Высокоуровневый план реализации и Список проектов, а также обновленная Архитектура приложения, которая выполняет функции программы, которую следует использовать в проекте реализации.
В фазе F расставляются приоритеты проектов реализации и выполняется детализированное планирование и анализ просчетов процесса миграции. В это задание входит оценка зависимостей между проектами и минимизация их итогового влияния на функции предприятия. В этой фазе обновляется Список проектов, детализируется План реализации, а Программа передается коллективам, занимающимся реализацией.
После утверждения спецификации проекта фокус перемещается на формулирование более конкретных условий и рекомендаций для каждого из проектов реализации. На протяжении фазы G устанавливается связь между упрвляющей архитектурой (TOGAF) и разрабатывающей организацией (которая может быть настроена при помощи RUP и Project Management Body of Knowledge (PMBOK), например, или каких-либо еще методологий управления проектом, а выбранные проекты реализуются под управлением формальной архитектуры. На выходе этой фазы мы имеем Архитектурные контракты, которые утверждаются организацией-разработчиком. Конечным выходом фазы G являются решения, совместимые с архитектурой.
В фазе H акцент переносится на управление изменением основой архитектуры, которая достигается поставкой реализованных решений. В этой фазе может быть создано Требование к архитектурному заданию, которое устанавливает цели для последующих циклов реализации архитектуры предприятия.
Не смотря на большую проработанность данной методологии по сравнению с моделью Захмана, надо понимать, что подход 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 - отсутствие стандартного инструмента для фиксации и управления артефактами архитектуры предприятия и отсутствие стандартной нотации.
Крупные компании-поставщики инфраструктурных информационных технологий, такие как Microsoft, IBM, SAP и другие могут «позволить себе роскошь» создания собственных методик разработки архитектуры информационных систем предприятия - конечно, с учетом своей области специализации. В то же время - это в какой-то степени и обязанность таких компаний, поскольку спектр предлагаемых ими технологий покрывает существенную часть архитектуры предприятия в целом, и специалистам нужны соответствующие практические рекомендации непосредственно от поставщиков.
Взгляды компании Microsoft на архитектуру информационных систем достаточно подробно изложены в [(Platt)]. Эти подходы в большей степени сфокусированы на процессах разработки конкретных программных прикладных систем и создании технологической инфраструктуры, включая центры обработки данных различного масштаба и уровня надежности. Как практически и во всех других методиках, здесь выделяются четыре представления (домена) в архитектуре: бизнес-архитектура, архитектура информации, прикладные системы и технологическая архитектура. Эти представления рассматриваются на различных уровнях абстракции: концептуальном, логическом и физическом. Помимо этого, явно выделяются процессы разработки прикладных систем, организация процессов эксплуатации технологической инфраструктуры и создание соответствующих шаблонов, которые могут использоваться как при разработке архитектуры систем, так и при ее создании.
При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы разработки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (МSM), которые будут рассмотрены ниже.
Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов:
Методики Microsoft сосредоточены, в основном, на системном уровне - уровне архитектуры прикладных систем и обеспечивающей инфраструктуры (это не методики описания архитектуры предприятия как таковые). Поэтому в этой более «узкой» области полезными являются приведенные соотношения между различными перспективами описания системы и моделями, используемыми для описания на соответствующем уровне абстракции так, как показано на рис. 2.11 [(А. Данилин, 2005)].
Рис. 2.11. Соотношение между уровня абстракции и различными моделями
То есть в идеале для каждой перспективы используется какой-то один тип моделей так, как это показано на рисунке. Но в реальности могут использоваться и несколько различных моделей для описания каждой из перспектив, т.е. концептуальной, логической и физической архитектур системы.
Microsoft выделяет
два типа руководств и
Второй набор руководств, которыми могут пользоваться системные архитекторы - это архитектурные шаблоны, которые основаны на практическом опыте большого количества успешно реализованных проектов создания распределенных прикладных систем; они явились следствием использования описанных выше архитектурных концепций. Эти шаблоны содержат в себе лучшие практики проектирования распределенных приложений и средства по минимизации рисков неудач проектов, поскольку рекомендуют хорошо апробированные модели.
Эти два типа руководств - архитектурные концепции и шаблоны - могут присутствовать и использоваться на различных уровнях проектирования архитектуры прикладной системы;
Рисунок 2.12 показывает взаимосвязи между различными перспективами в описании архитектуры, используемыми шаблонами проектирования, а также примерно отображает соответствие между методиками Microsoft и соответствующими элементами архитектуры.
Рис. 2.12. Архитектурные шаблоны и методики компании Microsoft
Знание и использование этих концепций и шаблонов является важным условием успешного, быстрого и эффективного с точки зрения затрат создания систем и использования информационных технологий организациями.
Поэтому помимо самих методик MSF, MOF, MSA и MSM компанией опубликованы подробные руководства по разработке архитектуры систем [(Microsoft Application Architecture Guide, 2nd Edition, 2009)], а также шаблоны, которые могут применяться при проектировании корпоративных информационных систем [(Enterprise Solution Patterns Using Microsoft .NET, 2003)].
Информация о работе Применение архитектурных подходов в сфере информационных технологий