Оптимальный путь к корпоративным архитектурам (Часть 1)
в рубрике ALM, Project Management, Другое
Создание распределенных приложений
Роджер Сешнс (Roger Sessions)
Применение:
- Архитектура приложений
Итерации с декомпозицией
Аннотация. Сешнс представляет рекомендации по созданию эффективной корпоративной архитектуры путем применения итераций с декомпозицией — процесса, основанного на практических следствиях теории вероятностей и стратегии ведения военных действий. Оригинальная статья разделена на три части. Мы публикуем первую часть статьи.
Содержание
- Определение корпоративной архитектуры
История корпоративных архитектур
Примеры внедрения в государственном секторе
Примеры внедрения в частном секторе
Введение
Должным образом работающие корпоративные архитектуры предоставляют широчайшие возможности для поиска эффективных путей применения технологий. Однако если корпоративная архитектура работает плохо, последствия могут быть обратными, так как драгоценные ресурсы организации будут истощаться. И гораздо чаще в организациях происходит именно так.
Нельзя игнорировать преимущества, которые предоставляет эффективная корпоративная архитектура: уменьшение затрат, рост доходов, усовершенствование процессов и появление новых возможностей для бизнеса. В то же время нельзя игнорировать риски, возникающие при использовании неэффективных корпоративных архитектур: гигантские затраты, тупиковые технологические решения и снижение доверия к руководству.
Однако, не стоит отчаиваться: в этой статье показано, каким образом организация может получить описанные выше преимущества и избежать проблем, применяя при создании корпоративной архитектуры принципы двух не зависящих друг от друга теорий: теории вероятностей и стратегии ведения боевых действий.
Теория вероятностей поможет нам понять характер сложности. Я уверен, что ошибки при управлении сложностью являются основной причиной столь частых неудач при создании корпоративных архитектур. Архитектура современных организаций очень сложна, но лишь немногие методики построения корпоративных архитектур предлагают конкретные способы управления сложностью.
Как же управлять сложностью? Ответ на этот вопрос лежит там, где вы его вряд ли ожидали найти — в области стратегии боевых действий. Вы увидите, каким образом опыт пилотов истребителей, которые стремились победить в воздушных боях 50 лет назад, может помочь в создании современных сложных корпоративных инфраструктур.
В заключение я изложу несколько рекомендаций, обобщающих материал статьи и помогающих создать корпоративную архитектуру, которая станет важнейшим активом организации, а не превратится в дорогостоящее бремя.
Определение корпоративной архитектуры
Прежде чем обсуждать корпоративные архитектуры, необходимо найти определение этого термина.
Университет Карнеги — Меллон (в котором работают признанные авторитеты в этой области) предлагает следующее определение:
Корпоративная архитектура — это средство описания бизнес-структур и соединяющих их процессов. [CMU]
В силу своей лаконичности это определение не учитывает ни высоких затрат, с которыми обычно сопряжена разработка корпоративной архитектуры, ни коммерческого обоснования используемых процессов.
Википедия предлагает более полное определение.
Корпоративная архитектура — это практическое применение точного, комплексного метода для описания текущей или будущей структуры подразделений, кадров, информационных систем и процессов организации, позволяющее обеспечить их соответствие стратегическим направлениям развития и основным целям организации. [Wiki]
Определение из Википедии лучше отражает сложность многих современных методологий создания корпоративной архитектуры. Еще более полное определение дает Управление по информационным технологиям правительства США.
Корпоративная архитектура — это стратегический информационный актив, определяющий особенности ведения бизнеса, технологии, необходимые для поддержания коммерческих операций, и переходные процессы, необходимые для внедрения новых технологий в ответ на изменение потребностей бизнеса. [Gov]
Вы уже начали понимать, почему корпоративные архитектуры могут требовать значительных затрат? При создании корпоративной архитектуры необходимо задокументировать огромные объемы информации.
Дороговизна создания корпоративной архитектуры объясняется следующими факторами:
- Длительные сроки, необходимые для всестороннего анализа
- Вовлечение в процесс большого числа высокопоставленных сотрудников организации
- Привлечение большого числа дорогостоящих консультантов, необходимых, чтобы ориентироваться в сложных методиках
Однако так быть не должно. Вот мое определение корпоративной архитектуры, содержащее несколько подсказок относительно возможностей усовершенствования этого процесса.
Корпоративная архитектура — это описание целей организации, способов достижения этих целей с помощью бизнес-процессов и методик повышения эффективности обслуживания бизнес-процессов с применением различных технологий.
Многие скажут, что мое определение является неполным. Однако я не соглашусь. Мое определение подразумевает, что целью организации является не полное документирование каждого бизнес-процесса, базы данных и программной системы, а достижение более практичного результата — повышения эффективности коммерческой деятельности путем применения технологий.
Если повышение эффективности коммерческой деятельности не является основной целью корпоративной архитектуры, значит усилия, потраченные на ее создания, пропали зря. Если кто-то сможет достичь этой цели, не используя длительный и дорогостоящий процесс, я скажу: тем лучше.
Отличия моего подхода от всех остальных начинаются с определения термина архитектура. Слово “архитектура” подразумевает использование проектов, в которых подробно описано множество деталей: от правил соединения крыши со стенами — до трасс прокладки труб и местоположений электрических розеток. Однако в корпоративной архитектуре такая детализация является ненужной и неуместной.
Пытаясь найти новые способы применения технологий для повышения эффективности коммерческой деятельности, мы должны ответить на следующие вопросы:
- Каковы основные цели компании?
- Каким образом коммерческая деятельность разделена на независимые бизнес-процессы?
- Как эти бизнес-процессы связаны друг с другом?
- Какие бизнес-процессы (или отношения между процессами) можно улучшить с помощью технологий?
- В чем состоит план подобных улучшений?
Обратите внимание, что ни один из подходов не предусматривает создания законченной корпоративной архитектуры — корпоративная архитектура рассматривается как изменяющийся набор документов, регламентирующих применение технологий. В этом она больше похожа на план города, а не на проект здания.
Сходство корпоративной архитектуры с планом города впервые было отмечено Армором в 1999 году [Arm], и частично сохраняется и для современных организаций с высоким уровнем сложности.
План города и проект здания предназначены для решения разных задач. План города позволяет ответить на следующие вопросы:
- Какие типы зданий можно будет строить в той или иной зоне (например, коммерческие или жилые)?
- Каким образом здания подключены к городской инфраструктуре (например, к водопроводной и электрической сети)?
- Как однотипные здания будут влиять друг на друга (например, при учете трафика и качества воздуха)?
- Использовались ли при строительстве зданий стандарты, обеспечивающие защиту жильцов (например, стандарты пожарозащищенности)?
Представьте себе город, план которого включает подробный проект каждого здания в городе. Чтобы создать такой план, потребовались бы огромные расходы. И даже если бы он был создан, он был бы негибким и неудобным в работе. Если подумать, он был бы похож на некоторые корпоративные архитектуры, с которым я сталкивался.
История корпоративных архитектур
Принято считать, что направление корпоративных архитектур появилось в 1987 году после публикации в IBM Systems Journal статьи Захмана A framework for information systems architecture (Инфраструктура для архитектуры информационных систем) [Zac]. В дальнейшем Захман переименовал инфраструктуру “информационных систем” в инфраструктуру “корпоративной архитектуры”. Сегодня эта инфраструктура известна как инфраструктура Захмана.
В 1994 году Министерство обороны США представило архитектуру технического обеспечения для управления информацией (Technical Architecture Framework for Information Management, TAFIM) [TAF]. Архитектура TAFIM позиционировалась как новый стандарт корпоративной архитектуры для всех оборонных работ и прошла через ряд итераций, пока не была полностью отменена в 2000 году.
Хотя архитектура TAFIM больше не используется, некоторые ее принципы нашли применение в инфраструктуре архитектуры Open Group (TOGAF). TOGAF — это инфраструктура “с открытым кодом”, контролируемая консорциумом Open Group. В настоящее время используется версия 8.1 [TOG]. По всей видимости, TOGAF — это наиболее популярная на сегодняшний день инфраструктура корпоративной архитектуры из используемых в частном секторе. Несколько реже используется модель Захмана.
В 1996 году развитие корпоративных архитектур ускорилось благодаря принятию Конгрессом США акта Клингера — Коэна, называемого также Законом о реформе управления информационными технологиями (Information Technology Management Reform Act, ITMRA). Этот закон предоставляет Административно-бюджетному управлению США (OMB) широкие права “анализа, отслеживания и оценки рисков и результатов всех крупных капиталовложений в информационные системы, совершаемых органами исполнительной власти”. [Cli]
Акт Клингера — Коэна требует от всех органов исполнительной власти назначать директоров по ИТ, которые, в частности, несут ответственность за “разработку, сопровождение и упрощение внедрения … интегрированной инфраструктуры, предназначенной для развития или сопровождения существующих ИТ-продуктов и приобретения новых ИТ-продуктов, необходимых для достижения стратегических целей соответствующего учреждения и управления информационными ресурсами”. [Cli]
Хотя в акте Клингера — Коэна ничего не говорится о корпоративной архитектуре, OMB расценило этот закон как поручение создать универсальную инфраструктуру корпоративной архитектуры для правительства США в целом. Эта инфраструктура получила название FEAF (Federal Enterprise Architectural Framework) [FEA]. Сегодня OMB требует от всех органов исполнительной власти, от Министерства юстиции до Министерства национальной безопасности и Министерства сельского хозяйства, разработать корпоративную архитектуру и показать, каким образом эта архитектура соотносится с FEAF.
Таким образом, фактическим результатом принятия акта Клингера — Коэна стало то, что все работы, относящиеся к ИТ и проводимые правительственными учреждениями США или для правительственных учреждений США, должны (по крайней мере, теоретически) выполняться в рамках единой, общей корпоративной архитектуры.
Примеры внедрения в государственном секторе
Акт Клингера — Коэна не только обязывает использовать архитектуру Federal enterprise architecture (а именно так его трактуют), но и требует регулярно проводить мониторинг программ и составлять отчеты, позволяя нам увидеть масштабную корпоративную архитектуру в действии.
Фактически перед нами — практический пример использования всеобъемлющей корпоративной архитектуры (FEAF) самой крупной организацией в мире — правительством США. А поскольку на архитектуру FEAF оказали значительное влияние архитектуры TOGAF и Захмана, мы можем экстраполировать на них выводы, полученные при изучении FEAF.
Так как же Правительство США справилось с этой задачей?
По-видимому, не очень хорошо. Не было практически ни одного месяца, в который Счетная палата (GAO), независимый контролирующий орган правительства США, не направило бы крайне негативный отзыв об использовании информационных технологий хотя бы в одном учреждении. Создается впечатление, что чем важнее роль конкретного правительственного органа, тем больше вероятность значительных проблем в работе его ИТ-систем.
В ноябре 2005 года GAO обнаружило следующие проблемы в работе ИТ-систем Налогового управления США (IRS).
Отсутствие высококачественной системы управления финансами, способной своевременно предоставлять точные данные, которые ежедневно нужны для принятия решений, остается серьезным недочетом в управлении IRS. Система управления финансами, используемая IRS в настоящее время, … ограничивает возможности IRS реагировать на оперативные проблемы и проблемы управления финансами, которые необходимо разрешать в ходе работы национального сборщика налогов. [GAO1]
Министерство обороны также неоднократно подвергалось критике. Например, в июне 2005 года в отчете GAO было отмечено следующее:
Значительные недочеты в управлении финансовой и коммерческой деятельностью Министерства обороны не только негативно влияют на способность предоставлять финансовые данные для аудита, но и препятствуют своевременному получению руководством министерства и Конгрессом США точной и полной информации, необходимой для принятия решений. Кроме того, отсутствие надлежащего учета при выполнении всех основных коммерческих операций Министерства обороны приводит к неоправданным ежегодным расходам, исчисляемым миллиардами долларов, в условиях роста бюджетных ограничений и оказывает отрицательное влияние на работу. [GAO2]
В играющем важнейшую роль Министерстве национальной безопасности также существует множество проблем. В августе 2004 года в отчете GAO говорилось следующее:
В Министерстве национальной безопасности полностью или частично отсутствуют все основные составляющие правильно структурированной архитектуры, такие как описания бизнес-процессов, информационных потоков между этими процессами и норм безопасности для этих информационных потоков… Кроме того, при создании основных элементов, которые хотя бы частично присутствуют в начальной версии, не были учтены рекомендации по разработке архитектуры… В результате в Министерстве национальной безопасности отсутствуют проекты архитектуры, необходимые для эффективного внесения изменений в коммерческую деятельность министерства и использования сотен миллионов долларов, вкладываемых министерством в поддержку ИТ-активов, а также для управления этим процессом. [GAO3]
Этот перечень можно продолжать до бесконечности. ФБР долго критиковали за разбазаривание свыше 500 млн долларов, потраченных на неудачный проект по созданию системы управления делами. Федеральное агентство по управлению в чрезвычайных ситуациях потратило более 100 млн долларов на систему, которая оказалась неэффективной при устранении последствий урагана “Катрина”. Критике GAO подверглись и другие правительственные органы, включая Бюро переписи населения, Федеральное авиационное управление, NASA, Министерство жилищного строительства и городского развития, Министерство здравоохранения и социальных служб, а также федеральная программа медицинской помощи престарелым и федеральная система медицинской помощи неимущим.
Однако наиболее парадоксальным, по всей видимости, является то, что одним из подразделений, которые не выполнили требования акта Клингера — Коэна, стало… Административно-бюджетное управление — орган, который должен проверять выполнение этого закона другими правительственными учреждениями!
И если федеральное правительство демонстрирует лучшие примеры внедрения корпоративной архитектуры, то надо признать, что эта технологическая отрасль находится в весьма плачевном состоянии.
Примеры внедрения в частном секторе
Хотя неудачные внедрения в частном секторе не вызывают такого же резонанса в СМИ, компании частного сектора также допускают серьезные промахи при широкомасштабном развертывании ИТ. В частности, можно вспомнить следующие неудачные попытки внедрения корпоративной архитектуры в частном секторе:
- Компания Макдоналдс не смогла создать интегрированную систему управления бизнесом, которая должна была объединить все рестораны
Компании Форд не удалось разработать интегрированную систему закупок. Затраты: 400 млн долларов [For]
Компания KMart не смогла создать современную систему управления каналом поставок. Затраты: 130 млн долларов [Kma]
В статье, появившейся недавно в “Нью-Йорк таймс”, Николас Гарр (Nicholas G. Carr) делает такое заключение:
Глядя на частный сектор, можно прийти к выводу, что неудачи с программным обеспечением являются обыденным явлением. И чем амбициознее проект, тем больше вероятность неудачи. [Car]
В статье, опубликованной недавно в IEEE Spectrum, содержится следующая мрачная оценка:
Принимая во внимание совокупный размер инвестиций в новые корпоративные и государственные программные проекты за последние пять лет, я делаю вывод, что неудачи при реализации этих проектов будут стоить экономике США от 25 до 75 млрд долларов. Разумеется, в эти 75 млрд не включены ни проекты, превысившие бюджет, что происходит с большинством проектов, ни проекты, сроки реализации которых были нарушены, что также происходит в большинстве случаев. Кроме того, в эту сумму не включены скрытые издержки на повторное выполнение остановленного ранее проекта и устранение ошибок в системах, многократно подвергавшихся переработке. [Cha]
И в государственном, и в частном секторе мы раз за разом сталкиваемся с масштабными и дорогостоящими корпоративными архитектурами, не способными удовлетворить требования бизнеса и использовать технологические решения. С учетом вышесказанного можно прийти к выводу, что либо корпоративные архитектуры бесполезны, либо мы используем ошибочные методики создания таких архитектур.
Интуиция подсказывает, что корпоративная архитектура может принести пользу. Поэтому давайте еще раз обратим внимание на определение, которое я уже приводил выше.
Корпоративная архитектура — это описание целей организации, способов достижения этих целей с помощью бизнес-процессов и методик повышения эффективности обслуживания бизнес-процессов с применением различных технологий.
Трудно усомниться в том, что нужно находить более эффективные способы достижения целей организации путем применения технологий. Поэтому остается предположить, что мы ошиблись при выборе методик.
Анонс:
26 марта в Москве пройдет первая Enterprise Developers Conference.
Если вы архитектор предприятия или разработчик в крупной компании, не пропустите это событие.
Прокомментировать
Вы должны быть авторизованы для комментирования.



