Комментарии 12
Подход TOGAF, на сегодня - наиболее распространенный подход к реализации и поддержанию архитектуры или архитектур решений в компаниях. Он включает в себя наиболее важные вехи, которые необходимо учитывать при работе над информационными продуктами. Он не требует сильной адаптации. Этап может быть сколь угодно мал, но он обязан быть. Иначе бардак, хаос, размытие ответственности.
Вроде всё правильно, но в последнее время всё больше и больше убеждаюсь, что чем громче кто-то меня пугает хаосом и предлагает против какие-то решения или методологии как например SAFe или SCRUM, то понимаю, что хаоса будет в два раза больше. А затрат раз в пять больше. Но - это моё личное мнение.
Сравниваю программистов одиночек, которые создают успешные и красивые Apps (чаще games or frameworks) с корпоротивными программами и понимаю, что разница как между небом и землёй. В пользу одиночек. А почему? Потому что у них есть возможность, но самое главное желание - вначале продумать, потом только начинать. В корпоративах всегда начинают, в надежде когда-нибудь найти время для обдумывания, но так никогда его и не найдя. И хаос, который они должны были вроде обуздать (потому что ведь у них правильная методология) - переполнил все борта.
Об отсутствии какой-либо ответственности я вообще молчу. Сложные проекты расчитаны на мин.3-5 лет (например миграция soft- или it-инфраструктуры в Cloud). Среднее время между переходами манагеров среднего звена 2-3 года. И какую понесёт отвественность архитектор-манагер, если через какое-то время огрехи в архитектуре начнуть всё больше и больше о себе знать, когда этого манагера уже нет поблизости?
Диаграмму деятельности со спокойной совестью можно поменять на BPMN
Я сам обожаю BPMN, но убеждаюсь, что в большинстве своём - если что и пишется с помощью BPMN, то только в архив. Почти никто с этими диаграммами не работает, а делают их или просто из спортивного интереса, тк. кто-то для себя это открывает в первый раз или для лицензирования ISO 9000 или ISO 9001. И каждый раз, как только приходят аудиторы, то достаются из ящиков диаграммы, которые с реальностью ну вообще ничего не имеют общего уже много лет. Но выглядят они убедительно.
А всё почему? Да потому что один из тезисов агильного манифеста гласит - работающая система стоит выше чем документация о системе.
Те. с Вашими словами я соглащаюсь, но в реальности вижу совсем не то. Надо реальность наверное поменять :)
Потому что у них есть возможность, но самое главное желание - вначале продумать, потом только начинать
Спасибо за мнение и опыт. У Вас в общем-то нет вопроса, но мне кажется логичным немного ответить Вам не вступая в полемику, а продемонстрировать другую сторону медали.
Мне кажется не совсем уместным сравнивать программистов одиночек и компаний. Там где есть возможность делать в одиночку не образуется компаний. Там есть конкретный труд. Когда этот "труд" перерастает во что-то большее/великое/хорошее нужна система, чтобы целенаправленно развивать этот самый "труд". Вот тут и встает дилемма о том, как организовать целенаправленное развитие. Одиночка всегда более эффективен, чем среднестатистическая единица в группе, потому что группа 40% своих затрат тратит на синхронизацию.
Но для того, чтобы было над чем думать у каждого должен быть опыт. Тут есть 2 цикла, которые заточены под работу над опытом
Цикл PDCA (ссылка) - когда мы говорим про работу над информацией
Цикл Колба (ссылка)- когда мы говорим про работу над развитием навыка
Эти циклы противопоставляются друг другу, но это в корне не верно. Один дополняет другой.
Вы говорите о том, что программист более эффективен за счет того, что у него есть возможность подумать. С этим я согласен. Но я делаю шаг в сторону и думаю о том, что надо программисту, чтобы он смог "эффективно" подумать. Ему нужен опыт, который научил его быть эффективным. Это как раз Цикл Колба.
С организациями все точно так же. Есть куча работы, которую нужно делать. Нужно потому, что нет возможности делать только крутые продукты. Нужно реагировать на требования государства, нужно реагировать на изменения законодательства, нужно людям зарплату считать и т.д.
Как эту всю махину организовать? Вот есть такое субъективное мнение, что так можно. На практике подтверждено, что есть компании и которых так получается эффективно. Да, их немного, но они есть. Мне кажется этого достаточно, чтобы последовать их примеру и по пути постоянных и небольших изменений из чего-то хорошего сделать что-то более хорошее )
Я сам обожаю BPMN, но убеждаюсь, что в большинстве своём - если что и пишется с помощью BPMN, то только в архив. Почти никто с этими диаграммами не работает
У меня полностью противоположное мнение. Когда я отрисовывал процесс в BPMN при проектировании доработки системы, руководству и заказчику это очень нравилось.
Максимум, что меня просили ещё сделать - легенду для облегчения понимая неоднозначных элементов.
UPD для понимания контекста: я системный аналитик и писал и согласовывал с заказчиком ТЗ
У меня тоже есть аналогичный опыт использования BPMN и он показывает свою оправданность, когда для него созрела целевая аудитория.
легенду для облегчения понимая неоднозначных элементов
На это есть отдельный аналитический артефакт (ссылка). Может будет полезно.
Архитектурные концепты при создании информационных продуктов включают в себя понимание структуры и организации информации в продукте, а также способа ее представления и взаимодействия с пользователем.
Для понимания архитектурных концептов при создании информационных продуктов следует учитывать следующие факторы:
1. Целевая аудитория: необходимо определить, для кого будет создан продукт, какие потребности и ожидания у пользователей, какие задачи он должен решать.
2. Структура информации: необходимо определить, как будет организована информация в продукте, какие разделы и подразделы будут созданы, какая будет иерархия информации.
3. Навигация: необходимо определить, как пользователь будет перемещаться по продукту, какие элементы навигации будут использоваться (меню, кнопки, ссылки и т.д.).
4. Визуальное оформление: необходимо определить, как будет оформлена информация в продукте, какие элементы дизайна будут использоваться (цвета, шрифты, изображения и т.д.). 5. Функциональность: необходимо определить, какие функции будут реализованы в продукте, какие возможности будут предоставлены пользователю.
6. Взаимодействие с пользователем: необходимо определить, как будет организовано взаимодействие с пользователем, какие элементы интерфейса будут использоваться (формы, поля ввода, кнопки и т.д.).
В целом, понимание архитектурных концептов при создании информационных продуктов позволяет создать продукт, который будет удобен и понятен для пользователей, а также будет эффективно решать поставленные задачи.
Перечитал вновь и появился доп. вопрос к теме
Кто нужен для реализации намеченных возможностей?
Попытаюсь вначале дать сравнение. Представьте цель - участие в олимпиаде. И под вопросом, кто поедет туда участвовать даётся ответ - спортсмен, хорошо подготовленный, занимающий в секциях, соблюдающий режим еды итд.. Вроде-бы всё правильно, но как-бы это всё - второстепенно. Самое важное, что спортсмен или систем-архитектор - умеет делать то, для чего он нужен - так, чтобы добиться результата. Будет-ли при тренировки красивый стадион или SAFe - думаю важно, но не настолько как первое.
А в статье первое берётся как данность и разговор идёт о втором. В жизни много раз наяву видел реализацию басни Крылова с животными и музыкальными инструментами. Так и с проектами - концентрация шла на методологию, а потом выяснилось, что наархитектовали так, что после 3-5 лет проекта его заменили на новый проект. И самое печальное - те-же самые архитекторы уже под другой методологией 'создавали' следующие шедевры.
Я понимаю, что в рамках такой статьи поднять этот вопрос нелегко. Мне хотелось просто об этом напомнить.
Спасибо. Крутая аналогия.
Полностью согласен с тем, что важна - ядро, мотивация, желание. Это основа. Желание доводит начатое до конца. Мне кажется этому ни один фреймворк и подход не научит. Это закладывается на уровне семьи, на уровне культуры, на уровне воспитания.
А по поводу:
Будет-ли при тренировки красивый стадион или SAFe - думаю важно, но не настолько как первое
Позвольте ответить аналогией на аналогию.
Возьмем все тот же спорт. Скажем футбол.
В странах, где развита инфраструктура. Куча красивых стадионов больше шансов, что дети пойдут и будут заниматься футболом. и будут в перспективе приносить стране множество медалей и кубков. И от этого инфраструктура будет только расти. И это станет коммерчески выгодным всем. Детям, организациям, стране.
В стране, где нет красивых стадионов и не занимаются целенаправленным развитием инфраструктуры есть шанс выиграть что-то у кого-то когда-то, но нет шанса построить систему целенаправленного развития.
С чего начинается построение любой архитектуры?
Если, уж, нам нужна архитектура, то нам нужен обзор возможных предметных областей и предметных ситуаций. Нужна классификация задач: тут у нас — торговля, тут к нас — образование, тут — производство, тут — развлечение (просмотр фильмов, прослушивание музыки), а тут — творчество (создание нового). Но это всё — первичная классификация. Архитектура выражает собою системный подход. А системный подход подразумевает, что имеются определённые кирпичики = типовые задачи, и эти типовые задачи одинаковы для всех предметных областей: что храним, что обрабатываем, как обрабатываем, редактируем или нет, порядок действий (открытие, просмотр/редактирование, сохранение) и т. д. и т. п. Типовые объекты и типовые объекты, которые везде (а каждой предметной области) имеют свои локальные имена, но одинаковы по управлению. И архитектор — это тот, кто очень хорошо видит эти обобщённые сущности (абстракции) за лесом подробностей предметной области.
Как создать цифровые продукты, которые будут удовлетворять требованиям заказчиков, вписываться в намеченные сроки и бюджеты?
Для этого нужно один раз провести формализацию всех имеющихся предметных областей и предметных ситуаций и получить стоящие за ними абстракции. А потом собирать коробочную версию программного продукта из готовых компонентов для каждого конкретного пользователя. Но этим способом никто не пользуется.
Вот, что у нас есть?
Торговля. Ситуация: покупатель/продавец, поставщик/производитель. Есть: материалы/склады/логистика, цены/партии, единицы измерения, номенклатура. Требуется: оперативный/бухгалтерский/аналитический учёт.
Образование. Ситуация: учитель/ученик. Есть: учебные материалы/темы, задачи/решения. Требуется: оперативный/бухгалтерский/аналитический учёт (то же самое!). Здесь оперативный учёт — это, собственно, учёт текущих действий учителя/ученика, а аналитический учёт — это анализ эффективности процесса обучения.
Научная/творческая деятельность: написание статей, рисование картин, съёмка фильмов, проведение спектаклей и радио, накопление данных, обработка данных.
Строительство, проектная деятельность, управление территориями.
Спорт.
А ещё у нас есть
пользователи, которые могут быть простыми потребителями услуг, а могут быть и источниками всевозможного содержимого + всевозможные роли (включая и роли администратора);
конкретные объекты, с которыми мы имеем дело (товары, материалы, книги/фильмы/статьи//научные/публицистические/критические//, научные/исторические данные, ...);
конкретные способы обращения с этими объектами (типовые операции и типовые сценарии).
Понятное дело, что различных предметных областях имеются, грубо говоря, свои "склады", своя номенклатура "товаров", свои "накладные", свои "регистры" и свои отчёты. Архитектура — это представление о том, что имеются эти самые "товары", "склады", "накладные", "регистры" и отчёты (и как они взаимодействуют).
Из чего должна складываться структура продукта и как он должен реализовывать функциональные требования?
Возьмём для "примера" задачу решения квадратных уравнений. Сама по себе эта задача решается простой процедурой, которая получает на входе три числа, а на выходе два совершенно других числа, которые (вот ведь какая история!) могут оказаться и комплексными! Но! Попробуйте сделать так, чтобы у этой процедуры были пользователи. Это значит, что надо будет вести историю вызовов, и у каждого. пользователя она будет своя, и свои данные и свои результаты. Тут можно заговорить и о разграничении доступа. Хорошо! А что должна выводить процедура? Чисел мало, нужен поясняющий текст и, вообще, анализ того, что и в каком случае получается, вплоть до полной документации, фактически, описывающей теорию решений элементарного квадратного уравнения. (Запахло ChatGPT? Да-да!!)))) А как эта процедура будет устроена внутри? Просто прочитать три числа из входного файла/потока? Или получить их прямо в визуальной форме? Но можно сделать режим мастера, и действовать строго последовательно (или каким-то образом гарантировать строгую последовательность в рамках общей формы ввода). Уже довольно много вариантов взаимодействия. А если мы хотим решать не только квадратные уравнения? А если мы хотим, чтобы пользователи сами формулировали свои задачи?
И ещё. Каждой архитектуре соответствует своя схема базы данных. Можно для каждого набора взаимосвязанных сущностей создавать отдельный набор табличных объектов одного и того же вида, а можно создавать один набор табличных объектов, но хранить в таблицах разнородные данные и ещё иметь дополнительные справочники метаданных.
Если мы допустим ошибки на более верхних, тактических уровнях они сразу станут видны и понятны, условно - дешевоисправимы. А если на более нижних, стратегических уровнях, то выявить их будет более сложно, исправить более дорого.
Самая дорогая ошибка связана с тем, что мы разрабатываем программный продукт для работы в конкретной операционной системе, вычислительной сети (интернет) и для конкретной (реальной) организации работы. Это неустранимая ошибка, но именно она обходится нам дороже всего. Надо бы делать операционные системы под конкретные задачи, но всё наоборот. Было бы удобнее иметь единый для всех участников рынка справочник номенклатуры/план счетов/реестр документов и отчётных форм, но в каждой предметной области/стране/ведомстве свои правила и требования.
А так... получается, что армии разработчиков в тысячах организациях по всему миру решают одни и те же задачи. Вот это и есть ошибка на самом верхнем уровне. Меняются только аббревиатуры технологий. И постоянно устаревает код. Хотя задачи всё те же. Как-то так.
Спасибо за комментарий.
Давайте попробую пояснить свою мысль.
Если, уж, нам нужна архитектура, то нам нужен обзор возможных предметных областей и предметных ситуаций. Нужна классификация задач: тут у нас — торговля, тут к нас — образование, тут — производство, тут — развлечение (просмотр фильмов, прослушивание музыки), а тут — творчество (создание нового)
Вы говорите, про архитектуру конкретного решения, решений. Я говорю, про архитектуру построения системы развития ИТ.
Если мы посмотрим, на интересующую Вас область, то внутри TOGAF, есть этапам/активность - бизнес архитектура. Внутри этой активности есть область бизнес анализ (BABOK). Внутри этой области есть действия по построению целевой бизнес процессов, то есть того, как должны работать - торговля/образование/производство/... Там Вы берете какой-то существующий инструмент и с его помощью наводите порядок. Инструментов много. Например такой (ссылка) - хорошо себя зарекомендовавшие схемы процессов по разным коммерческим сферам деятельности. Тут нет концептов и нет архитектуры. Тут нужно выбрать/разработать/адаптировать модель деятельности, которую нужно последовательно воплотить в коде. Вот тут, в воплощении и появляется архитектура, которая должна соответствовать параметрам, которые я предложил Выше в разделе "Почему информационный продукт должен быть именно таким?"
Для этого нужно один раз провести формализацию всех имеющихся предметных областей и предметных ситуаций и получить стоящие за ними абстракции. А потом собирать коробочную версию программного продукта из готовых компонентов для каждого конкретного пользователя. Но этим способом никто не пользуется.
Я с Вами не соглашусь. Такой деятельностью занимаются и на это есть отдельная сфера деятельности, отдельная специализация, которой уже учат в институтах (ссылка), на профильных курсах, за деньги для уже состоявшихся специалистов. Это системный менеджмент. Да, пока, он не очень распространен, но при этом уже многие компании начинают внедрять и адаптировать его под себя.
Архитектура — это представление о том, что имеются эти самые "товары", "склады", "накладные", "регистры" и отчёты (и как они взаимодействуют).
Точно. Но тут Вы про архитектуру конкретного решения, конкретного продукта. Полностью согласен.
(Запахло ChatGPT? Да-да!!)))) А как эта процедура будет устроена внутри? Просто прочитать три числа из входного файла/потока? Или получить их прямо в визуальной форме? Но можно сделать режим мастера, и действовать строго последовательно (или каким-то образом гарантировать строгую последовательность в рамках общей формы ввода). Уже довольно много вариантов взаимодействия. А если мы хотим решать не только квадратные уравнения? А если мы хотим, чтобы пользователи сами формулировали свои задачи?
ChatGPT - не панацея. Это инструмент, которым нужно уметь пользоваться, который нужно уметь настраивать. Инженер не может не понимая инструмента его использовать. Иначе инженер не может отвечать за результаты своего труда.
А как эта процедура будет устроена внутри? Просто прочитать три числа из входного файла/потока? Или получить их прямо в визуальной форме? Но можно сделать режим мастера, и действовать строго последовательно (или каким-то образом гарантировать строгую последовательность в рамках общей формы ввода). Уже довольно много вариантов взаимодействия. А если мы хотим решать не только квадратные уравнения? А если мы хотим, чтобы пользователи сами формулировали свои задачи?
Все можно. Но как проверить, что расчет верный. Как провести тестирование/верификацию/валидацию. Как дорабатывать и развивать инструмент? Для этого должен быть кто-то, кто понимает как он работает. Нужна система вокруг инструмента. И чем более широко и масштабно мы используем инструмент, тем система будет больше, сложнее. Это эволюционные витки развития любого инструмента. Примеров, чтобы было не так в социотехнических системах нет. Как только мы начинаем применять сложные решения, так сразу вокруг этих решений начинают расти подразделения, в которых количество специалистов обслуживающих их множится и множится. И вот тут вам потребуется организационная система. Предлагаемый в моей статье концепт не про систему конкретного решения, а про техническую среду, в которой можно будет системно заниматься развитием в том числе и таких решений, которые предлагаете Вы.
И ещё. Каждой архитектуре соответствует своя схема базы данных. Можно для каждого набора взаимосвязанных сущностей создавать отдельный набор табличных объектов одного и того же вида, а можно создавать один набор табличных объектов, но хранить в таблицах разнородные данные и ещё иметь дополнительные справочники метаданных.
Можно. И такие системы уже есть. Коммерчески успешные. Например - SAP, котораzреализована как раз вот так. На обслуживание такой технической системы требуется очень много профильного персонала, которые должны работать по своим правилам. Каким правилам? - Как взаимодействовать с пользователями, как вносить изменения в справочники, как развивать систему, как адаптировать систему под конкретные изменения. Все такие системы объединены в отдельный класс систем, которые развиваются по принципам шаблонного проектирования. Это отдельное направление деятельности, которое приводит к своим виткам развития в ИТ. Например к BPMS системам или Low code системам и т.д. Но внедрив такую систему, Вам все равно придется думать и решать задачи связанные с их развитием
А так... получается, что армии разработчиков в тысячах организациях по всему миру решают одни и те же задачи. Вот это и есть ошибка на самом верхнем уровне. Меняются только аббревиатуры технологий. И постоянно устаревает код. Хотя задачи всё те же. Как-то так.
Полностью согласен. На разных витках развития мы, как отрасль, решаем одни и те же вопросы, но решаем их по разному. С разными инструментами, с разным уровнем накопленных данных, разными культурными и инженерными принципами и подходами к решению задач. Для меня это и есть эволюция.
5 «Почему» для понимания архитектурных концептов при создании информационных продуктов