«For Exam 70-100 Scott F. Wilson Bruce Maples Tim Landgrave МююзоП Press Принципы проектирования и разработки программного обеспечения Официальное пособие Microsoft для самостоятельной подготовки к экзамену 70-100 Скотт ...»

Analyzing

Requirements and

Defining Solution

Architectures

For Exam 70-100

Scott F. Wilson

Bruce Maples

Tim Landgrave

МююзоП Press

Принципы

проектирования

и разработки

программного

обеспечения

Официальное пособие Microsoft

для самостоятельной подготовки

к экзамену 70-100

Скотт Ф. Уилсон

Брюс Мэйплс

Тим Лэндгрейв

Москва 2002

Н. Р Ш Ш ШИШ

УДК 004.45

ББК 32.973.26-018.2 М59 Microsoft Corporation М59 Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD/Пер. с англ. — 2-е изд., испр. — М: Издательско-торговый дом «Русская Редакция», 2002. — 736 стр.: ил.

ISBN 5-7502-0213^ Настоящий учебный курс посвящен разработанной компанией Microsoft методологии проектирования и разработки программного обеспечения Microsoft Solutions Framework. Эта методология вобрала в себя последние достижения в области проектирования и разработки приложений масштаба предприятия. Значительное внимание уделено вопросам управления проектами разработки программного обеспечения.

Книга адресована менеджерам проектов и разработчикам программного обеспечения. Кроме того, этот учебный курс рекомендован корпорацией Microsoft для самостоятельной подготовки к обязательному экзамену №70-100 по программе сертификации разработчиков Microsoft Certified Solution Developer (MCSD).

Книга состоит из 14 глав, 10 практикумов, приложения и предметного указателя. К учебному курсу прилагается компакт-диск с учебными и демонстрационными материалами словарем терминов, электронной версией учебного курса и программным обеспечением для проведения экзаменационного теста.

УДК 004. ББК 32.973.26-018. Подготовлено к изданию по лицензионному договору с Microsoft Corporation. Редмонд. Вашингтон, США.

ActiveX, JScript, Microsoft, Microsoft Press, MSDN, MS-DOS, PowerPoint, Visual Basic, Visual C++, Visual InterDev. Visual SourceSafe, Visual Studio, Win32, Windows и Windows NT являются товарными знаками или охраняемыми товарными знаками корпорации Microsoft в США и/или других странах. Все другие товарные знаки являются собственностью соответствующих фирм.

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

© Оригинальное издание на английском языке, Microsoft Corporation, © Перевод на русский язык, Microsoft Corporation. -7 (англ.) g, оформление и подготовка к изданию, издательскоISBN 5-7502—0213—5 торговый дом «Русская Редакция", Содержание Об этой книге XVII Часть I. Методология Глава 1. Производственная архитектура Что такое архитектура От концепции к практике Задачи информационной инфраструктуры Производственная архитектура и задачи ИТ Задача производственной архитектуры Принципы разработки приложений MSF Модель производственной архитектуры Модель проектной группы Модель процесса разработки ПО Модель управления рисками Модель процесса проектирования Модель приложения MSF в этой книге Модель производственной архитектуры MSF Бизнес-перспектива Прикладная перспектива Информационная перспектива Технологическая перспектива Четыре перспективы — одна архитектура Как соотнести цели бизнеса и ИТ Основные опасности при разработке производственной Задачи модели производственной архитектуры MSF Миф о всеохватывающей и всепроникающей архитектуре Движение от существующей архитектуры к желаемой Производственная архитектура и конкретные проекты Планирование во время разработки и разработка во время Практикум 1. Разработка производственной архитектуры Прогнозирование, реагирование и версии Глава 2, Приложения масштаба предприятия Характеристики приложений масштаба предприятия Архитектура производственных приложений Основные принципы разработки приложений Средства, используемые на разных фазах проекта Проектирование с помощью модели производственного Повышение эффективности коллективной работы Практикум 2. Знакомьтесь: проектная группа Фазы процесса разработки MSF и их основные результаты Разбиение больших проектов на управляемые части Рекомендации по организации выпуска версий продукта Роли членов группы в модели процесса разработки Особенности модели процесса разработки MSF Этап «Одобрение концепции» и его результаты Другие области применения аналитического подхода Фаза «Планирование» и процесс проектирования Распределение ролей при планировании )( Содержание Этап «Одобрение плана проекта» и его результаты Пересмотренный документ оценки рисков Знако\^тво с процессом проектирования Совещание группы архитектуры и разработчиков Глава?, Технологии пользовательского уровня Выбор архитектуры пользовательского уровня Элементы пользовательского интерфейса Создание пользовательского интерфейса Реализация пользовательского уровня Связывание пользовательского и прикладного уровней Доставка бизнес-объектов на клиентский компьютер Доступ к бизнес-объектам в «родных» приложениях Доступ к бизнес-объектам из Web-приложений Доступ к удаленным объектам с помощью RDS Глава 8. Технологии прикладного уровня Основные прикладные сервисы Windows NT Особенности проектирования приложений Интерфейсы прикладного программирования Доступ к данным на традиционных системах COMTI и интеграция данных на мэйнфреймах Упрощение применения транзакций средствами COMTI Различия между технологиями Windows-платформ Глава 10. Тестирование и производственный цикл Тестирование приложений масштаба предприятия Определение требуемой производительности Подбор тестов для определения производительности Масштабирование производственной среды Конфигурация 3: SQL Server на отдельном узле Конфигурация 4: каждая база данных на отдельном узле Конфигурация 5: распределенная база данных Конфигурация 6: распределенное приложение Защита сервисов операционной системы Глава 12 Стадия «Разработка» и ее результаты Связь фаз «Проектирование» и «Разработка» Распределение обязанностей на стадии разработки Этап «Завершение разработки» и его результаты Пересмотренные функциональные спецификации Пересмотренный сводный документ оценки рисков Средства повышения эффективности работы пользователей Этап I: версии, появляющиеся по мере устранения ошибок... Материалы для сопровождения приложения и поддержки Развертывание промежуточных выпусков продукта Сосуществование данных и версий Рекомендации по проведению встречи Группа, организующая обсуждение проекта Представление и обсуждение рекомендаций Практикум 10. Выпуск приложения Готовы ли мы к встрече с пользователями? Об этой книге Мы рады представить вам учебный курс «Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD», предназначенный для подготовки к экзамену 70-100 по программе сертификации специалистов Microsoft Certified Solution Developer (MCSD).

