Кто такой архитектор ПО?

Для того чтобы дать ответ на этот вопрос необходимо рассмотреть, чем является архитектура сама по себе.

Процитируем определение данное ISO 42010:

Фундаментальная организация системы, воплощенная в ее компонентах, их связях друг с другом, ее окружении и принципах, управляющих ее созданием и эволюции

Из этого определения видно, что архитектор, – это человек, который создает системы и их описания. К сожалению на этом определении люди, которые открыли стандарт обычно и останавливаются, в лучшем случае дочитав остаток по диагонали. Подавляющее большинство людей отмахиваются от важных вопросов о том, что такое система, как правильно выделить систему из доступной информации, что такое целевая и обеспечивающая системы и многие другие вопросы. Сколько раз, мне доводилось слышать реплики, по типу «Это все про космические корабли, мне это не надо». В итоге мы имеем большой набор специалистов, которые неизбежно выстроили свои собственные «велосипеды» для того, чтобы как-то эти информационные пробелы закрыть. Это приводит к одной простой, но неизбежной истине – люди, занимающиеся архитектурой в восточно-европейском регионе не имеют целостной картины о полном цикле разработки архитектуры, начиная от анализа предметной области и заканчивая проверкой архитектуры на корректность. Если вы архитектор, задайте себе простой вопрос, какие существуют формальные инструменты для оценки качества архитектуры или хотя бы вопрос, что такое качество архитектуры и попробуйте перечислить хотя бы 4 показателя, которые можно измерить и выразить колчественно. Держу пари, что у вас ничего не получится. Хотя в реальности и инструменты, и показатели такие есть. Вы просто до них не дочитали, потому что это вам казалось про «постройку космических кораблей».

Проблема усугубляется тем что в нашем регионе очень узкое понимание архитектурных дисциплин. Конкретно, мы смотрим на архитектуру систем исключительно с точки зрения организации исходного кода. Это в корне неверный подход, при таком рассмотрении проблемы возникает конфликт между разработчиками высоких уровней и архитекторами, потому что по сути им предлагается решать один и тот же круг задач. Из-за этого возникает картина кривого зеркала, когда появляются вакансии в стиле «требуется разработчик уровня architect»… Мне часто возражают на мое возмущение сложившейся ситуацией, если рынок просит, значит, это для рынка работает. Замечание безусловно справедливое, действительно, разрабочик уровня архитект может закрыть какие-то сиюминутные потребности, однако такой специалист не сможет закрывать потребности, которые закрываются архитекторской компетенцией на международном рынке. Потому что там архитектор – это не просто суперкрутой разрабочик. Более того, для того чтобы стать Enterprise Architect, вы не можете ни дня разработчиком и не проработать.

Основные дисциплины архитектуры, их миссии и, соответственно, архитекторские роли на международном рынке разработки выглядят следующим образом:

Software Architecture. Проектирование системы, используя семантику модульного разбиения. Оценка сроков и качества имплементации системы.
Systems Architecture. Проектирование системы, используя семантику технологий и окружающей среды, в которой эта система должны функционировать. Выделение и поддерживание целевой системы и обеспечивающей системы. Эта дисциплина является фундаментом, для более высокоуровневых архитектур.
Solutions Architecture. Концентрируется на комплексном решении конкретной бизнес задачи, используя функциональную семантику компонентного разбиения. Результатом применения Solution Architecture является комплексное решение, включающее в себя разработку непосредственно целевой системы, ее инфраструктуры, набора обеспечивающих систем и выравнивание их показателей относительно бизнес-цели продиктованной решаемой задачей.
Enterprise Architecture. Архитектура предприятия фокусируется на решении набора бизнес-задач, определенных в границах бизнес-стратегии. По сути применение Enterprise Architecture дает верифицируемый ответ на вопрос: «что нам надо сделать, чтобы достичь определенных показателей через год».
Business Architecture. Концентрируется на создании верифицируемой бизнес-модели, используя цели, определенные в mission и vision statements. Занимается разработкой необходимых показателей и ключевых факторов успеха бизнеса, а также позволяет выстроить вертикальную систему соответствия высокоуровневых capabilities конкретной инфраструктуре, которая лежит в области имплементации бизнес-модели в рамках конкретного предприятия.

Распространенное заблуждение – это то, что архитектором невозможно стать никому, кто не был бы разработчиком. Конечно, для того, чтобы выполнять роль Software Architect и даже Systems Architect в компании занимающейся разработкой программного обеспечения технические навыки необходимо иметь. Поэтому эти две дисциплины действительно проще всего осваиваются именно сотрудниками, имеющими багаж разработчика, причем весьма хорошего разработчика, из миддла архитектором не стать.  А вот три остальные дисциплины доступны намного более широкому кругу людей. Так, например, в Solutions Architect может вполне переквалифицироваться аналитик либо же проектный менеджер с техническим бэкграундом. А архитектура предприятия и бизнес архитектура и вовсе не требуют каких-то специальных знаний в области разработки программного обеспечения, хотя какое-то базовое понимание этих концепций, хотя бы на уровне средней школы очень желательно. На инфографике ниже изображена схема перехода из одной роли в другую.



В зависимости от выбранной роли, специалист должен владеть, в полном объеме, соответствующей архитектурной дисциплиной, а также на достаточно хорошем уровне знать рядом стоящие дисциплины. Так, например, Solutions Architect должен в полном объеме владеть практиками Solutions Architecture, а также хорошо знать области Systems Architecture и Enterprise Architecture. Потому что это смежные области знаний, которые ему необходимо понимать для того, чтобы правильно коммуницировать как со своими заказчиками, которые находятся в зоне Enterprise Architecture, так и с исполнителями, которые являются представителями Systems и Software Architecture, если мы говорим о разработке программного обеспечения.

Отдельно можно выделить несколько активностей, для успешного завершения которых, необходимо владеть всем стеком архитекторских дисциплин:

• Самая сложная активность в современных компаниях, которые уже вышли из зоны стартапов, это создание тендерных/коммерческих предложений (presale). В зависимости от размера тендера над проектом предложения может трудится от одного человека, до большой команды сотрудников, центральным звеном которой является архитектор. Именно от него зависит будущий облик предлагаемого решения, его стоимость и параметры качества. Отдельным, усложняющим фактором тут является время. Без наличия архитектуры невозможно построить проектный план, план тестирования и развертывания, создать WBS, согласовать бюджет и сделать много других необходимых вещей, которые нужны, чтобы обойти конкурентов. Этот фактор поднимает необходимый уровень профессионализма архитектора на подобной позиции до очень больших высот. Конечно, если речь о проектах более чем на три человеко-месяца.

• Бизнес трансформации. С этим пунктом у нас традиционно все грустно. Так получилось, что на территории постсоветского пространства такие дисциплины как бизнес-архитектура и архитектура предприятия либо в общей массе отсутствуют, либо сильно перекошены советскими практиками тяжелого машиностроения и плановой экономики. Отсутствие носителей этих дисциплин приводит к ситуации, когда комплекс мероприятий по воплощению бизнес-стратегии компании либо без особого успеха проводится сотрудниками-добровольцами, чуть-ли не в свободное от проектной работы время, либо ложиться на плечи топ-менеджмента, который тоже вынужден этим заниматься отрывочно и по остаточному принципу, потому что у них есть свой круг задач, которыми они занимаются в первую очередь. Получается классическая ситуация, в которой верхи не хотят, а низы не могут. В итоге, подавляющее большинство украинских компаний не могут управлять процессом бизнес трансформаций и вынуждены плыть по течению рыночной конъюнктуры, что не позволяет им быть эффективными.

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