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

(Из ленты Курсы бизнес анализа, тренинги и обучение бизнес аналитике| ArtofBA)
Изучение архитектуры как одно из направлений развития карьеры бизнес-аналитика меня интересовало давно. Когда же два из трех докладов, признанных лучшими на конференции по бизнес-анализу, были посвящены архитектуре, я поняла, что надо разобраться с этим вопросом более системно. Естественно, при помощи интернета. Так что эта статья носит реферативный характер и даже школярский подход к описанию. Но может быть полезна тем, кто, как и я, хочет ознакомиться с этой областью знаний, но не знает с чего начать. Приступив к поиску, прежде всего сталкиваешься с многообразием понятий архитектуры: архитектура программного обеспечения (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 архитектуру предприятия можно представить в виде четырёх основных доменов: · Бизнес архитектура (Business) · Архитектура данных (Data) · Архитектура приложений (Application) · Технологическая архитектура (Technology) Togaf описывает метод работы с АП, предлагая набор стандартных фаз разработки: · Предварительная фаза; · Фаза A: Видение архитектуры; · Фаза B: Бизнес архитектура; · Фаза C: Архитектура информационных систем; · Фаза D: Технологическая архитектура; · Фаза E: Возможности и решения; · Фаза F: Планирование перехода; · Фаза G: Управление реализацией; · Фаза H: Управление изменениями в архитектуре; · Управление требованиями, как процесс, который охватывает все этапы разработки архитектуры и обеспечивает целостность всего проекта. Он дает рекомендации по усовершенствованию архитектуры на каждом шаге, фокусируясь в первую очередь на процессе ее построения и развития. Альтернативой можно назвать модель Захмана. Модель представляет собой таблицу, столбцы которой содержат «открытые вопросы», отражающие фундаментальные понятия АП: · Данные (DATA) — что? · Функции (FUNCTION) – как? · Место (NETWORK) – где? · Люди (PEOPLE) — кто? · Время (TIME) — когда? · Мотивация (MOTIVATION) — почему? Строки в таблице предлагают уровни абстракции, на которых строятся модели предприятия. Уровни соответствуют точкам зрения заинтересованных лиц · Сфера действия (SCOPE) – планировщик; · Модель бизнеса (BUSINESS MODEL) – собственник; · Системная модель (SYSTEM MODEL) — проектировщик (дизайнер); · Технологическая модель (TECHNOLOGY MODEL) – разработчик; · Детали реализации (DETAILED REPRESENTATIONS) – подрядчик; · Работающая организация (FUNCTIONING ENTERPRISE) –предприятие. Идея матрицы состоит в том, чтобы заполнить все ячейки соответствующими представлениями, не пропустив важные характеристики системы. Эти архитектурные описания, увязанные в таблицу, представляют единое архитектурное полотно. При этом модель не позиционируется как методология т.к. не говорит, как именно представления разрабатывать, а только предоставляет шаблон «куда вписывать проектный артефакт», т.е. какие аспекты она должна отразить. Стоит упомянуть еще одну модель Gartner Enterprise Architecture Framework (GEAF). – Модель рассматривает архитектуру предприятия как стратегию, соединяющую информационные технологии и требования бизнеса в единое целое. Аналитики Gartner разделяют архитектуру предприятия на три основных слоя, критичных для архитектуры предприятия. · Бизнес архитектура (Business Architecture) · Информационная архитектура (Information Architecture) · Техническая архитектура (Technology Architecture) И выделяют четыре уровня детализации описания: · Среда бизнес-взаимодействия (Business Relationship Grid); · Бизнес-процессы и стили бизнес-процессов; · Шаблоны; · Технологические строительные блоки (кирпичики – bricks). На пересечении строятся представления архитектуры. В методологии Gartner архитектурный процесс разбит на четыре основные фазы, в рамках каждой из которых выполняется определенных набор шагов (Tasks). · Фаза 1. Инициализация (Phase I — Initiation). o Шаг 1. Организация архитектурного процесса (Organize Architecture Effort) o Шаг 2. Анализ ситуации на предприятии (Analyze Enterprise Context). · Фаза 2. Определение Целевой архитектуры (Future State Architecture “Architecting”). o Шаг 3. Разработка требований (Develop Requirements). o Шаг 4. Разработка принципов (Develop Principles) o Шаг 5. Разработка моделей (Develop Models) · Фаза 3. Разработка текущей архитектуры (Current State Architecture). o Шаг 6. Документирование (Documenting). · Фаза 4. Проведение GAP анализа (Closing the Gap). o Шаг 7. GAP анализ (Analyze Gaps) o Шаг 8. План миграции (Plan Migration). Можно приводить примеры других фреймворков. Но даже из такого беглого обзора можно увидеть общее: акцентируя внимания на разных аспектах, фреймворки предлагают рекомендации по разработки набора представлений, необходимого для понимания системы. Как я упоминала, я делаю первые шаги в освоении АП и не могу дать оценку различным подходам к ее разработке и описанию или сравнивать их эффективность. Мне представляется, что углубленным изучением архитектурных фреймворков стоит заниматься, если стоит вопрос о его внедрении для упорядочивания взаимодействий заинтересованных лиц и построения репозитария накопленных артефактов, то есть, когда организация достигла определенного уровня зрелости. Моей целью было выбрать некоторое средство, которое позволило бы «пощупать» модели. То есть меня интересовал скорее инструмент описания моделей, чем полноценный архитектурный фреймворк. При чем инструмент достаточно простой, позволяющий сосредоточиться на сущностях, а не нотациях. Суммируя то, что говорилось выше, основными трудностями в описании АП представляются Для их преодоления, инструментарий описания должен располагать следующими средствами: Инструментарием, отвечающим этим требованиям, оказался ArchiMate. Наверняка есть альтернативы, но опять таки я не ставила себе задачи их изучения. ArchiMate вполне соответствовал целям ознакомления с АП. На первый взгляд он выглядел привычно, напоминая знакомые средства моделирования, и в то же время открывал новые возможности. ArchiMate развивается и поддерживается The Open Group в дополнение к Togaf как язык моделирования, предназначенный для описания, анализа и визуализации архитектуры предприятия. Однако, он может использоваться и для описания архитектуры, базирующейся на других стандартах. Так же как и Togaf не требует обязательного применения ArchiMate, заменяя его на другие средства моделирования. ArchiMate отличается от других языков моделирования (таких как UML или BPWIN) в первую очередь предметом описания, включающим концепции АП, которые уже упоминались выше: бизнес-процессы, организационные структуры, информационные потоки, техническую инфраструктуру и т.д. Другим отличием является стремление ArchiMate быть как можно проще. Возможно, в ущерб точности он пренебрегает некоторыми пограничными случаями, не отражает всех альтернативных сценариев. Мы поймем, что неизбежные упрощения, ограничения и даже субъективные искажения оправданны, если вспомнить основное предназначение АП связать разнородные сущности и добиться общего их видения у различных заинтересованных лиц. Компромисс между детальностью проработки и читаемостью модели, а также своевременностью получения описания – еще одна неотъемлимая особенность процесса разработки АП. Помимо рекомендации набора понятий и нотации для их представления ArchiMate устанавливает определенные отношения между ними, формируя метамодель, а также предлагает стандартные представления и типы моделей, что позволяет говорить о нем не только как о языке моделирования, но и о методологии. Ядро ArchiMate выделяет три уровня описания системы: · business (бизнес), · application (приложения) and · technology (технология) (как мы видели, выделение уровней стандартный подход в описаниях АП разными фреймворками, хотя сами уровни могут отличаться) и три вида объектов: · Active (Активные) — для представления структурных понятий: бизнес-актеров, компонент, устройств и т.д · Behavior (Поведенческие) – для представления действий: события, процессы, функции. · Passive (Пассивные) – для представления объектов, над которыми выполняются действия. Как правило, это информационные артифакты, хотя могут быть и физические объекты. Полный ArchiMate фреймворк добавлет несколько уровней описаний, и, что более интересно, 2 расширения • Motivation Extension (Мотивационное расширение) • Implementation and Migration Extension (Расширение реализации) Мотивационное расширение мне кажется наиболее привлекательной для бизнес-аналитика возможностью ArchiMate. Оно позволяет описать цели, факторы влияния, принципы взаимодействия, а также бизнес-ограничения. Бизнес-аналитику часто приходится касаться этих вопросов. В конечном счете, это именно то, что в первую очередь интересует спонсоров проектов и владельцев продуктов. Однако, сходя из моего опыта, эти понятия хотя и присутствуют в обсуждениях, но плохо формализованы. Добавление их в модель и представление в виде схем и диаграмм упрощает понимание, позволяет проанализировать связи, что существенно улучшает коммуникации между заинтересованными лицами, участвующими в принятии решений. Расширение реализации еще одна полезная возможность, позволяющая визуализировать расхождения между желаемым и текущим состоянием АП и показать пути, какими эти расхождения будут преодолены. Это расширение вводит понятия пакетов работ и их результатов, завершая, таким образом, описание цикла разработки. Что еще выгодно отличает ArchiMate от таких языков моделирования UML и BPWIN, так это то, что предопределенные представления включают кросс-уровневые модели, которые содержат элементы разных слоев. Этот подход дает возможность проследить жизненный цикл решения от факторов, повлиявших на его принятия, до воплощения в продуктах и приложениях. Он позволяет трассировать изначальные требования, основанные на целях, к их реализации в приложениях при помощи выбранных технологий и к способам их доставки. Такая возможность особенно важна в процессе гибкой разработки где процесс формализации и приоритизации требований происходит непрерывно, а практики continuous integration and continuous delivery получают все большее распространение. После беглого знакомства ArchiMate выглядит как мощное, и в то же время легкое в использовании средство коммуникации между бизнесом и айтишниками, позволяющее преодолеть вавилонскую проблему разноязыкости заинтересованных лиц. В интернете можно найти множество средств, которые не только предоставляют удобные для создания ArchiMate моделей, но также обеспечивают их целостность и непротиворечивость. Мне приглянулся Archi. В заключение хочу сказать, что то, при ближайшем рассмотрение архитектура предприятия уже не кажется такой необозримой и мудреной. То, что виделось очень сложным, выглядит еще более сложным вполне доступным, разложенное на сущности в модели и представленное в схемах. Главное не запутаться в деталях. Тренинги от «Art of Business Analysis»: Комплексный тренинг по бизнес-анализу Базовые компетенции бизнес-аналитика Data Science и машинное обучение для бизнес-аналитиков
Power BI: Создание решения для бизнеса

Источник: Архитектура предприятия глазами аналитика