Скажу сразу – я начинающий архитектор, который переучивается данному ремеслу с системного администрирования. В данной статье не будет рассуждений на следующие тематики:
- Как меня занесло в данную отрасль и беды системного администрирования;
- Наличие/отсутствие вменяемой литературы и статей, школы системных архитекторов;
- Как я себя чувствую на новой должности и планы на будущее и т.д.
Вводную часть начну с моего ограниченного понимания места архитектора в крупной компании.
В отделе информационных технологий присутствует множество участников процесса сопровождения и разработки ПО: программисты различных направлений, аналитики, тестировщики, администраторы систем, техподдержка разных уровней и т.д. Каждый из них видит либо часть системы, либо целую систему, но со своей точки зрения (к примеру, специалист технической поддержки первого уровня «видит» систему как продвинутый пользователь).
Немного философии. Все информационные активы предприятия (приложения, БД и репозитории, источники данных, интеграционные сервисы) представляют собой единое целое. Современное предприятие не имеет полностью автономных сервисов. От активов, которые не взаимодействуют с сервисами предприятия, в будущем обязательно потребуется интеграция.
Так вот, от архитектора во всем этом котле логики и данных требуется особое – архитектурное видение информационной системы. Архитектор – человек, который знает почти все и почти обо всем. Нет, я не имею ввиду что он способен полезть в код и исправить баг. Я имею в виду «видение» с точки зрения данных и связей между ними. Интеграция информационных систем сейчас является наиболее сложной и критичной задачей архитектуры. Все дома уже построены – предприятия часто предпочитают покупные системы самописным. Да в зданиях делают косметические ремонты, но это не самое главное. (Если вы не работаете в компании, разрабатывающей софт). Основная задача архитектора – проложить коммуникации и построить инфраструктуру.
Но компания, в большинстве случаев, не живет в изолированной среде. Есть ли смысл в городе с хорошей инфраструктурой, к которому не ведет ни одно шоссе? Предприятие взаимодействует с IT системами различных организаций и частными лицами напрямую либо через посредников. Организовать такое взаимодействие в разы сложнее, ведь нужно договорится со всеми участниками системы о предмете и форматах обмена. Дело может упростить тот факт, что данные договоренности уже были достигнуты и оговорены в международных стандартах, но на практике мало кто их придерживается.
Теперь немного про «косметический ремонт». Наш город уже имеет внутреннюю и внешнюю инфраструктуру — что еще, казалось нужно, если бы только в городе не жили бы люди. И у людей постоянно появляются новые потребности, от ремонта квартиры до постройки нового здания. Так само и в IT, где непрерывный поток новых требований является вполне нормальным явлением. Задача архитектора прослеживать требования и их реализацию, а также влиять на решения по их реализации. Нельзя допустить чтобы снос стены в одной из квартир разрушил все здание либо мы построили никому не нужный дом.
Бывают случаи когда разработчики выпускают продукт, не удовлетворяющий требованиям пользователя. И здесь выплывает одна из малоприятных, но первоочередных задач архитектора — прослеживать процесс реализации требований пользователя в программном коде. Архитектор должен понимать и документировать не только решения, но и причины принятия данных решений.
Из предыдущего абзаца следует главное отличие ремесел системного архитектора и градостроителя. Готовы? Открою простую истину — на архитектуру программного обеспечения не влияют законы физики! Нет, конечно есть системные ограничения, лучшие практики, патерны и принципы. Но все это можно запросто обойти, мы можем построить дом как из камня, так и из песка и оба простоят сотни лет. Можем пустить трубопровод через ядро Земли либо расположить дом верх ногами — и все это будет идеально работать если решение принято взвешено. Информационные активы, в каком то смысле, не реальны и здесь нет предела полету фантазии разработчика (в разумных пределах, конечно).
Одним из методов ограничения полета фантазии разработчиков являются архитектурные принципы и ограничения. Они представляют собой набор правил системного и бизнес уровня. К примеру, один из принципов может звучать следующим образом «Для проекта используем технологию ASP.Net». Не плохо сразу же писать и причины данных принципов.
Естественно, все вышесказанное должно хранится в двух местах: кратко в голове архитектора и подробно в документации. Ведение документации является задачей не менее важной и сложной чем все вышеописанное. Сам документ архитектуры по уровню детализации должен находится где-то посредине между требованиями и исходным кодом. Данный документ нечто вроде истории превращения требований пользователя в подсистему.
Одна из трудностей документа архитектуры – частые изменения. И здесь нет однозначной методики контроля и ведения истории данных изменений. У меня также нет понимания принципов ведения данного документа, но я постараюсь раскрыть их в третьей или четвертой статье из моего цикла.
Вот и все на сегодня. Я решил не писать слишком большие статьи, а дробить все на небольшие части (Это, к стати, тоже одна из задач архитектора). В следующей статье мы поговорим о языке архитекторов – UML и об абстракциях.
UPDATE. Очень прошу комментировать по тематике. Уровень моей компетенции оценивать не нужно.
