Комментарии 16
Очень структурировано получилось!
В целом согласен с озвученной идеей. Правда от себя бы отметил, что важнее всего не "Архитектура как код" (то есть код - как один из вариантов формализации), а непосредственно применение лучших архитектурных практик в устройстве самого бизнеса. А уж в каком виде это записать/формализовать - вопрос второй. А то придумать то подобных способов можно массу, но толку от них не будет, если пользующийся ими человек в архитектуре не особо то и смыслит.
Главная причина подхода в том, что он встраивается в DevOps как активный элемент. Т.е. может исполняться и приносить результат.
Например, арх спроектировал АС и предал в производство. Разработчик получил доступ к ее описанию в среде разработки. Декомпозировал описание на модули. Написал код и разметил его на АС как объект архитектурного учета. Передал DevOps для развертывания. Тот, в своей среде разработки, обогатил арх описание метаданными развертывания.
В результате мы получили цифровую копию ИТ ландшафта, которую можем использовать для моделирования, оценки требуемых ресурсов, генерации скриптов развертывания и тестирования.
Слабо представляю, как это можно сделать в draw.io или PlantUML.
С основой мыслью поспорить сложно. Архитектор должен архитектурить, чтобы архитектурно было. Знать практики. Но он часто испытывает проблемы при этом. Нередко его замысел, построенный на лучших практиках, не доходить в оригинальном виде до прода.
Выше описанный подход позволяет ему проникнуть в реализацию на этапе разработки. Чем повысить успешность применения лучших практик.
Также, код архитектуры делает возможным обмен архитектурными паттернами аналогично модулям кода приложений, которые ты подключаешь к своему приложению. Что, мне кажется, может стимулировать развитие лучших практик.
В модели business-application-technology, DevOps это уровень technology (& implementation).
Архитектура бизнесов находится на два этажа выше. Там есть свои паттерны, только целевой платформой выступает не айти, а различные regulations, legal и т.п.
Когда мы научимся формализовать и проектировать бизнесовые архитектуры непосредственно в терминах технологий, наступит глобальная технократия. Но пока это сильно из области фантастики.
Именно! Поэтому, кажется важным начать грызть этот гранит уже прямо сейчас, не откладывая, чтобы хотя бы на несколько мгновений приблизить глобальную технократию, тем самым повлияв на судьбу человечества.
Если предположить, что изменения в бизнесе должны непосредственно влиять на технологии, то зависимости должны бы инвертированы (IoC) - стрелки идут от бизнеса в сторону нижних слоев, а не наоборот. Значит от бизнеса нужны контракты. В принципе, как вы и описываете.
Могу предложить, что это уровень ГОСТ, СНиП и прочих НПА которые задают атрибуты качества, а также же определяют методики проверки соответствия: сертификация, аудит и т.п. Может это и есть элементы архитектурного девопса?
К счастью нет. В основном, технологии влияют на бизнес. На мелкий и средний точно. На крупный в основном. Технологии это артефакт внешней среды для бизнеса. И исследуется в таком инструменте как PESTEL анализ.
Т.е. бизнес и технологии сильно увязаны. Утверждение, что бизнес всегда прав - фундаментально ошибочно в стратегическом плане. Очень много заметных бизнесов было построено на случайных прорывах в технологиях.
Я попробую помедитировать над этим. Но вообще неоднократно видел как меняются технологические стеки, платформы, вендоры. А бизнес продолжает работать как и работал.
Например, сейчас много заказов на миграцию с on-prem в клауды. Это как пересесть со старого дизельного гелендвагена, на электричку типа теслы: изменение влияет на отдельные, чисто эксплуатационные моменты, но основная бизнесовая логистика и маршруты остаются такими же. Снаружи так вообще ни кто ни чего заметить не должен.
Как раз таки с позиции архитектуры это фатально, когда "бизнес и технологии сильно увязаны". Безусловно, могут появляется различные бизнесы вокруг каких-то конкретных технологий, и быть весьма успешными до поры до времени. Но это бизнес, что называется, на один вечер, если они от этих конкретных технологий не отвяжутся. Пока эта технология актуальна и они поспевают за спросом. Уйдет технология - уйдет и бизнес. Выше @funca тоже об этом написал.
Мой комментарий выше вообще и был по большей части про архитектуру бизнеса и процессов в нем. И конкретно про IT даже и не думал. И именно так воспринял саму статью. IT - это по-прежнему лишь инструмент для бизнеса. И как бы мы ни хотели возвеличивать важность и полезность этого инструмента, от него тоже нужно абстрагироваться.
Вы как-то романтизируете бизнес. Или делаете его каким-то очень правильным. Нет. Бизнес по сути - комплекс мероприятий по получению выгоды из внешней среды с использованием доступных ресурсов. Это все.
И вот теперь, если взять его основу - бизнес всегда временен. Он получает доход из текущих потребностей кого-то, давая ему что-то. И это делается с учетом реальности мира и его технологий.
Если бизнес живет десятилетиями, то он эволюционирует. Сложно представить себе производство мерседеса сегодня с использованием технологий начала века. Причем это во всех смыслах. В том числе и в технологиях управления глобальными корпорациями.
Бизнес обязан видоизменяться и адаптироваться под внешние условия. В которых технологии дают ключевое конкурентное преимущество.
Я ИТ не возвеличиваю. Я изучаю его величие и отражаю в фактах. Как бы бизнес не считал, что ИТ его инструмент, он сегодня от него завист чуть меньше, чем полностью.
Я бизнес не романтизирую, я просто радею за то, чтобы любая компания (особенно в которых мне доводится работать) была грамотно "спроектирована". Я в таком ключе на любую систему в жизни уже и смотрю: точно так же, как и на ПО. Как она спроектирована. Что в ней может сломаться, что уязвимо, какие принципы в целом нарушены, и так далее. И это комично порой выглядит, когда приходишь работать в компанию, чтобы делать им крутое ПО, а сама копания сплошь на костылях работает. Типа как условный кладовщик одновременно и менеджер по продажам и чуть не бухгалтер. Ну и тому подобное.
Бизнес обязан видоизменяться и адаптироваться под внешние условия.
Я про это, в общем-то, и говорю. И как раз именно это, в том числе, и призвана обеспечить грамотная архитектура системы: способность к изменениям и отказоустойчивость. Говоря про "отвязку" от IT я же не говорю про отказ от его использования. Я говорю про абстрагирование от него.
Говоря про IT как инструмент, скажу вам больше: как сотрудник для бизнеса вы тоже инструмент. Бизнес, конечно, может и на вас лично жестко завязаться: какой вы замечательный человек, большое кол-во навыков и так далее. Но очевидно, люди приходят и уходят, на худой конец могут и заболеть, и так далее. Поэтому бизнес, если он хочет большей отказоустойчивости, будет от вас абстрагироваться. Для него вы - просто сотрудник по контракту. Ушел один - заменили другим. Или взяли еще одного помимо вас. А та часть бизнеса, что над вами, завязана не на вас лично, а на абстрактного сотрудника (контракт).
Смотрите, я не буду ставить под сомнение ваш подход. Ровно потому, что не считаю свой верный. Да и, честно говоря, уже не могу его внятно сформулировать, на данном этапе. Скажем так - я наблюдаю и учусь по новой.
Так вот... удержать в голове можно очень ограниченный контекст. Т.е. способность осознания системы как целого, выявление ее недостатков и сильных сторон напрямую зависит от органических способностей человека.
Из этого можно, мне кажется, смело сказать - сложные системы не может проектировать один человек. Ему приходится ее упрощать для осознания. Так учат многие подходы. Но... система остается все такая же сложная.
Упрощение системы ведет лишь к отказу погружаться в частности. Это волевое решение принятия рисков. Волевое решение конкретной личности. Потому, что она не может погрузиться во все.
Таким образом, мне кажется, говорить о том, что система должна быть хорошо спроектирована, это как говорить - мир должен быть хорошо устроен. Может и должен. Но он такой, какой есть. Потому, что мы не можем его монополизировать. Даже свой участок в ДНП, мы не сможем сделать так как хотим.
В подходе "Архитектура как код" я вижу решение осознания большего. Через средства автоматизированного контроля. Через сегментирование архитектуры, оставляя при этом ее управляемой. Т.е. ты сможешь проектировать действительно большие системы в действительно большой команде.
Кажется, что этот подход должен значительно расширить органические возможности умных людей и заметно снизить врожденную силу других.
Говоря про IT как инструмент, скажу вам больше: как сотрудник для бизнеса вы тоже инструмент.
Да, скорее всего мы говорим об одном и том же. Но с разных ракурсов. Я уверен в величии ИТ. Но я совсем не уверен в величии любого ИТшника. ИТ это феномен человечества. А ИТшник, это человек, который этот феномен эксплуатирует.
Кто "ты" для бизнеса, решать тебе. Это не метафора. Именно тебе. Хочешь быть его инструментом? Будь. Хочешь использовать чей-то бизнес для получения стабильного дохода, чтобы выращивать новый вид гладиолусов? Разве можно тебе это запретить?
Но очевидно, люди приходят и уходят, на худой конец могут и заболеть, и так далее.
Очевидно и обратное - бизнесы уходят и приходят. Я чаще меняю работу, чем умираю. Так кто для кого в этой жизни?
Все зависит от контекста (с)
Ну в целом то да, мы примерно об одном и том же, просто с разных точек зрения. И идея "Архитектура как код" мне действительно нравится как раз из тех соображений, что описал выше: на любую систему уже смотрю с позиции, словно это работающее ПО, соотв-но таким же образом, по крайней мере лично, было бы удобно и описывать их, словно это и есть программа. А там уже и прочие фишки можно применить: проанализировать все те же зависимости и так далее.
Так вот... удержать в голове можно очень ограниченный контекст.
Тут, кстати, как раз кроется один из подходов в проектировании: откладывать решения на потом. Рассматривать часть системы независимо от того, как будет сделана остальная часть. Все то же абстрагирование.
Я уверен в величии ИТ.
Ну я так-то тоже не устаю восхищаться, какие возможности открывает для человека IT, и рад быть в этой сфере. Но все же иногда лишний раз одергиваю себя, когда возникает какая-то задача. Это можно сравнить с использованием какого-нибудь фреймворка в приложении. Один разработчик пишет "на" фреймворке, а второй фреймворк просто использует в той степени, какая ему нужна. Первый, когда у него возникнет какая-то задача, рассуждает в категориях "как это сделать в этом фреймворке", и порой может раздосадоваться, если фреймворк этого не умеет. Второй же рассуждает скорее в категориях "сможет ли мне здесь фреймворк помочь" (да, так да, нет так нет).
Касаемо последних двух абзацев: так и есть. Для меня работодатель тоже абстракция. Или чтобы звучало все же красивее и человечнее: партнер. То есть для меня отношения работодателя и сотрудника - это исключительно взаимовыгодное сотрудничество на тех условиях, на которых договорились. И пока мы друг друга устраиваем, сотрудничаем дальше. Как работодатель не зависит лично от меня, а зависит от абстракции, так и я не завишу конкретно от него. Но естественно, это не мешает нам плодотворно работать, но каждый - в своих интересах.
В качестве старческого брюзжания: значит, архитектор - это роль, а девопс - боевая единица, необходимая в стартапе на 10 человек.
Поразительно, конечно, как далеко от задумки оно зашло в массы.
Не уверен, что я вас понял верно. Но, скорее я вижу это так. В сегодняшнем, наблюдаемом мной мире. Хотя, можно сказать, что DevOps роль четко выделяемая уже на первом этапе разработки цифровых продуктов. В отличии от архитектора. Она как бы размазана. Принятие архитектурных решений в стартапе доверяется чуть меньше чем всем. Но область воздействия у них скорее ограничена.
Мне кажется, что в стартапе все единицы боевые. Степень влияния любой роли на продукт ограничена лишь желанием и способностью члена команды генерировать полезные идеи и доносить их.
Но в целом, почти всегда возникает технический лидер, с которым согласовываются ключевые решения. Лычки при этом могут быть разные.
И это, все же усредненный паттерн. Конкретный ролевой ландшафт напрямую зависит от самой команды. И очень быстро мутирует.
Спасибо, начинаем думать об этом - статья очень в тему попалась на глаза
Публикации
Кто последний на индустриальный стандарт? Мне только спросить…