Корпоративная, системная и прикладная архитектура (передовой опыт?)
В настоящее время мне поручено создание документированного и согласованного руководства по архитектуре для разработки программного обеспечения. У нас много умных людей, которые делают правильные вещи, но только не последовательно и не повторяемо.
Мы используем Руководство по архитектуре приложений Microsoft 2.0 в качестве отправной точки. Следовательно, придумать архитектуру приложения довольно (я не скажу просто) прямо вперед. Возможно, потому что у меня есть опыт работы разработчиком в течение нескольких лет, поэтому я достаточно хорошо понимаю эту область, а также множество примеров и рекомендаций.
Поскольку в нашей организации есть пара приложений, которые формируют 1 или более систем, которые мы затем устанавливаем "на" клиентах... мы подумали, что было бы целесообразно также создать Системную архитектуру и Корпоративную архитектуру. И вот тут начинаются проблемы.
Там нет последовательного руководства там. Если вы ищете "Примеры архитектуры системы", то, что вы получите, настолько отличается, что мне интересно, есть ли "Стандартный" способ сделать это.
Из моего (ограниченного - ясно) понимания всего этого, архитектура системы - это абстракция 1 или более архитектур приложений, показывающих, как они работают вместе, чтобы сформировать систему. Кроме того, корпоративная архитектура - это еще одна абстракция, показывающая, как ваши системы вписываются в корпоративное предприятие и как оно взаимодействует с бизнес-процессами, ИТ-стратегией и как она интегрируется в другие системы на предприятии.
- Я совершенно не прав?
- Существуют ли какие-либо стандарты (и где я могу их найти)?
- Должны ли существовать стандарты или "хорошая" системная архитектура - это просто документ любого формата, понятный и легко понятный и полезный для читателей?
- Что бы закаленные архитекторы подумали об этом подходе?
Я не хочу просто перечислять набор шаблонов, связанных с SOA, которые могут быть полезны... Я хотел бы сделать его немного более сфокусированным на том, что мы делаем, - на построении финансовых решений на основе сервис-ориентированной архитектуры.
Обновление: как насчет TOGAF (9). Есть ли у кого-нибудь опыт с этим вообще, и стоит ли пытаться понять это в деталях.
4 ответа
Я представил вопрос пару дней назад, но, продолжая исследования и после прочтения ответа Littlegeek, я нашел интересную белую книгу, которая показалась мне очень информативной и интересной.
Читайте: Сравнение четырех лучших методологий корпоративной архитектуры Автор: Roger Sessions
фрагмент...
- - - - - - - - - - - 8<- - - - - - - - - - - -
Многие корпоративно-архитектурные методологии пришли и ушли за последние 20 лет. На данный момент, возможно, 90 процентов месторождений используют одну из следующих четырех методологий:
- Платформа Zachman для корпоративных архитектур - хотя сама описывается как структура, на самом деле более точно определяется как таксономия
- Архитектурный каркас Open Group (TOGAF) - хотя он и называется каркасом, на самом деле более точно определяется как процесс
- Федеральная корпоративная архитектура - может рассматриваться как реализованная корпоративная архитектура или методология для создания корпоративной архитектуры.
- Методология Gartner - лучше всего описать как корпоративную архитектурную практику
В этом техническом документе рассматриваются эти четыре подхода к архитектуре предприятия. Это происходит в контексте вымышленной компании, которая сталкивается с некоторыми весьма неэффективными операционными проблемами. Эти проблемы включают в себя:
- ИТ-системы, которые стали неуправляемо сложными и все более дорогостоящими в обслуживании.
- ИТ-системы, которые препятствуют способности организации своевременно и экономически эффективно реагировать на текущие и будущие рыночные условия.
- Критически важная информация, которая постоянно устаревает и / или просто неверна.
- Культура недоверия между деловыми и технологическими сторонами организации.
- - - - - - - - - - - 8<- - - - - - - - - - - -
Белая книга помогла мне несколькими способами.
- Это дало мне хорошее представление и историю архитектуры (особенно архитектуры предприятия)
- Он познакомил меня с тем, что автор предлагает 4 ведущих корпоративных архитектуры.
- А затем продолжает сравнивать их в логической и простой форме с хорошими примерами, к которым я мог бы привести.
Я не могу сказать, что на все мои вопросы были даны ответы, и теперь я готов умереть:-), но многое стало яснее, и поэтому я подумал, что кто-то еще может найти это полезным.
Я по-прежнему буду благодарен за любые дополнительные комментарии, предложения и вопросы, которые могут у вас возникнуть по этому вопросу.
Похоже, вы действительно хорошо понимаете ситуацию и понимаете сферу искусства архитектуры.
"Системную" архитектуру определить немного сложнее - может быть, вы ищете "решение" или "ИТ", но похоже, что вы ищете, как ваша программная архитектура соотносится с физическим серверным миром, с небольшой сетью
"У нас много умных людей, которые делают правильные вещи, но только не последовательно и не повторяемо".
Затем, будучи сертифицированным TOGAF 8, я бы сказал, что TOGAF привносит чувство "методологии" в различные аспекты определения архитектуры и в способ объединения технических групп специалистов по различным видам и закрепления их в целях бизнеса. TOGAF также помогает понять необходимость управления архитектурой и твердо внедряет в процесс идею изменений (со всех сторон - технических, данных, систем, программного обеспечения и бизнеса).
- Метод развития архитектуры
- Техническая эталонная модель
- Информационная база стандартов
- Предприятие Континуум
Все они помогают собирать информацию об усилиях Archtecture и обеспечивают последовательный подход к разработке и EA.
Это также помогает клиентам понять, что вы делаете, и как вы можете представить TOAGF как способ показать, как он сочетается.
PS - Я только заявляю, что TOGAF является полезным, сделайте цитату, которую я вытащил, поскольку TOAGF решит эту проблему для вас.
Есть и другие архитектурные работы.
У меня нет практического опыта в EA, но я на самом деле с ним. Среди 4 лучших методологий EA я встречал первые три. Я просто не знаю Gartner, возможно, из-за недоступности его документов. ИМХО, когда мы говорим об EA, мы на самом деле говорим о согласовании бизнеса с технологиями. Таким образом, все методологии EA должны быть ориентированы на бизнес. Если нет, то это вовсе не EA.
Я думаю, что TOGAF довольно полезен и понятен. Да, это процесс, который развивает текущую базовую архитектуру в целевую архитектуру. Принципы архитектуры выступают в качестве руководства высокого уровня развития EA. Основными компонентами TOGAF являются бизнес-архитектура, информационная архитектура и технологическая архитектура. И у каждого из них могут быть свои шаблоны архитектуры. NIH внедрила советника с FEAF. Это хороший пример для реализации советника. Я думаю, что это очень похоже на подход TOGAF, по крайней мере, с точки зрения результатов.
До сих пор единственной разумной попыткой создать среду моделирования для EA была Archimate: https://en.wikipedia.org/wiki/ArchiMate
ArchiMate - это технический стандарт от The Open Group, основанный на концепциях стандарта IEEE 1471.
Также смотрите следующую ссылку об артефактах EA и прослеживаемости между ними: