Всем привет!
Читая очередную книгу по архитектуре ПО, я в который раз столкнулся с новым определением того, что же это такое. И всё бы ничего — я уже как будто привык к этому, но буквально те же самые авторы давали совсем другое определение в предыдущей книге!
— Да сколько можно! — подумал я. И тут во мне проснулось любопытство: а сколько вообще таких определений от разных авторов? Есть ли какое-то общепризнанное мнение?
Как оказалось, нет — разные авторы, фреймворки и спецификации дают разные определения. SEI (Software Engineering Institute) даже составил документ около 10 лет назад со списком разных определений. Но в рамках исследования для этой статьи я понял, что и он неполный.
При этом анализируя разные определения, я заметил закономерности. Поэтому в данной статье я постараюсь не просто привести список определений, но также сгруппировать и проанализировать их. В конце статьи я оставлю ссылки на ресурсы, чтобы любой желающий мог сам ознакомиться с источниками.
Структурируем определения
В процессе анализа я смог выделить 3 группы:
Архитектура как структура системы
Архитектура как перспектива принятия решений
Архитектура как мультиперспектива
Подробнее про каждую из них ниже.
Группа 1: Архитектура как структура системы
Эта группа определений исторически первая и характеризуется тем, что описывает архитектуру системы как набор структур и их взаимодействий.
Начнем, пожалуй, с определения из самой известной книги по архитектуре ПО. Определение из Википедии также повторяет его.
Архитектура программного обеспечения на практике (4е издание), Лен Басс:
Архитектура программного обеспечения системы — это набор структур, необходимых для рассуждения о системе. Эти структуры включают программные элементы, связи между ними и свойства тех и других.
Оригинальная цитата:
The software architecture of a system is the set of structures needed to reason about the system. These structures comprise software elements, relations among them, and properties of both.
И далее автор даёт отличное объяснение этому определению:
Это определение противоречит другим определениям, в которых говорится о "ранних", "основных" или "важных" решениях системы. Хотя это правда, что многие архитектурные решения принимаются на ранних этапах, это происходит не всегда — особенно в Agile и проектах со спиральной разработкой. Верно и то, что многие решения, принятые на ранних этапах, не являются тем, что мы считаем архитектурным. Кроме того, трудно взглянуть на решение и сказать, является ли оно "основным". Иногда это покажет только время. А поскольку выбор архитектуры является одной из важнейших обязанностей архитектора, нам необходимо знать, из каких решений состоит архитектура.
Структуры, напротив, довольно легко идентифицировать в программном обеспечении, и они образуют мощный инструмент для проектирования и анализа систем.
Итак, вот мы и пришли к тому что: Архитектура — это структуры, позволяющие рассуждать.
Основной принцип архитектуры программного обеспечения заключается в том, что каждая программная система создается для удовлетворения бизнес-целей организации, и что архитектура системы — это мост между этими (часто абстрактными) бизнес-целями и конечной (конкретной) результирующей системой.
Оригинальная цитата:
This definition stands in contrast to other definitions that talk about the system’s “early” or “major” or “important” decisions. While it is true that many architectural decisions are made early, not all are—especially in Agile and spiral-development projects. It’s also true that many decisions that are made early are not what we would consider architectural. Also, it’s hard to look at a decision and tell whether it’s “major.” Sometimes only time will tell. And since deciding on an architecture is one of the architect’s most important obligations, we need to know which decisions an architecture comprises.
Structures, by contrast, are fairly easy to identify in software, and they form a powerful tool for system design and analysis.
So, there we are: Architecture is about reasoning-enabling structures.
The basic principle of software architecture is every software system is constructed to satisfy an organization’s business goals, and that the architecture of a system is a bridge between those (often abstract) business goals and the final (concrete) resulting system.
Ещё несколько популярных определений:
Спецификация ISO/IEC/IEEE 42010:2022, Software, systems and enterprise — Architecture description
Фундаментальные концепции или свойства сущности в её окружении и руководящие принципы реализации и эволюции этой сущности и связанных с ней процессов жизненного цикла.
Оригинальная цитата:
Fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes
Garlan and Perry (одни из пионеров определения архитектуры ПО, 1995):
Структура компонентов системы, их взаимосвязей, принципов и гайдлайнов, управляющих (governing) их проектированием и эволюцией во времени.
Оригинальная цитата:
The structure of the components of a system, their interrelationships, and principles and guidelines governing their design and evolution over time.
The Open Group для своего TOGAF использует 2 определения, одно из которых является устаревшей версией ISO, а другое — определением от Garlan и Perry:
1. Фундаментальные концепции или свойства системы в её окружении, воплощенные в её элементах, взаимосвязях и принципах её проектирования и эволюции. (Источник: ISO/IEC/IEEE 42010: 2011) 2. Структура компонентов, их взаимосвязи, а также принципы и руководящие указания, управляющие их проектированием и развитием во времени.
Оригинальная цитата:
1. The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (Source: ISO/IEC/IEEE 42010: 2011) 2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
Довольно похожее по смыслу определение даёт и Боб Мартин в своей «Чистой Архитектуре»:
Архитектура программной системы — это форма, которая придается системе ее создателями. Эта форма выражается в разделении системы на компоненты, в расположении этих компонентов и в способах взаимодействия этих компонентов друг с другом.
Оригинальная цитата:
The architecture of a software system is the shape given to that system by those who build it. The form of that shape is in the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other.
Группа 2: Архитектура как решения
Данная группа определений характеризуется тем, что описывает архитектуру системы как набор важных решений, которые (чаще всего) сложно или дорого поменять позднее. Она стала популярнее в 2000-х, что можно связать с приходом Agile-разработки.
Одним из первых и самых известных популяризаторов был Мартин Фаулер (цитируя Ральфа Джонсона) с весьма расплывчатым определением:
Архитектура — это про важное. Что бы это ни было.
Оригинальная цитата:
Architecture is about the important stuff. Whatever that is.
Грейди Буч высказывается чуть более конкретно:
Архитектура представляет собой значимые проектные решения, которые придают форму и функцию системы, где значимость измеряется стоимостью изменений.
Оригинальная цитата:
Architecture represents the significant design decisions that shape the form and function of a system, where significant is measured by the cost of change.
Дезмонд Ф. Д'Суза и Алан Кэмерона Уиллс предлагают немного другую перспективу (из книги Objects, Components, and Frameworks with UML: The Catalysis Approach):
Набор проектных решений о любой системе, который удерживает её разработчиков и сопровождающих(maintainers) от проявления ненужной креативности.
Оригинальная цитата:
The set of design decisions about any system that keeps its implementors and maintainers from exercising needless creativity.
Отдельно стоит выделить определение от Gregor Hohpe из его книги The Software Architect Elevator. Несмотря на то, что он ссылается на разные определения разных авторов, он даёт ещё одно интересное определение, переводя архитектуру на язык бизнеса и финансов:
Архитектура — это продажа опционов.
Оригинальная цитата:
Architecture is selling options.
Этому посвящена целая глава в его книге, где он довольно логично объясняет, почему это очень похожие механизмы. Небольшой отрывок из книги для большего понимания:
Все, что вам нужно сделать, — это спроектировать систему таким образом, чтобы она откладывала решения.
Вы добиваетесь этого, предоставляя опционы (возможности выбора), которыми можно воспользоваться в будущем.
Классический пример — определение размера сервера: перед развертыванием приложения традиционные ИТ-команды проводили длительное исследование, чтобы рассчитать количество оборудования, необходимого для запуска приложения.
...
Для этого примера опцион, который создает архитектор, — это горизонтальное масштабирование, позволяющее добавлять или убавлять вычислительные ресурсы позже. Очевидно, что этот опцион имеет ценность: инфраструктура может быть подобрана в соответствии с реальными потребностями приложения и может расти (или уменьшаться) по мере необходимости. Кроме того, этот опцион не бесплатен, учитывая, что система должна быть спроектирована с возможностью масштабирования; например, путем создания компонентов приложения без сохранения состояния (stateless) или использования распределенной базы данных.
Оригинальная цитата:
All you need to do is design your system such that it defers decisions. You accomplish that by providing options that can be exercised in the future. A classic example is server sizing: before deploying an application, traditional IT teams would conduct a lengthy sizing study to calculate the amount of hardware required to run the application.
...
For this example, the option the architect creates is horizontal scaling, allowing compute resources to be added or subtracted at a later time. Clearly, this option has a value: infrastructure can be sized according to the application’s actual needs and can grow (or shrink) as required. Also, this option isn’t free given that the system has to be designed to be able to scale out; for example, by making application components stateless or by using a distributed database.
Ещё примеры:
Нил Форд, Марк Ричардс и соавторы в книги Software Architecture: The Hard Parts:
Архитектура программного обеспечения — это то, что сложно изменить впоследствии.
Оригинальная цитата:
Software architecture is the stuff that’s hard to change later.
Eoin Woods (автор нескольких книг по архитектуре ПО):
Архитектура программного обеспечения — это набор проектных решений, которые, если они приняты неверно, могут привести к отмене вашего проекта.
Оригинальная цитата:
Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.
Michael Keeling в книге Design It! From Programmer to Software Architect
Архитектура программного обеспечения системы — это набор значимых проектных решений о том, как организовано программное обеспечение для обеспечения желаемых атрибутов качества и других свойств.
Оригинальная цитата:
A system’s software architecture is the set of significant design decisions about how the software is organized to promote desired quality attributes and other properties.
И немного объяснения:
Проектное решение может быть значимым по ряду причин. Оно может представлять собой точку невозврата или влиять на атрибуты качества, график или затраты. Значимым решением может быть то, которое затрагивает многих людей или заставляет менять другие программные системы. В любом случае, значимые проектные решения дорого менять позже, если вы ошибетесь.
Обеспечивать атрибут качества — значит поощрять его проявление в программной системе. Когда архитектура хорошо организована, она усиливает атрибуты качества, которые нужны стейкхолдерам, и преуменьшает или устраняет те, которые им не нужны.
Оригинальная цитата:
A design decision might be significant for any number of reasons. It might represent a point of no return or influence quality attributes, schedule, or costs. A significant decision might be one that affects many people or forces other software systems to change. In any case, significant design decisions are costly to change later if you get them wrong.
To promote a quality attribute means to encourage it to appear in the software system. When the architecture is well organized, it will boost the quality attributes stakeholders want and downplay or eliminate the quality attributes stakeholders don’t want.
Группа 3: Архитектура как мультиперспектива
Последняя группа определений представляет собой комплексный взгляд и зачастую объединяет структуру и решения.
Марк Ричардс и Нил Форд в книге Fundamentals of Software Architecture:
Так что же такое архитектура программного обеспечения? Это определение имеет четыре измерения. Архитектура программного обеспечения системы состоит из архитектурного стиля в качестве отправной точки в сочетании с архитектурными характеристиками, которые он должен поддерживать, логическими компонентами для реализации его поведения и, наконец, архитектурными решениями, обосновывающими всё это.
Оригинальная цитата:
So what is software architecture? This definition has four dimensions. The software architecture of a system consists of an architecture style as the starting point, combined with the architecture characteristics it must support, the logical components to implement its behavior, and finally the architecture decisions justifying it all.
Kruchten: The Rational Unified Process. Также цитируется в Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison Wesley, 1999:
Архитектура — это набор значимых решений об организации программной системы, выбор структурных элементов и их интерфейсов, из которых состоит система, вместе с их поведением, определённым во взаимодействиях между этими элементами, композиция этих структурных и поведенческих элементов в постепенно увеличивающиеся подсистемы, а также архитектурный стиль, который направляет эту организацию — эти элементы и их интерфейсы, их взаимодействия и их композицию.
Оригинальная цитата:
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition
Len Bass и соавторы, 1994:
...архитектурный дизайн системы может быть описан (как минимум) с трех точек зрения: функциональное разделение интересующей предметной области, её структура и распределение функций предметной области по этой структуре.
Оригинальная цитата:
...the architectural design of a system can be described from (at least) three perspectives -- functional partitioning of its domain of interest, its structure, and the allocation of domain function to that structure.”
Barry Boehm и его студенты в Центре Программной Инженерии USC в 1995 году пишут, что:
Архитектура программной системы включает:
Коллекцию программных и системных компонентов, связей и ограничений.
Коллекцию заявлений о потребностях заинтересованных сторон (стейкхолдеров) системы.
Обоснование, которое демонстрирует, что компоненты, связи и ограничения определяют систему, которая, будучи реализованной, удовлетворит коллекцию заявлений о потребностях стейкхолдеров.
Оригинальная цитата:
A software system architecture comprises
A collection of software and system components, connections, and constraints.
A collection of system stakeholders’ need statements.
A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders’ need statements
Simon Brown в книге Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility описывает архитектуру как существительное и архитектуру как глагол:
Архитектура как существительное — структура
Как существительное, архитектура может быть кратко описана как структура. Речь идет о декомпозиции продукта на набор более мелких строительных блоков и взаимодействиях/отношениях между этими строительными блоками. При этом необходимо учитывать продукт целиком, включая фундамент и инфраструктурные сервисы, которые имеют дело со сквозными задачами, такими как безопасность, конфигурация, обработка ошибок и т. д. Цитируя Басса, Клементса и Казмана: "Архитектура программного обеспечения программы или вычислительной системы — это структура или структуры системы, которые включают программные элементы, внешне видимые свойства этих элементов и связи между ними".
Архитектура как глагол — видение
Как глагол, архитектура (т. е. процесс создания архитектуры) заключается в переводе архитектурных драйверов (функциональных требований, атрибутов качества, ограничений и принципов) в техническое решение, тем самым создавая техническую дорожную карту или видение. Крайне важно, что это также касается донесения этого видения до ряда стейкхолдеров как внутри, так и за пределами непосредственной команды разработчиков, чтобы у всех было единое представление о том, что строится (или было построено). Процесс архитектуры дополнительно заключается во внедрении технического лидерства, чтобы все, кто участвует в создании программной системы, могли вносить свой вклад позитивным и последовательным образом.
Оригинальная цитата:
Architecture as a noun - structure
As a noun, architecture can be summarised as being about structure. It’s about the decomposition of a product into a collection of smaller building blocks¹ and the interactions/relationships between these building blocks. This needs to take into account the whole of the product; including the foundations and the infrastructure services that deal with crosscutting concerns such as security, configuration, error handling, etc. To quote Bass, Clements, and Kazman: “The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relations among them."
Architecture as a verb - vision
As a verb, architecture (i.e. the process of creating architecture, or “architecting”) is about translating the architectural drivers (functional requirements, quality attributes, constraints, and principles) into a technical solution, thereby creating a technical roadmap or vision. Crucially, it’s also about communicating that vision to a number of stakeholders both inside and outside of the immediate software development team, so that everybody has a consistent view of what is being (or has been) built. The process of architecting is additionally about introducing technical leadership so that everybody involved with the construction of the software system is able to contribute in a positive and consistent way.
Анализ
Как мы видим, существует большое количество определений. Я считаю, что большинство из них корректны, просто они смотрят на архитектуру с разных точек зрения. Но мне хотелось бы пойти немного дальше.
Для начала я хочу ответить на вопрос: «Стоит ли фокусироваться только на "важных" частях системы?»
Не совсем. Несмотря на то, что зачастую как архитекторы мы будем фокусироваться именно на сложных частях системы, значит ли это, что мы можем забыть про все остальные? Я считаю, что нет. Они всё ещё являются частью архитектуры, просто не настолько важной, как другие. Однако тут тоже кроется опасность: игнорируя «неважные» части, можно не заметить, как они станут «важными», пока не станет слишком поздно.
А теперь, давайте проведём два мысленных эксперимента.
Эксперимент 1. Представим, что вы только пришли на огромный легаси-проект, на котором нет документации, диаграмм, ADR (Architecture Decision Records — записей архитектурных решений) или хранителей знаний (knowledge keepers). Вы можете только ретроспективно догадываться о том, какие были приняты решения и как они повлияли на систему. Вы также можете вообще не гадать об этом и сказать: «Раз эту часть системы очень сложно и дорого менять, значит, это результат архитектурно важного решения», — даже если в момент его принятия этого никто не понимал. Однако, чтобы хотя бы прийти к этому пониманию, вы сначала проанализируете структуру проекта — компоненты, из которых он состоит, и связи между ними.
Эксперимент 2. Вы проектируете простенький проект, у которого пока нет обязательных атрибутов качества, и единственное архитектурно важное требование (ASR) — это простота системы и скорость выхода на рынок (time-to-market). На начальных этапах практически любое решение будет легко поменять: сменить базу данных, разделить на микросервисы, поменять облачного провайдера.
А теперь предположим, что к вам приходит стейкхолдер и спрашивает: «Какая архитектура у нашего проекта?» Что вы ответите? Что её нет, потому что проект слишком простой? Или всё же что-то вроде: «Довольно простая — мы используем монолит, такую-то базу, такое-то облако»? Возможно, вы даже скажете: «Чтобы обеспечить основные требования быстрого time-to-market, мы приняли решение использовать…». И тут может показаться, что вот же оно — перспектива через решения! Однако, если задуматься, что вы в итоге опишете? Вы опишете структуру, хотя она и была создана вашими решениями на основе требований.
— Так может, это всё-таки мультиперспектива?
И да, и нет. Как я и писал ранее, практически каждое из приведенных определений правдиво. Просто не во всех случаях.
Архитектура — это что-то, что сложно изменить?
Архитектура — это набор проектных решений, который удерживает разработчиков от проявления ненужной креативности?
Архитектура — это набор значимых проектных решений для обеспечения желаемых атрибутов качества?
Архитектура — это продажа опционов?
Ответ на все эти вопросы — в подавляющем большинстве случаев — да.
Однако ответ на вопрос:
«Архитектура — это набор структур, необходимых для рассуждения о системе?»
Всегда да.
Заключение
Как мы видим, единого понятия архитектуры не существует, и многие авторы видят это по-разному. Лично я долгое время склонялся к определению через значимые решения, в силу его притягательной простоты, но во время написания этой статьи поменял своё мнение в сторону определения архитектуры как структуры от Лена Басса. Не потому, что остальные авторы не правы, а потому, что структура — это единственный артефакт, который есть всегда и минимально нужный чтобы рассуждать о системе. Вы можете не знать о “сложных” решениях, у вас может не быть требований к атрибутам качества, вы можете не думать о решениях как об опционах, но вы не можете не иметь структуры.
А что Вы думаете?
PS
Ну и напоследок цитата диалога с Кентом Беком (один из создателей Agile-манифеста, экстремального программирования, и JUnit) из 1992:
— Мистер Бек, что такое архитектура программного обеспечения?
— Архитектура ПО? — ответил Кент. — Ну, это то, чем занимаются архитекторы ПО.
— Тогда кто такой архитектор?
— Хм, "архитектор" — это новый напыщенный титул, который программисты требуют писать на своих визитках, чтобы оправдать свои огромные гонорары.
Оригинальная цитата:
“Mr. Beck, what is software architecture?”
“Software architecture?” replied Kent, “well, it is what software architects do.”
“So then, what is an architect?”
“Hum, ‘software architect’ it’s a new pompous title that programmers demand to have on their business cards to justify their sumptuous emoluments.”
Список литературы
Посмотреть список
Статьи, документы, и стандарты:
Software Engineering Institute (SEI): List of Software Architecture Definitions
ISO/IEC/IEEE 42010:2022: Software, systems and enterprise — Architecture description
Martin Fowler: Who Needs an Architect?
The Open Group: The TOGAF® Standard, 10th Edition
Grady Booch: Handbook of Software Architecture
Ruth Malan: Software Architecture and Related Concerns
Wikipedia: Software architecture
Книги:
Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice (4th Edition)
Mary Shaw, David Garlan: Software Architecture: Perspectives on an Emerging Discipline
Robert C. Martin: Clean Architecture: A Craftsman’s Guide to Software Structure and Design
Neal Ford, Mark Richards, et al.: Software Architecture: The Hard Parts
Desmond F. D’Souza, Alan Cameron Wills: Objects, Components, and Frameworks with UML: The Catalysis Approach
Gregor Hohpe: The Software Architect Elevator
Nick Rozanski, Eoin Woods: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives
Michael Keeling: Design It!: From Programmer to Software Architect
Mark Richards, Neal Ford: Fundamentals of Software Architecture
Philippe Kruchten: The Rational Unified Process: An Introduction
Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language User Guide
Simon Brown: Software Architecture for Developers
