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