Архитектура – это про будущее…
— именно на этой мысли мы остановились в конце 1й части статьи. Продолжаем.
Хорошая архитектура – та, что соответствует своему назначению, т.е. позволяет решать поставленные перед ней задачи.
Задачи бывают разные. Стандартные и специфичные. Локальные и масштабные.
Но в любом случае, как вряд ли кто-то захочет дом “на один сезон” (хотя такое тоже возможно, но это как раз из разряда “специфичного”, и едва ли для подобного строительства будут прибегать к услугам архитектора) — так и сомнительно, чтобы кто-то хотел получить в итоге систему без перспективы ее развития в будущем.
От правильности построения архитектуры зависит масса полезных характеристик системы, среди которых немаловажная — это показатель срока ее жизни в процессе наращивания функционала, роста объемов данных и нагрузки.
Хорошая архитектура должна обладать свойством устойчивости – т.е. изменение вышеперечисленных параметров не должно приводить к необходимости коренного пересмотра реализации решения.
Это возможно, если при проектировании учитывается набор так называемых нефункциональных требований. Пользователь начинает их замечать только в случае их нарушения — пользователь сосредоточен, прежде всего, на функционале, который ему необходим. Но это не значит, что этот аспект должен уйти из нашего фокуса внимания. Когда эти требования нарушаются, для пользователя зачастую это выглядит просто – система не работает.
Итак, к нефункциональным свойствам относятся:
Кроме того, хорошо продуманная архитектура может позволить организовать параллельное развитие системы одновременно несколькими исполнителями, т.к. границы ответственности и точки интеграции компонентов хорошо очерчены и понятны.
И это положительно сказывается на сроках реализации проекта.
Архитектура – это способ борьбы со сложностью
Не думаю, что кто-то будет оспаривать факт: ИТ-системы – это, в целом, системы сложные. И вся практика создания ИТ-систем и комплексов идет под флагом борьбы со сложностью.
Позволю себе вспомнить одну давнюю историю замечательных студенческих времен.
Когда наступило время готовить дипломную работу, я попала к очень «правильному» преподавателю, который в обязательном порядке потребовал от меня главу с расчетом надежности моего «программно-аппаратного комплекса», как гордо именовалась мое небольшое приложение для персонального компьютера. Я попыталась возмущаться, потом расстроилась – мне казалось, очень бессмысленно и расточительно тратить драгоценное время на столь формальный вопрос…Но когда я пришла в библиотеку, я узнала для себя массу интересного. В частности, в руки мне попалась великолепная работа Г.Дж.Майерса “Надежность программного обеспечения” (“Software Reliability: Principles and Practices”).
У Майерса говорилось, например, о том, что подходы к расчету надежности ПО сильно отличаются от расчетов для аппаратных средств. И уровень надежности ПО прямо коррелирует с ее сложностью. Поэтому, ключевые подходы по увеличению надежности программных систем сводятся к различным практикам борьбы со сложностью.
В отличие от аппаратных средств, программное обеспечение слишком сложно, чтобы быть “абсолютно надежным”. И один из постулатов теории надежности ПО гласит: “В любой программе есть хотя бы одна ошибка”.
Соответственно, в индустрии производства ПО появляется множество практик, подходов, инструментов, которые позволяют снизить сложность и управлять ею.
В частности, создание языков высокого уровня, специализированного (инфраструктурного) ПО – СУБД, серверы приложений и т.п. Все это попытки разбить сложный процесс реализации ПО на иерархические уровни, каждый из которых решает задачи своего уровня, а каждый последующий пользуется сервисом предыдущего, “не задумываясь”, как именно он это реализует.
Как мы прояснили выше, одна из задач архитектора заключается в умении разбить целую систему на компоненты, выделив зоны их ответственности и выстроив общую логику их взаимодействия.
Таким образом, при построении архитектуры мы активно используем общеизвестный принцип “разделяй и властвуй”. В нашем случае, можно сказать так: “Разделяй на компоненты, модули, слои – и управляй каждым компонентом в отдельности, выстроив единые правила игры”.
Помимо улучшения надежности, мы здесь затрагиваем еще одно важное нефункциональное свойство системы – способность к модификации.
Избегая монолитных конструкций, разделяя систему на составные части — модули, которые понятным образом функционируют и взаимодействуют, мы повышаем возможности вносить изменения в отдельные компоненты, сводя влияние на другие ее части к минимуму. Проще говоря, в будущем в процессе развития системы это позволит не оказаться в ситуации “тут тронешь – там посыплется”.
Архитектура должна поддержать будущий процесс управления изменениями в системе, ограничив влияние компонентов друг на друга и предусмотрев средства выполнения оценки влияния предстоящих изменений.
Кроме того, в случае продуманного модульного подхода к построению системы появляется возможность параллельного и условно независимого (до определенной степени) реализации различных компонент системы разными исполнителями и даже командами и подрядчиками.
Более того, для реализации отдельных слоев возможно использование различных технологий и платформ. Необходимо лишь проработать их внутреннее интеграционное взаимодействие.
Таким образом, когда мы, например, на концептуальной архитектурной схеме видим несколько слоев – это не повод для грусти. Это повод порадоваться, что наша система обретет замечательную возможность долго эволюционировать, обрастая функционалом и не выходя за пределы своей сложности – а значит, сохраняя качества надежности и модифицируемости.
Теперь от высокого уровня “Enterprise” спустимся “на землю” – т.е. в проекты. И посмотрим на мир архитектора глазами участников проектов по разработке ПО.
Что это за таинственный человек — архитектор?
Код не пишет (может и писать, но реже и не сейчас, когда мы за ним наблюдаем). Сидит себе сперва в углу – мыслит, чертит, придумывает… «Витает в облаках» — думают разработчики. «Ну-ну, посмотрим» — думает начальник.
Да, код не пишет. Часто пишет на бумаге. Или на доске. Один или с кем-то – рисуют, рисуют… Обсуждают. Снова рисуют.
Потом у него вызревает… концепция (или видение (vision) – в зависимости от масштаба задачи).
В концепции реализуется основная идея, прозвучавшая от «заказчика архитектуры» (см. 1ю часть статьи).
В итоге, у архитектора появляется набор картинок и краткая презентация, объясняющая суть проблемы, поставленную задачу и подход к ее реализации. Далее начинается процесс представления архитектуры заинтересованным сторонам и согласование – как со стороны «бизнеса», так и со стороны ИТ-специалистов, т.к. вопросы могут быть у всех разные. И они должны быть учтены. Задача этого этапа – достичь равного понимания. Это не так просто, как кажется. И это не всегда удается… И… это нормально. Это часть профессии.
Короче говоря, на этом этапе искусство архитектора — в том, чтобы придумать концепцию, представить ее и получить одобрение, после которого она может служить основой для реализации (более подробно этот процесс был рассмотрен ранее, в 1й части статьи).
Архитектор – это не сколько удачливый “кодер” и изобретательный “кулибин”. Это человек, наделенный ответственностью – за направление, за команду, за систему… От его экспертизы, вдумчивости и умения “заглядывать в будущее” зависит успех работы многих людей.
Как мы говорили, проектированию и разработке системы должно по-хорошему предшествовать создание целевой архитектуры и видения. Т.е. прежде чем затевать проект – нужно четко обозначить цель и увидеть смысл будущих деяний.
Архитектору надо уверовать в эту цель. Так как именно он отвечает за то, чтобы “отряд” по дороге не слился в неком непонятном направлении – например, решил отправиться в баню, попариться… или огороды кому-то копать…
Когда целевое видение выбрано, всем понятно и созвучно, то именно на его основе потом осуществляет контроль правильности движения.
Предстоит путь “в 1000 миль”. Шаг за шагом – прежде чем возникнет что-то работающее и осязаемое. И задача архитектора– “не дать свинтить”. Поэтому, помимо технического бэкграунда и умения мыслить стратегически, ему крайне необходимы истинные лидерские качества и то, что сейчас модно назвать soft skills — т.е. способность вести переговоры, работать с людьми, хорошо владеть собой и управлять ситуацией.
Редко кому все эти разнообразные качества даются от природы. Что-то нам дано, а что-то надо воспитывать и выращивать.
Концепция или Vision — это лишь первый шаг.
Дальше нужно «заглубиться в детали» — проработать отдельные ключевые моменты будущей системы и ее компонентов.
И этот шаг включает в себя проработку несколько моделей разного уровня и назначения – например, модели данных, взаимодействия, бизнес-процессов, переходов состояний и т.п.
Для этого используются специализированные средства, предназначенные для того, или иного аспекта моделирования – так называемые, CASE-технологии. Существуют также проработанные стандарты в этой области – ER-модели, UML-диаграммы, нотации для описания бизнес-процессов (BPMN, EPC) и т.д.
Важным моментом здесь будет являться возможность поддержать непрерывный процесс разработки – из модели должна создаваться некая «рабочая» часть системы – на основе модели данных будет создана структура базы данных, на основе UML-диаграммы классов – заготовки классов и интерфейсов для будущего программного кода. Также со стороны CASE средства важно уметь поддержать обратный процесс – от кода – к модели.
И все-таки это еще не код. Это лишь первые «мосточки» — каркас – от концепции к будущему продукту.
Графическая нотация и модели – это хорошо. Но этого не достаточно. Должно быть некое описание – как с этим работать. Да-да – без текста – никуда. Здесь и появляется такой артефакт как спецификация.
Кто пишет спецификации?
Спецификации пишут системные аналитики – в части функциональных аспектов и системные архитекторы – в части системных (общих, ключевых) свойств компонентов и их взаимодействия.
Спецификация – это фактически формализованные требования – детальная постановка задачи для разработчика.
Что важно для спецификации?
Прежде всего, соблюсти баланс между:
Важен еще один момент.
Как ни странно, спецификация должна не только ограничивать разработчика, но и оставлять ему некоторую свободу — в области, где именно он принимает решение (и несет за него ответственность). Разумеется, он должен об этом знать.
Для чего это нужно?
Во-первых, трудно предусмотреть и предугадать все заранее. Разработка ПО – довольно сложная область, с бесконечной вариативностью возможных сценариев работы.
Во-вторых, если этого не делать, то это будет лишать “систему” и коллектив, который ее разрабатывает, пространства для саморазвития.
Излишняя “заорганизованность” лишает творческого начала. Человек начинает чувствовать себя “винтиком”. А это страшно демотивирует. На моей памяти были несколько случаев, когда разработчики теряли интерес и уходили именно по этой причине. Как ни странно, при создании архитектуры системы, нужно предусматривать “островки хаоса” – “островки свободы” для творчества других людей.
Осознание необходимости построения архитектуры предприятия и внедрения практики ее развития свидетельствует о достаточном уровне зрелости компании.
Существует множество компаний, где нет понимания необходимости планирования ИТ-архитектуры даже на ближайшее будущее – хотя бы в горизонте 1 года. Тем не менее, они как-то развиваются – меняется бизнес, появляются новые требования, модернизируются ИТ-системы, появляются новые интеграционные потоки, а также каналы распространения информации по предприятию и т.д.
Что же произойдет, если не задумываться об архитектуре предприятия?
Ответ прост – либо будут упущены некоторые возможности (упущенная прибыль), либо случатся некие потери (дополнительные затраты).
Поскольку если мы не заглядываем в «картину будущего», не пытаемся его увидеть сегодня – оно настигнет нас «внезапно», но все равно настигнет. Что при этом будет? Может быть, и ничего страшного не произойдет. А может быть, компания немного потеряет от своей конкурентоспособности, а может – случится что-то более серьезное, что поставит под удар ее основной бизнес. Мы не знаем этого заранее.
Но надежда и «рулетка» — весьма ненадежная стратегия развития – как бизнеса, так и ИТ, обеспечивающего бизнес.
Элемент случайности и хаоса, безусловно, будет присутствовать в любом случае. Мы не можем предугадать все. Слишком много есть внешних факторов, влияющих на ситуацию.
Но вопрос – хотим ли мы сделать его управляемым? Хотим ли мы расширить зону нашего влияния, либо положиться «на авось»?
Если хотим, то это уже следующий уровень зрелости – когда есть осознание необходимости построения и управления архитектурой предприятия. В этом случае компания «говорит» себе, что мы готовы «посмотреть в будущее» и сформировать некую картину – на 1-3-5 лет вперед. Разумеется, она будет корректироваться «по ходу пьесы». Но мы должны осознать, какие направления для нас ценны, во что мы готовы вкладываться и почему? Где мы готовы рискнуть? Где может быть наше «вау»? Где нам нужна, прежде всего, стабильность, а в чем мы можем быть немного «сумасшедшими»? В чем мы хотим быть более талантливы, чем другие компании, какие наши реальные шансы? А где нам просто нужны проверенные тиражируемые решения?
Одного осознания мало. «Увидеть» архитектуру, выстроить архитектурные процессы (включая внесения изменений и контроля) не так-то просто. Это нельзя назвать «элементарным» (рутинным) действием. И не исключено, что при неправильных решениях и некорректных подходах мы можем нанести скорее вред, чем пользу — и компания в погоне за красивой, но не реалистичной картинкой может понести лишние затраты.
Здесь в какой-то степени на помощь могут прийти упомянутые ранее архитектурные фреймворки, которые включают себя как стандарты описания архитектур, так и методологию процесса ее развития. Опора на них не исключает, но уменьшает риск неудачи в этом непростом деле.
Ценность применения любого стандарта, любой референсной практики состоит в умении адаптировать. Любая компания уникальна. Не существует двух одинаковых банков, ритейл-компаний, заводов, городских администраций и т.д. Везде есть своя специфика – географическая, человеческая, организационная, технологическая и т.д. Поэтому, попытка «снять кальку» с одной организации – и применить подобную практику к другой, без каких-либо изменений – скорее всего, ни к чему хорошему не приведет. Можно перенять определенный опыт. Но и его надо адаптировать к своей компании.
Построение корпоративной архитектуры – процесс творческий, уникальный – как уникальна каждая компания и люди, которые в ней работают.
Кроме того, на архитектурные процессы влияют особенности корпоративной культуры компании – особенно модель принятия решений, способы коммуникации, информационная открытость и т.д.
Архитектура – это про будущее, про людей, про устойчивое развитие компании.
Стало быть, если компания желает устойчиво развиваться, то ей надо начинать вкладываться в архитектуру и процессы управления ее изменением.
— именно на этой мысли мы остановились в конце 1й части статьи. Продолжаем.
Что такое хорошая архитектура?
Хорошая архитектура – та, что соответствует своему назначению, т.е. позволяет решать поставленные перед ней задачи.
Задачи бывают разные. Стандартные и специфичные. Локальные и масштабные.
Но в любом случае, как вряд ли кто-то захочет дом “на один сезон” (хотя такое тоже возможно, но это как раз из разряда “специфичного”, и едва ли для подобного строительства будут прибегать к услугам архитектора) — так и сомнительно, чтобы кто-то хотел получить в итоге систему без перспективы ее развития в будущем.
От правильности построения архитектуры зависит масса полезных характеристик системы, среди которых немаловажная — это показатель срока ее жизни в процессе наращивания функционала, роста объемов данных и нагрузки.
Хорошая архитектура должна обладать свойством устойчивости – т.е. изменение вышеперечисленных параметров не должно приводить к необходимости коренного пересмотра реализации решения.
Это возможно, если при проектировании учитывается набор так называемых нефункциональных требований. Пользователь начинает их замечать только в случае их нарушения — пользователь сосредоточен, прежде всего, на функционале, который ему необходим. Но это не значит, что этот аспект должен уйти из нашего фокуса внимания. Когда эти требования нарушаются, для пользователя зачастую это выглядит просто – система не работает.
Итак, к нефункциональным свойствам относятся:
- Надежность;
- Производительность;
- Модифицируемость;
- Масштабируемость;
- Способность к интеграции;
- Безопасность.
Кроме того, хорошо продуманная архитектура может позволить организовать параллельное развитие системы одновременно несколькими исполнителями, т.к. границы ответственности и точки интеграции компонентов хорошо очерчены и понятны.
И это положительно сказывается на сроках реализации проекта.
Архитектура – это способ борьбы со сложностью
Не думаю, что кто-то будет оспаривать факт: ИТ-системы – это, в целом, системы сложные. И вся практика создания ИТ-систем и комплексов идет под флагом борьбы со сложностью.
Позволю себе вспомнить одну давнюю историю замечательных студенческих времен.
Когда наступило время готовить дипломную работу, я попала к очень «правильному» преподавателю, который в обязательном порядке потребовал от меня главу с расчетом надежности моего «программно-аппаратного комплекса», как гордо именовалась мое небольшое приложение для персонального компьютера. Я попыталась возмущаться, потом расстроилась – мне казалось, очень бессмысленно и расточительно тратить драгоценное время на столь формальный вопрос…Но когда я пришла в библиотеку, я узнала для себя массу интересного. В частности, в руки мне попалась великолепная работа Г.Дж.Майерса “Надежность программного обеспечения” (“Software Reliability: Principles and Practices”).
У Майерса говорилось, например, о том, что подходы к расчету надежности ПО сильно отличаются от расчетов для аппаратных средств. И уровень надежности ПО прямо коррелирует с ее сложностью. Поэтому, ключевые подходы по увеличению надежности программных систем сводятся к различным практикам борьбы со сложностью.
В отличие от аппаратных средств, программное обеспечение слишком сложно, чтобы быть “абсолютно надежным”. И один из постулатов теории надежности ПО гласит: “В любой программе есть хотя бы одна ошибка”.
Соответственно, в индустрии производства ПО появляется множество практик, подходов, инструментов, которые позволяют снизить сложность и управлять ею.
В частности, создание языков высокого уровня, специализированного (инфраструктурного) ПО – СУБД, серверы приложений и т.п. Все это попытки разбить сложный процесс реализации ПО на иерархические уровни, каждый из которых решает задачи своего уровня, а каждый последующий пользуется сервисом предыдущего, “не задумываясь”, как именно он это реализует.
Как мы прояснили выше, одна из задач архитектора заключается в умении разбить целую систему на компоненты, выделив зоны их ответственности и выстроив общую логику их взаимодействия.
Таким образом, при построении архитектуры мы активно используем общеизвестный принцип “разделяй и властвуй”. В нашем случае, можно сказать так: “Разделяй на компоненты, модули, слои – и управляй каждым компонентом в отдельности, выстроив единые правила игры”.
Помимо улучшения надежности, мы здесь затрагиваем еще одно важное нефункциональное свойство системы – способность к модификации.
Избегая монолитных конструкций, разделяя систему на составные части — модули, которые понятным образом функционируют и взаимодействуют, мы повышаем возможности вносить изменения в отдельные компоненты, сводя влияние на другие ее части к минимуму. Проще говоря, в будущем в процессе развития системы это позволит не оказаться в ситуации “тут тронешь – там посыплется”.
Архитектура должна поддержать будущий процесс управления изменениями в системе, ограничив влияние компонентов друг на друга и предусмотрев средства выполнения оценки влияния предстоящих изменений.
Кроме того, в случае продуманного модульного подхода к построению системы появляется возможность параллельного и условно независимого (до определенной степени) реализации различных компонент системы разными исполнителями и даже командами и подрядчиками.
Более того, для реализации отдельных слоев возможно использование различных технологий и платформ. Необходимо лишь проработать их внутреннее интеграционное взаимодействие.
Таким образом, когда мы, например, на концептуальной архитектурной схеме видим несколько слоев – это не повод для грусти. Это повод порадоваться, что наша система обретет замечательную возможность долго эволюционировать, обрастая функционалом и не выходя за пределы своей сложности – а значит, сохраняя качества надежности и модифицируемости.
Зачем нужны архитекторы? Какова их роль? Что от них можно ожидать и почему?
Теперь от высокого уровня “Enterprise” спустимся “на землю” – т.е. в проекты. И посмотрим на мир архитектора глазами участников проектов по разработке ПО.
Что это за таинственный человек — архитектор?
Код не пишет (может и писать, но реже и не сейчас, когда мы за ним наблюдаем). Сидит себе сперва в углу – мыслит, чертит, придумывает… «Витает в облаках» — думают разработчики. «Ну-ну, посмотрим» — думает начальник.
Да, код не пишет. Часто пишет на бумаге. Или на доске. Один или с кем-то – рисуют, рисуют… Обсуждают. Снова рисуют.
Потом у него вызревает… концепция (или видение (vision) – в зависимости от масштаба задачи).
В концепции реализуется основная идея, прозвучавшая от «заказчика архитектуры» (см. 1ю часть статьи).
Представление концепции (видения)
В итоге, у архитектора появляется набор картинок и краткая презентация, объясняющая суть проблемы, поставленную задачу и подход к ее реализации. Далее начинается процесс представления архитектуры заинтересованным сторонам и согласование – как со стороны «бизнеса», так и со стороны ИТ-специалистов, т.к. вопросы могут быть у всех разные. И они должны быть учтены. Задача этого этапа – достичь равного понимания. Это не так просто, как кажется. И это не всегда удается… И… это нормально. Это часть профессии.
Короче говоря, на этом этапе искусство архитектора — в том, чтобы придумать концепцию, представить ее и получить одобрение, после которого она может служить основой для реализации (более подробно этот процесс был рассмотрен ранее, в 1й части статьи).
Архитектор – это не сколько удачливый “кодер” и изобретательный “кулибин”. Это человек, наделенный ответственностью – за направление, за команду, за систему… От его экспертизы, вдумчивости и умения “заглядывать в будущее” зависит успех работы многих людей.
Как мы говорили, проектированию и разработке системы должно по-хорошему предшествовать создание целевой архитектуры и видения. Т.е. прежде чем затевать проект – нужно четко обозначить цель и увидеть смысл будущих деяний.
Архитектору надо уверовать в эту цель. Так как именно он отвечает за то, чтобы “отряд” по дороге не слился в неком непонятном направлении – например, решил отправиться в баню, попариться… или огороды кому-то копать…
Когда целевое видение выбрано, всем понятно и созвучно, то именно на его основе потом осуществляет контроль правильности движения.
Предстоит путь “в 1000 миль”. Шаг за шагом – прежде чем возникнет что-то работающее и осязаемое. И задача архитектора– “не дать свинтить”. Поэтому, помимо технического бэкграунда и умения мыслить стратегически, ему крайне необходимы истинные лидерские качества и то, что сейчас модно назвать soft skills — т.е. способность вести переговоры, работать с людьми, хорошо владеть собой и управлять ситуацией.
Редко кому все эти разнообразные качества даются от природы. Что-то нам дано, а что-то надо воспитывать и выращивать.
Кто ты – идеальная спецификация?
Концепция или Vision — это лишь первый шаг.
Дальше нужно «заглубиться в детали» — проработать отдельные ключевые моменты будущей системы и ее компонентов.
И этот шаг включает в себя проработку несколько моделей разного уровня и назначения – например, модели данных, взаимодействия, бизнес-процессов, переходов состояний и т.п.
Для этого используются специализированные средства, предназначенные для того, или иного аспекта моделирования – так называемые, CASE-технологии. Существуют также проработанные стандарты в этой области – ER-модели, UML-диаграммы, нотации для описания бизнес-процессов (BPMN, EPC) и т.д.
Важным моментом здесь будет являться возможность поддержать непрерывный процесс разработки – из модели должна создаваться некая «рабочая» часть системы – на основе модели данных будет создана структура базы данных, на основе UML-диаграммы классов – заготовки классов и интерфейсов для будущего программного кода. Также со стороны CASE средства важно уметь поддержать обратный процесс – от кода – к модели.
И все-таки это еще не код. Это лишь первые «мосточки» — каркас – от концепции к будущему продукту.
Графическая нотация и модели – это хорошо. Но этого не достаточно. Должно быть некое описание – как с этим работать. Да-да – без текста – никуда. Здесь и появляется такой артефакт как спецификация.
Кто пишет спецификации?
Спецификации пишут системные аналитики – в части функциональных аспектов и системные архитекторы – в части системных (общих, ключевых) свойств компонентов и их взаимодействия.
Спецификация – это фактически формализованные требования – детальная постановка задачи для разработчика.
Что важно для спецификации?
Прежде всего, соблюсти баланс между:
- точностью, понятностью / и слишком высокой детальностью;
- универсальностью / и простотой;
- полнотой охвата / и реалистичностью по ресурсам.
Важен еще один момент.
Как ни странно, спецификация должна не только ограничивать разработчика, но и оставлять ему некоторую свободу — в области, где именно он принимает решение (и несет за него ответственность). Разумеется, он должен об этом знать.
Для чего это нужно?
Во-первых, трудно предусмотреть и предугадать все заранее. Разработка ПО – довольно сложная область, с бесконечной вариативностью возможных сценариев работы.
Во-вторых, если этого не делать, то это будет лишать “систему” и коллектив, который ее разрабатывает, пространства для саморазвития.
Излишняя “заорганизованность” лишает творческого начала. Человек начинает чувствовать себя “винтиком”. А это страшно демотивирует. На моей памяти были несколько случаев, когда разработчики теряли интерес и уходили именно по этой причине. Как ни странно, при создании архитектуры системы, нужно предусматривать “островки хаоса” – “островки свободы” для творчества других людей.
Когда компании нужно вкладываться в Архитектуру? И что будет, если этого не делать?
Осознание необходимости построения архитектуры предприятия и внедрения практики ее развития свидетельствует о достаточном уровне зрелости компании.
Существует множество компаний, где нет понимания необходимости планирования ИТ-архитектуры даже на ближайшее будущее – хотя бы в горизонте 1 года. Тем не менее, они как-то развиваются – меняется бизнес, появляются новые требования, модернизируются ИТ-системы, появляются новые интеграционные потоки, а также каналы распространения информации по предприятию и т.д.
Что же произойдет, если не задумываться об архитектуре предприятия?
Ответ прост – либо будут упущены некоторые возможности (упущенная прибыль), либо случатся некие потери (дополнительные затраты).
Поскольку если мы не заглядываем в «картину будущего», не пытаемся его увидеть сегодня – оно настигнет нас «внезапно», но все равно настигнет. Что при этом будет? Может быть, и ничего страшного не произойдет. А может быть, компания немного потеряет от своей конкурентоспособности, а может – случится что-то более серьезное, что поставит под удар ее основной бизнес. Мы не знаем этого заранее.
Но надежда и «рулетка» — весьма ненадежная стратегия развития – как бизнеса, так и ИТ, обеспечивающего бизнес.
Элемент случайности и хаоса, безусловно, будет присутствовать в любом случае. Мы не можем предугадать все. Слишком много есть внешних факторов, влияющих на ситуацию.
Но вопрос – хотим ли мы сделать его управляемым? Хотим ли мы расширить зону нашего влияния, либо положиться «на авось»?
Если хотим, то это уже следующий уровень зрелости – когда есть осознание необходимости построения и управления архитектурой предприятия. В этом случае компания «говорит» себе, что мы готовы «посмотреть в будущее» и сформировать некую картину – на 1-3-5 лет вперед. Разумеется, она будет корректироваться «по ходу пьесы». Но мы должны осознать, какие направления для нас ценны, во что мы готовы вкладываться и почему? Где мы готовы рискнуть? Где может быть наше «вау»? Где нам нужна, прежде всего, стабильность, а в чем мы можем быть немного «сумасшедшими»? В чем мы хотим быть более талантливы, чем другие компании, какие наши реальные шансы? А где нам просто нужны проверенные тиражируемые решения?
Одного осознания мало. «Увидеть» архитектуру, выстроить архитектурные процессы (включая внесения изменений и контроля) не так-то просто. Это нельзя назвать «элементарным» (рутинным) действием. И не исключено, что при неправильных решениях и некорректных подходах мы можем нанести скорее вред, чем пользу — и компания в погоне за красивой, но не реалистичной картинкой может понести лишние затраты.
Здесь в какой-то степени на помощь могут прийти упомянутые ранее архитектурные фреймворки, которые включают себя как стандарты описания архитектур, так и методологию процесса ее развития. Опора на них не исключает, но уменьшает риск неудачи в этом непростом деле.
Ценность применения любого стандарта, любой референсной практики состоит в умении адаптировать. Любая компания уникальна. Не существует двух одинаковых банков, ритейл-компаний, заводов, городских администраций и т.д. Везде есть своя специфика – географическая, человеческая, организационная, технологическая и т.д. Поэтому, попытка «снять кальку» с одной организации – и применить подобную практику к другой, без каких-либо изменений – скорее всего, ни к чему хорошему не приведет. Можно перенять определенный опыт. Но и его надо адаптировать к своей компании.
Построение корпоративной архитектуры – процесс творческий, уникальный – как уникальна каждая компания и люди, которые в ней работают.
Кроме того, на архитектурные процессы влияют особенности корпоративной культуры компании – особенно модель принятия решений, способы коммуникации, информационная открытость и т.д.
Архитектура – это про будущее, про людей, про устойчивое развитие компании.
Стало быть, если компания желает устойчиво развиваться, то ей надо начинать вкладываться в архитектуру и процессы управления ее изменением.
