Как проработать архитектурную концепцию it-проекта с помощью attribute-driven design

От бизнес- архитектуре к архитектуре ИТ

Согласование требований бизнеса и возможностей информационных технологий является одним из ключевых преимуществ от управления архитектурой предприятия. Сейчас развитие современного бизнеса трудно представить без применения информационных технологий, ведь результативность существующих бизнес-процессов зависит от качества их информационной поддержки. Часто в крупных компаниях каждое подразделение использует в работе «собственные» информационные системы, начиная от электронных таблиц и заканчивая «тяжелыми» ERP – системами. Однако во многих случаях отсутствует единый взгляд на использование информационных систем в рамках «сквозного» процесса компании.

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

В российской практике существует множество случаев, когда компании отказывались от внедренной информационной системы, из-за некачественного документирования и начинали внедрение новой системы. Это происходит по причине невозможности внесения изменений в такую систему, что делает ее неудобной для бизнеса. Таким образом, управление архитектурой предприятия может решить основную проблему автоматизации бизнес-процессов сократить «разрыв» между существующими бизнес-процессами и средствами их автоматизации. В большинстве случаев причиной такого разрыва является неформализованность бизнес-процессов и требований к информационной системе, а также сложность внесения изменений в существующие ИТ-решения. И если не предпринимать специальных действий, то этот «разрыв» будет только увеличиваться со временем, пока не произойдет отказ бизнеса от использования информационной системы, а значит потери сделанных инвестиций в развитие информационных технологий.

В настоящее время на ИТ- рынке окончилась «ERP-эйфория» – вера в возможность полной автоматизации бизнеса одной монолитной информационной системой. Множество компаний, вложив миллионы долларов в автоматизацию, так и не получили требуемых преимуществ. И теперь понятно, что «зоопарк» информационных систем в компании неизбежен. Именно поэтому сегодня необходимо описывать и анализировать существующую ИТ- архитектуру компании и синхронизировать ее с бизнес- архитектурой, а не надеяться на полномасштабную автоматизацию с помощью одной информационной системой. Сложность взаимодействия бизнеса и ИТ усугубляется масштабностью бизнеса в глобальных холдингах, а также наследованием бизнес-процессов и информационных систем в результате слияний и поглощений. При увеличении уровня использования информационных технологий, растет зависимость бизнеса от качества и надежности поддерживающих его информационных систем и ИТ- инфраструктуры, что в свою очередь требует четкости и прозрачности взаимосвязи бизнес-процессов с ИТ- архитектурой и ИТ- инфраструктурой.

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

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

Плюсы и минусы профессии

Плюсы:

Возможность (и необходимость!) постоянного повышения профессионального уровня в соответствии с прогрессом IT-отрасли и сферы бизнеса.
Высокая оплата труда.
Престиж и всё возрастающая востребованность профессии.

Минусы:

Один общий минус для всех профессий IT-сферы – постоянная сидячая работа за компьютером.
Ответственность и умение правильно оценить и взвесить каждое свое решение, так как цена ошибки архитектора выше, чем другого специалиста.
Возможное недовольство заказчика результатом работы.
Необходимость работать с чужим кодом.
Большое количество заинтересованных лиц в каждом проекте, у которых свои пожелания, требования, ограничения: заказчик, менеджеры проекта, топ-менеджеры, сотрудники разных специализаций. Каждый специалист говорит на своем профессиональном языке и не вполне понимает других. Архитектору необходимо интегрировать все эти особенности и принять решение, которое устроит всех.
Довольно частые митинги и совещания, на которых архитектор обязан присутствовать.

Шаг 7. Проверка выполнения требований

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

Мы уточняем и конкретизируем требования, расставляем приоритеты и затем повторяем шаги со 2 по 7 в каждой итерации. Таким образом необходимо проработать все требования с высоким приоритетом, соблюдая все ограничения. Но не обязательно проводить итерации последовательно. Скорее всего, вы будете чередовать этапы проектирования и реализации системы.

3. Отслеживаем прогресс

Чтобы вовремя выполнить перечисленные выше шаги, архитектору нужно наблюдать за прогрессом работы команды и оперативно откликаться на изменения. Авторы методологии советуют отслеживать выполнение шагов с помощью архитектурного бэклога в виде канбан-доски. В ее столбцы мы помещаем архитектурно значимые требования, ограничения и системные задачи. Они могут иметь следующие статусы:

Not Yet Addressed (Еще не рассмотрено)
Partially Addressed (Рассмотрено частично)
Completely Addressed (Рассмотрено полностью)
Discarded (Отброшено)

2 Привлечение разработчиков

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

Станьте IT-компанией. Например, первый зампред Сбербанка в интервью на РКБ заявил, что Сбербанк теперь IT-компаний с банковской лицензией. При переходе от классической к технической компании сложнее всего изменить культуру, об этом подробнее ниже.
Стартовать интересные проекты. Интересные значит масштабные и дерзкие. Предприниматели должны идти дальше покупки CRM или автоматизации документооборота. В разделе рассмотрим несколько проектов, которые вдохновляют меня.
Делать проекты на новых технологиях и подходах. Будьте современны. Не стоит заставлять работать с FoxPro только потому, что вы в него верите. Дайте разработчикам сделать выбор. О том как сделать выбор расскажу в разделе .
Будьте заметными для разработчиков. Вдохновляйте целями компании и рассказывайте о планах. Для это подойдет спонсорство на конференциях, выступления на конференциях, статьи на Хабр или на VC.ru.
Вкладывайте силы в ключевую конкурентную компетенцию. Если вы купили и внедрили 1С, то это никак не изменило расстановку сил на рынке. Конкуренты купят 1С, и вы окажетесь с ними на равных. Делайте проекты, которые выделяют вас на рынке, такие проекты привлекают разработчиков.
Если у вас бедный, но перспективный стартап, предлагайте процент бизнеса и вдохновляйте. Предлагайте разработчиками акции или долю в бизнесе. Это типовой подход для IT-стартапов.

2.1 Воспитайте инженерную культуру

При переходе от традиционной компании к чисто технической сложнее всего изменить культуру.

Если организацию представить в виде пирамидки, то культура — тугая резинка вокруг пирамидки. Вы сдвигаете одну из частей пирамиды, например, делаете процессы более «гибкими». Резинка натягивается и со временем аккуратно возвращает процессы на прежнее место:

Подробнее о подходах к изменению культуры в статье Culture is a rubber band around your organization.

Кто такой архитектор IT

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

ИТ-архитектор относится к сотрудникам IT-отделов крупных компаний или выполняет заказы на фрилансе. В зависимости от уровня квалификации и специализации профессионалы разделяются на:

Фронтэнд-специалиста – профессионала, организующего и участвующего в разработке внешних оболочек и интерфейсов информационных продуктов, с запуском презентаций, прикреплением рекламных окон и баннеров, настройкой всплывающих информационных таблиц и электронных помощников.
Бэкэнд–разработчиков – технических специалистов, ответственных за программные кодировки, встраиваемые команды, настройки алгоритмов, тестировку и автоматический контроль с отправкой регулярных отчетов о стабильности работы сервиса.
Специалистов широкого профиля, выполняющего проект «с нуля» до готового продукта предоставляемого пользователям.

Профессионалы, занимающиеся полным циклом разработки наиболее востребованы на рынке труда и получают заработную плату в 2 3 раза выше, чем оклады узкоспециализированных ИТ-архитекторов.

Обзор методологии

1. Собираем требования

В качестве источника могут выступать результаты опросов стейк-холдеров, анализ бизнес-целей проекта и историй использования

При этом важно конкретизировать, что имеет в виду клиент. Например, не просто «безотказная работа сайта», а «допустимый период простоя – 30 минут в месяц».

Далее мы оцениваем важность требований по двум критериям:

ценность для бизнеса;
степень влияния на архитектуру.

Уровни важности оцениваем по шкале HML (high, medium, low — высокий, средний, низкий). Таким образом, каждое требование будет иметь двухбуквенное сочетание

Архитектурно значимые пункты имеют обозначения HH, HM, HL, MH, MM. Стоит отметить, что большое число требований HH означает высокие риски на проекте.

2. Проектируем архитектуру

Мы проектируем архитектуру ПО, исходя из наиболее значимых атрибутов качества.

Это рекурсивный процесс, в ходе которого система декомпозируется на более мелкие подсистемы.

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

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

Плюсы и минусы профессии

Мы разобрали профессию архитектора ПО на достоинства и недостатки. Пункты из обоих списков помогут составить мнение о деятельности без необходимости погружаться в нее.

Плюсы:

высокий уровень заработной платы; роль важного, даже ключевого специалиста на проекте; имея опыт работы архитектором ПО, можно создать свой бизнес, например по консалтингу проектов; постепенно растущая востребованность на отечественном рынке труда; работа с любой отраслью бизнеса (плюс государственные организации). Минусы:

Минусы:

высокий порог входа в профессию, особенно для тех, кто далек от технического IT (для таких людей порог входа запредельный);
огромная ответственность за проект;
высокие нагрузки как в разрезе мыслительного процесса, так и на психоэмоциональном уровне;
с некоторыми заказчиками могут возникать противоречия и разногласия из-за того, что они плохо разбираются в программном обеспечении как таковом.

Archimate. Многослойная архитектура

Еще один инструмент, который мне сильно помогает, – Archimate.

Архитектуры бывают разные – бизнес-архитектуры, архитектуры решений, архитектуры приложений, интеграционные архитектуры. Еще туда накладываются английские термины: Enterprise Architecture и Solution Architecture. Совершенно непонятно, что под этими словами скрывается и какие должностные обязанности у человека, который будет эти архитектуры разрабатывать.

Чтобы добавить ясности в эти термины, архитектурная группа TOGAF – это такая группа, которая консолидирует лучшие практики по IT в целом в мире – выпустила спецификацию Archimate, которая переводится как «друг архитектора».

Согласно этой спецификации, архитектура делится на слои:

слой бизнеса;
слой технологии;
слой инфраструктуры.

Для описания слоев спецификация Archimate предлагает несколько простых общих блоков: сервис, процесс и функция.

Описание архитектуры зависит от того, с какой стороны мы хотим смотреть на этот архитектурный объект.

Если мы описываем слой бизнеса, у нас есть:

клиент – Business Actor;
менеджер по продажам – тоже Business Actor;
некий процесс, в котором они работают – Business Process
при этом задействуются бизнес-службы – Business Service – склад и личный кабинет.

Этот склад и личный кабинет работают на основе какого-то софта. Описание слоя софта выглядит так:

управление складом WMS организовано на УТ;
работу личного кабинета тоже обеспечивает ряд каких-то сервисов – для аутентификации, веб-интерфейса, внутренние сервисы и т. д.

Т.е. есть некий бизнес-процесс, который поддерживается вот таким софтом.

Этот софт работает на железяках (в нотации Archimate железяки показываются зеленым цветом) – WMS работает на кластере 1C, есть Kubernetes, а между ними Kafka.

То есть бизнес-процесс поддерживается софтом, который работает на железках.

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

Сейчас самое интересное – то, что мне нравится больше всего.

Профессиональные знания

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

Высшее техническое образование.
Общий опыт работы на позициях корпоративного/системного архитектора/технического руководителя/ведущего разработчика/ведущего системного аналитика или схожих позициях не менее 2-3 лет в крупных компаниях финансового сектора (брокеры, банки топ-50, инвест-банки, системные интеграторы).
Бизнес-экспертиза в финансовом секторе – понимание продуктов и процессов розничных банков, брокеров, инвест-банков, процессов их вспомогательных подразделений (персонал, информационная безопасность, управленческий учет и т. д.).
ИТ-экспертиза, связанная с автоматизацией общекорпоративных процессов в компаниях финансового сектора:
- в области электронного документооборота – основные технологии lotus notes, exchange, lync, sharepoint, wwf, bpm;
- в области интеграции приложений (esb, soa);
- в области технологической инфраструктуры (сервера, схд, сети, виртуализация, active directory, nlb, wsfc, ip-телефония cisco);
- в области управленческого учета – основные технологии mssql, ssrs, ssas, 1С, cognos.
Базовые знания методологий проектирования, описания архитектуры (Togaf, Zachmann,RUP, DoDAF, TEAF).
Владение инструментами проектирования, описания архитектуры.
Практический опыт проектирования архитектуры и разработки технического дизайна инфраструктуры для Enterprise-приложений.
Навыки проектирования систем и сервисов с применением:
- сервис-ориентированной архитектуры (SOA), WS-*;
- архитектуры, ориентированой на сообщения (MOM);
- архитектуры ориентированной на события (EBA);
- архитектуры корпоративных шин данных (ESB);
- архитектуры управления процессами предприятия (BPM);
- шаблонов проектирования: GRASP, Gof, Enterprise Application.
Практический опыт использования UML и OOП.
Базовый опыт разработки на платформе .Net/ Java EE, опыт работы с промышленными серверами баз данных (MSSQL, Oracle).
Знание и практический опыт применения основных серверных продуктов Microsoft. Базовые знания продуктов IBM, Oracle.
Базовые знания особенностей продуктов классов ERP, CRM, HRM, ECM, BPM, BI, DWH, IDM, ESB, ETL различных вендоров.
Базовые знания в области управления проектами.
Владение английским (чтение, письмо, речь) – не ниже intermediate.

Как банку подготовиться к трансформации

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

Уже в начале пути полезно проанализировать собственную потребность в партнерствах и изучить рынок возможных поставщиков технических решений и интеграторов.

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

Наконец, непосредственному началу процесса трансформации должно предшествовать создание рабочих групп, отвечающих за каждое из направлений

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

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

Какие бывают архитекторы ПО

Среди архитекторов в ИТ тоже есть свои специализаци и направления.

Например, если компании нужно выбрать язык, технологии и фреймворки, чтобы написать самую быструю программу, то зовут software-архитектора. Ещё он нужен, когда в программе планируется много разных модулей и их нужно грамотно соединить друг с другом.

Если задача — интегрировать программу в другую большую систему или развивать уже готовый продукт, то здесь будет больше полезен solution-архитектор. Он прикинет все возможные варианты, просчитает их плюсы и минусы и найдёт оптимальное решение.

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

Особенности профессии

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

Информационные технологии прогрессируют так стремительно, что в какой-то момент развитие бизнеса начинает не соответствовать им. Для поддержания баланса и необходим архитектор – продвинутый ИТ-специалист, хорошо разбирающийся в тонкостях конкретного бизнеса. Корпоративный архитектор принимает ответственные решения, связанные с информационными технологиями, учитывая их влияние на бизнес компании в целом.

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

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

Хотите устроиться на работу сразу после получения профессии? Skillbox гарантирует это! При покупке курса с трудоустройством, Skillbox поможет с поиском работы по новой специальности. Если у вас не получится найти работу, Skillbox вернёт деньги за курс. Акция действует до конца 2022 года! Сейчас самое время, пока идет новогодняя распродажа со скидками до 60%!

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