Автор статьи: Максим Рогоза, корпоративный архитектор.

Я уже четверть века работаю в сфере IT. Мой профессиональный путь начинался с разработки, а сейчас я дорос до должности корпоративного архитектора в одном из ведущих российских интеграторов. За время моей карьеры я сменил множество компаний, ролей и команд разработки. В процессе работы я часто сталкивался с неприятной проблемой — при разработке проекта или продукта IT‑специалисты, к сожалению, не всегда учитывают интересы бизнеса. Нередко они зацикливаются на создании красивого кода, который нравится только им самим, и который совершенно не удовлетворяет потребности бизнеса. Это может привести к серьезным проблемам и даже к полному провалу проекта, если команда зациклится на создании «красивости» в ущерб бизнес‑интересам.

Первоначально я считал, что такой подход — это врожденная черта разработчиков. Однако со временем я понял, что это не так. Программисты и архитекторы могут начать мыслить по‑другому, если им предоставить правильный инструмент. И таким инструментом для меня стал язык Архимейт.

Когда я первый раз познакомился с этим архитектурным языком, я был в восторге от возможности связывать бизнес‑процессы с конкретной реализацией программы. Такой подход позволял мне гораздо лучше понимать логику работы программы. Если обычные компонентные диаграммы, которые я видел ранее, могли дать представление о том, как устроена программа, то комплексная модель на языке Архимейт, включающая в себя программный и бизнес‑слой, давала мне полное представление о том, какие процессы автоматизируются. Я заметил, что когда разработчик видит Архимейт модель с описанием бизнес‑слоя, он может гораздо лучше понять логику программы. Это значительно снижает необходимость подробно описывать все детали и процессы, которые нужно реализовать.

Более того, программисты часто еще на этапе подготовки бэклога предлагают, как можно улучшить процесс вместо того, чтобы создавать сложные конструкции в коде. А ведь это и есть бизнес‑ориентированный подход! В конце концов, я убедился на собственном опыте, что использование языка Архимейт помогает программистам и архитекторам перенаправить свое внимание на решение задачи бизнеса вместо написания красивого, но неэффективного кода.

Я считаю, что причина такой перемены заключается в том, что программисты не руководствуются только желанием написать «красивый» код. Они ограничиваются теми языковыми конструкциями, которые знают, придумывая решение. Если программист использует язык программирования, то он думает только о синтаксисе и структуре кода. Если используется простой архитектурный язык, который позволяет строить компонентные диаграммы, то программист думает только о компонентах и структуре архитектуры программы. Архимейт, в свою очередь, позволяет думать категориями бизнес‑архитектуры и даже продумывать стратегию и мотивацию. Этот язык позволяет программистам рассматривать проект с более широкой перспективы, а не только как набор кода. Благодаря Архимейту разработчики могут глубже понимать бизнес, который нужно автоматизировать, и предлагать более эффективные решения.

Когда программист или архитектор использует язык Архимейт, он может легко преодолеть языковые барьеры и думать на более высоком уровне абстракции. Он уже не ограничен теми языковыми конструкциями, которые были ему известны ранее, и может свободно представлять бизнес‑процессы и их взаимодействие в рамках программы, а также понимать стратегические цели и ограничения, которые есть у заказчика. А это, в свою очередь, позволяет ему создавать программное обеспечение, которое наиболее точно соответствует потребностям бизнеса.

Конечно, надо понимать, что Архимейт изначально задуман для описания корпоративной архитектуры. Этот язык не является идеальным инструментом для описания архитектуры данных или описания архитектуры классов, но, к счастью, это почти и не нужно в современных гибких подходах к разработке. По моему опыту, Архимейт может является очень полезным инструментом проектирования архитектуры программного обеспечения. У меня было несколько проектов, где мы использовали Архимейт как единый язык описания архитектуры решения на всех уровнях проработки, и это был успешный опыт. Хотя, конечно, приходилось применять некоторые хитрости, чтобы обойти ограничения языка. Но в конечном счете, способность разработчиков видеть проект целиком, знать и понимать цели и задачи бизнеса, значительно перевешивали те ограничения, которые накладывал Архимейт на возможности описания низкоуровневой архитектуры.

В итоге, по моему опыту, использование языка Архимейт не только повышает эффективность разработки, сокращает затраты на разработку и поддержку программного обеспечения. Но также улучшает качество IT решения и повышает удовлетворенность клиентов, так как результат работы программистов становится более ориентированным на решение бизнес‑задач.

В заключение рекомендую открытый урок «Описание программного слоя на языке Архимейт» в OTUS. На этом уроке мы изучим элементы Архимейт для отображения программной архитектуры, связи программного слоя с другими слоями. Рассмотрим примеры.

План урока:
1. Аспекты архитектуры, отображаемые на программном слое.
2. Элементы программного слоя.
3. Связь программного слоя с другими слоями.
4. Практика отображения мотивационного слоя.

Записаться можно на странице курса «Archimate».