Архитектура предприятия, систем и приложений (лучшая практика?)

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

В качестве отправной точки мы используем Руководство по архитектуре приложений Microsoft 2.0. Следовательно, придумать архитектуру приложения достаточно (я не скажу легко) прямо. Возможно, потому, что у меня есть опыт работы в течение нескольких лет в качестве разработчика, поэтому у меня есть довольно хорошее понимание этого мира, а также множество примеров и рекомендаций.

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

Нет никаких последовательных указаний. Если вы ищете "Примеры системной архитектуры", материал, который вы получаете, настолько отличается, что мне интересно, существует ли "стандартный" способ сделать это.

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

  • Есть ли у меня это полностью неправильно?
  • Существуют ли какие-либо стандарты (и где их можно найти)?
  • Должны ли существовать стандарты или "хорошая" архитектура системы - это любой документ в любом формате, который четко и легко понятен и полезен для его читателей?
  • Что бы подумали опытные архитекторы об этом подходе?

Я не хочу просто перечислять набор связанных с SOA шаблонов, которые могут быть полезны... Я хотел бы сделать это немного более сфокусированным на том, что мы делаем, что является финансовыми решениями сборки на службе Orientated Архитектура.

Обновление: как насчет TOGAF (9). У кого-нибудь есть опыт с ним вообще, и стоит ли пытаться понять его подробно.

Ответы

Ответ 1

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

Читайте: Сравнение четырех лучших методологий архитектуры предприятия Автор: Roger Sessions

фрагмент...

- - - - - - - - - - - 8 < - - - - - - - - - - - -

Многие корпоративные архитектурные методологии появились и ушли за последние 20 лет. На данный момент, возможно, 90 процентов поля используют одну из этих четырех методологий:

  • Zachman Framework для корпоративных архитектур - хотя самоописана как структура, на самом деле более точно определена как систематика
  • Архитектура Open Group (TOGAF) - хотя и называется каркасом, на самом деле более точно определяется как процесс
  • Федеральная архитектура предприятия - может рассматриваться как внедренная корпоративная архитектура или прокси-методология для создания корпоративной архитектуры.
  • Методология Gartner - лучше всего описать как корпоративную архитектурную практику.

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

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

- - - - - - - - - - - 8 < - - - - - - - - - - - -

Белая книга помогла мне несколькими способами.

  • Это дало мне хорошее введение и историю архитектуры (Enterprise Architecture).
  • Это познакомило меня с тем, что, по мнению автора, является 4-мя ведущими корпоративными архитектурами.
  • И затем продолжает сравнивать их логичным и простым способом с хорошими примерами, к которым я мог бы относиться.

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

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

Ответ 2

У вас, кажется, действительно хорошее понимание ситуации и понимания области архитектуры.

"Системы" Architecure немного сложнее определить - может быть поиск "решения" или "ИТ", но похоже, что вы ищете, как ваша архитектура программного обеспечения относится к физическому серверному миру, с небольшим количеством сетей,

"У нас много умных людей, которые делают правильные вещи, но просто не последовательно и повторяемо".

Тогда, будучи сертифицированным TOGAF 8, я бы сказал, что TOGAF привносит чувство "методологии" в различные аспекты определения архитектуры и способ объединить различные технические группы специалистов и точно привязать их к бизнес-целям. TOGAF также помогает понять необходимость управления архитектурой и прочно вносит в процесс идею изменения (со всех частей технических, данных, систем, программного обеспечения и бизнеса).

  • Метод разработки архитектуры
  • Техническая справочная модель.
  • Информационная база стандартов
  • Предприятие Continuum

Вся помощь в сборе информации об усилиях Archtecture и обеспечении последовательного подхода к разработке и EA.

Это также помогает клиентам понять, что вы делаете, и как вы можете представить TOAGF как метод показа, как он сочетается.

PS - Я только утверждаю, что TOGAF полезен для цитаты, которую я вытащил, поскольку TOAGF обратится к этому для вас.

Там есть другие архивные рамки архитектора.

Ответ 3

У меня нет практического опыта работы с EA, но я на самом деле на нем. Среди четырех лучших методологий EA я столкнулся с первыми тремя. Я просто не знаю Gartner, возможно, из-за недоступности его документов. ИМХО, когда мы говорим об EA, мы на самом деле говорим о согласовании бизнеса с технологиями. Поэтому все методологии EA должны быть ориентированы на бизнес. Если нет, это не EA вообще.

Я думаю, что TOGAF весьма полезен и понятен. Да, это процесс, который превращает текущую базовую архитектуру в целевую архитектуру. Архитектурные принципы выступают в качестве руководства высокого уровня развития EA. Основными компонентами TOGAF являются бизнес-архитектура, информационная архитектура и технологическая архитектура. И каждый из них может иметь свои собственные шаблоны архитектуры. NIH внедрил EA с FEAF. Это хороший пример для внедрения EA. Я думаю, что это очень похоже на подход TOGAF, по крайней мере, с точки зрения результатов.

Ответ 4

До сих пор единственной разумной попыткой создать среду моделирования для EA была Archimate: https://en.wikipedia.org/wiki/ArchiMate

ArchiMate - это технический стандарт от The Open Group, основанный на концепциях стандарта IEEE 1471.

Также см. Следующую ссылку об артефактах EA и прослеживаемости между ними:

https://www.ontario.ca/document/go-its-56-ops-enterprise-architecture-principles-and-artefacts-appendix-ontario-public-service