Виды архитектур в процессе разработки ПО

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

Но основная интрига заключается в том, что все эти архитектуры ложилась в стройный life cycle:

  1. Business Architecture. В первую очередь, предже чем мы что-то разрабатываем, мы задумываемся над тем, «а что же надо получить», «какие проблемы должны быть решены», «что же нужно автоматизировать». Ответы на эти вопросы можно получить в процессе составления Business Architecture. В этот момент практически не играет роли, какие технологии будут использоваться. Самое важное — очертить круг логик, которые нужно автоматизировать
  2. Information Architecture. После того, как мы определили границы нужных нам логик (границы системы) в процессе составления Business Architecture, мы выделяем сущности, их структуру и взаимосвязи.
  3. Technology Architecture. На основе установленных бизнес логик, правил и требований из Business Architecture, принимаются решения: посредством каких технологий и технологических процессов можно обеспечить автоматизацию нужных бизнес процессов.
  4. Solution Architecture (оно же System, оно же Application). Непосредственно реализация смеси всех вышеописанных абстракций. На данной ступени можно выделить составляющие: a) Data Architecture — описывает реализацию структур данных и их логические связи, b) Software Architecture — описывает программные компоненты и связи между ними.

Например, схема базы данных или объектная модель — относятся к Data Architecture. А тонкости реализации паттерна MVC в конкретном проекте — можно отнести к Software Architecture.

Если посмотреть на все эти Architectures, то можно заметить, что каждая последующая Architecture — это реализация предыдущей Architecture на следующем более низком уровне абстракции.

Что ещё интересно — так это явное разделение зон ответственности за виды архитектур между Системным Аналитиком и Системным Архитектором. Аналитик собирает информацию (Business Architecture) и систематизирует её (Information Architecture). Архитектор, используя работу Аналитика, решает, какие технологии он готов применить (Technology Architecture) и как именно в рамках этих технологий будут реализованы те или иные логики (Solution Architecture).

И в довершение, если вы хотите окончательно сломать мозг — вам сюда.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

en.m.wikipedia.org/..._Maturity_Model
Выбираете Ваш уровень. Если 1: делаете все что описали, если 2: убираете первый пункт и тд.
Даже Там не видят смысла в ежедневном изобретении велосипедов.
А то что книжки читаете — это очень хорошо!

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

Понятно. Первое. Называть `статьей` эталонную модель организации разработки програмного обеспечения Министерства Обороны США, разработанной Институтом Програмной Инженерии Университета Корнеги-Меллона, по моему, несколько... ммм.. неловко... Во вторых. `Путь аналитика` , без сомненья, очень круто.. но... вам, как мне видется, не приводилось в своей работе заниматься управлением проектами. Самая популярная на сегодняшний день модель разработки называется `как получится`... а назвать ее можно как угодно: Scram, Kanban, и да , различать их очень важно:-) Последняя фраза — несомненно ` Да`. Будте любезны на практике продемонстрируйте:-) Например создание ресурса... типа Facebook.

Кажется, меня решил потроллить «настоящий практик с богатым опытом управления проектами». Что касается «эталонной модели организации бла-бла-бла», на которую вы тут «ссылаетесь», то лично я с ней не знакома. А материал, представленный в этой заметке — отражает мои представления о связи архитектур между собой. На каком основании я делаю такие выводы? Ну, во-первых, я изучила достаточно много теории на эту тему, а во-вторых, я опираюсь на собственный опыт. Если вам есть что сказать по делу — жду ответную разгромную статью вашего авторства.

Ты, что Вы читаете, надо применять на практике. Я Вам задал не сложный вопрос, а Вы, милочка, так сказать, стрелки перевели. То что Вы описали в своих выводах видится так: я разобралась в высшей математике! Думаю " дважды два равно четыре".

Конечно нужно применять на практике, но как вы себе представляете это применение на практике тут на ресурсе? Код проекта выложить или что? И кроме того, чтобы применять на практике — для начала нужно разобраться в том, что применять будете, собственно для этого теория и существует — чтобы её изучать и разбираться, а не «я такой умный, всё и так умею». Если вы не считаете нужным читать теорию, а уж тем более делать свои выводы о том, что прочитали — это не значит, что все должны поступать так же. И по поводу «несложного вопроса» — где он прозвучал? В ваших комментариях нет ни одного вопросительного предложения.

а почему это должно ломать мозг?

Был бы мозг, а сломать это тривиальная задача. :)

Больше похоже на схемы распределения полномочий в рамках большого проекта.

docs.google.com/...sp=docslist_api

ни разу не видел чтобы архитектура была разработанна с 0 с помощью солюшин архитектов, технолоджи или вообще других архитектов. Как правило берут какуюто работающую систему и просто улучшают какие то функции путем применения более быстрых более гибких технологий. Правда вспомнил — видел одну софтину для внутреннего трекинга проектов. Например проект внедрения нового оффиса в новом регионе должен пройти через дирекцию маркетинга (что бы новый регион был включен в рекламу) , через техническую дирекцию (чтобы там был интернет и телефон) через дирекцию развития ( чтобы включили новый регион в бюджет на следующий год) и т.д. Ранее это все решалось рассылкой писем от проджект менеджера в разные дирекции и потом он получал из каждой дирекции подтверждения что типа дирекция подтверждает принятие нового региона и все будет ок. Так как писем было дофига и к ним были приложены разные атачменты и позже письма обрастали ответами и причинами задержек или дополнительными требованиями то было решено накатать электронную систему проектного документооборота, были приглашена IBM и Тата как консультанты и в конце концов индусы получили этот проект. Они походили и побеседовали со всем отделами и выкатили полный аналог аутлука только вместо писем в ящик падает типовая форма с обязательными полями. В форме есть 5-8 вкладок (по количеству департаментов которые согласовывают проект) и на каждой вкладке будет высвеченна только твоя часть проекта — там можна посмотреть часть документации касающуюся тебя, можна зааплоадить что то (например план айпи сети) , туда же можна написать комментарии почему отказываешься апрувить проект и наконец там же можна заапрувить свою часть. Тоесть, все эти солюшены и прочая лабуда — это красивая теория, в реальности берется старый аналогичный проект какой то и дополняется новыми требованиями и пускается в продакшн по ходу корректируюясь новыми требованиями заказчика.

Это вам просто не везло с проектами.

И как это всё запомнить? 8-O

Практиковаться, или пару лет поработать в банке, все равно кем:-)

Підписатись на коментарі