24.11.2021 17:29

Новости

Администратор

Автор:

Администратор

Секретное искусство совершенствования технической архитектуры

Построение эффективных ИТ. Теперь, когда вы знаете, что у вас есть в вашей технической архитектуре, и насколько она хороша (или не очень хороша), вы готовы планировать ее улучшение.


Автор: Боб Льюис, обозреватель CIO

 

Выберите одно слово для описания технической архитектуры вашей компании, и оно, скорее всего, будет «действительно сложная».

Ладно, это два слова, но большинство технических архитектур действительно очень сложны. Придумываете, как их упростить и улучшить? Нам нужно будет повторить «действительно» еще несколько раз: это действительно, действительно, действительно сложно.

 

Конечно, когда что-то настолько сложное или запутанное, то это помогает начать разбираться, прежде чем составлять план улучшения. Здесь мы делаем именно это, помогая вам избавиться от нескольких из этих «действительно», чтобы вы могли составить практический план игры, который поможет технической архитектуре вашей компании наилучшим образом служить бизнесу.

 

Распутывание технической архитектуры

 

Предыдущая часть этой серии предоставила основу для описания технической архитектуры, разбив ее на три портфеля и их подпортфели:

 

* Приложения: системы записи, интерфейсы и интеграция, а также спутниковые приложения

* Данные: как структурированные, так и неструктурированные

* Технологии: объекты, инфраструктура и платформы

 

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

 

И это показало, как соединить техническую и бизнес-архитектуру, в частности, с помощью «модели бизнес-возможностей» (BCM) – таксономии бизнес-функций, с которой сопоставляется каждое приложение в технической архитектуре.

 

Вместе они позволяют вам идентифицировать, классифицировать и оценивать то, что у вас есть.

 

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

 

Специфика зависит от того, с каким портфелем и субпортфелем вы имеете дело. Здесь мы разберем это снизу вверх.

 

Объекты и инфраструктура

 

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

 

Далее следуют диспозиции. Для объектов и инфраструктуры вы можете выбрать следующие варианты:

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

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

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

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

 

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

 

Платформы

 

Определение приоритетов и расположения платформ отличается от их определения для объектов и инфраструктуры, поскольку платформы имеют гораздо больше взаимозависимостей. Хороший способ справиться с этой сложностью – определить стеки. Стек представляет собой комбинацию платформ, используемых по крайней мере одним приложением, включая серверную ОС, среду разработки (включая библиотеки), систему управления базами данных (СУБД), CMS (систему управления контентом), веб-сервер и поддерживаемые браузеры (при условии, что пользовательский интерфейс приложения отображается через браузер), а также операционные системы, на которых работают различные платформы.

 

Стоит отметить, что стеки рекурсивны: платформы могут располагаться на других платформах. Также стоит отметить, что некоторые приложения также могут быть платформами. Например, SharePoint – это приложение, которое также может служить средой разработки для создания пользовательских приложений.

 

Приоритеты: работоспособность стека – это среднее состояние его компонентов, оцененное с использованием критериев процесса, структуры и выборки.

Для этого нет безошибочной «лучшей практики». Подход, позволяющий преодолеть сложность, состоит в том, чтобы определить нездоровую платформу, которая, если ее исправить, улучшит большинство стеков в наибольшей степени. Для иллюстрации представьте, что вы определили 60 стеков в своей технической  архитектуре. Также представьте, что самая нездоровая платформа, которая у вас есть в производстве, – это Windows Server 2003 – дайте ей гипотетический показатель работоспособности -1,5.

 

В этом гипотетическом примере представьте, что повышение его оценки до +2 перемещает 14 стеков с -1 до 0 и еще 6 стеков с 0 до 1. Это 22 стека, улучшенных за счет исправления Windows 2003 Server. Индекс приоритета Windows 2003 Server составляет 20 из 60 улучшенных стеков: 0,33.

 

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

 

Диспозиции. Диспозиции платформы аналогичны тем, которые определены для объектов и инфраструктуры:

 

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

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

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

* Консолидация. Редко встречается  техническая архитектура, в которой не используются избыточные платформы. Между серверными операционными системами, СУБД, интегрированными средами разработки и т.д. Установление стандартов с наивысшими показателями работоспособности в качестве стандартов компании и перенос остальных на эти стандарты может предоставить широкие возможности для упрощения и улучшения.

 

Данные

 

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

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

 

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

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

 

Приложения

 

Теперь становится интересно.

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

* Сохранение. Продолжайте использовать приложение, поддерживая и совершенствуя его по мере изменения потребностей бизнеса.

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

* Реплатформинг. «Поднимите и переместите» (lift and shift) приложение на более дешевый, но в остальном эквивалентный набор платформ.

* Рефакторинг. Перепишите приложение в соответствии с вашими техническими стандартами проектирования архитектуры.

* Адаптация. Если платформа собирается измениться, некоторые приложения должны будут измениться вместе с ней.

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

* Выход на пенсию. Отключите приложение и отмените его лицензии. Если ситуация требует этого, сначала заархивируйте данные приложения.

 

А как насчет облака? Облако не является ни несущественным, ни важным для этого анализа, пока вы не закончите назначение диспозиций приложений.

 

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

 

От приоритетов и диспозиций к плану

 

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

 

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

 

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

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

 

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

 

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

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

 

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

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

 

И в заключение

 

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

 

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

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

 

Но это нормально, потому что не документировать все, что у вас есть, и не планировать необходимые улучшения в конечном итоге отнимает еще больше времени и средств.

 

Когда вы выбираете, платить сейчас или платить позже, единственное, на что вы можете рассчитывать, это на то, что платить позже намного хуже.

 

Ссылка на источник


0


Нет комментариев. Ваш будет первым!
Загрузка...