Примечание Дополнительную информацию о программе сертификации разработчиков по программе Microsoft Certified Solution Developer см. в разделе «Программа сертификации специалистов Microsoft».

Кому адресована эта книга Настоящий учебный курс адресован всем, кто хочет изучить методы анализа требований к программным системам и проектирование архитектуры решений. В книгу включены следующие темы: разработка распределенных приложений с помощью методики Microsoft Solutions Framework (MSF), разработка многоуровневых приложений и приложений архитектуры клиент-сервер, создание компонентов для работы под управлением сервера транзакций Microsoft Transaction Server (MTS) и специализированных интерфейсов модели компонентных объектов (Component Object Model, COM).

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

Как минимум, от вас требуются:

• основные навыки программирования;

• умение создавать и компилировать простые приложения;

• понимание основ реляционных баз данных.

С чего начать Настоящий учебный курс поможет вам подготовиться к экзамену 70-100: Analyzing Requirements and Defining Solution Architectures. Для изучения материала вам не потребуется ни компьютер, ни программное обеспечение. Однако, если вы захотите познакомиться с учебным приложением «Система управления ресурсами» (Resource Management System, RMS), активно используемым в практикуме, вам понадобится аппаратное и программное обеспечение, о котором подробнее рассказано в следующих разделах.

Требования к аппаратному обеспечению для работы с учебным приложением Конкретные требования к аппаратуре, необходимой для работы Microsoft Windows NT Server, Microsoft Internet Information Server, Microsoft Transaction Server и Microsoft SQL Server приведены в документации к этим программным продуктам, Минимальные рекомендуемые конфигурации сервера и клиентской рабочей станции таковы:

• Pentium II 266 МГц или другой процессор эквивалентной мощности;

• 128 Мб памяти;

• жесткий диск 4 Гб;

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

• дисковод для компакт-дисков.

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

Программное обеспечение, устанавливаемое на сервере:

• Windows NT Server 4.0 с установленным сервисным пакетом 4;

• Windows NT Option Pack 4, Internet Information Server 4.0 и Microsoft Transaction Server 2.0:

• Microsoft Exchange Server 5.5 с сервисным пакетом 2;

• Microsoft Collaborative Data Objects 1.21 и Microsoft Outlook 98/ (на компьютере, где установлен Microsoft Transaction Server и бизнес-компоненты приложения RMS):

• Microsoft SQL Server 7.0;

• Microsoft Data Access Components 2.1;

• Microsoft Internet Explorer 4.01 (или следующая версия).

Программное обеспечение, устанавливаемое на клиентской рабочей станции:

• Windows NT Server 4.0 с установленным сервисным пакетом 4, Windows 98 или Windows 95 (с установленной поддержкой DCOM95);

• распространяемые компоненты Microsoft Data Access 2.1 устанавливаются одновременно с клиентским ПО учебного приложения;

дополнительно необходимо установить распространяемые компоненты ADOR 1.5;

• Internet Explorer 4.01 или более поздняя версия;

• Microsoft Outlook 98/2000.

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

Ниже кратко описаны главы и приложения учебного курса.

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

• Глава 1 «Производственная архитектура»: в этой главе вы узнаете, почему разработку приложений и развитие инфраструктуры надо ориентировать на базовые концепции уровня предприятия. Здесь рассмотрена концепция разработки систем с позиции «приоритета архитектуры», созданные компанией Microsoft принципы разработки приложений Microsoft Solutions Framework (MSF), рассматривающие архитектуру с точки зрения бизнеса, приложений, информации и технологии, организация процесса разработки производственной архитектуры и создание систем и приложений, когда производственная архитектура еще не сформирована.

• Глава 2 «Приложения масштаба предприятия» начинается с описания функций современных производственных приложений и проблем, связанных с ними. Затем вы познакомитесь с десятью принципами успешного создания программных продуктов и проектированием крупномасштабных распределенных производственных приложений. Кроме того, здесь описаны методы снижения сложности таких проектов и модель производственных приложений, разработанная компанией Microsoft. В заключение обсуждается каркас архитектуры приложений, представленный в модели разработки приложений MSF.

• Из главы 3 «Проектные группы» вы узнаете, кто же непосредственно выполняет проект, познакомитесь с принципами создания проектных, групп в контексте модели проектной группы MSF и с обязанностями членов проектной группы. Мы начнем с поиска кандидатов на роль руководителей и расскажем о шести основных направлениях работы группы. Затем мы познакомим вас с обязанностями участников проекта и их распределением среди членов группы. Далее мы расскажем о способах анализа требований к проекту с точки зрения его участников, методах масштабирования группы в соответствии с его значением и размером и, наконец.

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

Глава 4 «Процесс разработки» посвящена модели процесса разработки приложений MSF (MSF Process Model for Application Development), или, короче, модели процесса разработки. Эта модель гибкий компонент обшей модели процесса MSF, с успехом применяемый в индустрии разработки программного обеспечения для повышения управляемости проектов, минимизации рискон, повышения качества продукции и ускорения разработки. Кроме того, в этой главе вы познакомитесь с практическими рекомендациями по проведению формального рецензирования, с критериями отбора участников этой процедуры и методами ее организации. Мы покажем, как организовывать и проводить соответствующие совещания, как собирать и документировать информацию. В завершение мы обсудим создание и роль специальной обзорной группы в больших проектах.

В главе 5 «Предпроект» мы опишем динамику фазы «Анализ» модели процесса разработки MSF. Мы обсудим, какую информацию необходимо получить от участников проекта и как создавать концепцию продукта, расскажем о партнерстве различных ролей в проектной группе, созданной в соответствии с моделью группы разработчиков MSF, и выясним, какова область ответственности каждой роли на фазе «Анализ». Мы также посмотрим, как процесс исследования развивается во времени, и наконец, детально обсудим процесс управления рисками, базирующийся на модели управления рисками MSF.

