Архитектурные характеристики предприятия
До недавнего времени «архитектурой предприятия» называлась и практика проектирования и моделирования предприятия (практика оргдизайна), совмещённая с собственно архитектурной работой в её современном понимании (как это описано в курсе «Системная инженерия»), и прихват к этой практике работ по проектированию и архитектуре информационных систем предприятия, плюс ещё так могли называть концепцию организации-предприятия, совмещённую с воплощёнными в этой концепции архитектурными решениями.
Сегодня всё это стараются рассматривать отдельно. Так что архитектурная практика для организации — это принятие архитектурных решений по верхнеуровневому составу оргзвеньев и способам взаимодействия оргзвеньев, а также надзора за соблюдением менеджерами по оргразвитию (оргпроектировщиками и лидерами) этих решений. Информационные системы при этом существенны для организации взаимодействия между оргзвеньями, поэтому архитектура организации обычно включает в себя как часть и архитектуру корпоративных информационных систем.
Если оргдизайн распределился по организации, то архитектурой занимаются обычно более централизованно — ибо хорошая архитектура как раз и позволяет распараллелить работу большого числа оргдизайнеров. Тут все те же рассуждения, что и про разработчиков и архитекторов, которые проводились в «Системной инженерии», только это всё разворачивается для организационной системы, которую «разрабатывают» (то есть создают и развивают) менеджеры оргразвития. Общий тренд — это работа множества независимых оргзвеньев как маленьких команд, координируемая через корпоративный софт («организационный экзокортекс»).
Всё это делается для того, чтобы привести в приемлемые значения архитектурные характеристики предприятия (-ilities/-ости, то есть надёжность, масштабируемость и т.д.). Они те же, что и для систем общего вида, небольшое их число отбирается как самые важные для организации и дальше предлагаются меры, чтобы удержать приемлемые для бизнесмена значения этих характеристик. Бизнесмен тут важен, потому как ему надо будет продавать организацию, а её цена будет существенно зависеть от значения этих характеристик. Можно думать об архитектурной работе и так, что оргдизайнеры стремятся удовлетворить прежде всего сиюминутные интересы визионеров (по-быстрому реализовать в организации оргвозможности, позволяющие удовлетворить текущих клиентов, выдать рынку как можно быстрее и дешевле хорошо продающиеся сейчас продукты и сервисы компании), но вот архитекторы следят, что бы формула «деньги сейчас» была более полной (этот вариант был предложен в такой формулировке Элияху Голдраттом): «деньги сейчас и в будущем». Вот архитекторы как раз стоят на страже «денег в будущем»: их задача в том, чтобы организация могла быстро приспособиться к непредвиденным изменениям, которые несёт будущее. В будущем могут быть виражи/pivots (смена направлений деятельности фирмы), резкий рост (проблемы масштабируемости), резкое изменение текущей технологии (переход на иные принципы работы, например, переход к 3D-печати готовых изделий вместо литья заготовок и последующей их долгой обработки), покупка субконтракторов для слияния их организаций с купившей их фирмой, и что угодно ещё. Архитекторы должны держать организацию в форме, которая позволяет это всё «переварить», причём быстро.
Но главная повседневная возможность, которую даёт хорошая архитектура — это вообще возможность хоть что-то менять. Как ни странно, без модульности невозможно проводить организационные изменения, осваивать новые практики. Без хорошо организованной модульности организация не может приобрести новые оргвозможности. Эти возможности появляются только после разбиения организации как «кучи людей с их компьютерами и оборудованием» на оргзвенья-модули и простройка взаимодействий не между отдельными людьми, а между оргзвеньями. Налаживание взаимодействия между оргзвеньями многоуровнево: части личности внутри человека, люди внутри команд, команды внутри коллективов, коллективы внутри большой организации в целом (конечно, уровней тут может быть больше) тем сложней, чем больше число связей.
Каждая связь между модулями имеет свою цену на её организацию, поддержание и отслеживание. Не было бы цены такой связи, не было бы модульности, и это показывается в исследованиях по биологической эволюции[1]:
Каждая связь имеет цену: она накладывает штраф на будущие возможные эволюционные изменения, и для техно-эволюции (а у организаций, конечно, техно-эволюция) всё это сохраняется.
Для эволюции сугубо технических систем получены похожие результаты, и там считалось, каким образом можно изолировать ошибки в модулях, если пытаться их улучшить в ходе эволюции. В работе «Role of design complexity in technology improvement»[2] проверялось, насколько хорошо выполняется примерно тот сюжет, который рассказывает Tony Seba в разделе по стратегированию: насколько при наличии улучшений в отдельных модулях системы мы можем уменьшить цену (или, что то же самое — улучшить характеристики, не меняя цены). Бралось число модулей N, число взаимодействий между модулями (connectivity) D и оценивалось падение цены в зависимости от попыток улучшений при случайных мутациях. Вот результат:
Видно, что само число модулей не слишком влияет на падение цены, но число взаимодействий между модулями драматически ухудшает ситуацию: если связей много, то небольшое улучшение в одном модуле вызывает ухудшения в других модулях. Ибо одно лечим, а другое калечим. Это верно и для киберфизических систем (самолётов и атомных электростанций), но это же верно для организаций.
Если вы решили улучшить работу какого-то подразделения или комиссии, то просто факт изменений в ходе этих улучшений может негативно повлиять на работу других оргзвеньев, и это может быть трудно отследить. Поэтому архитектура предусматривает, как обычно, минимизацию межмодульных связей. Но, как мы помним, минимизировать полностью связи нельзя, ибо не будут проявляться эмерджентные характеристики системы, они появляются именно при взаимодействии частей системы! Поэтому архитектурные решения сложные, и как говорят сами архитекторы, они выбирают наименее плохое решение из плохих.
В любом случае, в организации надо строить оргструктуру как подводную лодку: с переборками, чтобы затопление одного отсека не влияло на работоспособность других отсеков, насколько это вообще возможно. Если в каком-то оргзвене всё резко пошло не так, то это оргзвено должно быть можно легко отделить от его окружения, заменить на другое (передать выполнение его сервисов кому-то другому), интерфейсы оргзвена должны быть хорошо прописаны, никакая работа не должна попадать внутрь оргзвена мимо организационного интерфейса, иначе планирование работ будет невозможно, длительность работ будет непредсказуема — оценить длину очереди работ с невидимыми прилётами внутрь этой очереди не удастся.
Границы в оргзвеньях невидимы, если «общение софта» двух оргзвеньев ещё как-то можно отследить, то общение людей в двух оргзвеньях отследить крайне сложно. При этом помним о неявных зависимостях, они тоже будут проявляться точно так же, как и в любых других системах. Например, помним, как были популярны в 90х годах идеи повторного использования в софте — и они не выжили, ибо «повторное использование» оказалось замаскированными межмодульными связями: вроде как правишь кусок кода для одного места, а он ломает работу четырёх других мест, где он был «повторно использован». В организациях будут проявляться все те же эффекты.