Какой архитектурный фреймворк использует сбербанк togaf aris

Обновлено: 01.07.2024

В этой статье пойдёт речь о международном стандарте TOGAF (The Open Group Architecture Framework) в области системной архитектуры предприятия. TOGAF 9.1 занимает почти 700 страниц, поэтому здесь мы сможем рассмотреть только введение. Без исторического вступления, без объяснений, что такое Open Group, и рассуждений о пользе и трудностях практического применения стандартов — со всем этим разберётесь без меня — перейду сразу к делу.

Краткий обзор

На первых страницах стандарта приводится Executive Overview, в котором, судя по всему, даются ответы на возможные вопросы со стороны топ-менеджмента.

Что такое предприятие (enterprise)?

В соответствии с TOGAF термин «предприятие» имеет широкую трактовку. Предприятием называется одна или несколько организаций с общими целями. В этом смысле предприятием может считаться как целая корпорация, так и её подразделение; как государственное учреждение, так и коммерческая фирма или, например, несколько фирм с общими владельцами.

Что такое архитектура предприятия?

Основные термины в стандарте TOGAF взяты из стандарта ISO 42010 «Программная инженерия — Описание архитектуры». В соответствии с ISO 42010 архитектура представляет собой: «фундаментальную организацию системы, состоящую из компонент, их отношениях друг к другу и окружающей среде, а также принципов, определяющих проектирование и развитие системы». В этом смысле TOGAF рассматривает организацию как систему.

В тоже время TOGAF вводит для архитектуры и более частное определение, которое применяется в своём контексте. В соответствии с ним: « архитектура — это формальное описание системы или детальные план системы на уровне компонент, на основании которого осуществляется реализация системы».

Зачем нужно заниматься архитектурой предприятия?

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

Что же заставит меня («капитана бизнеса») заниматься архитектурой предприятия?

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

Какие задачи ставятся архитектору на уровне предприятия?
  • Формализация выявленных проблем и заявленных требований к ИТ со стороны бизнеса. Отмечу, что выявлением проблем и установкой требований должен заниматься менеджмент.
  • Разработка архитектурных представлений (уровней), которые бы показывали, как решаются конкретные задачи и как обеспечивается реализация требований.
  • Определение точек разногласия различных заинтересованных сторон и разработка компромиссных предложений.
Почему в качестве основы для разработки архитектуры предприятия мне нужно выбрать именно TOGAF?

Разработка и поддержание архитектуры предприятия представляет собой технически сложный процесс и охватывает различные стороны, имеющие собственные точки зрения и интересы. В этой ситуации TOGAF может создать авторитетную основу для внутрикорпоративной стандартизации и снижения проектных рисков при разработке архитектуры. В создании TOGAF принимали участие более 300 участников форума Open Group из ведущих компаний в сфере ИТ (в большинстве, конечно, американских компаний). В результате TOGAF представляет собой набор «лучших мировых практик», которые позволяют сделать работоспособную и экономически эффективную архитектуру предприятия, ориентированную на потребности бизнеса.

Как относиться к подобной аргументации — решайте сами.

Домены архитектуры

  • Бизнес архитектура — определяет стратегию предприятия, структуру управления и ключевые бизнес процессы.
  • Архитектура данных — описывает логическую и физическую структуру данных организации, а также структуру корпоративных ресурсов для управления данными.
  • Архитектура приложений — служит своеобразной картой всех используемых корпоративных приложений и определяет следующие аспекты:
    1. участие каждого из приложений в бизнес процессах компании;
    2. взаимодействие приложений друг с другом и внешними сервисами.
  • Технологическая архитектура — определяет структуру и логику программного обеспечения и аппаратной среды, необходимых для работы бизнес приложений и доступа к нужным данным. Этот уровень включает всю поддерживающую инфраструктуру: сети, сервера, процессинг и т. п.

Архитектор уровня предприятия должен успешно работать в каждом из этих доменов.

Метод разработки архитектуры

TOGAF основан на итеративной процессной модели, которая предусматривает повторное использование имеющихся архитектурных компонент. TOGAF включает методологию разработки архитектуры под названием Architecture Development Method (ADM). В соответствии с ADM разработка системной архитектуры состоит из следующих фаз:


Architecture Development Method

Следующая статья будет посвящена структурным элементам TOGAF

Обзор подготовлен с использованием материалов стандарта TOGAF версии 9.1


Много кто пользуется приложением Сбербанк Онлайн, но немногие знают, как оно работает. Настало время приоткрыть завесу тайны – в этой статье мы расскажем о некоторых подходах, которые используем в разработке.


Здесь не будет биг даты, блокчейна, аджайла и другого рокет-сайенса. Зато будет описано API, на котором работают наши самые популярные приложения. Ценность этой статьи не в прорывных идеях, а в подходах и практиках, которые работают в большом приложении с одной из самых требовательных аудиторий.

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

О чем пойдет речь

Мы расскажем, как в мобильном и веб приложениях Сбербанк Онлайн работают платежные сценарии, а именно про API между приложениями и сервер-сайдом.


Почему фокус на API? Все просто – это фактически единственный мостик, который соединяет клиентские приложения и бэкенд. Если проект небольшой, то мы можем легко менять API и переписывать под него приложения. Но если проект масштабный (такой, как у нас), то даже небольшие изменения API требуют вовлечения большого количества ресурсов как на фронте, так и на бэкенде, и становятся очень дорогими. И второй момент – чем раньше мы зафиксировали API, тем раньше фронтальные и бэковые команды могут начинать разработку. Им просто надо будет сойтись в одну точку.

Сначала мы немного расскажем о наших возможностях и ограничениях, чтобы было понятно, почему мы выбирали то, а не иное решение, а потом представим сам протокол API на верхнем уровне.

Специфика и мотивация

Приложения большие. Когда мы писали эту статью, приложение Сбербанк Онлайн на Android занимало около 800 000 строк кода, на iOS – 500 000 строк кода. И это только наш код, без подключаемых библиотек.

Обратная совместимость и много пользователей. MAU – 32 млн активных пользователей мобильного приложения. И если мы не сделаем обратную совместимость на уровне API, очень многим пользователям по всей стране придется качать приложения заново. Это очень нехорошо. Кстати, это одна из причин, почему у нас так много кода.

Сбербанк Онлайн разрабатывает много небольших команд. Вы, наверное, слышали про Agile в Сбербанке. Это правда, мы работаем по Agile в командах по 9 человек.

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

Два типа команд. Есть платформенные – они отвечают за разработку ядра приложения. И есть фичёвые команды – они создают прикладной функционал для конечных пользователей, используя архитектуру и инструменты, которые даёт платформа.

Омниканальность. Крайне важная история. Чтобы не разрабатывать бэк несколько раз – отдельно для мобильных приложений и отдельно, например, для веб-версии и банкоматов, нужно сделать так, чтобы API был максимально схожим для всех каналов (как минимум должна быть одинаковой структура ответа).

Мобильное приложение

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

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

Лучший клиентский опыт: мы выбрали для себя основную технологию разработки мобильных приложений – разработка на нативных языках. Только так можно получить лучший клиентский опыт.

Если обобщить все эти требования – приложения должны разрабатываться на нативных языках, иметь повторно используемые компоненты внутри себя, но при этом вся бизнес-логика должна управляться со стороны сервера.

Как делать не стали

После того как мы обозначили граничные условия, расскажем, какие существующие решения мы анализировали.

Программирование на JSON

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

Не используем описание стилей компонентов, поскольку они могут разниться от форм-фактора, платформы и даже режима работы (портретная/ландшафтная ориентация, responsive в web). Декларации стилей в конечной реализации всегда будут качественнее, ближе к реальности и корректнее работать с краевыми случаями. Кроме этого, бывает, что компоненты со схожей логикой принципиально по-разному работают на разных устройствах: например, ввод номера телефона – с телефонной книгой на мобильном устройстве и без неё в вебе.

Фиксация модели данных в интерфейсе приложения

Этот способ еще называется «прибить гвоздями». Смысл в том, что интерфейс приложения строится на уникальных идентификаторах объектов, которые передаются с сервера. В такой схеме любые изменения на стороне сервера приводят к переработкам клиентской части. Невозможно повторно использовать код. Сложно поддерживать.
Единственное, почему стоит выбирать такой способ на своем проекте, – уверенность на 99%, что API не будет меняться. Ну или если проект совсем небольшой и проектировать API дороже, чем быстро переделать пользовательский интерфейс под изменения в API.