В главе 6 «План проекта» в общих чертах описан переход от «теории» к «практике» и рассказано о задачах проектной группы на стадии «Планирование». Мы подробно рассмотрим модель процесса разработки MSF наряду с концептуальной, логической и физической архитектурой приложения и интеграцию различных уровней модели приложения MSF (пользовательского, прикладного и уровня данных) в физическую архитектуру приложения.

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

Из главы 7 «Технологии пользовательского уровня» вы узнаете, как создавать эффективный пользовательский интерфейс (User Interface, UI) и пользовательские сервисы. Мы расскажем об уже существующих технологиях, влияющих на дизайн пользовательского уровня модели приложения MSF, об их перспективах и о воздействии Web-технологий на современные методы проектирования приложений. В начале главы обсуждаются проектирование пользовательских сервисов и разные типы пользовательского интерфейса.

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

В главе 8 «Технологии прикладного уровня» обсуждаются вопросы.

решение которых необходимо для обеспечения корректной работы бизнес-сервисов приложения, включая использование контекста объекта для управления состоянием, использование явно определенных интерфейсов, функциональный состав компонентов, сохранение состояния в границах транзакции, контроль ошибок и программное управление зашитой. Кроме того, в этой главе описана компонентная объектная модель (Microsoft Component Object Model, COM) и ее применение в бизнес-сервисах приложения.

Глава 9 «Технологии уровня данных» посвящена особенностям проектирования, связанным с данными, включая реализацию сервисов доступа к данным. Мы познакомим вас с характеристиками различных технологий доступа и рассмотрим способы их использования, обсудим нормализацию данных, вопросы целостности, влияние бизнес-правил на данные и поясним, где эти правила лучше реализовать. Потом мы обсудим технологии доступа к данным, хранящимся в традиционных системах и приложениях управления ресурсами предприятия (Enterprise Resource Planning, ERP), например, SAP R/3 фирмы SAP AG. В заключение мы обсудим базу данных в памяти (ln-Memory Database, IMDB), которая позволяет повысить производительность работы с данными.

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

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

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

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

Глава 13 «Стабилизация продукта» посвящена фазе «Стабилизация»

модели MSF, когда проектная группа заканчивает разработку продукта и переходит к завершающим этапам его выпуска. Мы обсудим переход от этапа «Завершение разработки» фазы «Разработка»

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

Глава 14 «Обсуждение проекта» посвящена методам организации обсуждения завершенных проектов. Мы покажем, что практика рецензирования завершенных проектов позволяет повысить качество управления этими проектами, рассмотрим взаимосвязь обсуждения завершенных проектов с моделью зрелости разработки программного обеспечения (Capability Maturity Model for Software, CMM) и поясним, насколько велико значение рецензирования проектов для выработки оптимальных приемов работы. Кроме того, в этой главе вы познакомитесь с практическими рекомендациями по проведению формального рецензирования, с критериями отбора участников этой процедуры и методами ее организации.

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

Структура книги • Структура книги отражает последовательность разработки приложения.

• Каждая глава начинается с раздела «В этой главе*, где кратко перечислены обсуждаемые темы.

• В каждой главе приведен список дополнительных материалов по теме занятия.

• В разделе «Резюме» обобщены основные вопросы, затронутые в данной главе.

• Каждая глава завершается разделом «Закрепление материала», содержащим контрольные вопросы. Они помогут вам оценить, насколько вы усвоили материал. Ответы на вопросы вы найдете в приложении «Вопросы и ответы».

• В практикуме описана разработка многоуровневого распределенного приложения сотрудниками вымышленной фирмы «Фергюсон и Барделл». Авторы постарались проиллюстрировать эффективность работы в группе. Действующие лииа практикума и само приложение подробно описаны в разделе «Практикум» этой главы.

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

• Курсивом выделены новые термины; курсивом же даны цитаты из других книг.

• Имена файлов, папок и каталогов набраны с прописных букв.

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

• Расширения имен файлов набраны строчными буквами, • Аббревиатуры набраны прописными буквами.

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

