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

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

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

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

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

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

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

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

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

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

Материалы, посвященные управлению проектами

Вводное слово

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

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

Последствия… Вавилонская башня от Andreas Bengter

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

Бурж Халиф, самое высокое здание на текущий момент. Невозможно представить, что такое здание было построено без описания архитектуры здания в чертежах и планах, которые соединили тысячи работников в единый организм. И невозможно представить, как удается управлять компаниями без подобных детальных чертежей. Может поэтому в странах СНГ один из самых низких уровней организованности?

 

Определение понятие архитектуры по стандарту ISO/IEC/IEEE FDIS 42010:2011:

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

Как видно из определения, архитектура включает в себя как конструкцию, так и те факторы, которые влияют на ее развитие.

Архитектура создается для использования определенным кругом лиц. Такие лица называются заинтересованными, или, как один из аглоникаизмов, стейкхолдеры (те, которые держат отбивные :) ) - stakeholders. По определению стандарта IEEE заинтересованными лицами являются:

Заинтересованные лица - персоны, группы или целые организации (или классы таковых), которые интересуются системой, или кого таковая система затрагивает.

При этом “интересуются” и “затрагивает” - как в положительном, так и в отрицательном смысле этого слова. Может быть, что меня архитектура система и вообще не интересует, да и не нужна она мне вообще. Но если она меня затрагивает, например, после ее внедрения я буду работать в два раза больше/меньше, то я, получается, уже “заинтересованное лицо”.