Статьи

Роджер Сешнс (Roger Sessions)

Это продолжение статьи Роджера Сешнса “Оптимальный путь к корпоративным архитектурам”. Рекомендуем прочитать первую и вторую части.

Существующие инфраструктуры корпоративной архитектуры

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

Тот факт, что эти модели принадлежат к поколению OODA, очень важен, поскольку он означает, что все эти модели были созданы до появления сервис-ориентированных архитектур (SOA). Сегодня большинство крупных систем основано на концепции взаимодействия автономных приложений с использованием стандартов веб-служб (таких как SOAP, WS-Security и им подобных). Эта концепция тесно связана с парадигмой сервис-ориентированных архитектур, которая не была известна при создании разрабатываемых ранее моделей архитектуры.

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

В 2004 году в крупномасштабном исследовании, посвященном сложности ИТ-систем, академия Royal Academy of Engineering и сообщество British Computer Society отметили следующее:

“…существующие рекомендации и методы разработки ПО не обеспечивают масштабирование, которое позволило бы управлять все более сложными, глобальными распределенными системами с сохранением приемлемого уровня затрат или проектных рисков. Поэтому реагирование на непрекращающееся развитие вычислительных технологий и технологий связи является важнейшей задачей разработчиков ПО”. [Roy]

Проблемы, которые необходимо разрешить для крупных и сложных корпоративных архитектур, относятся к взаимодействию приложений, а не к реализации приложений как таковых. Концепция создания больших систем, состоящих из взаимодействующих автономных приложений, представляет собой технический эквивалент декомпозиции; она получила развитие спустя длительное время после окончания эры Объектов и фактически знаменовала наступление эры SOA.

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

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

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

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

Преимущества подхода на основе итераций с декомпозицией

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

В мире бизнеса TTV это важнейшая характеристика. Даже более важная, чем уровень возврата инвестиций (ROI). ROI — это цель, которая ставится в долгосрочной перспективе. Для любого проекта, даже очень плохо организованного, разработанного со значительным превышением бюджета и не соответствующего требованиям бизнеса, можно по истечении длительного времени добиться высокого значения ROI, когда затраты на проект будут амортизированы. Вопрос в том, проработает ли компания столько времени?

TTV — это характеристика, ориентированная на более близкую перспективу. Хотя существует несколько определений TTV, я использую следующее: TTV — это промежуток времени между утверждением бюджета проекта и моментом, когда руководство убеждается, что проект оказывает положительное влияние на работу организации. Другими словами, это промежуток времени между расходованием средств и получением положительного эффекта. Значение ROI с TTV почти не связано.

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

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

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

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

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

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

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

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

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

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

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

И последнее. Итерационный подход с декомпозицией значительно упрощает дальнейшее расширение возможностей системы по сравнению с OODA-подходом. Это происходит в силу следующих трех факторов:

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

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

При использовании этого подхода основное внимание уделяется времени достижения положительного эффекта (TTV), а не коэффициенту возврата инвестиций (ROI), который является одной из основных характеристик при использовании OODA. Большинство людей думают, что для получения положительных значений ROI необходимы широкие функции приложения. Они полагают, что наличие большего числа функций означает, что приложением сможет воспользоваться больше людей, а чем больше людей им пользуются, тем больше от него «отдачи». Поэтому чрезмерная увлеченность ROI заставляет постоянно наращивать возможности систем.

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

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

более быстрое получение заметной коммерческой выгоды;

повышение вероятности успешного завершения проекта;

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

повышение точности планирования проектов;

повышение уровня соответствия техническим сервис-ориентированным архитектурам;

естественное противодействие необоснованному наращиванию возможностей

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

Слагаемые успеха

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

Правило 1. Сначала используйте простое решение

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

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

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

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

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

Нарисовав схему приоритетов, расположите отметки «попаданий» вдоль каждой оси. Если, например, рассматриваемая подсистема имеет средний риск, поместите отметку на оси рисков в желтую зону. Завершив размещение отметок, вы увидите, какие проекты (подсистемы) следует разрабатывать в первую очередь.

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

Правило 2. Используйте возможности для экономии “в мелочах”

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

К сожалению, эта теория не учитывает основополагающий закон управления проектами: закон снижения эффективности ресурсов. Чем больше людей участвует в работе над проектом, тем ниже эффективность проекта в целом. Этот закон является следствием известного закона Брукса. Более 30 лет назад Фред Брукс (Fred Brooks) был первым, кто заметил, что выделение дополнительных ресурсов для проекта, выполнение которого задерживается, лишь увеличивает задержку [Bro]. В 1999 году за открытие этого закона и другие достижения ему была присуждена Премия Тьюринга

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

Безусловно, с увеличением масштабов мы можем добиться экономии. Однако настоящую экономию можно обеспечить при работе над небольшими, а не над крупномасштабными задачами.

Правило 3. Централизуйте взаимодействие, децентрализуйте реализацию

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

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

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

Давайте рассмотрим некоторые типичные ошибки при создании корпоративных архитектур.

Платформа. Многие организации пытаются выбрать стандартную платформу ПО и нередко ведут бесконечные споры, обсуждая, к примеру, Microsoft .NET, IBM’ WebSphere или BEA WebLogic. Это бесполезная трата сил. Выбор платформы — это решение, которое касается реализации и не влияет на то, как будут организованы совместная работа и взаимодействие приложений на этой платформе. Если платформа удовлетворяет потребности организации в обеспечении взаимодействия, разработчики должны иметь возможность самостоятельно выбирать платформу

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

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

Совместное использование кода. Многие организации считают, что повторное использование компонентов обеспечивается благодаря совместному использованию кода. Удивительно, что это мнение существует, несмотря на неудачные попытки добиться желаемого результата в течение десятков лет. Лучший способ уменьшить объем кода в проекте — делегирование функций (например, с помощью веб-служб), а не совместное использование кода.

Интерфейсы API веб-служб. Многие организации обоснованно полагают, что использование веб-служб является важнейшим условием обеспечения взаимодействия. При этом нередко считается, что это означает обязательную стандартизацию методов использования приложениями интерфейсов API веб-служб. Однако на самом деле интерфейсы API веб-служб лежат намного «ниже» той области, с которой работают приложения. Как правило, приложения используют предоставляемый поставщиком промежуточный уровень (например, предоставляемый платформой Microsoft .NET уровень Windows Communications Framework), избавляющий приложения от необходимости обращаться к сложным интерфейсам API веб-служб. Поскольку каждая платформа использует собственный промежуточный уровень, этот уровень является особенностью реализации приложения.

Из всего вышесказанного можно сделать вывод: корпоративная архитектура и архитектура приложений — это разные понятия. Архитектура приложений определяет возможности приложения, которые должны соответствовать требованиям пользователей этого приложения. Это один из способов, позволяющих добиться экономии в малых масштабах (см. Правило 2. Используйте возможности для экономии “в мелочах”). А корпоративная архитектура описывает, каким образом эти приложения работают вместе, позволяя организации получать коммерческую выгоду.

Заключение

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

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

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

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

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

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

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

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

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

более эффективное применение технологий для разрешения актуальных проблем бизнеса;

значительное уменьшение затрат на создание сложных систем;

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

более эффективное управление совокупными затратами на создание системы;

более точное прогнозирование сроков завершения проекта;

значительное повышение вероятности успешного завершения проекта.

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

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