Добавляем к каждому объекту признак стиля. UI приложений строим на основании этого признака. Стилей ограниченное число, поэтому появляется возможность строить интерфейс динамически. Но с увеличением функциональности UI приходится увеличивать количество стилей.
В этом варианте становится возможно управлять отображением отдельных элементов, но повышается сложность реализации связанности между разными полями. И главное – с ростом вариативности UI у вас будет постоянная необходимость расширять протокол API.

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

Web Components / React Components API

Концепция веб-компонентов, которая в том числе значительно повлияла на API компонентов React, нам подходит уже намного лучше: с одной стороны, у нас есть контроль за отображением, с другой стороны – есть возможность привязывать данные к элементам UI.
К сожалению, всё слишком сильно завязано на HTML + CSS + JS. Напрямую не используешь, но запомним – потом пригодится.

Как решили делать

UI-контейнеры

Объекты упаковываются в контейнеры, презентационную логику приложения строим на этих контейнерах. Основное преимущество – можем группировать несколько простых объектов в один контейнер. Это дает свободу в программировании UX/UI на клиенте, например, можем управлять скрытием/отображением одного поля при заполнении данных в другом. При этом базовых типов объектов – ограниченное число, и весь бизнес-транспорт реализуется на них.

Мы выбрали именно этот подход. Сначала мы опишем протокол API, а потом – как устроены фрэймворки внутри мобильных и веб-приложений.

Чтобы было понятнее, рассмотрим API на примере простого процесса, например, перевод между своими счетами. Как добираемся до точки входа, не рассматриваем – это не процесс и для этого есть свой API (о нем мы тоже как-нибудь расскажем). Итого, процесс у нас начинается с точки входа:

Транспорт данных

Для начала договоримся об основных принципах – как передаём данные. За основу возьмём самый простой подход – пары «ключ-значение». Ключом пусть будет строка из букв латинского алфавита, значение – тоже строки, но уже произвольные.

Формы для заполнения бывают сложные, с вложенными элементами и подразделами, значит, надо допускать вложенность. Можно именовать ключи в формате camelCase, но они могут быть плохо читаемым (например, в логах) или даже «портиться» в системах, нечувствительных к регистру. Нужно ввести разделитель.

Самый очевидный разделитель – точка – во многих языках используется для доступа к свойствам объекта. При неаккуратном использовании ключи с таким разделителем будут создавать словари (или объекты), в которых возможны коллизии. Например, “foo.bar” = “foobar” и “foo.bar.baz” = “foobarbaz” в javascript может повлечь перезапись свойства “bar” объекта “foo” со строки на объект. В конце концов, договорились на двоеточии: с одной стороны, явное визуальное разделение и семантическое отражение вложенности, с другой стороны, достаточно безопасно для всех используемых языков.

Что делать с повторяемыми полями? Вводим дополнительное правило: между парой разделителей могут быть либо латинские буквы, либо цифры. Получаются конструкции вида: children:5:name:first.

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

Решение: значение – либо строка, либо список строк. Так решение выглядит типовым, но в то же время накладные расходы оказываются незначительными.


Шаг – это состояние процесса. Первый шаг у нас – выбор счета списания и счета зачисления и ввод суммы.

UI на этой картинке не видно, потому что шаг – это про серверную логику, а не про презентационную. Есть два подхода к работе с шагами: можно передавать с сервера только разницу (нарастающий итог в клиентском приложении) или каждый шаг целиком (нарастающий итог на сервере).

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

Из дополнительных плюсов: при возврате к редактированию не нужно проигрывать весь сценарий или передавать дополнительный параметр “отдай всё”. При старте шага клиентское приложение сразу же получает всю нужную информацию для построения экранов.

Экраны


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

Для экранов мы ввели два правила:

  1. переход между экранами может быть только линейным, без ветвлений;
  2. переход между экранами не требует взаимодействий с бэкэндом.

UI компоненты (блоки)

