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

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

 

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

 

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

 

Эта структура позволяет вам идентифицировать и классифицировать то, что у вас есть. Пока все хорошо.

 

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

 

Две точки зрения на техническую архитектуру

 

Описания технической архитектуры делятся на две взаимодополняющие точки зрения: целостный дизайн и представление портфеля.

 

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

 

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

 

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

 

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

 

Связь с бизнес-архитектурой 

 

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

 

Таксономия. Здесь мы говорим о таксономии бизнес-функций. Обычно достаточно трех уровней – возможностей (L1), обязанностей (L2) и процессов (L3). Например, отдел кадров (L1) включает управление компенсациями (L2), которое, в свою очередь, включает расчет заработной платы (L3), так же как отдел финансов и бухгалтерского учета (L1) включает дебиторскую задолженность (L2), которая включает сборы (L3). Если вы хотите полностью соответствовать модным словам, назовите эту таксономию своей BCM (моделью бизнес-возможностей).

 

Отображение. Второй ключевой элемент – это отображение того, на какие приложения опирается каждая функция в BCM. У бизнес-архитекторов может возникнуть соблазн сопоставить их на уровне возможностей, но без сопоставлений L2 и L3 модель бизнес-возможностей будет иметь ограниченную полезность.

 

Оценка. Третья ключевая информация – это оценка общей эффективности каждой функции BCM.

 

Важность. Остается четвертый и самый спорный вопрос: относительная важность каждой бизнес-функции. Два совета по этому поводу: (1) Определите важность как влияние на конкурентное преимущество; и (2) оцените их, а не ранжируйте.

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

* Функциональность. Это критерий «Капитана Очевидность» – делает ли компонент то, что нужно бизнесу, или нет.

* Гибкость. Насколько хорошо компонент адаптируется к новым и меняющимся ситуациям.

* Стабильность и производительность. Снова «Капитан Очевидность». Приложение, платформа или компонент инфраструктуры, который часто выходит из строя и работает ужасно медленно, когда он доступен, – это проблема.

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

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

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

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

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

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

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

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

 

Подсчет очков

 

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

 

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

 

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

 

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

 

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

 

Что дальше?

 

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

 

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

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

 

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