Стратегия архитектуры переводит бизнес-стратегию в цели по созданию, расширению или замене бизнес-возможностей и систем вместе с планом внедрения, сохраняя при этом устойчивость к изменениям в качестве ключевой архитектурной цели.
Как архитектура предприятия связана со стратегией и бизнес-планированием?
Архитектура и стратегическое планирование гарантируют, что информационные системы не будут работать в вакууме. Архитектура предприятия описывает процессы организации, информационные процессы, персонал и другие организационные подразделения, соответствующие основным целям и стратегиям организации.
Как архитектура предприятия поддерживает бизнес-цели и стратегию?
Архитектура предприятия помогает крупным или растущим организациям объединить свою ИТ-инфраструктуру со своими бизнес-целями. Эта практика способствует переводу стратегий в понятные, четко определенные процедуры, процессы и технологические требования.
Каковы основные методологии архитектуры предприятия?
В частности, статья посвящена четырем наиболее широко известным фреймворкам EA: Zachman Framework, FEAF, DoDAF и TOGAF.
ЭТО ИНТЕРЕСНО: Можно ли обратно сохранить SolidWorks?
Как вы объясните архитектуру предприятия?
Архитектура предприятия (EA) — это дисциплина для проактивного и комплексного реагирования предприятия на разрушительные силы путем выявления и анализа выполнения изменений для достижения желаемого бизнес-видения и результатов.
Что такое стандарты архитектуры предприятия?
Стандарт архитектуры предприятия также представляет собой всеобъемлющую структуру, которая помогает определить и описать текущие («как есть») технологические платформы Университета, а также его целевое («будущее») технологическое направление.
Как архитектура предприятия связана со стратегическим бизнесом и технологиями?
EA наиболее эффективна, когда она одновременно поддерживает планирование и принятие решений руководителями по принципу «сверху вниз» в рамках всего предприятия и планирование и принятие решений по принципу «снизу вверх» в каждом LOB. Таким образом, EA помогает гарантировать, что стратегия определяет бизнес- и технологическое планирование.
Как успешно спланировать архитектуру предприятия?
Ключом к эффективному использованию архитектуры предприятия является понимание того, как решать важные проблемы всего предприятия, такие как реализация новой стратегической инициативы, удовлетворение потребностей заинтересованных сторон, согласование ИТ-ресурсов с потребностями бизнеса или сокращение дублирующих систем, данных и процессов.
Как архитектура предприятия может улучшить процесс принятия решений в организации?
Эти элементы управления действуют как поддерживающая структура для принятия решений. Корпоративная архитектура улучшает организационное воздействие за счет производительности, гибкости, своевременности продуктов и услуг, роста доходов и снижения затрат. Каждый из них по отдельности может стать аргументом в пользу корпоративной архитектуры.
Как корпоративные модели могут помочь в решении бизнес-задач?
Моделирование предприятия помогает лидерам визуализировать то, что происходит в бизнесе и как вносить изменения. Ранние формы корпоративного моделирования помогали аналитикам чинить аппаратное обеспечение и устранять другие неисправности.
ЭТО ИНТЕРЕСНО: Можно ли измерить в autocad trueview?
Какие 3 наиболее важных фактора следует учитывать при создании архитектуры предприятия?
Каковы пять основных элементов подхода к архитектуре предприятия?
Модель архитектуры предприятия включает пять архитектурных компонентов: организационную архитектуру, бизнес-архитектуру, информационную архитектуру, архитектуру приложений и технологическую архитектуру.
Каковы три самые популярные методологии архитектуры предприятия?
Лучшие методологии архитектуры предприятия
- Введение.
- Zachman Framework для корпоративных архитектур.
- Структура архитектуры открытых групп (TOGAF)
- Архитектура федерального предприятия (FEA)
- Архитектура предприятия Gartner (GEA)
Что такое стили архитектуры предприятия?
В случае архитектуры предприятия эти модели описывают логические бизнес-функции или возможности, бизнес-процессы, человеческие роли и участников, физическую организационную структуру, потоки данных и хранилища данных, бизнес-приложения и платформенные приложения, аппаратное обеспечение и коммуникационную инфраструктуру.
Что такое структура архитектуры предприятия и как ИТ помогает с архитектурой предприятия?
Архитектура предприятия — это концептуальный план, и цель структуры — помочь архитекторам, дизайнерам и инженерам понять, как системы и активы организации логически структурированы и связаны между собой.
Источник: powerpointmaniac.com
Enterprise Architecture и ее подходы
Привет, Хабр! В основном всем понятно, чем занимаются архитекторы решений, архитекторы по интеграции, системные архитекторы, но у многих возникают вопросы по поводу Архитекторов Предприятий, они же Enterprise Architects.
Архитектура предприятия (EA) — это практика проектирования, планирования и управления общей структурой и работой организации. Она связана с согласованием технологий, процессов и людей организации с ее бизнес-целями и стратегией.
По своей сути EA помогает организациям понять, как взаимосвязаны их различные системы, процессы и отделы, и как их можно оптимизировать для более эффективной совместной работы. Она также помогает организациям адаптироваться к изменениям, предоставляя основу для внедрения новых технологий и процессов контролируемым и стратегическим образом.
EA часто используется для того, чтобы:
- Определять и документировать текущее состояние систем и процессов организации.
- Определять желаемое будущее состояние и создавать дорожную карту для его достижения.
- Определять приоритеты областей для улучшения и модернизации.
- Убедиться, что инвестиции в новые технологии соответствуют бизнес-целям и стратегии.
- Способствовать общению и сотрудничеству между отделами и уровнями организации.
EA обычно включает в себя комбинацию подходов «сверху вниз» и «снизу вверх». Подходы «сверху вниз» включают в себя постановку целей высокого уровня и разработку плана их достижения, тогда как подходы «снизу вверх» включают сбор информации и отзывов от заинтересованных сторон по всей организации.
Существует несколько платформ и методологий, которые можно использовать для поддержки EA, в том числе Open Group Architecture Framework (TOGAF), Zachman Framework и Federal Enterprise Architecture Framework (FEAF). Эти рамки содержат общий словарь и набор принципов, которым должны следовать специалисты по АП, и могут помочь организациям обеспечить всеобъемлющий и последовательный характер их усилий по АП.
Эффективное EA требует глубокого понимания бизнес-целей и стратегии организации, а также поддерживающих ее технологий и процессов. Это также требует сильных навыков общения и совместной работы, поскольку специалисты-практики EA должны работать с заинтересованными сторонами по всей организации, чтобы собирать информацию, определять области для улучшения и разрабатывать план достижения желаемого будущего состояния.
В целом, EA является критически важной практикой для организаций, стремящихся оптимизировать свою деятельность, адаптироваться к изменениям и убедиться, что их инвестиции в технологии соответствуют их бизнес-целям. Это помогает организациям понять, как их различные системы и процессы сочетаются друг с другом, и определить возможности для улучшения, что позволяет им работать более эффективно и результативно.
Open Group Architecture Framework (TOGAF) — это широко используемая структура корпоративной архитектуры (EA), которая помогает организациям проектировать, планировать и управлять общей структурой и работой своих систем и процессов. Разработанный и поддерживаемый The Open Group, глобальным консорциумом из более чем 600 организаций, TOGAF спроектирован так, чтобы быть независимым от поставщиков и масштабируемым, что делает его подходящим для организаций любого размера и в любой отрасли.
В основе TOGAF лежит метод разработки архитектуры (ADM), систематический подход к разработке и поддержке архитектуры предприятия. ADM состоит из ряда этапов, которые помогают организациям в процессе определения и реализации своего EA. Эти этапы включают:
- Этап A: Цикл разработки архитектуры. На этой фазе устанавливаются общая структура и цели EA, включая объем и границы архитектуры, заинтересованные стороны и механизмы управления, а также принципы, которыми будет руководствоваться разработка архитектуры.
- Этап B: Бизнес-архитектура. На этом этапе основное внимание уделяется бизнес-целям и стратегии организации, включая бизнес-факторы, влияющие на архитектуру, бизнес-возможности и процессы, необходимые для поддержки этих целей, а также заинтересованные стороны организации и их потребности.
- Этап C: Архитектура данных. На этом этапе рассматриваются требования организации к данным и информации, включая структуры данных и модели, необходимые для поддержки бизнес-процессов, источников и приемников данных, а также политик руководства и управления данными.
- Этап D: Архитектура приложений. На этом этапе основное внимание уделяется приложениям и программным системам, которые поддерживают бизнес-процессы, включая функциональные и нефункциональные требования к этим системам, проектирование и интеграцию этих систем, а также развертывание и эксплуатацию этих систем.
- Этап E: Технологическая архитектура. На этом этапе рассматривается базовое оборудование, программное обеспечение и инфраструктура, поддерживающие архитектуры приложений и данных, включая аппаратные и программные платформы, сетевую инфраструктуру и инфраструктуру безопасности, а также центры обработки данных и облачную инфраструктуру.
- Этап F: Возможности и решения. Этот этап включает в себя определение возможностей для улучшения и инноваций в архитектуре, а также разработку решений и дорожных карт для реализации этих возможностей.
- Этап G: Планирование миграции. На этом этапе основное внимание уделяется планированию и выполнению миграции до желаемого будущего состояния архитектуры, включая идентификацию и управление рисками, зависимостями и заинтересованными сторонами, а также разработку подробного плана миграции.
- Этап H: Управление реализацией. Эта фаза касается руководства и управления архитектурой во время и после внедрения, включая создание процессов управления, мониторинг и измерение архитектуры, а также текущее обслуживание и развитие архитектуры.
TOGAF — это комплексная и гибкая структура, обеспечивающая структурированный подход к архитектуре предприятия. Она помогает организациям понять свои текущие системы и процессы, определить желаемое будущее состояние и разработать план достижения этого состояния. TOGAF широко используется организациями по всему миру и поддерживается большим сообществом практиков и экспертов.
Федеральная структура архитектуры предприятия (FEAF) — это структура, используемая федеральным правительством США для разработки и поддержки архитектуры предприятия (EA). Разработанный Управлением управления и бюджета (OMB), FEAF призван помочь агентствам федерального правительства привести свои технологии, процессы и людей в соответствие с их миссией и целями.
FEAF состоит из пяти основных компонентов:
- Эталонная модель: это общий словарь и набор принципов, которые обеспечивают основу для остальной части FEAF. Он включает в себя набор стандартных определений и понятий, а также основу для организации и классификации различных компонентов архитектуры.
- Эталонная бизнес-модель (BRM): это представление бизнес-процессов и возможностей федерального правительства, организованное вокруг набора стандартных бизнес-функций. Он обеспечивает общее понимание деловой деятельности и процессов правительства и помогает агентствам выявлять возможности для улучшения и инноваций.
- Эталонная модель данных (DRM): это представление требований к данным и информации федерального правительства, включая структуры данных и модели, необходимые для поддержки бизнес-процессов, источников и приемников данных, а также политик управления данными.
- Техническая эталонная модель (TRM): это представление базовой технологической инфраструктуры федерального правительства, включая аппаратные и программные платформы, сетевую инфраструктуру и инфраструктуру безопасности, а также центры обработки данных и облачную инфраструктуру.
- Эталонная модель услуг (SRM): это представление услуг, предоставляемых федеральным правительством, включая функциональные и нефункциональные требования к этим услугам, проектирование и интеграцию этих услуг, а также развертывание и эксплуатацию этих услуг.
FEAF обеспечивает структурированный подход к разработке и поддержке корпоративной архитектуры для федерального правительства. Она помогает агентствам понять свои текущие системы и процессы, определить желаемое будущее состояние и разработать план достижения этого состояния. FEAF также помогает агентствам гарантировать, что их инвестиции в технологии соответствуют их миссии и целям, и способствует общению и сотрудничеству между департаментами и уровнями правительства.
FEAF поддерживается набором инструментов и ресурсов, в том числе Методом разработки архитектуры на основе FEAF (FEAF-ADM), который обеспечивает систематический подход к EA, и Методологией архитектуры федеральных сегментов (FSAM), которая обеспечивает руководство по разработке и поддержание архитектур сегментов, которые представляют собой специализированные структуры EA, ориентированные на определенные области или области правительства.
Zachman Framework — это инструмент, используемый для организации и классификации архитектуры предприятия. Это матрица, состоящая из шести строк и столбцов, где каждая ячейка представляет определенный аспект архитектуры. Строки представляют шесть вопросов «wh» (who, what, where, when, why, and how): кто, что, где, когда, почему и как; а столбцы представляют шесть категорий: контекста, мотива, масштаба, перспективы, реализации и эволюции.
Zachman Framework часто используется, чтобы помочь организациям понять и задокументировать их текущую архитектуру, а также спланировать будущие изменения и разработки. Это помогает обеспечить учет всех аспектов архитектуры и наличие четкой линии связи между различными заинтересованными сторонами.
Одним из ключевых преимуществ Zachman Framework является то, что он обеспечивает общий язык и структуру для обсуждения и документирования архитектуры предприятия. Это может помочь уменьшить путаницу и недопонимание, а также упростить взаимодействие и эффективную совместную работу различных групп и отделов.
Однако есть некоторые критические замечания в адрес Zachman Framework. Некоторые утверждают, что он может быть слишком жестким и негибким, и что он может неадекватно отражать сложность и динамичный характер современных предприятий. Другие отмечают, что это лишь один из многих инструментов, который можно использовать для понимания и управления архитектурой предприятия, и что важно также учитывать ряд других подходов и сред.
В целом Zachman Framework — ценный инструмент для организации и понимания архитектуры предприятия, но важно использовать его в сочетании с другими инструментами и подходами, чтобы обеспечить всеобъемлющий и эффективный подход к управлению архитектурой.
На самом деле, помимо базовых трех существует много разных подходов. Например, возьмем IBM:
IBM имеет долгую историю разработки и внедрения сред и инструментов корпоративной архитектуры. Они предназначены для того, чтобы помочь организациям понять, спроектировать и управлять своими сложными системами и процессами, а также обеспечить их соответствие бизнес-целям и задачам.
Одной из ключевых структур архитектуры предприятия, используемых IBM, является эталонная архитектура IBM для интеллектуальных предприятий (RAIE). Эта структура предназначена для того, чтобы помочь организациям разрабатывать и внедрять интеллектуальные системы, которые могут принимать более обоснованные решения и действовать на основе данных и идей. Он включает в себя набор шаблонов, моделей и практик, которые можно настраивать и применять к различным отраслям и организациям.
В дополнение к инфраструктуре RAIE IBM также предлагает ряд других инструментов и ресурсов для архитектуры предприятия, в том числе IBM Rational System Architect, который представляет собой инструмент для проектирования и моделирования сложных систем и процессов, а также IBM Enterprise Architecture Practice, который включает команду экспертов, которые предоставляют консультации и рекомендации по проектам архитектуры предприятия.
Предложения IBM по корпоративной архитектуре призваны помочь организациям оптимизировать свои системы и процессы, снизить затраты и повысить эффективность и результативность. Они основаны на долгой истории исследований и разработок в области корпоративной архитектуры и используются организациями по всему миру для улучшения своей деятельности и достижения своих бизнес-целей.
Теперь, думаю, у многих отпали вопросы по поводу роли Архитектора Предприятия (Enterprise Architect).
В заключение рекомендую всем желающим посетить открытое занятие «Определение бизнес-архитектуры как метода структурного управления инвестициями». На этом уроке участники:
- Рассмотрят определение бизнес-архитектуры как метод структурного управления инвестициями.
- Изучат общие принципы декомпозиции архитектуры предприятия, определение доменов и «строительных» блоков (ABB, SBB).
- Научатся моделировать бизнес-архитектуру, предприятия, а также мотивацию и стратегию изменений архитектуры предприятия.
Регистрация на урок открыта по ссылке.
- Enterprise Architect
- архитектор предприятия
- бизнес-архитектура
Источник: habr.com
Корпоративная архитектура и SOA
Архитектура предприятия – основа корпоративной информационной системы, требующая четкого определения и систематизации связанных с ней понятий, которые, однако, часто используются совершенно независимо. Методология SAP EAF позволяет ответить на вопросы, для чего нужно проектировать архитектуру предприятия, как начать переход к сервисной архитектуре и какова их взаимосвязь.
Многие компании уже осознали необходимость планирования развития не только бизнеса, но и ресурсов, необходимых для его поддержки. Налаживание оптимальной взаимосвязи бизнеса и ИТ невозможно без планирования ИТ-стратегии, согласованной с задачами и целями организации. Один из инструментов обеспечения подобной согласованности – сервисная архитектура, применяемая при проектировании и реализации приложений. Однако успех вопрлощения этого подхода в корпоративных информационных системах зависит от планирования и проектирования архитектуры приложений или, если подняться на одну ступень выше, от планирования и проектирования архитектуры предприятия в целом.
Архитектура предприятия
Архитектура предприятия (Enterprise Architecture, EA) – это концепция, описывающая текущее и целевое состояние архитектуры приложений, бизнес-процессов, ИТ-инфраструктуры, согласованных с бизнес-стратегией компании. Она также описывает механизмы организации, управления и ведения архитектуры, планы по переходу к целевому состоянию.
Архитектура предприятия является попыткой построить систему управления предприятием «сверху вниз». Есть множество различных моделей, позволяющих выбрать наиболее оптимальный вариант осуществления подобной трансформации, часть из них предлагает разнообразные версии структуры архитектуры предприятия (метамодели), раскрытые в моделях Захмана (Zachman Framework) или в модели US Federal EA, другие описывают подход к построению архитектуры предприятия (TOGAF). Компания SAP разработала методологию ведения архитектуры предприятия SAP EAF на базе TOGAF, которая ориентирована на интерпретацию и поддержку реализации целей компании посредством планирования и ведения специализированных описаний и представлений в следующих областях: бизнес-архитектура (в том числе бизнес-процессы, организационная структура); архитектура приложений; архитектура данных; техническая архитектура. Основное назначение SAP EAF – ускорение разработки архитектуры предприятия и снижение ее трудоемкости.
В рамках методологии создается ряд взаимосвязанных диаграмм, описывающих текущее и целевое состояние компании, а также план проведения изменений. SAP EAF предполагает также постановку процесса по непрерывному управлению архитектурой предприятия и полную реализацию цикла управления архитектурой предприятия.
Можно выделить три уровня архитектуры: архитектура предприятия, архитектура корпоративных (сквозных) приложений и архитектура приложений (рис. 1).
Архитектура предприятия рассматривает ландшафт предприятия в целом, определяет структуру, контекст и стандарты организации, поддерживает корпоративную стратегию, планирует развитие бизнес-процессов и ИТ-систем. Горизонт планирования архитектуры предприятия составляет обычно три–пять лет. В рамках архитектуры предприятия разрабатывается видение и определяются возможности и «разрывы» в ландшафте, а также разрабатывается план перехода и план миграции, включающий новые решения и проекты.
Архитектура корпоративных приложений ориентирована на поддержку решения одной из стратегических задач в перспективе до двух лет, включает в себя соответствующие проекты по реализации ИТ-систем. Один из подходов, который можно использовать для поддержки стратегических преобразований, базируется на идеях сервисной архитектуры (Service-Oriented Architecture, SOA), его успех во многом зависит от того, насколько точно архитектор понимает связь ИТ-ландшафта с бизнес-процессами и целями внедрения отдельных компонентов ландшафта. Иначе возникает риск создания и внедрения эффективного механизма интеграции приложений на базе сервисов без получения каких-либо бизнес-выгод.
Планирование архитектуры приложения ориентировано на перспективу до года и поддерживает тактические проекты. Архитектура приложения описывает решение и реализацию конкретной ИТ-системы, отражает выполнение соответствующего шага плана трансформации и реализацию одного из проектов.
Подход по планированию и проектированию архитектуры на базе методологии SAP EAF поддерживает разработку архитектуры на каждом из перечисленных уровней.
SOA
Если переходить к архитектуре конкретных приложений, то можно увидеть разнообразие различных типов архитектур, используемых при построении информационных систем. Среди них все большую популярность приобретает сервисная архитектура приложений. Концепция сервисной архитектуры существует уже давно, но далеко не всегда ее применение ведет к успеху – многое зависит от выбранного подхода к ведению и управлению архитектурой предприятия в целом.
Прикладная логика реализуется в SOA-приложениях так же, как и в обычных, а для доступа к функциям приложений используется специальная «обертка» в виде Web-сервиса, позволяющая вызывать данную функциональность из других приложений и подсистем. При этом SOA рассматривается не только как архитектура для развертывания и выполнения распределенных прикладных решений, но и как модель программирования, в которой архитектура приложения строится на основе сервисов, предоставляемых другим приложениям в сетевой среде с помощью описания и публикации соответствующих интерфейсов. Однако концепция SOA не дает точного описания, как именно должны взаимодействовать сервисы, как добиться того, чтобы они понимали друг друга и могли быть интегрированы.
Сервисы в SOA могут представлять собой простые или сложные объекты, процессы взаимодействия некоторого множества объектов, процессы, состоящие в свою очередь из нескольких процессов, или даже некий комплекс приложений, которые в совокупности приводят к получению единого результата. Важно, что с точки зрения архитектуры сервис (независимо от внутренней структуры и языка реализации) выглядит как единое целое.
К сервисам можно отнести элементы, которые: являются востребованной функцией приложения либо системы; являются выполняемой функцией; удовлетворяют политике и требованиям к качеству сервиса – обеспечивают масштабируемость, надежность, соблюдение соглашения об уровне обслуживании.
Для того чтобы начать переход к сервисной архитектуре, необходимо определить процессы и приложения, которые больше всего подходят для использования данной концепции. Для этого в SAP рекомендуют анализировать архитектуру предприятия в целом, причем от уровня детализации описания бизнес-процессов, ИТ-систем и данных, выполняемых в рамках проводимого анализа, зависит проработка потенциальных сервисов, описание их операций и политик. Это позволит корректно отразить и реализовать целевые бизнес-процессы и потребности пользователей в ИТ-системах.
При идентификации сервисов необходимо обращать внимание на следующие черты бизнес-процесса, которые помогут отличить сервисы от обычных операций процесса и определить потенциальных кандидатов на роль сервисов:
- возможность повторного использования функциональности;
- степень стандартизации прикладной функциональности;
- степень автоматизации операций сервиса, в котором не должно быть задач, выполняемых вручную;
- приемлемая стоимость реализации;
- возможность синхронного взаимодействия приложений; для реализации асинхронного взаимодействия, как правило, используется корпоративная сервисная шина (Enterprise Service Bus, ESB).
В рамках архитектуры предприятия выделяют два подхода: бизнес-представление SOA и ее техническое представление. Техническое представление – это SOA в классическом понимании, а бизнес-представление введено в рамках концепций SAP EAF и TOGAF, и направлено оно на то, чтобы выявить новые возможности бизнеса, применяя концепцию SOA, и использовать их для успешного развития предприятия, а также при реализации новых продуктов и услуг. Бизнес-сервис – это компонент, который:
- выполняется вручную или является автоматизированным;
- выполняется в рамках предприятия или передан на аутсорсинг;
- доступен для сотрудников предприятия, партнеров, клиентов и поставщиков;
- выполняется в рамках соответствующей организационной единицы или на уровне корпоративного центра компетенций;
- имеет соглашение об уровне обслуживания (Service Level Agreement, SLA).
Примерами бизнес-сервисов могут служить электронная почта, call-центр, ИТ-поддержка в режиме онлайн, энергоснабжение, централизованные закупки и др. Выделение бизнес-сервисов позволяет определить бизнес-модель предприятия, которая накладывает ограничения на сервисные операции, интерфейсы и определяет соглашение об уровне обслуживания. Кроме того, такая формализация бизнес-процессов существенно облегчает работу разработчика SOA-решений.
ИТ-стратегия, архитектура предприятия и SOA
Зрелые компании достаточно четко описывают текущее состояние архитектуры предприятия (т.е. в классическом варианте состояние бизнес-архитектуры, архитектуры приложений, архитектуры данных, технической архитектуры) и необходимые организационные процедуры и процессы управления. Однако концепция архитектуры предприятия охватывает лишь часть ИТ-стратегии (рис. 2), а SOA является одной из концепций уровня архитектуры корпоративных приложений и помогает создавать корпоративные приложения на основе принципов, заложенных в архитектуру предприятия.
Архитектура предприятия покрывает часть важных для ИТ-стратегии компонентов, оставляя за рамками элементы стандартных для ИТ-департамента процедур планирования, принципов и методов управления, организации деятельности и поддержки. С другой стороны, в современных организациях, где нет четко выделенного процесса ведения архитектуры предприятия, отсутствуют архитекторы (бизнес, технические и корпоративные), – в лучшем случае функции технических архитекторов распределены между несколькими специалистами.
Характерной иллюстрацией различия проектов по построению ИТ-стратегии и архитектуры предприятия является то, насколько большое внимание уделяется проработке принципов управления ИТ-ресурсами при формировании ИТ-стратегии, в то время как при проектировании архитектуры предприятия ведется разработка соответствующих документов только для группы архитекторов. Таким образом, концепция архитектуры предприятия ориентирована на поддержку организации в части эффективного планирования и управления ИТ-процессами. Эта концепция должна помочь в построении эффективной системы управления предприятием и упростить задачу ИТ-директора по управлению и развитию информационных технологий в рамках компании.
ИТ-стратегия является важным компонентом управления, планирования и развития информационных технологий в рамках предприятия. Для того чтобы помочь организациям в ведении и управлении ИТ, появилась концепция архитектуры предприятия, которая включает в себя компоненты управления ИТ-ландшафтом, ИТ-инфраструктурой, процедуры ведения и изменения архитектуры предприятия, планирование навыков ИТ-персонала, мониторинг эффективности.
Все перечисленные компоненты расшифровывают и расширяют понятие ИТ-стратегии и помогают ИТ-директору правильно построить план развития и перехода к целевому ландшафту в зависимости от поставленных бизнесом целей. При этом хорошо структурированные и детальные описания всех доменов архитектуры предприятия позволяют построить и реализовать приложения, в наибольшей степени отражающие требования бизнеса, а также выбрать соответствующую архитектуру корпоративных приложений или принять решение о переходе на сервисную архитектуру. В этом случае результаты проектирования архитектуры предприятия используются как входящая информация и ограничения для описания и выделения сервисов приложений. Причем важно понимать, что SOA используется для разработки архитектуры корпоративных приложений и зависит от стратегического видения архитектурных принципов и ИТ-целей, принятых в рамках архитектуры предприятия.
Понятия SOA и архитектура предприятия относятся к разным уровням архитектуры: архитектура предприятия определяет целевую ИТ-архитектуру в рамках компании, основные направления развития и план трансформации, в то время как SOA используется при разработке и проектировании корпоративных приложений. Успешность реализации и результат разработки сервис-ориентированных приложений зависят от того, насколько полно
и детально ведется архитектура предприятия, понимается ли она бизнес-пользователями и отражает ли актуальные бизнес-цели и потребности. n
SOA: подходы к реализации. Управление ИТ
Появление концепции SOA стало закономерным шагом на пути поиска решения одной из самых насущных и сложных проблем ИТ-индустрии – проблемы интеграции приложений.
http://www.osp.ru/os/2004/06/184450
Методология SAP EAF
Методология состоит из SAP EAF Architecture Process, SAP EAF MetaModel, руководства, ресурсной базы и инструментов.
SAP EAF Architecture Process – модель, описывающая процесс разработки архитектуры и предлагающая разбить его на фазы (см. рисунок): видение архитектуры (А) – определение границ проекта, разработка общего представления архитектуры, согласование плана работ и подхода; бизнес-архитектура (B) – множество бизнес- и технических требований, целей и стратегических направлений развития, данные gap-анализа, описание текущих и целевых бизнес-процессов, функций, сервисов, план перехода на новую бизнес-архитектуру; архитектура информационной системы (С) – формализованное описание существующей архитектуры приложений и данных на основе разработанной бизнес-архитектуры и проведенного gap-анализа, документация по целевой архитектуре и составные элементы архитектуры приложений и архитектуры данных. Далее в SAP EAF Architecture Process входит описание текущей и целевой технической архитектуры (D): системное программное обеспечение, серверы, базы данных, аппаратное обеспечение, сеть, а также высокоуровневый план перехода к целевой архитектуре (Е).
Планирование миграции (F) предполагает разработку детального плана перехода к целевой архитектуре, включающего все необходимые для этого изменения (организационные, бизнес-процессы, ИТ-ландшафт). Основная цель управления реализацией (G) состоит в мониторинге процессов проектирования, реализации корпоративных информационных систем и своевременном внесении изменений во все домены архитектуры предприятия. Управление изменениями архитектуры (H) включает в себя весь комплекс мероприятий по управлению изменениями (разработка новой функциональности, изменения в бизнес-процессах, изменения принципов управления). Управление требованиями является ядром процесса создания архитектуры предприятия на базе SAP EAF и предусматривает постоянный мониторинг, сбор и формализация потребностей бизнеса.
SAP EAF MetaModel – модель, определяющая соглашения о проектировании архитектуры предприятия. На базе отдельных каталогов в модели описываются компоненты архитектуры, взаимоотношения между компонентами отображаются с помощью специальных матриц. В финальном графическом представлении описываются все домены текущей и целевой архитектур.
Руководства по построению архитектуры предприятия, шаблоны и примеры. Ресурсная база – база архитектурных стандартов, используемых при проектировании архитектуры предприятия. Инструменты, поддерживающие разработку и моделирование архитектуры предприятия. Модель архитектуры предприятия на базе SAP EAF может быть описана с помощью целого ряда инструментов, существующих сегодня на рынке моделирования бизнес-процессов (например, ARIS).
Таким образом, методология SAP EAF определяет последовательность действий (SAP EAF Architecture Process) и набор результирующих документов (матрицы, представления – SAP EAF Metamodel), разрабатываемых на каждом шаге при проектировании архитектуры предприятия.
Источник: www.osp.ru