• Необязательные элементы синтаксических операторов взяты в квадратные скобки []. Если, например, в синтаксисе команды приведен параметр [имя_файла\, то это значит, что вы можете (но не обязаны) задать имя файла в качестве параметра команды. При этом достаточно ввести только имя файла — сами скобки набирать не нужно.

• Обязательные элементы синтаксических операторов выделены фигурными скобками {}. Набирать следует только информацию, взятую в скобки — сами скобки набирать не нужно, Содержимое компакт-диска Компакт-диск учебного курса содержит электронную версию книги, а также программное обеспечение для сдачи тестового экзамена (он аналогичен реальному экзамену 70-100: Analyzing Requirements and Defining Solution Architectures). Воспользовавшись программным обеспечением, разработанным компанией Self-Test Software (STSl, вы проверите знания и навыки, которые вам придется продемонстрировать на сертификационном экзамене. Для каждого вопроса приведен ответ со ссылками на материал учебного курса и другие справочные материалы. Полный список сертификационных экзаменов, к которым можно подготовиться средствами программного обеспечения компании Self-Test Software (STS), вы найдете на Web-узле компании по адресу www.selfteslsofrware.com.

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

Практикум Концепции, излагаемые в учебном курсе, иллюстрируются в главах практикума. Это рассказ о вымышленной компании «Фергюсон и Барделл», сотрудники которой анализируют требования, проектируют архитектуру и разрабатывают конкретное приложение, применяя концепции, описанные в учебном курсе. Назначение практикума проиллюстрировать применение концепций процесса разработки на практике и помочь разобраться в том, как использовать его в проектах. Сама компания и ее сотрудники описаны в следующем разделе.

Внимательно прочитайте его, прежде чем приступать к изучению учебного курса.

Учебное приложение «Система управления ресурсами» (Resource Management System, RMS), о котором говорится в практикуме, — это реальное многоуровневое распределенное приложение, работающее с двумя хранилищами данных и использующее для управления ресурсами компании основные технологии корпорации Microsoft (Microsoft Visual Basic 6.0, Active Server Pages, Dynamic HTML, Microsoft Outlook 98.

Microsoft Transaction Server 2.0, Microsoft Exchange Server 5.5, Microsoft SQL Server 7.0 и т. д.). Помимо исполняемых модулей и исходных кодов, на компакт-диске вы найдете документацию, которая служит примером документов, создаваемых проектной группой в процессе разработки. Учебное приложение — это система управления ресурсами начального уровня, отслеживающая занятость сотрудников компании и обеспечивающая доступ к информации об их квалификации и работе над проектами. Это приложение создано двумя разработчиками за два месяца, что свидетельствует в пользу как их квалификации, так и технологий, избранных для создания решения.

Требования к аппаратному и программному обеспечению для работы с учебным приложением описаны ранее в разделе «С чего начать».

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

Сейчас мы познакомим вас с историей и специализацией компании и ее сотрудниками.

Компания «Фергюсон и Барделл» — чикагская компания, занимающаяся архитектурными и проектными решениями в сфере строительства. В настоящее время годовой оборот компании, основанной двумя ветеранами второй мировой войны в 1948 году, составляет около 230 млн.

долларов; в ней работает около 800 сотрудников. Штаб-квартира компании занимает семь этажей в престижном небоскребе в центре Чикаго; у компании есть отделения в Детройте, Милуоки, Цинцинати, Индианаполисе и Луисвилле.

Компания «Фергюсон и Барделл» давно и активно использует информационные технологии, однако ее подход к развитию информационной инфраструктуры не отличался последовательностью. Это привело к чрезмерной «пестроте» форматов хранения информации в региональных отделениях, откуда данные поступают в центральный офис по модему или с курьером. Кроме того, до самого последнего времени в компании использовалось три программы редактирования текста, в том числе давно устаревшее приложение для мэйнфреймов.

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

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

Новый директор по ИТ, приступивший к исполнению своих обязанностей в октябре 1998 года, представил блестящие рекомендации от своего предыдущего работодателя — местной юридической компании, где он за пять лет прошел путь от администратора сети до директора по ИТ. Прежний директор «Фергюсон и Барделл* по ИТ, который предпочел покинуть компанию, несколько лет пытался создать новую инфраструктуру и связать все региональные подразделения «Фергюсон и Барделл» через Интернет. В результате новому директору понадобилось некоторое время на ознакомление с ситуацией, прежде чем он смог заняться новыми проектами. Первые три месяца он знакомился с сотрудниками, изучал особенности бизнеса и делопроизводства в компании и потихоньку вводил в практику новые методы работы.

В январе он пригласил сертифицированного инструктора, чтобы познакомить своих основных сотрудников с методологией разработки Microsoft Solutions Framework (MSF). Реакция сотрудников была далеко не единодушной — кто-то проявил энтузиазм, кто-то реагировал скептически, а часть сотрудников решила, что новому директору просто нечем заняться. Однако директор не отступал, поскольку был твердо уверен, что лишь четкая методика реализации проектов, основанная на постоянном обмене информацией между ИТ-отделом и бизнес-подразделениями, позволит компаниидобиться положительных результатов.

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

Для построения корпоративной архитектуры директор по ИТ решил собрать группу в следующем составе.

• Дэн Шелли, директор по ИТ. Ему чуть больше сорока, он влюблен в свое дело, информационные технологии и «Чикаго Булле» (не обязательно в указанном порядке). Его любят и уважают. Члены совета директоров ценят его понимание дела, а коллегам в отделе импонирует то, что он прошел все ступени служебной лестницы.

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

• Дженни Сакс, сетевой инженер. Она год назад закончила колледж и с тех пор работает в группе сопровождения сети компании «Фергюсон и Барделл». За это время она приобрела репутацию человека, документирующего каждый шаг. Первое в компании руководство по работе с пользователями появилось, как в сказке, в понедельник утром после того, как она провела всю пятницу в беседах с раздосадованными пользователями. Дженни очень въедлива и никогда не упускает шанс научиться чему-то новому.

• Кевин Кеннеди, специалист по менеджменту. Кевин — член комитета по долгосрочному планированию. Весь прошлый год он работал вместе с исполнительным директором и занимался оптимизацией процессов планирования и финансирования. За глаза его называют нахалом, но все понимают, что он быстрыми шагами идет к должности исполнительного директора, которая должна освободиться через четыре года. Он поработал на всех управляющих должностях компании и заработал репутацию человека, делающего свое дело несмотря ни на что, • Джозефина (Джо) Браун, заместитель директора по производству. В прошлом году, когда никто не хотел браться за провальный проект проверки готовности компании к 2000 году, Джо взяла эту неприятную обязанность на себя и отлично справилась с ней. Закончив проект на пять месяцев раньше срока, Джо вернулась к своим обязанностям — обеспечению бесперебойной работы компании. Ее последняя работа — создание руководства, которое должно помочь упростить делопроизводство. Все знают, что лучше придерживаться этого руководства — иначе вал гневных электронных писем от заместителя директора им обеспечен.

Дик Кип л а и, аналитик. В каждой компании есть свой сумасшедший; в «Фергюсон и Барделл» это Дик Каплан. В прежней жизни Д и к был профессором философии; за его плечами диссертация и несколько книг. Однако в начале 80-х он решил начать новую жизнь и занялся консультированием. Десять лет назад он пришел в «Фергюсон и Барделл», где до сих пор и работает — аналитиком.

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

Хотя корпоративная архитектура все еще находится в стадии разработки, Дэн решил приступить к новому проекту — созданию системы учета ресурсов — по методике MSF. Для этого он создал проектную группу.

Билл Парди, заведующий отделом разработки. Билл работает в компании с тех пор, как демобилизовался в 1978 году. Он медленно.

но верно шел вверх по служебной лестнице, начав с работы на устройстве по подготовке перфокарт, и наконец добрался до разработки приложений баз данных для персональных компьютеров на базе dBase III и Paradox. Он стал заведующим отделом в 1996 году после того, как в течении двух лет руководил группой из 35 разработчиков, «с нуля» создававших для «Фергюсон и Барделл» новый бухгалтерский пакет. Хотя проект затянулся на полгода и обошелся на 40% дороже, чем планировалось, все были уверены, что, если бы не Билл, все было бы гораздо хуже.

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

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

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

• Мэри-Лу Морис, инструктор. Независимый инструктор из Чикаго и любимица всех сотрудников «Фергюсон и Барделл». Она читает лекции в разных компаниях и в центрах подготовки по всему северо-востоку США. Ее курсы неоднократно слушали и сотрудники Джейн, причем за это время Мэри-Лу с Джейн стали подругами. Именно Джейн порекомендовала ее Дэну, узнав, что в проектной группе требуется инструктор.

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

Материалы для подготовки к экзамену В приведенных ниже таблицах перечислены темы сертификационного экзамена 70-100: Analyzing Requirements and Defining Solution Architectures с указанием глав учебного курса, где обсуждаются соответствующие вопросы.

Анализ требований Анализ предметной области, включая существующие реше- 1, 2, 4, ния, возможные изменения среды, время жизни решения, возможные компромиссы между затратами времени и средств и характеристиками решения Анализ бизнес-требований • определение типа решения (например, система сооб- :• щений или коммуникационное приложение) • обеспечение быстрого возврата инвестиций в проект 3. 5, 6, • учет инфраструктуры и платформ в проектировании решения • выявление и учет необходимости перехода на новые I технологии • выявление физических требований, включая • планирование среды, необходимой для работы прило- 6—9, жения, включая аппаратные платформы, операционные системы и вопросы сопровождения • выявление ограничений, вызванных организационной 1, 3, структурой, включая финансовую ситуацию, политику компании, уровень технической подготовки персонала и необходимость в дополнительной подготовке Анализ требований к защите • анализ ролей и групп пользователей решения • ограничения, накладываемые существующей средой • требования в отношении сопровождения решения • распространение базы данных системы зашиты Анализ требований к производительности, включая: необ- 2, ходимую скорость обработки транзакций, полосу пропускания, число обслуживаемых пользователей, соответствие стандартам, соотношение между пиковой и средней нагрузкой, необходимое и нынешнее время отклика, ожидаемые проблемы Анализ требований к сопровождению, включая: распро- 3, 10, страненность приложения, методы распространения, ожидаемые затраты на сопровождение, местонахождение и необходимый уровень квалификации службы поддержки, учет существующих соглашений с внешними службами технической поддержки Анализ требований к расширению, включая: учет 10, 3, расширения функциональных возможностей продукта Анализ требований к доступности, включая: планируемый распорядок использования, степень доступности и последствия простоя Анализ человеческого фактора, включая: пользовательскую 3, аудиторию, необходимость локализации, средства доступа для инвалидов, наличие мобильных пользователей, справочную службу, требования по подготовке пользователей и ограничения, накладываемые физической средой Анализ требований, накладываемых интеграцией с суше- ствующими приложениями, включая: традиционные приложения, формат и местонахождение накопленных данных, совместимость с существующими приложениями, необходимость преобразования и более эффективного использования данных Анализ бизнес-процессов и накладываемых ими ограничений, 1, 3, включая: юридические ограничения, практику ведения дел, структуру организации, управление процессами, бюджет, методики развертывания решений и подготовки пользователей, требования контроля качества и пожелания пользователей Анализ требований к масштабированию, включая: возможное 1, 3- расширение аудитории, рост организации, увеличение объема данных и особенности использования Выбор архитектуры решения Выбор типа решения (одноуровневое, двухуровневое 1, или N-уровневое) в конкретной ситуации Выбор технологий для реализации решения с учетом еле- 2, 7—9, дуюших вопросов: технологические стандарты (EDI, Интернет, OSl. COMTI, POSIX), технологии, требующие лицензирования, нынешняя и планируемая технологическая инфраструктура компании, выбор средств разработки Выбор архитектуры хранилища данных с учетом следующих 1, 2, 5, 6, вопросов: объем, число транзакций в единицу времени, число подключений или сеансов, требования бизнес-среды, необходимость расширения, число пользователей и тип базы данных Проверка реализуемости выбранной архитектуры, включая: 5, 6, демонстрацию соответствия бизнес-требованиям, демонстрацию соответствия сценариям использования, демонстрацию учета технологических ограничений, учет последствий невозможности реализации отдельных требований Концептуальное и логическое проектирование Разработка концепции, учитывающей различные сценарии, контекст, бизнес-процессы, последовательность выполнения отдельных задач и модели среды.

Типы решений: однооконные, многооконные, консольные 5, и диалоговые приложения для настольных систем; двухуровневые, клиент-серверные и Web-приложения; N-уровневые приложения и приложения для коллективной работы Применение принципов модульного проектирования к концеп- 5, ции для выделения компонентов и сервисов, образующих логический проект Учет бизнес-требований при проектировании объектов 5, Оценка влияния логического проекта на производительность, 10, простоту сопровождения, возможность расширения, масштабируемость, доступность и защиту Проектирование моделей данных Организация данных с применением правил нормализации Выбор внешних ключей для обеспечения целостности Учет бизнес-требований и ограничений в модели данных 10, Разработка базы данных с учетом стандартов и практики разработки БД Разработка пользовательского интерфейса и сервисов пользовательского уровня Выявление процедур проверки вводимой информации, которые надо интегрировать в пользовательский интерфейс Оценка и выбор архитектуры справочной системы (строка состояния, советы и справочные файлы) Создание прототипа пользовательского интерфейса с учетом 1, 4, бизнес-требований, правил проектирования интерфейса и стандартов, принятых в организации Анализ необходимости использования элементов управления на базе меню Анализ необходимости использования клавиатурных сокра- 1. 4, щений для ускорения выполнения различных функций Физическое проектирование Оценка влияния физического проекта на производительность, 6, 9- простоту сопровождения, возможность расширения, масштабируемость, доступность и защиту Оценка необходимости объектной инкапсуляции доступа к БД 8, Проектирование свойств, методов и событий для конкретных 6, компонентов Программа сертификации специалистов Microsoft Программа сертификации специалистов Microsoft (Microsoft Certified Professional, MCP) — отличная возможность подтвердить знание современных технологий и программных продуктов этой фирмы. Компания Microsoft, лидер в области сертификации, разработала соврем е н н ы е методы тестирования. Они убедительно подтвердят вашу квалификацию разработчика или специалиста по реализации решений на основе технологий и программных продуктов Microsoft. Профессионалы, сертифицированные компанией Microsoft, квалифицируются как эксперты и пользуются огромным спросом на рынке труда.

В апреле 2002 г. вниманию соискателей предлагались следующие типы сертификации.

• Сертифицированные специалисты по продуктам Microsoft (Microsoft Certified Professional) — требует досконального знания как минимум одной операционной системы Microsoft. Кандидаты могут слать дополнительные экзамены, что подтвердит их право на работу с продуктами Microsoft BackOffice, инструментами или прикладными программами.

Сертифицированные специалисты по продуктам Microsoft и Интернету (Microsoft Certified Professional + Internet, MCP + Internet) планирование систем защиты, установка и конфигурирование серверных продуктов, управление ресурсами сервера, расширение возможностей сервера средствами сценариев интерфейса общего шлюза (Common Gateway Interface, CGI) и интерфейса прикладного программирования сервера Интернета (Internet Server Application Programming Interface, ISAPI), мониторинг работы сервера, анализ его производительности и устранение неисправностей.

Сертифицированные специалисты по продуктам Microsoft и проектированию Web-узлов (Microsoft Certified Professional + Site Building, MCP + Site Building) — проектирование, создание, управление и поддержка работы Web-узлов с использованием технологий и продуктов корпорации Microsoft.

Сертифицированные системные администраторы Microsoft (Microsoft Certified Systems Administrator, MCSA) — реализация, управление и устранение неполадок в существующих системах на основе Windows 2000, включая Windows.NET Server.

Сертифицированные разработчики Microsoft (Microsoft Certified Solution Developer, MCSD) — разработка и создание прикладных приложений с применением инструментов, технологий и платформ Microsoft, а также архитектуры Windows DNA.

Сертифицированные системные инженеры Microsoft (Microsoft Certified Systems Engineer, MCSE) — проектирование и реализация инфраструктуры для бизнес-решений на базе платформы Windows 2000 и серверных продуктов Microsoft.

Сертифицированные администраторы баз данных Microsoft (Microsoft Certified Database Administrator, MSDBA) — разработка физической структуры баз данных, проектирование логических моделей БД, создание БД и сервисов данных средствами TransactSQL, администрирование и сопровождение БД, настройка и сопровождение системы защиты, установка и конфигурирование Microsoft SQL Server.

Сертифицированные инструкторы Microsoft (Microsoft Certified Trainer, MCT) — теоретическая и практическая подготовка для ведения соответствующих курсов в авторизованных учебных центрах Microsoft.

Набор доступных сертификации постоянно обновляется в соответствии с требованиями компьютерной индустрии. Для получения самой свежей информации о них и о требованиях, предъявляемых к соискателям, обращайтесь на Web-узел корпорации Microsoft по адресу http://www.microsoft.com/rus/mcp.

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

Индивидуальная сертификация Вот какие преимущества дает звание Microsoft Certified Professional:

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

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

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

• доступ к специальным форумам MSNTM, The Microsoft Network и CompuServe, которые позволяют сертифицированным специалистам контактировать с Microsoft и друг с другом;

• приглашения на конференции, практикумы и специальные мероприятия Microsoft, предназначенные для специалистов;

• сертификат «Microsoft Certified Professional».

Кроме того, в зависимости от типа сертификации и страны, сертифицированные специалисты получают:

• годичную подписку на ежемесячно распространяемые компактдиски Microsoft TechNet (Technical Information Network).

XXXVI • годичную подписку на программу бета-тестирования продуктов Microsoft; в результате вы бесплатно получите до 12 компакт-дисков с бета-версиями новейших программных продуктов.

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

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

• позволяет увеличить эффективность обслуживания клиентов, повысить производительность и снизить расходы на сопровождение;

• обеспечивает надежные критерии для найма специалистов и их продвижения по службе;

• предоставляет методы оценки эффективности труда персонала;

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

• позволяет оценить партнеров — сторонние фирмы.

Дополнительную информацию о том, какую пользу ваша компания извлечет из сертификации, см. на странице http://www.microsoft. com/rus/mcp/mcp_benef. html.

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

Издательство Microsoft Press публикует постоянно обновляемый список исправлений и дополнений к своим книгам по адресу:

http://mspress.microsoft.com/support.

Если у вас все же возникнет вопрос или комментарий, обращайтесь в издательство Microsoft Press по одному из указанных ниже адресов.

• Электронная почта: [email protected] • Обычная почта:

Microsoft Press Attn: Analyzing Requirements & Defining Solutions Architecture Training Editor One Microsoft Way Redmond, WA 98052- Указанные адреса не предназначены для поддержки программных продуктов, упомянутых в учебном курсе. Ее вы найдете на узле http:// suppon.microsoft.com или обратившись в службу технической поддержки компании Microsoft по телефону (800) 936-3500, За пределами США обращайтесь в местное представительство компании Microsoft.

Об авторах • Тим Лэндгрейв (Tim Landgrave) В 1991 году Тим Лэндгрейв основал компанию KiZAN, специализирующуюся на разработке клиент-серверных приложений на базе технологий Microsoft. С тех пор Тим занимается проектированием, разработкой и развертыванием программных систем на базе ключевых технологий Microsoft. Тим — не только исполнительный директор компании KiZAN, но и директор регионального отделения Microsoft. В этом качестве он организует различные мероприятия, например, встречи разработчиков, и пропагандирует платформы Microsoft как основу разработки надежных многоуровневых приложений. Прежде Тим работал директором по технологиям компании Cobb Group, где основал несколько журналов для разработчиков. Кроме того, он занимал пост главного редактора таких журналов, как Inside Visual Basic, Inside Visual C++ и Microsoft Networking Journal.

• Брюс Мэйплс (Bruce Maples) В 1984 у Брюса появился первый Apple II, на котором он учился копаться в операционной системе и понемножечку программировать. С тех пор он успел многое: писал приложения на множестве языков от dBase до Visual Basic, читал лекции, консультировал, стал автором нескольких книг. Тим живет в Луисвилле, шт. Кентукки, с женой Ниной и сыновьями Гриффином и Бенджамином, Помимо увлечения компьютерами, Брюс активно участвует в делах местной церковной общины.

• Скотт Ф. Уилсон (Scott F. Wilson) Скотт помог превратить KiZAN в успешную программистскую компанию, специализирующуюся на разработке многоуровневых приложений и сетевых сервисов на базе технологий Microsoft.

Скотт занимался проектированием производственных архитектур, инфраструктуры сетей и приложений масштаба предприятия для клиентов KiZAN. Последние три года он помогает корпоративным заказчикам создавать и развертывать Web-приложения на платформе MCIS и Microsoft Site Server Commerce. Скотт — не только директор по технологиям в компании KiZAN, но еше и сертифицированный инструктор и системный инженер Microsoft (с года). С ним можно связаться по адресу [email protected].

Благодарности Я признателен моей семье, сотрудникам компании KiZAN и моим соавторам Брюсу и Тиму за постоянную поддержку. Спасибо Эрику, Венди и Вики из Microsoft Press за помошь в издании этой книги, Коду Фергюсону за вдумчивые комментарии, а группе MSF и Мэри Киртлэнд — за возможность воспользоваться их материалом.

Эта книга не появилась бы на свет без группы редакторов издательства OTSI. Особая благодарность Джойсу Коксу и Джоан Лэмберт. Если что-то в этой книге правильно, благодарите их, а все что неверно — на моей совести.

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

— Скотт Ф. Уилсон Прежде всего, спасибо Скотту — работа с ним доставила мне огромное удовольствие. Писать большую книгу — чаще изматывающий труд, чем удовольствие, однако благодаря Скотту удовольствия было больше. Я хочу поблагодарить сотрудников KiZAN за их безотказную помошь, профессионализм и за то, что с ними всегда приятно иметь дело. Спасибо Алану Макгаффи, который научил меня не быть пассивным.

Кроме того, я признателен всем, кто работает в кафе Steak-andShake (хотя они об этом и не узнают) — без них материал, над которым я работал поздним вечером, остался бы неоконченным. И наконец, спасибо двум самым главным персонажам моей жизни: Господу Богу и моей жене Нине. Благодаря им я счастлив, как никто другой.

— Брюс Мэйплс Спасибо сотрудникам KiZAN — они всегда делают работу «на отлично». Спасибо моей жене Лауре и нашим дочерям Тэйлор и Ханне за любовь, терпение и поддержку.

- Тим Лэндгрейв Часть I.

Методология Производственная архитектура 1, Разработка производственной архитектуры Приложения масштаба предприятия Глава 3. Проектные группы Практикую 2. Знакомьтесь: проектная группа Глава 4„ Процесс разработки Практикум 3. Знакомство с проектом RMS Практикум 4, Определение целей Производственная архитектура В этой главе Решение современных задач из области информационных технологий (ИТ) требует применения принципов и методов, которые мы совокупно называем «Производственной архитектурой». В этой главе рассказывается, почему разработку приложений и развитие инфраструктуры надо ориентировать на базовые концепции уровня предприятия. Прежде всего мы рассмотрим концепции разработки систем с позиции «приоритета архитектуры». Далее мы опишем выработанные компанией Microsoft принципы создания приложений Microsoft Solutions Framework (MSF). в которых архитектура рассматривается с четырех точек зрения {назовем их перспективами): бизнеса, приложений, информации и технологии. При использовании метода MSF решения получаются комплексными, итерационными, работоспособными, с четко определенными приоритетами. Наконец, мы обсудим организацию процесса разработки производственной архитектуры и покажем, как создавать системы и приложения, когда производственная архитектура еще не сформирована.

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

Изучив материал этой главы, вы сможете:

охарактеризовать достоинства разработки проектов с позиций приоритета архитектуры;

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

описать четыре перспективы — составные части модели производственной архитектуры MSF;

описать структуру каждой перспективы;

описать -преимущества планового полхода к созданию производственной архитектуры.

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

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

Отличный пример важности выбора направления движения — диалог Алисы и Чеширского кота из книги Льюиса Кэрролла «Алиса в стране чудес»*:

«—• Скажите пожалуйста, куда мне отсюда идти? — спросила Алиса.

— А куда ты хочешь попасть? — ответил Кот.

- Мне все равно... — сказала Алиса.

- Тогда все равно, куда и идти, — заметил Кот».

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

* Цитируется по изданию: Л. Кэрролл. «Алиса и стране чудес» (перевод и подготовка текста Н.М. Демуровой), М.: Наука, 1990,— Прим. ред.

Метод, который мы определили как «приоритет архитектуры», основан на следующем; прежде чем начать любой проект, надо ответить на простые вопросы.

• Как мы пришли к существующему положению?

• Знаем ли мы, куда движемся?

• Зачем мы туда идем?

• Какие задачи нужно решить, чтобы достичь желаемого?

• В каком порядке следует решать эти задачи?

• Как мы поймем, что цель достигнута?

• Что еще следует принять во внимание?

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

• целями и требованиями, определяемыми бизнесом;

• важнейшими проектными решениями;.

• затратами человеческих ресурсов;

• финансовыми затратами организации.

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

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

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

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

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

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

Задачи информационной инфраструктуры Давайте на минуту отвлечемся и рассмотрим проблемы, стоящие перед современным бизнесом. Ситуация на внутренних и внешних рынках стремительно меняется, что требует постоянного предложения разнообразных и сложных новых продуктов и услуг. Руководство ожидает, что цикл разработки новых продуктов будет сокращаться во имя ускорения их появления на рынке. Чтобы сохранить конкурентоспособность, организации вынуждены осваивать постоянно изменяющиеся технологии. Справляться с этой сложной задачей помогает следующее (рис. 1.1):

• рационализация производственных процессов;

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

• внедрение новых технологий в сжатые сроки.

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

• двойственности — инфраструктура должна удовлетворять нужды клиентов и в то же время поддерживать задачи производства;

• гибкости — необходимость приспосабливаться к постоянно изменяющемуся технологическому пейзажу и в то же время не нарушать любимого правила руководства: «Лучше, быстрее, дешевле — и срочно!».

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

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

• Продвижение товаров— специальные программы способны по компьютерным сетям мгновенно распространять информацию о продукте буквально по всему миру.

• Возможность привлечения огромного числа клиентов — пользователями таких приложений потенциально являются миллионы человек.

Если не использовать возможности, предоставляемые современными ИТ, эти потребители не станут клиентами вашей компании.

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

• Возможности хранения — необходимые для работы приложения данные находятся на нескольких компьютерах. Возможно, что эти компьютеры расположены не на одной территории или не доступны постоянно.

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

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

• следовать целям бизнеса — необходимо тесно увязывать ИТ с целями бизнеса;

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

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

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

• считать приоритетным учет нужд бизнеса;

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

• обеспечить достаточную гибкость при адаптации к неизбежной эволюции технологии и организации производства.

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

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

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

Попытаемся пояснить это утверждение.

• Логически связанный — все части общего плана рассматриваются вместе, они должны быть логически связаны.

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

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

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

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

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

• модель производственной архитектуры;

• модель проектной группы;

• модель процесса разработки ПО;

• модель управления рисками;

' модель процесса проектирования;

• модель приложения.

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

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

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

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

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

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

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

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

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

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

Модель производственной архитектуры MSF является структурной и состоит из четырех элементов (перспектив): бизнеса, приложения, информации и технологии (рис. 1.2).

Рис. 1.2. Элементы (перспективы) производственной архитектуры Бизнес - перспектива Бизнес-перспектива состоит из множества стратегий и планов, цель которых — переход организации от сложившегося состояния к желаемому. Она описывает организацию работ в компании. Модель включает:

• глобальные цели и задачи организации;

• виды продуктов и услуг, производимых организацией;

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

• основные структуры;

• взаимодействие всех перечисленных элементов.

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

• описание сервисов, которые поддерживают бизнес-процессы, представленные в бизнес-перспективе;

• описание взаимодействий и взаимозависимостей корпоративных приложений;

• приоритеты для совершенствования существующих и развития новых приложений на основе бизнес-перспективы.

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

• стандартные модели данных;

• методы организации данных и управления ими;

• описание структуры «производства* и «потребления» информации в организации.

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

Технологическая перспектива Технологическая перспектива представляет аппаратное и программное обеспечение, необходимое для работы организации. Она включает:

• персональные компьютеры и серверы;

• операционные системы;

• сетевые компоненты;

• принтеры;

• использование Интернета;

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

• топологии;

• среды разработки;

• прикладные интерфейсы;

• средства защиты;

• сетевые сервисы;

• сервисы баз данных;

• технические спецификации.

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

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

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

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

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

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

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

Модель производственной архитектуры MSF— это инструмент.

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

«Искусственная стена»

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

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

• ИТ-подразделения: «Мы уже знаем*. Это другое распространенное заблуждение. Многие руководители ИТ-подразделений полагают, что их отстраненность от бизнеса не мешает им создавать эффективные решения. И снова жизнь доказывает обратное; люди, не соприкасающиеся непосредственно с бизнесом, не могут понять всех его нюансов.

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

Ключевыми при этом являются следующие соображения.

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

• Понимание задач бизнеса ИТ-подразделениями — до ИТ-отделов надо довести четко сформулированные пели и механизмы ведеf Q Производственная зрхитеиура Глава ния дел, чтобы информационная инфраструктура организации развивалась рационально и обоснованно.

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

• Вовлечение руководителей ИТ-подразделенин в принятие бизнес-решений — это позволит эффективно совершенствовать существующие бизнес-процессы и планировать новые.

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

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

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

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

Отсутствие четкой формулировки целей Без компетентного планирования и ясного видения целей развития организации никакая производственная архитектура не поможет.

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

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

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

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

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

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

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

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

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

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

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

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

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

Модель производственной архитектуры MSF характеризуется;

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

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

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

• учетом приоритетов— работа над совершенствованием информационной инфраструктуры предприятия не мешает сосредоточить усилия на тех направлениях, где возможен наибольший эффект с точки зрения бизнеса. Разработка архитектуры всегда учитывает необходимость обеспечения поддержки основных бизнес-процессов, Создание производственной архитектуры Ранее мы описали четыре перспективы \годели производственной архитектуры MSF (бизнес, приложение, информация и технология) и некоторые трудности, возникающие при создании архитектуры. Мы рассмотрели четыре задачи производственной архитектуры (интеграция, итерация, работоспособность и учет приоритетов); мы также указали на вероятность возникновения «искусственных стен» между группами, непосредственно организующими бизнес, и ИТ-отделами. Вы узнали многое и наверняка у вас возникли вопросы: «Как достичь этих целей? Какие шаги следует предпринимать и в каком порядке?» Как воскликнул один раздраженный ИТ-менеджер: «Просто скажите мне, как загрузить файл проекта и соответствующие шаблоны Excel, и я начинаю работать!»

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

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

Несмотря на очевидную несостоятельность таких попыток, они регулярно повторяются. Многие компании нанимают архитекторов и консультантов, которые запираются на год-два и затем торжественно преподносят совету директоров свои «Ответы на все вопросы».

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

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

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

Поэтому архитектурным группам не следует при корректировании производственной архитектуры применять метод «штурма и натиска».

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