UI компонент – независимый компонент, который реализует клиентскую логику и наполняет документ данными. По сути, это ассоциация между управляющей командой в протоколе и куском кода и разметки в приложении. На первом экране три компонента:

  1. Счет списания
  2. Тот же компонент для счета зачисления
  3. Сумма перевода

Поля – это атомарные компоненты, которые выступают транспортом для отдельных элементов данных и обрабатывают пользовательский ввод в случае деградации блока. Типов полей ограниченное число и все они поддерживаются на уровне фрэймворка: text, checkbox, select, multiselect.

Это значит, что любая версия приложения может отрисовать интерфейс, опираясь только на типы полей.

Поля в UI-компонентах из нашего примера:


1. Поле со ссылкой на справочник в счете списания и счете зачисления. Почему ссылка на статический справочник? Потому что счет мы выбираем из списка карт (счетов), без лишнего обращения к серверу.


2. Два отдельных поля для суммы и валюты в компоненте ввода суммы

Таким образом, формат для полей имеет такую структуру:

События

Так как приложения ничего не знают о процессе, логично, чтобы события (кнопки, которые видит пользователь) тоже были частью ответа от сервера.

События мы разделили на два типа.

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


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

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

Справочники

Со справочниками все стандартно. Если он небольшой, то мы его присылаем полностью в ответе от сервера и называем статическим. Сделано это для того, чтобы минимизировать количество запросов к сервер-сайду и время отклика на действие пользователя в интерфейсе. Чтобы его отобразить в форме на экране, добавляем поле с типом – selectList, одно из свойств которого – ссылка на статический справочник.

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

Ошибки валидации на клиенте и сервере


Примерно так выглядит структура ответа:


Фрэймворки

Теперь немного о том, как с этим протоколом работают фрэймворки внутри приложений. Условно фрэймворки можно разделить на две основные части: workflow engine + обработчик UI-контейнеров. Такое разделение вызвано не только архитектурой приложений, но и организационной структурой. Движок разрабатывают и поддерживают платформенные команды, а UI-контейнеры фактически являются точками расширения и их программируют фичёвые команды. Таким образом, большему количеству команд не нужно вносить изменения в ядро.

Workflow engine

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

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

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

Как работают UI-контейнеры?

Анализ потребностей дизайнеров и бизнес-заказчиков показал, что все потребности не получится удовлетворить простым расширением атрибутивного состава полей.

Поэтому нужны были точки расширения. Этими точками расширения стали UI-компоненты – это нативная реализация кода в самих приложениях, который идентифицируется движком по названию. По сути, это группировка поля/нескольких полей в логический блок, который может отображать кастомный UI. При этом модель данных протокола используются только для транспорта данных на бэкенд, весь UX и UI реализуется на стороне приложения.

Два режима работы фрэймворка

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


Слева – как может отображаться контейнер для ввода суммы на списке из простых типов полей. Справа – если в сборке приложения есть UI-контейнер. Несмотря на то, что в режиме списка простых полей нет слайдера и есть отдельное поле вместо иконки с выбором валюты, – мы можем передать все данные с PL и процесс будет рабочим.

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

Каких правил мы стараемся придерживаться при работе с UI-компонентами:

  • Поддерживать работу функционала в режиме списка простых типов полей. У любого прикладного проекта есть соблазн превратить динамический протокол в статический. Поэтому мы всех просим сначала разработать функционал на типовом UI-контейнере, а потом обогащать UX/UI добавлением кастомных контейнеров на этой модели данных. Это не только позволит в будущем обновлять процессы на старых сборках, но и автоматически поддерживает логическую целостность API.
  • Не менять модель данных (JSON) для UI-контейнера, если он уже готов (проходит финальное тестирование или уже в продакшене). Так как логика на PL жестко связана с моделью данных, её изменение сломает функционал на версиях мобильного приложения, которые не обновляются. Тем не менее, модель можно расширять при условии сохранения обратной совместимости.
  • Называть свой UI-компонент системным именем. Так как имя UI-компонента – обязательный атрибут протокола и должен быть минимум один на каждом экране, мы ввели специальное системное имя, которые реализует простой список полей.
  • Не реализовывать бизнес-логику на UI-компонентах. Логику необходимо реализовывать на сервере, почему – писали выше.

