top of page

Архитектура предприятия глазами аналитика



Приступив к поиску, прежде всего сталкиваешься с многообразием понятий архитектуры: архитектура программного обеспечения (software architecture), архитектура решений (solution architecture), бизнес-архитектура (business architecture), архитектура предприятия (enterprise architecture).

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

В чем же собственно состоит этот новый взгляд?

Посмотрим, какие определения АП предлагают компетентные источники.

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



Enterprise architecture (EA) is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes (Wiki https://en.wikipedia.org/wiki/Software_architecture)

An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. (TechTarget http://searchcio.techtarget.com/definition/enterprise-architecture)

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. Gartner https://www.gartner.com/it-glossary/enterprise-architecture-ea/

Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company's operating model. The operating model is the desired state of business process integration and business process standardization for delivering goods and services to customers. The MIT Center for Information Systems Research (MIT CISR)

Enterprise architecture is a practice, which analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology. The Enterprise Architecture Body (http://www.eabok.org/) of Knowledge defines "architecture" as:

1.A formal description of a system, or a detailed plan of the system at component level to guide its implementation

2.The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

Добавим несколько "апокрифических" определений.

Архитектура предприятия – это способ понимания различных элементов, которые в совокупности составляют предприятие, и то, как эти элементы взаимосвязаны".

Архитектура предприятия – это архитектура возможностей и потенциала бизнеса, основанных на комбинации таких работающих совместно факторов как люди, процессы и технологии.

Беглого взгляда хватает, чтобы понять, что единого взгляда нет. Архитектурой называют и практику, и инфраструктуру, и организацию, и blueprint в значении «план, чертеж».

Дальше всех шагнул Togaf, изначально дав два определения, используемых в зависимости от контекста. Согласно этому стандарту архитектура предприятия это и сама структура компонент, и ее формальное описание, и принципы ее усовершенствования.

Напрашивается вывод, что архитектура предприятие (АП) – понятие неоднозначное и даже двусмысленное. Но если вдуматься, то в действительности, существующие в организации процессы и их усовершенствование неразделимы: процесс есть развитие организации и развитие в свою очередь является процессом. И Togaf прав, закладывая в свое определение двойственность архитектуры, ее инь и янь как статической системы, так и динамики ее развития.



Впрочем, поступим в соответствии с тезисом, сформулированным Giga Group [(The Pillars of Enterprise Architecture Terminology, 2002)] «в индустрии ИТ нет одного, единственно правильного стандарта на определение Архитектуры ИТ, поэтому общие соглашения внутри организации важнее теоретической точности», не будем излишне педантичны и сосредоточимся на сущностях, рассматриваемых АП.

Решив, что визуализация мне в этом поможет, я перешла к картинкам. Предложенные гуглом изображения архитектуры предприятия выглядели устрашающе.



Наиболее точно их характеризует слово «сложность». Эта сложность объективная и вызвана не только большим количеством элементов, но и тем, что эти элементы разнообразны и имеют совершенно несхожую природу: это и люди, и техника, и технологии, а зачастую и абстрактные понятия, такие как цели, правила, ограничения.

Вот далеко не полный список концепций, которые отображает архитектура предприятия:

• Цели и миссия

• Бизнес-функции

• Бизнес- процессы

• Роли и должности

• Продукты

• Сервисы

• Организационная структура

• Программное обеспечение

• Структуры и потоки данных

• Коммуникации



Разнообразие понятий, используемых в АП, естественно связано и с многообразием стейколдеров. Лица, влияющие на архитектуру и зависящие от архитектурных решений, занимают различные должности, работают в разных подразделениях, обладают отличающимися знаниями, подготовкой и даже менталитетом.

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

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

Слово "ана́лиз" в переводе с греческого означает разложение, разборка, расчленение, если хотите. Этот метод, которым мы все привыкли пользоваться, характеризуется выделением отдельных частей объектов исследования, предполагая, что изучив их, мы получим представление о целом. Наши излюбленные техники, такие как декомпозиция, work/scope breakdown structure и другие, основаны именно на таком подходе.

В противоположность ему архитектура предлагает использовать холистический подход. Холизм опирается на принцип: целое всегда есть нечто большее, чем простая сумма его частей. И потому простое изучение отдельных составляющих не даст полного представления о системе в целом. Для того, чтобы его получить нужно рассматривать систему с разных сторон, с различных точек зрения, соединяя полученные знания.

Как результат применения холистического подхода, говоря об архитектуре, оперируют следующими понятиями

3.68 Stakeholder

An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the outcome of the architecture.

Заинтересованные лица - Индивидуум, команда, организация или их группы, заинтересованные в создании архитектуры или имеющие некоторые соображения относительно архитектуры.

3.75 View

The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture.

Представление – отражение набора соображений относительно предприятия. Представление – взгляд на предприятие с определенной точки зрения. Представление может выражаться в модели, демонстрирующей заинтересованным лицам интересующие их аспекты архитектуры.

3.76 Viewpoint

A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template). A view is what you see; a viewpoint is where you are looking from - the vantage point or perspective that determines what you see.

Точка зрения – понимание, относительно которого создается представление. Это набор соглашений для создания и использования представления (часто на базе соответствующей схемы или шаблона). Представление – это то, что вы видите, а точка зрения – то, куда вы смотрите. Следовательно точка зрения определяет то, что вы видите.

И воспринимают АП как набор моделей, описывающих представления (views) различных аспектов предприятия (бизнес знаний и процессов, данных, приложений, технологических инфраструктур и так далее) с точек зрения (viewpoints) разных заинтересованных лиц (stakeholders). Помимо предметной области, точка зрения может варьироваться глубиной проработки деталей, что также находит отражение в моделях.

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

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

Эти размышления приводят к необходимости создания централизованного хранилища артефактов (репозитария) и средств работы с ним.

Многие организации могут обходиться без специализированных средств, используя графические пакеты типа VS Visio. Но по мере роста сложности ограничения таких средств начинают влиять на качество и целостность описания. Встает вопрос о выборе фреймворка для работы. Фреймворк должен определить основные принципы развития архитектуры, подходы к документированию, рекомендации к взаимодействию заинтересованных лиц.

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



Судя по количеству упоминаний, одним из самых распространенных является TOGAF.

В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов: