Управление архитектурой

О сущности управления архитектурой бизнеса или ИТ, как его неотделимой части, cм. рассуждения в конце страницы.

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


Услуга «Управление архитектурой предприятия» подразумевает создание и ведение для Заказчика следующих взаимоувязанных (!) каталогов архитектурных элементов:

  • каталог целей предприятия
  • каталог драйверов предприятия
  • каталог стейкхолдеров предприятия и их интересов
  • каталог KPI предприятия
  • каталог положений влияющих нормативных актов
  • каталог подразделений и групп предприятия
  • каталог проектов предприятия
  • каталог сотрудников и ролей на предприятии
  • каталог систем/приложений и функций систем на предприятии
  • каталог процессов предприятия
  • каталог информации и данных предприятия
  • каталог инфраструктуры предприятия
  • каталог требований к перечисленным выше сущностям

Каждый каталог образует архитектурный слой, элементы всех каталогов во всех слоях связаны друг с другом, что и есть предмет нашей работы: вычленение объектов реальности для каталогизации и установление между ними связей (отношений). Кроме того, все элементы идентифицируются и атрибутируются в нужном для Заказчика информационном объеме. Для материальных объектов порядок каталогизации более-менее очевиден, для когнитивных объектов (цели, драйверы, принципы, ограничения, нормы) всё не тривиально.

Некоторые из перечисленных выше каталогов или группы каталогов образуют т.н. частные или доменные архитектуры, как например, ИТ-архитектура или процессная архитектура. Такими архитектурами иногда приходится заниматься отдельно в отрыве от корпоративного контекста. Это не всегда хороший стиль, но если выбор сделан сознательно, то ситуация под контролем. Причинами, по которым корпоративная архитектура не создается в полном объеме, являются:

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

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

  • Каталогизация начинается с атомизации, то есть с поиска ответа на вопрос, чем является атом (атомарный элемент) управления? Что есть элементарная интеграция? Чем является атомарный объект данных? Даже по списку/каталогу систем в компании нет однозначного мнения: что есть система и сколько их в организации?
  • Что с чем связано, как связано и что-на-что влияет? Умение сформировать связи и наполнить их адекватным семантическим смыслом является больше искусством, чем наукой.
  • Где в организации хранится "каталог принятых решений"? Какие это решения? На что они оказали влияние в прошлом, как они влияют на будущее? Управление документооборотом и поручениями является скорее профанацией этой темы, чем начальным уровнем зрелости.
  • С какой точностью выполняется трассировка принятых управленческих решений на элементы (отделы, процессы, системы, интеграции, проекты и т.п.)?

Ответы на эти вопросы, как правило, приводят к реконструкции всего процесса управления и к понимаю необходимости управления архитектурой, как составной части общего управления. Главный результат состоит в том, что возникает качественно новое и точное понимание объекта управления (то есть предприятия и его организованности), а из этого понимания корректируются методы и процессы самого управления. Иногда "подход к снаряду" заканчивается печально: попробовали ⇒ осознали ⇒ подучились ⇒ испугались дисциплины ⇒ потеряли интерес.  В больших компаниях основной итог архитектурной ревизии может заключаться в выводе, что к трансформации (тем более - цифровой транформации) они не способны, но зато теперь понимают, где и что можно подкрутить для лучшего сопряжения ИТ и бизнеса.

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

  • каждое управленческое или инженерное решение должно быть привязано к архитектурному элементу и не к одному:
    - к подразделению, а лучше и к его функции;
    - к процессу, а лучше и к шагу процесса;
    - к системе, а лучше и к её функции;
    - к заинтереснованному лицу, а лучше к его интересу;
    - к объекту данных;
    - к интеграционному взаимодействию, а лучше и к использованному API-методу;
    - к оборудованию или объекту инфраструктуры;
    - к цели и её показателю.
  • управленческие решения должны быть привязаны друг к другу, если одно вытекают из другого или оказывает на него влияние.
  • каждый архитектурный элемент - это объект управления изменениями (change management element). Не будет таких объектов - не ясно, что же именно изменяется на предприятии, невозможно планировать изменения. См. также статью HBR по теме "любое управление - это управление изменениями".
  • зависимость элементов архитектуры друг от друга влияет на ход изменений в организации. Очень часто управленческие и даже инженерные решения не учитывают этого фактора.
  • запуск в компании нескольких инициатив по изменению или реализация нескольких (и тем более потока) управленческих решений не может быть распараллелен без понимания зависимостей в конструкции предприятия. Поиск таких зависимостей, разведение изменений по независимым маршрутам и есть основа управленческого успеха. Иначе одна инициатива топит другую.


При оказании услуг мы придерживаемся методологии TOGAF и нотации Archimate. Однако смело идем на нужные расширения или специализации базовых элементов, включая интеграцию практики заказчика с общепринятыми методологиями. Зачем нужен TOGAF/Archimate? - создание архитектуры начинается с выбора языка, то есть из каких смысловых единиц (концептов) будем строить модель. Выбор других концептов приведет к другой модели и другим выводам. 

Работы столь высокого уровня сложности — а количество элементов архитектуры и их взаимосвязей может превышать тысячи — невозможно выполнять без использования специализированных инструментов. Можно даже сказать, что правильный выбор инструмента является залогом успеха большого архитектурного проекта. Мы рекомендуем использовать отечественный программный продукт СиММА (см. отдельную страничку по проекту СиММА), других альтернатив для российского рынка на середину 2023 года нет. Более подробно по продуктам моделирования см. таблицу сравнения.

Строго выражаясь, архитектурой всегда управляет Заказчик. Наша же деятельность подобна штабной работе: мы собираем данные и готовим архитектурные решения. Любое управление само по себе есть сложный когнитивный процесс, основанный на умении собрать и подготовить данные, а также на смелости прогнозирования и предсказания, как действовать в ситуации будущей неопределенности. Однако стоит заметить, что в больших компаниях зачастую нет пространства для смелости, и правильные решения — это лишь решения, основанные на четком и ясном понимании (интерпретации?) существующей реальности. Поэтому способ и качество описания AsIs-архитектуры являются ключевыми факторами успеха управленца.



Причины и истоки популярности архитектурного подхода к инжинирингу бизнеса.

1. Сама комбинация слов "инжиниринг бизнеса" подразумевает применение инженерных подходов к проектированию организованности.

2. Истоки инженерных методов, применяемых для совершенстования деятельности предприятия, лежат в начале XX века. Одним из таких примеров является конвейер, как способ повысить производительность труда за счет улучшений в его организации. В этом казалось бы простом [с точки зрения сегодняшнего дня примере] мы как минимум видим необходимость выделения типов работ, участков работ, компетенций участников, последовательности работ, а также синхронизации действий участков работ по производительности.

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

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

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

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

7. Объем ИТ на предприятии вырос до таких размеров, что управлять нужно еще самими информационными технологиями.

8. На сегодня многие предприятия не в состоянии существовать самостоятельно, а лишь в составе экосистемы. Это экономично, технологично и даёт возможность зарабатывать больше. Таким образом управлять надо и своим окружением. Возможно слово "управлять" здесь не подходит, но как минимум - принимать во внимание (в детальный расчет!), где и как мы зависимы от нашего окружения.

Долгое время, да и сейчас в небольших компаниях, процессный подход и другие методы формализации бизнеса (BPM, ARIS, Value Chain, Value Stream, ISO 9000) успешно справлялись с налаживанием управления в компании. Успех таких проектов и бизнесов заключается в стабильной системе целей, стабильной продуктовой линейке, в низкой зависимости от ИТ. Любые отклонения от стабильности начинались сверху, от руководства и его целеполагания, и ... методология это выдерживала, справлялась.

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


Краткое введение в Архитектуру (2,9 МБ) Скачать


Список услуг