Coming soon…

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

Пишите в комментариях, что непонятно, что интересно – постараемся писать меньше, но чаще и в цель. У нас много интересных вызовов, и поэтому много материала.

анализ, бизнес-процессы, моделирование, BABOK, TOGAF, ARIS

Продолжая речь про анализ корпоративной деятельности, сегодня рассмотрим основы архитектуры предприятия и разберем 2 наиболее популярных подхода к ее проектированию: TOGAF и ARIS. Читайте далее, какие еще архитектурные фреймворки выделяет руководство по бизнес-анализу BABOK®Guide, чем TOGAF отличается от ARIS и как этот подход позволяет бизнес-аналитику комплексно описать корпоративную деятельность.

Немного об архитектуре предприятия: взгляд BABOK и не только

Описание корпоративной деятельности с целью ее оптимизации не сводится только к моделированию бизнес-процессов в стандартных нотациях, которые мы разбирали здесь. Согласно рекомендациям BABOK®Guide в главе «Анализ стратегии» (Strategy Analysis), следует также проанализировать существующие на предприятии организационные структуры (проектные и функциональные), цели и показатели их достижения, линейку создаваемых продуктов/услуг, которые приносят доход, а также инфраструктуру (программное и аппаратное обеспечение, оборудование), используемые в работе. Все это в совокупности образует единую систему – архитектуру предприятия, для проектирования которой существует множество специальных подходов (фреймворков), наиболее популярным из которых сегодня считается TOGAF (The Open Group Architecture Framework).

Справедливости ради стоит отметить, что руководство по бизнес-анализу BABOK®Guide при описании перспективы «Бизнес-архитектура» упоминает не только TOGAF, но и другие архитектурные фреймворки, например, eTOM, COBIT, ITIL, PCF и пр. в качестве эталонных бизнес-моделей, универсальных или специфических для отдельных предметных областей. При этом в BABOK фреймворк TOGAF позиционируется в качестве метода (техники), будучи упомянутым вместе с такими подходами как CJM, дорожная карта, фреймворк Захмана и т.д. Однако, такое позиционирование вызывает вопросы, поскольку TOGAF и, к примеру, карта взаимодействия с клиентом (Customer Journey Map, CJM) имеют абсолютно разные объемы и точки описания корпоративной деятельности. Впрочем, этот вопрос снимается, если вспомнить, что BABOK – это не строгий ГОСТ, а сборник лучших практик бизнес-анализа, не претендующий на абсолютную полноту содержащихся в нем знаний и рекомендаций.

The Open Group Architecture Framework (TOGAF) - методология/библиотечный метод описания/подход (framework) для описания архитектуры предприятия, который предлагает подход для проектирования, планирования, внедрения IT-архитектуры предприятия и управления ей. TOGAF разрабатывается с 1995 группой The Open Group на основе фреймворка Министерства обороны США TAFIM.

