Comments 11
Сами потребители не знают что хотят, пробуют выразить свое желание через фразу «Нарисуй мне архитектуру». На вопрос «Какую именно?», могут растерянно ответить «Техническую» или «Логическую», а вот попытка выяснить какую технику или логику там хотят увидеть, а главное зачем, уже вызывает заметные сложности.
Разве это правильная постановка вопроса?
На мой взгляд, это не «потребитель» должен приходить к «архитектору» и что-то там просить, а архитектор должен определять концепцию создания ПО и затем уже раздавать «ценные указания» тимлидам, техлидам либо «обычным» программистам. Если, конечно, вы имеете в виду архитектуру программного обеспечения.
По-хорошему, вместо общих слов, лучше просто дать пример «правильной» архитектуры для разработки хотя бы небольшой программы.
На примере собственной обучающей программы, реализованной, с большим трудом, в первой версии, при определении ее архитектуры для второй версии, я бы предложил следующее:
Архитектор создает прототип проекта, в котором разрабатываемые модули (по сути,, классы) имеют чисто формальные реализации., т.е., набор публичных функций с пустым телом. При этом, вызовы этих публичных функций в главном модуле приложения (для проектов на C++ / WTL это будет CMainFrame), за разработку которого отвечает архитектор, должны быть зафиксированы явно (скажем, в обработчиках сообщений либо в функциях потоков).
Этот проект, с «пустыми» модулями (классами) компилируется, но, по сути, ничего, особо не делает. Только отображение главного окна, его полного меню, но без реальной работы (разве что, просто вывод мессаджбокса с указанием выбранного пункта меню), тулбара и статусбара.
Этот прототип проекта раздается всем членам команды, с указанием, кому, какой модуль (класс) развивать, т.е., заменять пустые тела функций их реальным содержимым. При необходимости, программисты-исполнители могут добавлять приватные функции и данные, на свое собственное усмотрение.
При завершении работы над модулем, программист отправляет архитектору (это может быть и удаленная работа) свою полную реализацию класса, за который он ответственен.
Архитектор, делает замену формального модуля на реальный и осуществляет общее тестирование. При необходимости, вносит изменения в работу команды.
Принятый, в первом приближении, реальный модуль может стать доступным для всех членов команды и тестировщиков.
Если реальный модуль обновляется, то его новая версия замещает старую, путем простой замены файлов.
Задача архитектора состоит в том, чтобы эта схема, либо аналогичная, принятая всеми членами команды, работала.
Как-то так.
Когда я создам, по этому принципу, вторую версию своей обучающей программы, то, вероятно, напишу статью на эту тему.
Базовая задача архитектуры: кратко, но ёмко показать, как ИТ-продукт устроен сейчас и что надо изменить, чтобы разработать требуемые хотелки.
Архитектура - не про то, как сейчас устроен продукт. Это всегда про конечный результат. Даже идеализированный финальный продукт. Своего рода полярная звезда.
Так как архитектура начинается до разработки, курс неизбежно будет корректироваться, и нужно будет постоянно сверяться: так ли мы идём и движемся ли в нужном направлении.
Если в статье слова Архитектура \ ИТ-архитектура (EA и т.п.) заменить на BPM (классический BPM типа ARIS), а "архитектор" на "процессник" (по тексту UML, C4 model или Archimate заменить на EPC, BPMN, VAD), то можно заменить заголовок статьи на "Проблемы BPM" - оставляя текст в целом исходным. Это к тому, что проблемы BPM и EA схожие. Интересно, какие еще ИТ-области, можно включать в ряд BPM \ EA - для которых такие же - как указанные в статье проблемы?
Проблема оторванности миров "нарисованного" и "исполняемого" - медленно, но пыталась решаться, например, Архитектура как код в EA или BPMN-engine \ process mining в BPM. Только все идет к тому, что все роли, включая архитектора \ процессника и разработчика \ тестировщика, будет выполнять ИИ (разные ИИ-агенты, но в единой команде \ связке), а "он уж там сам как-нибудь разберется".
Звучит неплохо, остается только дождаться момента, когда потребители (customers) будут транслировать свои потребности (demands) напрямую ИИ. Это если возвести в абсолют тренд на избавление от промежуточных людей между AS IS и TO BE.
Звучит неплохо, остается только дождаться момента, когда потребители (customers) будут транслировать свои потребности (demands) напрямую ИИ.
Это показал тут.
Мысли в слух: если упороться и отрисовать бизнес в Archimate нотации, речь про слои Strategy и Motivation, то как тогда ИИ справится с проектированием бизнес-процессов и остальных низ лежащих слоев.
Кажется это годная идея для Pet-проекта
Моя мысль скорее к тезису:
Архитектура – это не абстрактные квадратики и стрелочки, она нужна для закрытия потребности понимания ИТ-системы или их набора (или даже целого ИТ-ландшафта)
как «as is» vs «as-really-is», т.е. противопоставление нарисованного реальному. Подробнее.
Архитектура системы - это всего лишь смачный термин для моделей, дающих более или менее смутное представление о составе элементов системы и распределении обязанностей между ними в попытках целенаправленных взаимодействий для достижения полезных результатов в контексте требуемых заинтересованными лицами вариантов использования моделируемой системы.
Любая модель сугубо субъективна, приблизительна и полезна лишь временно и в том случае, когда она помогает понять то, что было не понятно. И основными артефактами любой модели является не ее физическое представление в той или иной форме на том или ином носителе, а то, что сложилось в головах у людей, заинтересованных в понимании тех или иных аспектов системы. После этого модельная документация, как правило, уже не интересна и не нужна. Ну а зачем она, если и так всё уже понятно. В этом обычно кроется вполне естественная причина обесценивающего отношения к докам.
Разумная архитектура, как правило, соответствует устоявшимся общеизвестным паттернам, и для ее описания достаточно назвать эти паттерны своими именами. Если же выявляются нестандартные аспекты, то, как правило, это происходит в силу недостаточных знаний или опыта самих моделлеров. В очень редких случаях приходится что-то изобретать, да и тут целесообразно выявлять и обобщать полезные паттерны, чтобы повторно их использовать.
Так что фанатичное документирование архитектуры, как и любой другой модели системы - не является самоцелью, и отсутствие или устаревание этих доков - не проблема и не боль, если люди поняли, что и как, договорились, и могут дальше согласованно взаимодействовать.
Хорошее понимание системы через ее разумную модель позволяет людям легко вносить необходимые изменения по ходу реализации, не заморачиваясь догматическими позывами документировать уже вполне всем очевидные вещи. И это нормально, это здоровый подход к уменьшению информационной энтропии в команде.
А для ии ревью устаревшие доки - как красная тряпка - лучше уж только голимый код, иначе иишки будут орать, что код не соответствует докам.
Проблемы ИТ-архитектуры