Архитектура предприятия, систем и приложений (лучшая практика?)
https://stackoverflow.com/questions/755540
-
09-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
В настоящее время мне поручено создать документированное и последовательное руководство по архитектуре для разработки программного обеспечения.У нас много умных людей, которые делают правильные вещи, но не последовательно и не повторяемо.
В качестве отправной точки мы используем Руководство по архитектуре приложений Microsoft 2.0.Следовательно, придумать архитектуру приложения довольно (я не скажу, что это легко) просто.Возможно, потому, что у меня есть пару лет опыта работы в качестве разработчика, поэтому я довольно хорошо разбираюсь в этой области, а также есть множество примеров и рекомендаций.
Поскольку в нашей организации есть пара приложений, образующих 1 или несколько систем, которые мы затем устанавливаем «у» клиентов...мы подумали, что имеет смысл создать также системную архитектуру и архитектуру предприятия.И здесь начинаются проблемы.
Там нет последовательного руководства.Если вы ищете «Примеры системной архитектуры», то результат, который вы получите, настолько отличается, что мне интересно, существует ли «стандартный» способ сделать это.
Насколько я понимаю (ограниченно) всего этого, системная архитектура представляет собой абстракцию одной или нескольких архитектур приложений, показывающую, как они работают вместе, образуя систему.Кроме того, архитектура предприятия — это дополнительная абстракция, показывающая, как ваши системы вписываются в предприятие организации и как они взаимодействуют с бизнес-процессами, ИТ-стратегией и как они интегрируются в другие системы предприятия.
- Я что-то совершенно не так понимаю?
- Существуют ли какие-либо стандарты (и где их можно найти)?
- Должны ли существовать стандарты, или «хорошая» системная архитектура будет просто документом в любом формате, который ясно и легко понятен и полезен для читателей?
- Но что подумают об этом подходе опытные архитекторы?
Я не хочу просто перечислять набор шаблонов, связанных с SOA, которые могут быть полезны...Я хотел бы немного больше сосредоточиться на том, что мы делаем, а именно на создании финансовых решений на основе сервис-ориентированной архитектуры.
Обновлять:Как насчет ТОГАФ(9).Есть ли у кого-нибудь вообще опыт работы с этим и стоит ли пытаться понять это подробно.
Решение
Я задал вопрос пару дней назад, но, продолжая исследования и прочитав маленький компьютерщикВ ответ я думаю, что нашел интересный технический документ, который показался мне очень информативным и интересным.
Читать: Сравнение четырех лучших методологий построения архитектуры предприятияК:Роджер Сешнс
фрагмент...
-- - - - - - - - - - - 8< - - - - - - - - - - - -
За последние 20 лет появилось и исчезло множество методологий корпоративной архитектуры.На данный момент, возможно, 90 процентов специалистов используют одну из этих четырех методологий:
- Структура Захмана для корпоративных архитектур. Хотя она и называется структурой, на самом деле ее точнее определить как таксономию.
- Архитектурная структура открытой группы (TOGAF). Хотя она и называется структурой, на самом деле ее точнее определить как процесс.
- Архитектура федерального предприятия. Ее можно рассматривать либо как реализованную архитектуру предприятия, либо как предписывающую методологию создания архитектуры предприятия.
- Методологию Gartner лучше всего можно охарактеризовать как практику архитектуры предприятия.
В этом техническом документе обсуждаются эти четыре подхода к архитектуре предприятия.Это делается в контексте вымышленной компании, которая сталкивается с весьма невымышленными операционными проблемами.Эти проблемы включают в себя:
- ИТ-системы, которые стали неуправляемо сложными и все более дорогостоящими в обслуживании.
- ИТ-системы, которые мешают организации своевременно и с минимальными затратами реагировать на текущие и будущие рыночные условия.
- Критически важная информация, которая постоянно устаревает и/или просто неверна.
- Культура недоверия между деловой и технологической сторонами организации.
-- - - - - - - - - - - 8< - - - - - - - - - - - -
«Белая книга» помогла мне во многих отношениях.
- Это дало мне хорошее представление и историю архитектуры (в частности, архитектуры предприятия).
- Он познакомил меня с тем, что, по мнению автора, является четырьмя ведущими доступными архитектурами предприятия.
- А затем продолжает логично и просто сравнивать их с хорошими примерами, которые мне могут быть близки.
Я не могу сказать, что на все мои вопросы были даны ответы и теперь я готов умереть :-), но многое стало яснее, и поэтому я подумал, что кто-то еще может найти это полезным.
Я по-прежнему буду рад любым дополнительным комментариям, предложениям и вопросам, которые могут у вас возникнуть по этой теме.
Другие советы
Кажется, вы действительно хорошо разбираетесь в ситуации и понимаете сферу архитектуры.
«Системную» архитектуру определить немного сложнее — можно искать «решение» или «ИТ», но это похоже на то, что вы ищете, как архитектура вашего программного обеспечения связана с миром физических серверов, с добавлением небольшого количества сетевых ресурсов.
«У нас много умных людей, которые делают правильные вещи, но не последовательно и не повторяемо».
Затем, будучи сертифицированным TOGAF 8, я бы сказал, что TOGAF привносит чувство «методологии» в различные аспекты определения архитектуры и способ объединить различные технические группы специалистов и прочно связать их с бизнес-целями.TOGAF также помогает понять необходимость управления архитектурой и твердо привносит в процесс идею изменений (со всех частей: технических, данных, систем, программного обеспечения и бизнеса).
А
- Метод разработки архитектуры
- Техническая эталонная модель
- Информационная база стандартов
- Корпоративный континуум
Все они помогают собирать информацию о работе над архитектурой и обеспечивают последовательный подход к разработке и EA.
Это также помогает клиентам понять, что вы делаете и как вы можете представить TOAGF как метод, демонстрирующий, как он сочетается друг с другом.
PS. Я говорю только о том, что TOGAF полезен. Приведите цитату, которую я привел, поскольку TOAGF расскажет вам об этом.
Существуют и другие архитектурные фреймворки.
У меня нет практического опыта работы с EA, но я действительно с этим согласен.Среди четырех лучших методологий советников я встретил первые три.Я просто не знаю Gartner, возможно, из-за отсутствия ее документов.ИМХО, когда мы говорим об EA, мы на самом деле говорим о согласовании бизнеса с технологиями.Таким образом, все методологии ЭО должны быть ориентированы на бизнес.Если нет, то это вообще не EA.
Я считаю, что TOGAF весьма полезен и понятен.Да, это процесс, который превращает текущую базовую архитектуру в целевую архитектуру.Принципы архитектуры действуют как руководство высокого уровня при разработке EA.Основными компонентами TOGAF являются бизнес-архитектура, информационная архитектура и технологическая архитектура.И каждый из них может иметь свои собственные закономерности архитектуры. Национальные институты здравоохранения США реализовал советник с FEAF.Это хороший пример реализации EA.Я думаю, что это очень похоже на подход TOGAF, по крайней мере, с точки зрения результатов.
Единственной разумной попыткой создать среду моделирования для EA был Archimate: https://en.wikipedia.org/wiki/ArchiMate
ArchiMate — это технический стандарт The Open Group, основанный на концепциях стандарта IEEE 1471.
Также см. следующую ссылку об артефактах EA и отслеживаемости между ними:
