Процесс построения архитектуры

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

Обычная архитектура имеет дело с неживыми предметами. Кирпичи - они и в Африке кирпичи, а бетон, хоть и меняет агрегатные состояния, но предсказуем. Никакие чертежи, планы не могут изменить свойств кирпича.  А вот архитектура предприятия имеет дело с людьми, подразделениями, организациями. Все они имеют свои цели, устремления, поведение, хоть и на разных уровнях.  И они меняют свое поведение/характеристики по мере того, как меняется их понимание окружающей среды и их собственных целей. Если я увижу, что в новой архитектуре нет места моему подразделению (моей должности, организации, …), то очень легко предугадать, что мои характеристики как работника подразделения очень и очень изменятся. Точно так же изменятся характеристики всех участников жизни предприятия на всех уровнях. Таким образом, мы пришли к тому, что продукты разработки архитектуры предприятия носят очень и очень временный характер. Как только они разработаны, нужно их менять, так как предприятие уже изменилось даже в силу разработки этих же продуктов, не говоря уже о внешнем воздействии. И так постоянно, пока предприятие живо.

Если кирпичи и не изменяются в ходе разработки архитектуры здания, то рабочие даже очень.

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

• Нет документированной архитектуры вообще. Архитектура существует только в голове управленческого персонала компании. Нельзя сказать, что это плохо. Для частных предприятий, малых, - это даже хорошо. Есть экономия на разработке архитектуры, а результат от ее использования не так уж и велик. Количество сотрудников мало и архитектура может быть проговорена и распространена без лишней бюрократии. Но для больших предприятий - это беда. Не имея четкой основы для обсуждения, разные слои менеджмента движутся с большими задержками. Наверху жалуются на “тупых” подчиненных, которым всегда туго все доходит. Снизу жалуются на начальство, которое “понапридумывает всякой чепухи”, а реальные проблемы не решаются;
• Существует документированная архитектура в виде когда-то созданных инструкций, положений, регламентов, и т.д. Когда-то создали, и больше особо не меняли. В результате документация осталась тоже где-то в прошлом, а предприятие спотыкается о нее, с одной стороны стараясь приспособиться к новой внешней среде, а с другой стороны начальство продолжает стараться заставить подчиненных работать по инструкции. Это вариант, который остался от старого прошлого, когда организации эволюционировали медленно, так как все менялось медленно, когда цикл обновления оборудования был 10 лет, а то и больше. Сейчас, когда цикл обновления сократился до 3 лет, а программном обеспечении - так и вообще такое впечатление, что непрерывно, такой подход уже применять очень и очень тяжело. Лучше сказать, что невозможно. Кстати, нужно отметить, что в эту категорию попадают и те разработки архитектуры предприятия, где руководство и архитекторы не понимают ее природу. Создав кипу документации, создатели успокаиваются и начинают заставлять предприятие жить по этим инструкциям, не замечая, что их документация медленно, но верно устаревает;
• Архитектура предприятия создается до мельчайших подробностей. В результате получается многотомный продукт. И его уже нужно менять. А ресурсов на поддержание такой детальной документации обычно нет. И ситуация переходит в предыдущий вариант;
• Правильный вариант. Документация достаточно подробна, но и не тяжеловесна. Разрабатывается на основе тесного общения всех заинтересованных лиц. Будучи однажды разработанной, постоянно поддерживается в актуальном состоянии, более того - на основе ее разработки формируются рабочие документы, которые регулируют жизнь предприятия. Архитектура является средством, а не самоцелью.

Как видим, разработка архитектуры предприятия является также частью искусства и умения архитектора. Как говорится: “все хорошо в меру”. Так что в будущем нас ждет появление “лучших” и просто “хороших” практик, как разрабатывать и жить с архитектурой предприятия. На данном этапе такие хорошие практики распространяются с помощью методологий построения архитектуры предприятия.

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

Как и обычный продукт, архитектура разрабатывается в течение следующих этапов, шагов:

• Рассмотрение первоначальной идеи;
• Конструирование;
• Реализация; 
• Изменение и замена системы.