Корпоративная, системная и прикладная архитектура (передовой опыт?)

Question

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

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

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

Там нет последовательного руководства там. Если вы ищете «Примеры архитектуры системы», то, что вы получите, настолько отличается, что мне интересно, есть ли «Стандартный» способ сделать это.

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

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

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

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

Answer 1

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

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

фрагмент ...

- - - - - - - - - - - 8 <- - - - - - - - - - - - </p>

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

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

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

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

- - - - - - - - - - - 8 <- - - - - - - - - - - * </p>

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

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

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

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

Answer 2

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

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

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

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

1. Способ разработки архитектуры
2. Техническая справочная модель
3. Информационная база стандартов
4. Предприятие Континуум

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

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

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

Есть и другие архитектурные работы.

Answer 3

До сих пор единственной разумной попыткой создать среду моделирования для 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

Answer 4

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

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