TOGAF - высокоуровневый подход к проектированию. В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов:

  • Бизнес архитектура (Business) — определяет стратегию предприятия, структуру управления и ключевые бизнес процессы.
  • Архитектура данных (Data) — описывает логическую и физическую структуру данных организации, а также структуру корпоративных ресурсов для управления данными.
  • Архитектура приложений (Application) — служит своеобразной картой всех используемых корпоративных приложений и определяет следующие аспекты:
    • участие каждого из приложений в бизнес процессах компании;
    • взаимодействие приложений друг с другом и внешними сервисами.

    По состоянию на 2016, TOGAF используют 40 из 50 крупнейших транснациональных компаний и 300 из 500 самых крупных компаний США.

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

    Содержание

    Основные принципы

    • модульность
    • стандартизованность
    • повторное использование зарекомендовавших себя существующих продуктов и технологий

    Задачи системного архитектора

    • Формализация выявленных проблем и заявленных требований к ИТ со стороны бизнеса. Выявлением проблем и установкой требований должен заниматься менеджмент.
    • Разработка архитектурных представлений (уровней), которые бы показывали, как решаются конкретные задачи и как обеспечивается реализация требований.
    • Определение точек разногласия различных заинтересованных сторон и разработка компромиссных предложений.

    Терминология

    В соответствии с TOGAF термин «предприятие» имеет широкую трактовку. Предприятием называется одна или несколько организаций с общими целями. В этом смысле предприятием может считаться как целая корпорация, так и её подразделение; как государственное учреждение, так и коммерческая фирма или, например, несколько фирм с общими владельцами.

    Основные термины в стандарте TOGAF взяты из стандарта ISO 42010.

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

    Состав

    В состав модели TOGAF входят две основные компоненты:

    • Метод разработки архитектуры (ADM, Architecture Development Method), определяющий процесс разработки архитектуры;
    • Базовая Архитектура (Foundation Architecture)

    Метод разработки архитектуры

    TOGAF основан на итеративной процессной модели, которая предусматривает повторное использование имеющихся архитектурных компонент. В соответствии с ADM разработка системной архитектуры состоит из следующих фаз:

    ADM.jpg

    • Предварительная фаза предусматривает подготовку условий для разработки архитектуры, включая адаптацию TOGAF к реальной среде, и определение основных принципов, на которых будет строиться разработка архитектуры.
    • Фаза A: Видение архитектуры представляет собой начальную фазу цикла разработки архитектуры. Фаза включает планирование основных мероприятий, определение заинтересованных сторон, создание «Архитектурного видения» и утверждение это видения у руководства.
    • Фаза B: Бизнес архитектура предусматривает разработку архитектуры деятельности предприятия в соответствии с ранее утвержденным видением.
    • Фаза C: Архитектура информационных систем
    • Фаза D: Технологическая архитектура
    • Фаза E: Возможности и решения. Фаза определяет разрыв между текущей архитектурой и целевой, а также устанавливает набор возможных средств для достижения целевой архитектуры. В основе данной фазы лежит SWOT-анализ. В качестве средств достижения целей могут инициироваться различные проекты и программы.
    • Фаза F: Планирование перехода определяет мероприятия для перехода из текущего состояния архитектуры в целевое. Фаза предусматривает разработку «Плана реализации и перехода», детализированного до уровня пакетов работ, которым можно дать стоимостную оценку и, в конечном счёте, оценить проектные параметры (объём, сроки, стоимость) всего перехода в целом.
    • Фаза G: Управление реализацией обеспечивает архитектурный надзор в процесс перехода от текущего состояния к целевому.
    • Фаза H: Управление изменениями в архитектуре. Для того чтобы обеспечить достижение изначальных целей в меняющихся условиях, необходимо управлять всеми изменениями, которые вносятся в целевую архитектуру.
    • Управление требованиями — это процесс, который охватывает все этапы разработки архитектуры и обеспечивает целостность всего проекта.

    Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D!

    Базовая архитектура

    Базовая Архитектура включает в себя:

    • набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model – TRM);
    • набор элементарных архитектурных элементов, которые используются как "строительные блоки" (Building blocks) при построении конкретных решений:
      • Архитектурные блоки (Architecture Building Blocks) — определяют требования и создают каркас, необходимый для их реализации. Например, на уровне предприятия архитектурным блоком может стать необходимость предоставления клиентского сервиса, что, в конечном счёте, приведёт к разработке различных решений как на уровне бизнеса, так и на уровне ИТ.
      • Блоки реализации (Solution Building Blocks) — определяют компоненты готового решения. Например, корпоративная сеть, как готовый продукт, может быть строительным блоком при разработке распределённой информационной системы.

      Использование TOGAF с другими фреймворками

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

      Во всех случаях предполагается, что архитектор будет адаптировать и развивать TOGAF для того, чтобы определить индивидуальный метод, который интегрирован в процессы и организационные структуры предприятия. Эта адаптация может включать в себя принятие элементов из других архитектурных фреймворков или интеграцию методов TOGAF с другими стандартными фрейворками (ITIL, CMMI, COBIT, PRINCE2, PMBOK).


      Структура Open Group Architecture Framework ( TOGAF ) - это наиболее часто используемая структура для архитектуры предприятия на сегодняшний день, которая обеспечивает подход к проектированию, планированию, внедрению и управлению архитектурой информационных технологий предприятия. TOGAF - это высокоуровневый подход к дизайну. Обычно он моделируется на четырех уровнях: бизнес, приложения, данные и технологии. Он в значительной степени опирается на модульность, стандартизацию и уже существующие проверенные технологии и продукты.

      TOGAF была разработана , начиная 1995 года The Open Group , на основе Департамента обороны США 's TAFIM и Capgemini ' s Integrated Architecture Framework (IAF). По состоянию на 2016 год The ​​Open Group утверждает, что в TOGAF работают 80% компаний из списка Global 50 и 60% компаний из списка Fortune 500 .

      СОДЕРЖАНИЕ

      Обзор

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

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

      ANSI / IEEE Standard 1471-2000 спецификация архитектуры (из-программных систем) можно сформулировать так: «фундаментальной организации системы, воплощенная в ее компонентах, их отношениях друг с другом и окружающей среды, а также принципы , регулирующие его дизайн и эволюция ".

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

      Метод разработки архитектуры (ADM) является ядром TOGAF, который описывает метод разработки и управления жизненным циклом архитектуры предприятия.

      История


      Процесс планирования архитектуры на основе стандартов DoD в TAFIM .

      TOGAF был инициирован в начале 1990-х годов как методология разработки технической архитектуры и был разработан Open Group в обширную структуру архитектуры предприятия . В 1995 году была представлена ​​первая версия TOGAF (TOGAF 1.0). Эта версия была в основном основана на Технической структуре архитектуры для управления информацией (TAFIM), разработка которой началась в конце 1980-х годов Министерством обороны США .

      TOGAF 9 является эволюционным развитием TOGAF 8 и включает в себя множество новых функций, таких как:

      • Повышенная точность, включая формальную метамодель контента, которая связывает артефакты TOGAF вместе (хотя есть некоторые проблемы с метамоделью)
      • Репозиторий архитектуры и Enterprise Continuum
      • Устранение ненужных отличий и еще много примеров и шаблонов

      Дополнительные рекомендации и методы включают:

      • Формальный бизнес-ориентированный подход к архитектуре
      • Планирование на основе бизнес-возможностей
      • Руководство по использованию TOGAF для разработки архитектур безопасности и SOA

      Последняя версия - TOGAF 9.2, запущенная 16 апреля 2018 года.

      Open Group бесплатно предоставляет TOGAF организациям для их собственных внутренних некоммерческих целей.

      Столбы TOGAF

      Домены архитектуры предприятия

      TOGAF основан на четырех взаимосвязанных областях специализации, называемых доменами архитектуры :

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

      Метод разработки архитектуры

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

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

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

      Континуум предприятия

      Enterprise Continuum - это способ классификации решений и архитектур по континууму, который варьируется от общих базовых архитектур до индивидуальных для конкретной организации как внутри, так и вне репозитория архитектуры. К ним относятся архитектурные модели, архитектурные шаблоны, описания архитектуры и другие артефакты. Эти артефакты могут существовать как на предприятии, так и в ИТ-индустрии в целом.

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

      TOGAF 9.2 распознает следующие роли;

      • Члены Совета по архитектуре
      • Спонсор архитектуры
      • Менеджер по архитектуре
      • Архитекторы:

      Также добавив "И многие другие . " в конце этого списка. Двумя такими ролями могут быть бизнес-аналитик и системный аналитик .

      TOGAF культура

      TOGAF предоставляет сертификаты для инструментов и людей.

      Инструменты, сертифицированные TOGAF

      Сертифицированные инструменты TOGAF 9 перечислены в следующей таблице.

      Самый последний реестр сертифицированных инструментов можно найти в реестре Open Group.

      Квалификация

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

      (Уровень I) Гарантирует, что человек понимает архитектуру предприятия, а также основные концепции и терминологию TOGAF.

      Проверенный

      (Уровень II) В дополнение к квалификации Foundation, это означает, что кандидат может анализировать и применять свои знания для решения бизнес-задач.

      Получение статуса TOGAF Certified автоматически означает бесплатное членство в Ассоциации архитекторов предприятий.

      Критика

      Несмотря на то, что TOGAF считается стандартом де-факто в практике EA , он не обходится без критики:

      Читайте также: