Привет. Меня зовут Степан Новиков. В EPAM я занимаю позицию Solution Architect, и мой общий опыт работы над коммерческими проектами в ІТ — более 15 лет. За это время я примерил на себя несколько ролей: выполнял функции бизнес-аналитика, руководил отделом бизнес-анализа в одном из банков, затем вернулся в разработку, постепенно приобретая опыт в IT-архитектуре.
За эти годы я успел поработать со многими проектами. Какие-то из них были более успешны, какие-то менее. Обычно в процессе разбора неудач выяснялось, что одной из основных причин была проблема коммуникации между разработчиками и клиентом. Часто мы либо не понимали, что нужно заказчику, либо же не могли внятно донести ему необходимость и полезность того или иного технического решения. Итогом такого недопонимания становились продукты, которые, будучи замечательными с технической стороны, не отвечали потребностям и бизнес-модели клиента.
Я надеюсь, что данная статья поможет читателям не наступить на те же грабли, и даст понимание того, почему для создания хорошей архитектуры необходимо максимально проникнуться принципами работы компании клиента и её бизнес-потребностями.
Сразу оговорюсь, что материал описывает лишь ключевые этапы на пути выбора дизайна архитектуры. И не дает развернутое и пошаговое руководство, так как каждый из перечисленных ниже шагов заслуживает как минимум отдельного материала.
Однако было бы неправильно винить во всех неудачах только модель процесса разработки. Мы можем использовать популярный и эффективный Agile, но без нормальной коммуникации с клиентом, без понимания специфики его бизнеса этот подход сам по себе не гарантирует успех.
Только эффективное общение поможет понять важные аспекты для разработки удачного решения, и один из них — бизнес-модель клиента.
Ранее цифровые решения в большинстве случаев служили дополнением к существующим бизнес-моделям компаний, занимая лишь несколько строчек в данной канве. Однако сегодня для большого числа компаний в мире ІТ-решения становятся если не основой бизнеса, то одним из жизненно необходимых компонентов. А для кого-то и вовсе единственным инструментом для получения прибыли. Роль ІТ-специалистов и ІТ-решений для полноценной работы компаний растет, а вместе с этим увеличивается и уровень ответственности.
В то же время в конце 90-х и начале нулевых разработчики не всегда задумывались о сборе информации от заказчика. Считалось, что клиент сам должен собирать и формировать требования, спуская готовую документацию командам разработчиков. Естественно, такое положение дел приводило к ряду недопониманий и разногласий, а готовый продукт, кажущийся разработчикам вершиной инженерной мысли, мог не соответствовать потребностям и бизнес-модели клиента.
Со временем Scrum и другие Agile-подходы своим появлением привнесли новшества в эти взаимоотношения, дали понимание того, что с клиентом можно и нужно разговаривать. Появилась роль Product Owner, изменился подход к самой документации.
Отсутствие знаний о том, как работает бизнес заказчика и какое влияние на работу бизнеса оказывают качества системы, может привести к ряду последствий. Начиная на первый взгляд с безобидных — таких, как быстродействие системы или вероятность отказа при пиковой нагрузке на неё, до глобальных и сулящих бизнесу колоссальные потери. Вспомните обход защиты в PlayStation Network в 2011 году.
Сюда входят: потребители (клиенты), продукт, каналы сбыта, взаимоотношения с задействованными в бизнесе сторонами, финансовые потоки, структура доходов и расходов, ресурсы. Для иллюстрации бизнес-модели может применяться знакомый многим инструмент Business Model Canvas.
Business Model Canvas авторства Александра Остервальдера и Ива Пинье
Во избежание проблем, связанных с коммуникацией и недопониманием, во многих компаниях работают команды специалистов, среди которых не последнюю роль играют ІТ-архитекторы.
International Association for All IT Architects
IT-архитектору, чтобы построить свое решение, важно понимать, как работает бизнес клиента, каков контекст, с которым будет работать система, и как данная система будет решать задачи бизнеса. Без этих знаний архитектор, вероятно, не сможет быть эффективен — все предпринимаемые действия могут оказаться попытками автоматизации хаоса.
Также одна из важных задач в работе архитектора — формирование «опасений» (Architectural Concerns) касательно будущей либо существующей архитектуры, участие в коммуникации с клиентом и выявления соответствия клиентских ожиданий с реальными бизнес-потребностями и бизнес-моделью компании.
Например, на моей практике бывало так, что у представителей заказчика были завышенные ожидания качества системы, никак не подкреплённые потребностями бизнеса. Любое улучшение одной или нескольких характеристик качества связано с необходимостью инвестировать силы и время в дополнительную разработку, более дорогую инфраструктуру и поддержку системы. Также улучшение одной характеристики качества системы может негативно повлиять на другие.
Приведу пример из своей архитектурной практики: как-то заказчик прислал запрос на предложение с подробной спецификацией, больше похожей на техническое задание. Однако в ходе ответов клиента на мои вопросы оказалось, что архитектурные решения, указанные в спецификации, не соответствуют реальным потребностям бизнеса. Уже после пресейла при общении с заказчиком выяснилось, что ее прислал другой вендор в ответ на запрос предложения, а они особо не стали вчитываться и отправили нам в надежде на то, что эти подробности помогут точнее оценить трудозатраты.
Избежать подобных вещей поможет детальное изучение бизнес-контекста.
Теодор Левит
Выяснение бизнес-контекста — один из первых этапов, необходимых для разработки правильной архитектуры ІТ-решения.
На данном этапе главная цель для нас — подробный анализ бизнеса клиента. Сюда входит детальное изучение бизнес-модели, цепочек создания ценностей и добавленной стоимости для заказчика, клиентов компании, того, почему они покупают продукты и/или услуги, от каких поставщиков и партнёров зависит успех компании, а также архитектура существующих ІТ-решений и основные требования бизнеса к ним. Полученная информация станет определяющей для успешности дальнейшей работы архитектора и команды разработчиков.
Уже на этом этапе мы должны дать заказчику информацию о потенциальной прибыли от предлагаемого решения, индикативную оценку полной стоимости владения решением и обозначить период возврата инвестиций.
Пример, как мы можем произвести маппинг между ценностями для заказчика и приоритетными качествами системы через ключевые показатели эффективности, ориентированные на результат для бизнеса
Стоит также отметить один из подходов к разработке, помогающий дать решение, которое бы максимально отвечало бизнес-модели заказчика — Domain-driven Design (DDD).
При этом подходе важно сформировать общий глоссарий между бизнесом и командой разработчиков, определяющий ключевые понятия и требования, описывающий сущности и значения. Следование правилам DDD существенно упрощает процесс разработки, внесение корректировок, коммуникацию как внутри команды разработки, так и с клиентом. В больших компаниях это также может помочь в коммуникации между разными подразделениями бизнеса. По моему опыту, в разных подразделениях одной компании могут давать различные определения одному термину. Поэтому важно их согласовать со всеми вовлечёнными сторонами.
Как же нам получить эти необходимые вводные данные о бизнесе заказчика? Помимо изучения предоставленной документации и проведения интервью с представителями клиента, эффективным инструментов являются воркшопы. В рамках таких активностей есть возможность послушать точки зрения различных представителей заказчика, найти консенсус или же сразу принять решение.
Воркшоп с участием ІТ-департамента и представителей других отделов. Dilbert comic strip, Scott Adams
Часто воркшопы оказываются даже более полезны, чем интервью. Во многом, конечно, их успех будет зависеть от опыта и навыков того, кто их проводит: если воркшоп прошел не эффективно, то, вероятно, его подготовили или провели не на должном уровне. Например, свой первый воркшоп я завалил. У меня не было достаточной уверенности, а люди из бизнеса на руководящих позициях хорошо это видят, поэтому отказались принимать участие в нем. Следующие несколько мероприятий я провёл как помощник более опытных на тот момент коллег-архитекторов — набрался опыта и уверенности. После этого воркшопы стали проходить успешней и стали для меня эффективным инструментом работы.
Понимая бизнес-контекст, мы можем делать обоснованные суждения о приоритетах каждого атрибута системы, основываясь на фактах и данных.
how well the system satisfies the needs of its stakeholders.
SEI Software Architecture in Practice
Важно понимать, что система не может быть идеальной и абсолютной, поэтому при работе над атрибутами и их достижением необходимо учитывать приоритет и влияние на бизнес заказчика.
Улучшая один из атрибутов качества, как минимум мы вносим новые затраты, как максимум — негативно влияем на другие атрибуты качества. Например, увеличение скорости работы системы может потребовать кэширования данных. А для этого нужно написать код, поддерживающий инфраструктуру, которая отвечает за хранение кэшированных данных. Или же наоборот, то, что нам понадобилось усилить безопасность, добавив шифрование, может негативно сказаться на быстродействии.
Очевидно, что для банка во главе угла будет стоять безопасность, а для трейдинговой фирмы — скорость работы платформы. И если приоритеты расставить неверно, то в итоге мы получим решение, которое в лучшем случае не будет соответствовать потребностям клиента, в худшем — оставит его без прибыли.
Взаимосвязь атрибутов наглядно демонстрирует матрица взаимодействия от IASA:
Данная матрица не является завершённой, ее финальное наполнение будет зависеть от специфики решения
Поэтому, чтобы архитектура максимально соответствовала бизнес-модели компании, важно учитывать приоритеты. Каждое требования к качеству должно соответствовать реальной бизнес-задаче.
Приведу пример из жизни. Требование заказчика — время отклика системы не должно превышать 0,5 сек. Такая «хотелка» обошлась клиенту в кругленькую сумму, однако, как оказалось, конкретно для его бизнеса ценности она не несет — конечный пользователь системы просто не видел разницу, скорость не играла никакой роли для бизнеса. Деньги были потрачены зря. И обратная история: клиент хотел время отклика не более 0,6 сек. Проект был успешно реализован, отклик — 0,5 сек. Успех? Вовсе нет, компания потерпела неудачу на рынке, время отклика должно было составлять не 0,6 сек, а «быстрее, чем у конкурентов», у которых на момент выхода системы на рынок время отклика было уже меньше 0,4 сек.
Также следует помнить, что зачастую мы начинаем работу не с чистого листа, а с рядом технических ограничений, продиктованных решениями, которые кто-то уже принял и внедрил до нас. Например, у заказчика уже есть готовая система, элементы из которой он хочет повторно использовать в нашем проекте; уже куплен набор лицензий и так далее. Такие ограничения должны быть учтены во время расстановки приоритетов. Это не фокус нашей статьи, однако я решил упомянуть фактор ограничений, поскольку он будет влиять на будущую архитектуру.
Собрав все данные и расставив приоритеты качеств, мы можем переходить к выбору оптимальной архитектуры.
Подход к поиску оптимальной архитектуры согласно АТАМ
Наиболее распространенные подходы к дизайну и оценке архитектуры:
Attribute-driven Design (ADD). Согласно этому методу, решение о выборе архитектуры основывается на собранных атрибутах. Ранее ADD не всегда учитывал остаточные риски, связанные с применением тех или иных подходов, но последние версии ADD лишены данного недостатка. Цель ADD — получить максимальное качество при минимальных затратах.
Architecture Tradeoff Analysis Method (ATAM). Он сфокусирован на анализе архитектурных компромиссов и остаточных рисков. Если не вдаваться в подробности, цель ATAM — проверка правильности принятых решений. Мы принимаем решения для того, чтобы адресовать наши ключевые качества. Они начинаются с самых верхнеуровневых, например, выбора стиля: Layered, Monolith, Microservices и так далее. И двигаются в сторону паттернов и тактик. При помощи ATAM можно проверить, насколько каждое решение помогает в достижении нашей цели, а также какие риски оно несет и какое негативное влияние может оказать на другие качества.
Возьмем уже приведенный пример с безопасностью и скоростью работы. Добавляя шифрование, мы снижаем быстродействие. Архитектурным компромиссом (architecture tradeoff) в нашем случае может быть скорость. Если для нашего проекта она не имеет ключевого приоритета и добавление шифрования оставляет ее в заданных рамках, то такое уменьшение быстродействия приемлемо и не является риском.
Двигаясь путем анализа архитектурных компромиссов, мы выйдем на минимальные остаточные риски. Конечно, в реальности все может оказаться гораздо сложнее. Поэтому важно комплексно подойти к проверке выбора архитектуры, чтобы минимизировать риски её неправильного выбора и/или применения.
Quality Attribute Workshops (QAWs). Эта активность рекомендуется SEI (Software Engineering Institute) для сбора и приоритизации архитектурно значимых требований, которые можно использовать в качестве критериев проверки оптимальности решения и проведения приоритизации атрибутов качества. До этого этапа важно хорошо разобраться с бизнес-моделью, понимать основные драйверы бизнеса клиента. Упражнение помогает собрать требования заказчика через quality-атрибуты и идентифицировать ключевые из них.
ATAM. Я уже упоминал об этом подходе в блоке о выборе архитектуры. Если, используя ADD, мы принимаем решения, исходя из атрибутов, то метод ATAM дает возможность проверить соответствие принятых решений бизнес-целям и бизнес-драйверам заказчика, проанализировать возможные риски.
Приведу пример таблицы, основанной на ATAM, для самопроверки:
Пример применения ATAM для анализа архитектурных решений. Такая таблица служит скорее для внутреннего пользования. Клиенту результаты нужно предоставлять в более дружественном для нетехнических людей виде
Описание определений:
Sensitivity — основной компонент или тактика, которыми мы достигаем архитектурно значимого требования.
Tradeoff — архитектурный компромисс, например, когда мы улучшаем более приоритетное качество системы за счёт менее приоритетного (вспоминаем пример с безопасностью и скоростью).
Risk — риски, связанные с решением компонентом или тактикой, например, что мы не достигнем целевых значений для качества, которое пытаемся адресовать, или повлияем на другие качества так, что по ним будет риск невыполнения критериев успешности.
Non-risk — хорошее принятое решение, которое позитивно влияет на достижения качества системы согласно бизнес-задачам.
Пояснение к значениям в таблице:
S1 — Microservices architecture positively affects changeability and scalability, it’s positive for Time to Market.
S2 — SQL database will guaranty transactions consistency to address financial transaction consistency required.
S3 — On-premises deployment will reduce operational costs of solution using existing data center.
T1 — Introduce initial costs for deployment. In the short term it will slightly increase costs by necessity of buying licenses and spin-up infrastructure, but in the long run it would decrease cost in comparison with constant billings for cloud services.
R1 — Risk of performance and throughput issues.
R2 — Central SQL database can be a single point of failure, performance issues due to locks and amount of data.
R3 — No uptime guarantee, availability at risk.
QA-1, QA-2 and QA-5 impacted negatively — residual risks.
QA-4 and QA-6 haven’t addressed yet.
Вывод, который можно сделать из данной таблицы: решение номер 2 (Central SQL Database) следует пересмотреть. Также необходимо принять больше решений, чтобы закрыть остаточные риски (R1 и R3), и адресовать те качества, которые здесь не адресованы.
Важно отметить, что этот пример верный только для контекста задачи, к которой он применялся и детали которой мы не рассматриваем. В случае другого контекста и/или бизнес-модели пример может быть не актуален. Если мы имеем дело с банком, где важно централизованно управлять финансовыми операциями, микросервисы могу оказаться не лучшим выбором архитектурного стиля.
Прототипирование (Proof of Concept). Это более предметная и «жизненная» практика. Предположим, у нас есть набор технологий, однако ранее мы не сталкивались с ним в реальной жизни, похожих кейсов также нет. В таком случае необходимо прибегнуть к разработке прототипа системы или ключевых её компонентов. Особое внимание стоит обратить на ее интеграцию с другими системами. Чем раньше вы протестируете свое решение на прототипе, тем проще внести изменения по его результатам.
Архитектурная оценка. Данный инструмент используют в основном большие заказчики, поскольку такая услуга может стоить дорого. Зачастую используется во время сравнения клиентом предложений от различных вендоров. Для оценки привлекается независимый подрядчик (одним из пионеров в этой области были уже упомянутые SEI), который также ориентируется на соответствие технического решения потребностям бизнеса компании, проводит воркшопы, привлекает к работе архитекторов из компаний-вендоров.
При этом «пробелы» в предложениях вендоров могут искать при помощи подхода ATAM, а результатом такого ассесмента, как правило, является набор рекомендаций касательно существующих и предлагаемых решений: технические недостатки и преимущества, финансовые аспекты той или иной опции, «дорожная карта» для рекомендуемой опции.
При этом максимально эффективное решение — это решение, когда IT-архитектура удовлетворяет не только требования заказчика, но и реальные потребности его бизнеса, учитывает бизнес-модель как в краткосрочной, так и в долгосрочной перспективе. Таким образом, ІТ-специалистам важно понимать принципы работы и устройства бизнеса, чтобы быть успешными. Точно также это работает и в обратную сторону — представителям компаний-заказчиков важно прокачивать свои технические навыки хотя бы на уровне общего понимания, поскольку именно взаимопонимание и слаженная работа обеих сторон поможет достичь максимальных результатов.
Список источников для ознакомления:
dou.ua
За эти годы я успел поработать со многими проектами. Какие-то из них были более успешны, какие-то менее. Обычно в процессе разбора неудач выяснялось, что одной из основных причин была проблема коммуникации между разработчиками и клиентом. Часто мы либо не понимали, что нужно заказчику, либо же не могли внятно донести ему необходимость и полезность того или иного технического решения. Итогом такого недопонимания становились продукты, которые, будучи замечательными с технической стороны, не отвечали потребностям и бизнес-модели клиента.
Я надеюсь, что данная статья поможет читателям не наступить на те же грабли, и даст понимание того, почему для создания хорошей архитектуры необходимо максимально проникнуться принципами работы компании клиента и её бизнес-потребностями.
Сразу оговорюсь, что материал описывает лишь ключевые этапы на пути выбора дизайна архитектуры. И не дает развернутое и пошаговое руководство, так как каждый из перечисленных ниже шагов заслуживает как минимум отдельного материала.
Почему проекты фейлятся
Использование Waterfall — один из самых распространённых мифов о причинах провала проекта. Когда мы берем большую итерацию, набираем огромное количество требований и долго не синхронизируемся с заказчиком и его бизнесом, сложно говорить о нормальном взаимодействии и адекватной обратной связи. С одной стороны, у нас не будет представления об актуальных требованиях и потребностях бизнеса клиента. С другой — заказчик просто не будет понимать, над чем же мы работаем. Поэтому определенная доля правды в мифе о вредности Waterfall есть.Однако было бы неправильно винить во всех неудачах только модель процесса разработки. Мы можем использовать популярный и эффективный Agile, но без нормальной коммуникации с клиентом, без понимания специфики его бизнеса этот подход сам по себе не гарантирует успех.
Только эффективное общение поможет понять важные аспекты для разработки удачного решения, и один из них — бизнес-модель клиента.
Ранее цифровые решения в большинстве случаев служили дополнением к существующим бизнес-моделям компаний, занимая лишь несколько строчек в данной канве. Однако сегодня для большого числа компаний в мире ІТ-решения становятся если не основой бизнеса, то одним из жизненно необходимых компонентов. А для кого-то и вовсе единственным инструментом для получения прибыли. Роль ІТ-специалистов и ІТ-решений для полноценной работы компаний растет, а вместе с этим увеличивается и уровень ответственности.
В то же время в конце 90-х и начале нулевых разработчики не всегда задумывались о сборе информации от заказчика. Считалось, что клиент сам должен собирать и формировать требования, спуская готовую документацию командам разработчиков. Естественно, такое положение дел приводило к ряду недопониманий и разногласий, а готовый продукт, кажущийся разработчикам вершиной инженерной мысли, мог не соответствовать потребностям и бизнес-модели клиента.
Со временем Scrum и другие Agile-подходы своим появлением привнесли новшества в эти взаимоотношения, дали понимание того, что с клиентом можно и нужно разговаривать. Появилась роль Product Owner, изменился подход к самой документации.
Отсутствие знаний о том, как работает бизнес заказчика и какое влияние на работу бизнеса оказывают качества системы, может привести к ряду последствий. Начиная на первый взгляд с безобидных — таких, как быстродействие системы или вероятность отказа при пиковой нагрузке на неё, до глобальных и сулящих бизнесу колоссальные потери. Вспомните обход защиты в PlayStation Network в 2011 году.
Бизнес-модель компании как основа для разработки
Необязательно быть «серийным предпринимателем», чтобы понимать базовые принципы работы бизнеса и его бизнес-модель. Прежде всего, это комплекс факторов, совокупность которых помогает компании привлекать клиентов и за счёт предоставления им товаров и/или услуг зарабатывать деньги.Сюда входят: потребители (клиенты), продукт, каналы сбыта, взаимоотношения с задействованными в бизнесе сторонами, финансовые потоки, структура доходов и расходов, ресурсы. Для иллюстрации бизнес-модели может применяться знакомый многим инструмент Business Model Canvas.
Во избежание проблем, связанных с коммуникацией и недопониманием, во многих компаниях работают команды специалистов, среди которых не последнюю роль играют ІТ-архитекторы.
Роль IT-архитектора в понимании бизнес-модели заказчика
IT architecture is the art and science of designing and delivering valuable technology strategy.International Association for All IT Architects
IT-архитектору, чтобы построить свое решение, важно понимать, как работает бизнес клиента, каков контекст, с которым будет работать система, и как данная система будет решать задачи бизнеса. Без этих знаний архитектор, вероятно, не сможет быть эффективен — все предпринимаемые действия могут оказаться попытками автоматизации хаоса.
Также одна из важных задач в работе архитектора — формирование «опасений» (Architectural Concerns) касательно будущей либо существующей архитектуры, участие в коммуникации с клиентом и выявления соответствия клиентских ожиданий с реальными бизнес-потребностями и бизнес-моделью компании.
Например, на моей практике бывало так, что у представителей заказчика были завышенные ожидания качества системы, никак не подкреплённые потребностями бизнеса. Любое улучшение одной или нескольких характеристик качества связано с необходимостью инвестировать силы и время в дополнительную разработку, более дорогую инфраструктуру и поддержку системы. Также улучшение одной характеристики качества системы может негативно повлиять на другие.
Приведу пример из своей архитектурной практики: как-то заказчик прислал запрос на предложение с подробной спецификацией, больше похожей на техническое задание. Однако в ходе ответов клиента на мои вопросы оказалось, что архитектурные решения, указанные в спецификации, не соответствуют реальным потребностям бизнеса. Уже после пресейла при общении с заказчиком выяснилось, что ее прислал другой вендор в ответ на запрос предложения, а они особо не стали вчитываться и отправили нам в надежде на то, что эти подробности помогут точнее оценить трудозатраты.
Избежать подобных вещей поможет детальное изучение бизнес-контекста.
Выяснение бизнес-контекста
Предназначение бизнеса состоит в привлечении (новых) и сохранение (существующих) клиентов. Без клиентов никакое инженерное волшебство, умное финансирования или опыт работы не помогут удержать компанию на плаву.Теодор Левит
Выяснение бизнес-контекста — один из первых этапов, необходимых для разработки правильной архитектуры ІТ-решения.
На данном этапе главная цель для нас — подробный анализ бизнеса клиента. Сюда входит детальное изучение бизнес-модели, цепочек создания ценностей и добавленной стоимости для заказчика, клиентов компании, того, почему они покупают продукты и/или услуги, от каких поставщиков и партнёров зависит успех компании, а также архитектура существующих ІТ-решений и основные требования бизнеса к ним. Полученная информация станет определяющей для успешности дальнейшей работы архитектора и команды разработчиков.
Уже на этом этапе мы должны дать заказчику информацию о потенциальной прибыли от предлагаемого решения, индикативную оценку полной стоимости владения решением и обозначить период возврата инвестиций.
Стоит также отметить один из подходов к разработке, помогающий дать решение, которое бы максимально отвечало бизнес-модели заказчика — Domain-driven Design (DDD).
При этом подходе важно сформировать общий глоссарий между бизнесом и командой разработчиков, определяющий ключевые понятия и требования, описывающий сущности и значения. Следование правилам DDD существенно упрощает процесс разработки, внесение корректировок, коммуникацию как внутри команды разработки, так и с клиентом. В больших компаниях это также может помочь в коммуникации между разными подразделениями бизнеса. По моему опыту, в разных подразделениях одной компании могут давать различные определения одному термину. Поэтому важно их согласовать со всеми вовлечёнными сторонами.
Как же нам получить эти необходимые вводные данные о бизнесе заказчика? Помимо изучения предоставленной документации и проведения интервью с представителями клиента, эффективным инструментов являются воркшопы. В рамках таких активностей есть возможность послушать точки зрения различных представителей заказчика, найти консенсус или же сразу принять решение.
Часто воркшопы оказываются даже более полезны, чем интервью. Во многом, конечно, их успех будет зависеть от опыта и навыков того, кто их проводит: если воркшоп прошел не эффективно, то, вероятно, его подготовили или провели не на должном уровне. Например, свой первый воркшоп я завалил. У меня не было достаточной уверенности, а люди из бизнеса на руководящих позициях хорошо это видят, поэтому отказались принимать участие в нем. Следующие несколько мероприятий я провёл как помощник более опытных на тот момент коллег-архитекторов — набрался опыта и уверенности. После этого воркшопы стали проходить успешней и стали для меня эффективным инструментом работы.
Понимая бизнес-контекст, мы можем делать обоснованные суждения о приоритетах каждого атрибута системы, основываясь на фактах и данных.
Приоритеты и взаимовлияние атрибутов качества системы
A quality attribute (QA) is a measurable or testable property of a system that is used to indicatehow well the system satisfies the needs of its stakeholders.
SEI Software Architecture in Practice
Важно понимать, что система не может быть идеальной и абсолютной, поэтому при работе над атрибутами и их достижением необходимо учитывать приоритет и влияние на бизнес заказчика.
Улучшая один из атрибутов качества, как минимум мы вносим новые затраты, как максимум — негативно влияем на другие атрибуты качества. Например, увеличение скорости работы системы может потребовать кэширования данных. А для этого нужно написать код, поддерживающий инфраструктуру, которая отвечает за хранение кэшированных данных. Или же наоборот, то, что нам понадобилось усилить безопасность, добавив шифрование, может негативно сказаться на быстродействии.
Очевидно, что для банка во главе угла будет стоять безопасность, а для трейдинговой фирмы — скорость работы платформы. И если приоритеты расставить неверно, то в итоге мы получим решение, которое в лучшем случае не будет соответствовать потребностям клиента, в худшем — оставит его без прибыли.
Взаимосвязь атрибутов наглядно демонстрирует матрица взаимодействия от IASA:
Поэтому, чтобы архитектура максимально соответствовала бизнес-модели компании, важно учитывать приоритеты. Каждое требования к качеству должно соответствовать реальной бизнес-задаче.
Приведу пример из жизни. Требование заказчика — время отклика системы не должно превышать 0,5 сек. Такая «хотелка» обошлась клиенту в кругленькую сумму, однако, как оказалось, конкретно для его бизнеса ценности она не несет — конечный пользователь системы просто не видел разницу, скорость не играла никакой роли для бизнеса. Деньги были потрачены зря. И обратная история: клиент хотел время отклика не более 0,6 сек. Проект был успешно реализован, отклик — 0,5 сек. Успех? Вовсе нет, компания потерпела неудачу на рынке, время отклика должно было составлять не 0,6 сек, а «быстрее, чем у конкурентов», у которых на момент выхода системы на рынок время отклика было уже меньше 0,4 сек.
Также следует помнить, что зачастую мы начинаем работу не с чистого листа, а с рядом технических ограничений, продиктованных решениями, которые кто-то уже принял и внедрил до нас. Например, у заказчика уже есть готовая система, элементы из которой он хочет повторно использовать в нашем проекте; уже куплен набор лицензий и так далее. Такие ограничения должны быть учтены во время расстановки приоритетов. Это не фокус нашей статьи, однако я решил упомянуть фактор ограничений, поскольку он будет влиять на будущую архитектуру.
Собрав все данные и расставив приоритеты качеств, мы можем переходить к выбору оптимальной архитектуры.
Поиск оптимальной архитектуры
Когда требования заказчика собраны и согласованы, приоритеты атрибутов расставлены, мы можем приступать к разработке архитектуры. Здесь нет никакой «серебряной пули»: каждый проект уникален, имеет свой ряд особых требований, поэтому нет и рецепта универсальной архитектуры, даже в рамках одной предметной области.
Наиболее распространенные подходы к дизайну и оценке архитектуры:
Attribute-driven Design (ADD). Согласно этому методу, решение о выборе архитектуры основывается на собранных атрибутах. Ранее ADD не всегда учитывал остаточные риски, связанные с применением тех или иных подходов, но последние версии ADD лишены данного недостатка. Цель ADD — получить максимальное качество при минимальных затратах.
Architecture Tradeoff Analysis Method (ATAM). Он сфокусирован на анализе архитектурных компромиссов и остаточных рисков. Если не вдаваться в подробности, цель ATAM — проверка правильности принятых решений. Мы принимаем решения для того, чтобы адресовать наши ключевые качества. Они начинаются с самых верхнеуровневых, например, выбора стиля: Layered, Monolith, Microservices и так далее. И двигаются в сторону паттернов и тактик. При помощи ATAM можно проверить, насколько каждое решение помогает в достижении нашей цели, а также какие риски оно несет и какое негативное влияние может оказать на другие качества.
Возьмем уже приведенный пример с безопасностью и скоростью работы. Добавляя шифрование, мы снижаем быстродействие. Архитектурным компромиссом (architecture tradeoff) в нашем случае может быть скорость. Если для нашего проекта она не имеет ключевого приоритета и добавление шифрования оставляет ее в заданных рамках, то такое уменьшение быстродействия приемлемо и не является риском.
Двигаясь путем анализа архитектурных компромиссов, мы выйдем на минимальные остаточные риски. Конечно, в реальности все может оказаться гораздо сложнее. Поэтому важно комплексно подойти к проверке выбора архитектуры, чтобы минимизировать риски её неправильного выбора и/или применения.
Проверяем выбор архитектуры. Лучшие практики
Представим, что мы выбрали архитектуру, которая, как нам кажется, соответствует бизнес-модели заказчика. Теперь важно убедиться в правильности своего выбора. Для этого существует ряд подходов, которые уже зарекомендовали себя на рынке.Quality Attribute Workshops (QAWs). Эта активность рекомендуется SEI (Software Engineering Institute) для сбора и приоритизации архитектурно значимых требований, которые можно использовать в качестве критериев проверки оптимальности решения и проведения приоритизации атрибутов качества. До этого этапа важно хорошо разобраться с бизнес-моделью, понимать основные драйверы бизнеса клиента. Упражнение помогает собрать требования заказчика через quality-атрибуты и идентифицировать ключевые из них.
ATAM. Я уже упоминал об этом подходе в блоке о выборе архитектуры. Если, используя ADD, мы принимаем решения, исходя из атрибутов, то метод ATAM дает возможность проверить соответствие принятых решений бизнес-целям и бизнес-драйверам заказчика, проанализировать возможные риски.
Приведу пример таблицы, основанной на ATAM, для самопроверки:
Описание определений:
Sensitivity — основной компонент или тактика, которыми мы достигаем архитектурно значимого требования.
Tradeoff — архитектурный компромисс, например, когда мы улучшаем более приоритетное качество системы за счёт менее приоритетного (вспоминаем пример с безопасностью и скоростью).
Risk — риски, связанные с решением компонентом или тактикой, например, что мы не достигнем целевых значений для качества, которое пытаемся адресовать, или повлияем на другие качества так, что по ним будет риск невыполнения критериев успешности.
Non-risk — хорошее принятое решение, которое позитивно влияет на достижения качества системы согласно бизнес-задачам.
Пояснение к значениям в таблице:
S1 — Microservices architecture positively affects changeability and scalability, it’s positive for Time to Market.
S2 — SQL database will guaranty transactions consistency to address financial transaction consistency required.
S3 — On-premises deployment will reduce operational costs of solution using existing data center.
T1 — Introduce initial costs for deployment. In the short term it will slightly increase costs by necessity of buying licenses and spin-up infrastructure, but in the long run it would decrease cost in comparison with constant billings for cloud services.
R1 — Risk of performance and throughput issues.
R2 — Central SQL database can be a single point of failure, performance issues due to locks and amount of data.
R3 — No uptime guarantee, availability at risk.
QA-1, QA-2 and QA-5 impacted negatively — residual risks.
QA-4 and QA-6 haven’t addressed yet.
Вывод, который можно сделать из данной таблицы: решение номер 2 (Central SQL Database) следует пересмотреть. Также необходимо принять больше решений, чтобы закрыть остаточные риски (R1 и R3), и адресовать те качества, которые здесь не адресованы.
Важно отметить, что этот пример верный только для контекста задачи, к которой он применялся и детали которой мы не рассматриваем. В случае другого контекста и/или бизнес-модели пример может быть не актуален. Если мы имеем дело с банком, где важно централизованно управлять финансовыми операциями, микросервисы могу оказаться не лучшим выбором архитектурного стиля.
Прототипирование (Proof of Concept). Это более предметная и «жизненная» практика. Предположим, у нас есть набор технологий, однако ранее мы не сталкивались с ним в реальной жизни, похожих кейсов также нет. В таком случае необходимо прибегнуть к разработке прототипа системы или ключевых её компонентов. Особое внимание стоит обратить на ее интеграцию с другими системами. Чем раньше вы протестируете свое решение на прототипе, тем проще внести изменения по его результатам.
Архитектурная оценка. Данный инструмент используют в основном большие заказчики, поскольку такая услуга может стоить дорого. Зачастую используется во время сравнения клиентом предложений от различных вендоров. Для оценки привлекается независимый подрядчик (одним из пионеров в этой области были уже упомянутые SEI), который также ориентируется на соответствие технического решения потребностям бизнеса компании, проводит воркшопы, привлекает к работе архитекторов из компаний-вендоров.
При этом «пробелы» в предложениях вендоров могут искать при помощи подхода ATAM, а результатом такого ассесмента, как правило, является набор рекомендаций касательно существующих и предлагаемых решений: технические недостатки и преимущества, финансовые аспекты той или иной опции, «дорожная карта» для рекомендуемой опции.
Выводы
В современных условиях мы все меньше можем говорить об ІТ как о какой-то отдельной структуре или сервисе. Вместе со стремительным развитием технологий цифровые решения становятся важной (а иногда неотъемлемой) частью современного бизнеса, продолжая или же дополняя его бизнес-модель. Поэтому успешность современных компаний часто зависит от того, насколько архитектура ІТ-систем учитывает это.При этом максимально эффективное решение — это решение, когда IT-архитектура удовлетворяет не только требования заказчика, но и реальные потребности его бизнеса, учитывает бизнес-модель как в краткосрочной, так и в долгосрочной перспективе. Таким образом, ІТ-специалистам важно понимать принципы работы и устройства бизнеса, чтобы быть успешными. Точно также это работает и в обратную сторону — представителям компаний-заказчиков важно прокачивать свои технические навыки хотя бы на уровне общего понимания, поскольку именно взаимопонимание и слаженная работа обеих сторон поможет достичь максимальных результатов.
Список источников для ознакомления:
- Software Architecture in Practice от SEI, третье издание.
- Software Architecture Patterns, автор Mark Richards.
- Documenting Software Architectures Views and Beyond от SEI, второе издание.
- Patterns for Fault Tolerant Software, авторы Hanmer, Robert S.
- О паттернах от Microsoft.
- Паттерны от martinfowler.com: CQRS, CircuitBreaker, BlueGreenDeployment.
- Каталог из 65 интеграционных паттернов.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua