Боб Льюис, обозреватель CIO, опубликовал ряд статей, одну из которых, посвященную технической архитектуре, мы предлагаем читателю... Техническая архитектура - это совокупность и сущность того, что ИТ развертывает для поддержки предприятия. Таким образом, управление ею является ключевой ИТ-практикой. Что представляет собой хорошая техническая архитектура? Или, более фундаментально, что представляет собой техническая архитектура, хорошая, плохая или так себе?

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

Почему техническая архитектура имеет значение

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

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

Рисунок 1: Экономика технической архитектуры

Что представляет собой техническая архитектура

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

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

Рисунок 2: Составляющие технической архитектуры

Внешние факторы

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

• Бизнес-факторы: это огромные ИТ-возможности, которые понадобятся компании, исходя из ее стратегических целей. Это не требования в смысле разработки приложений. Они шире. Примерами таких возможностей могут быть машинное обучение, автоматический перевод с естественного языка и распознавание лиц. Бизнес-факторы оказывают прямое влияние на архитектуру; они также влияют на нее косвенно, помогая формулировать принципы архитектуры.
• Принципы архитектуры: Как объяснялось ранее, это общие принципы, которые определяют, что представляет собой “хорошую” архитектуру в вашем бизнесе. Они сочетают в себе общие знания о том, что представляет собой хороший инжиниринг, с бизнес-драйверами компании.
• Технологические тенденции: нет, вам не обязательно быть модным. Но вам нужно понимать, когда тенденция на внешнем рынке технологий приведет к аннулированию некоторых компонентов вашей технической архитектуры или может создать возможность сделать что-то по-другому и лучше.

Строительные блоки технической архитектуры

ИТ-архитектура является многоуровневой и сегментированной. Она состоит из приложений, данных и технологий. 

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

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

Данные: ИТ предоставляет возможности для управления двумя типами информации: структурированными, то есть данными, удобно представленными в таблицах и формах; и неструктурированными, то есть содержимым и документами более свободной формы по своей природе. Бизнес-пользователи, кстати, никогда не взаимодействуют напрямую с данными любого рода. Они взаимодействуют с приложениями, которые взаимодействуют с хранилищами данных, принимают их, управляют ими и представляют их. Уровень данных охватывает только сами данные, а не СУБД, системы управления контентом (CMS) и системы управления документами (DMS), которые их содержат.

Технология: состоит из двух подслоев:

Инфраструктура и объекты, которые включают в себя: сам центр обработки данных (даже если вы полностью облачны, где-то поблизости скрывается центр обработки данных); сети; серверы, физические или виртуальные; хранилище, будь то SAN, NAS или прямое подключение; плюс средства мониторинга, управления и администрирования систем — и тому подобное.

Платформы: программное обеспечение, на котором построено и работает все, что находится на более высоких уровнях, включая серверные операционные системы, языки разработки и среды, СУБД, CMSE и DMSE, а также корпоративные служебные шины (ESBS) и эквивалентные системы интеграции.

Стандарты

В результате оценки информационных технологий, развернутых в портфелях приложений, данных и технологий, ИТ устанавливает стандарты — руководящие принципы, которым должны соответствовать портфели. Стандарты делятся на две категории:

• Стандарты продукции: Конкретные продукты, одобренные для использования для предоставления каждой ИТ-возможности. MS Word, например, сегодня является стандартом обработки текстов для большинства предприятий. Приложения, хранилища данных и технологии, которые используются, но не одобрены для использования, нарушают стандарт архитектурного продукта.
• Технические стандарты: в дополнение к конкретным продуктам техническая архитектура также состоит из утвержденных способов структурирования различных ее компонентов. Например, большинство ИТ-магазинов считают нормализацию стандартным способом организации структурированных данных; многие находятся в процессе создания микросервисов в качестве стандартного способа организации логики приложений.

Переход от подготовки к получению результата

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