Результаты вышеперечисленных этапов являются основой для выполнения Gap-анализа, то есть выявления расхождений и различий между существующей и целевой бизнес-архитектурами. На основе Gap-анализа формируется план миграции, ориентированный на модернизацию ключевых компонент бизнес-архитектуры и конкретизирующий состав соответствующих проектов.
В ходе каждого из этапов (фаз) проекта складывается характерный набор документов и иных материалов, которые формируют информационную и методологическую базу модели бизнес-архитектуры и «фиксируют» пройденный маршрут по проекту.
Основным содержанием работы на этих этапах является эволюционный, итеративный процесс определения и описания текущего и желаемого состояния бизнес-архитектуры, совмещенный с процессом анализа результатов, идентификацией направлений и планов развития (Gap-анализ), который обеспечивает синхронизацию модернизации базовых компонент бизнес-архитектуры.
Вне зависимости от различных вариантов определения модели бизнес-архитектуры предприятия в конечном итоге обязательными составляющими методик описания модели являются такие принципы, как:
а) декомпозиция на различные представления архитектуры (предметные области): организационная, информационная, функциональная, технологическая компонента и т. д.;
б) различные уровни детализации и абстракции, а также средства формализации для описания каждой из компонент;
в) мониторинг существующих тенденций в области деятельности организации и тенденций в области развития информационных технологий;
г) мониторинг методической и нормативной базы по оценке бизнес-процессов в организации.
Выше отмечалось, что бизнес-архитектура является упрощенной моделью реальной организации. Необходимость получения практически значимого результата по моделированию в приемлемые сроки требует поиска компромисса не только в уровне детализации, но и на этапах его достижения.
Модель бизнес-архитектуры предприятия должна быть скорее гибкой, чем идеальной. Это нашло отражение в принципе, который был сформулирован как «достаточно хорошая» архитектура [15]. При этом принцип «достаточно хорошей» архитектуры противостоит стремлению создания «идеальной» архитектуры. Философия заключается в том, чтобы создать довольно гибкую и восприимчивую архитектуру, которая может модернизироваться в процессе своего жизненного цикла в ответ на изменения в моделях бизнеса и технологиях, и это гораздо важнее, чем создание теоретически правильной, идеальной архитектуры, представляющей полное и конечное видение [4].
В данных обстоятельствах целесообразно руководствоваться рекомендациями минималистского подхода по проектированию модели бизнес-архитектуры, то есть определять требования к бизнес-архитектуре самого высокого приоритета и затем делать минимально возможное, и не более того, чтобы удовлетворить этим требованиям [16]. Это позволяет иметь ограниченный и контролируемый набор бизнес-моделей высокого уровня (либо ключевых бизнес-процессов), но в то же время оставляет необходимую степень свободы для расширения состава бизнес-процессов, повышения детализации описания как самих бизнес-процессов, так и их компонент.
Базовый принцип минималистского подхода состоит в том, что если достижение некоторого требования по модели бизнес-архитектуры может быть реализовано за счет делегирования принятия решения на более низком уровне детализации, то соответствующее решение не является важным с архитектурной точки зрения (по крайней мере, для данного уровня).
Реализация минималистского подхода и подхода по «достаточно хорошей архитектуре» осуществляется в соответствии со следующими ключевыми принципами:
¦ быть гибким и разграничивать уровни бизнес-архитектуры. Гибкость может, в частности, достигаться за счет разделения бизнес-архитектуры на составные компоненты: организационная, технологическая, информационная и т. д. Это позволяет «локализовывать» необходимые изменения в рамках соответствующих предметных областей, учитывать связь (влияние) изменений между предметными областями и таким образом исключать необходимость переделки всей архитектуры целиком;
¦ проектировать модель бизнес-архитектуры таким образом, чтобы она могла развиваться итеративно. Основной предпосылкой должно быть то, что бизнес-архитектура в силу высокой динамичности внешних условий будет достаточно часто изменяться. Поэтому надо в рамках организации проекта изначально предусмотреть такие механизмы, организационные структуры, методы управления и надзора за разработкой и поддержкой модели бизнес-архитектуры, которые бы позволили вносить изменения так часто, как это требуется.
Ключевым условием, определяющим эффективное распределение ресурсов для исполнения проекта по моделированию бизнес-архитектуры, является обеспечение соответствия планирования проекта базовым рекомендациям. А именно построение модели бизнес-архитектуры должно охватывать три временных окна: состояние «как есть», состояние «как должно быть» на ближайшую перспективу и состояние «как должно быть» на отдаленную перспективу. Gartner рекомендует распределение ресурсов между данными промежутками устанавливать 15 %, 70 %, 15 % соответственно.
Работы, относящиеся к существующей организационно-технологической архитектуре предприятия, связаны с анализом и документированием имеющихся ключевых компонент архитектуры, то есть созданием моделей имеющихся бизнес-процессов в соответствии с действующими регламентами, описанием связей между процессами, моделированием используемых операционных документов и данных, организационной структуры, состава информационных систем и т. д.
Безусловно, эти работы имеют важное значение с точки зрения каталогизации и систематизации существующих связей, определения проектных решений в отношении создания новой информационной системы «модель бизнес-архитектуры». Вместе с тем потребительская ценность данных работ (с точки зрения наполнения модели контентом) не очень велика в случае планируемых мероприятий по оптимизации организационно-технологической структуры предприятия.
Как правило, результатом излишних усилий по описанию текущей бизнес-архитектуры являются редко востребованные альбомы и папки с документами. Из этих соображений, несмотря на ценность полученных результатов по систематизации знаний об организации и определению оптимальных проектных решений по формализации информации, время, инвестируемое в отображение текущей архитектуры, должно быть минимизировано. Данная минимизация должна проявиться в таком охвате и уровне детализации моделируемых бизнес-процессов и их компонент, который достаточен для понимания оптимизационных решений.
Целью проектирования будущей бизнес-архитектуры является обеспечение синхронизации со среднесрочной бизнес-стратегией, которая укладывается, как правило, во временной диапазон 2–3 года. Подобное выделение в качестве приоритета ближайшего будущего определяется сложностью точного прогнозирования влияния изменений внешней среды на деятельность предприятия. Высокая современная динамика внешней среды проявляется в изменении не только рынка (на котором позиционируется деятельность предприятия), но и информационных технологий, являющихся значимой составляющей производственных ресурсов организации. Очевидно, что для компаний, которые находятся в особо динамично развивающейся среде (состоянии), построение модели «завтрашнего» дня должно охватывать более короткий период, чем 2–3 года. Принятие правильных решений на уровне непосредственных, ближайших шагов гораздо важнее, чем определение конечной цели.
Gartner выделяет следующие временные горизонты для реализации и использования архитектуры предприятия, которые могут быть применены к модели бизнес-архитектуры, являющиеся ее составной компонентой:
¦ тактическое окно – 9 месяцев;
¦ скользящее окно оперативных возможностей – 18 месяцев;
¦ стратегическое окно – 30 месяцев.
Архитектура должна приносить пользу прежде всего с точки зрения достаточно короткого, 9-месячного промежутка времени. Окно оперативных возможностей должно постоянно перемещаться и соответствовать интервалу примерно в 18 месяцев. Это тот период времени, который связан с понятием «архитектура завтрашнего дня». Стратегическое окно должно быть не более 30 месяцев и соответствовать принятому в компании горизонту стратегического планирования [4] (рис. 8).
Управление процессом создания модели бизнес-архитектуры должно осуществляться в рамках ряда общих руководящих принципов:
¦ архитектура бизнес-процессов для состояния «как должно быть» должна проходить обязательные экспертные и расчетные процедуры контроля на эффективность;
¦ предлагаемые изменения в бизнес-процессах должны контролироваться с точки зрения их влияния на другие обеспечивающие компоненты: нормативную правовую базу, операционные данные и документы, автоматизированные технологии, организационную структуру;
¦ набор моделей бизнес-архитектуры будет поддерживаться в актуальном состоянии, с обеспечением и контролем целостности и взаимосвязи между компонентами;
¦ будут разработаны и поддерживаться стандарты и правила (политики) построения бизнес-моделей. В частности, должно быть разработано соглашение о моделировании. Соответствие стандартам и правилам будет контролироваться. Бизнес-архитектура будет неотъемлемой частью всего процесса управления развитием предприятия;
¦ команда проекта разработки бизнес-архитектуры, выполняющая основную работу, не является собственником этого процесса и результатов. Результаты разработки формируются в виде рекомендаций, подлежащих утверждению высшим руководством организации для придания легитимности;
¦ публикации и распространение информации и документов описания бизнес-архитектуры.
Следует отметить, что существенные изменения в архитектуре предприятия происходят примерно каждые два года (в то время как небольшие изменения – каждые полгода). Команда разработки архитектуры отвечает за реализацию этих изменений и, возможно, за создание специальных рабочих групп по внесению таких существенных изменений (либо это делегируется командам, отвечающим за отдельные домены архитектуры).
С организационной точки зрения работа над проектом по построению модели бизнес-архитектуры ведется на трех основных уровнях:
¦ стратегическом – на котором принимаются общие решения, касающиеся принципов построения и использования бизнес-архитектуры, основных направлений ее развития;
¦ уровне внесения существенных изменений в бизнес-архитектуру;
¦ повседневной работы над созданием документов и моделей, описывающих бизнес-архитектуру, информирования подразделений организации, обучения, демонстрации и т. д.
В крупной организации, имеющей сложную иерархическую структуру, работа по созданию модели бизнес-архитектуры может выполняться на нескольких уровнях. На региональном уровне должны приниматься общие решения, обеспечивающие совместимость и взаимодействие базовых компонент модели бизнес-архитектуры, а также вырабатываться другие общие требования и стандарты. На уровне отдельных крупных бизнес-подразделений или департаментов должны детализироваться и наполняться контентом соответствующие компоненты бизнес-архитектуры, исходя из:
¦ общих принципов, определенных для регионального уровня;
¦ специфики деятельности подразделения.
В составе результатов совместных усилий по разработке бизнес-архитектуры различных уровней предприятия могут быть перечни типовых бизнес-процессов, бизнес-функций, операционных данных и документов, прикладных приложений и т. д.
Применительно к такой организации проекта должны формироваться соответствующие группы управления, сопровождения и реализации со стороны заказчика и исполнителя. Обычно выделение отдельных структур со стороны заказчика считается целесообразным в случае наличия у него достаточно больших по размеру ИТ-служб, превышающих 100 и более сотрудников. Даже для больших организаций рекомендуется ограничивать состав основной команды 7–8 сотрудниками, а для более детальной проработки компонент бизнес-архитектуры – формировать отдельные проектные группы.
Для менее крупных организаций целесообразно использовать матричный метод, предусматривающий включение в команду проекта сотрудников различных бизнес-подразделений. При любом варианте организационной структуры поддержки исполнения проекта важна в первую очередь эффективная методология создания модели бизнес-архитектуры и управления всем данным процессом.
В табл. 7 приведены характерные качества, которыми должны в идеале обладать члены команды по формированию модели бизнес-архитектуры [4].
Помимо стандартного состава участников и порядка выполнения работ, характерных для любого проекта применительно к моделированию бизнес-процессов, особо следует отметить ряд характерных особенностей, которые будут подробно рассмотрены в данном разделе книги.
yaneuch.ru
Информационная архитектура (Enterprise Information Architecture, EIA), или архитектура информации, – это (с точки зрения аналитиков компании Meta Group) управляемый набор методик, описывающий информационную модель предприятия и включающий:
• базы данных и хранилища данных;
• информационные потоки (как внутри организации, так и связи с внешним миром).
Информационную архитектуру предприятия условно можно назвать уровнем потоков данных. Но при построении информационной архитектуры предприятия нет необходимости создавать модели всех видов данных, используемых на предприятии. Достаточно обеспечить выбор наиболее важных (критичных для предприятия) данных и моделировать их на высоком уровне абстракции.
Архитектура прикладных решений (Enterprise Solution Architecture, ESA), или, другими словами, архитектура приложений, включает совокупность программных продуктов и интерфейсов между ними.
Архитектуру прикладных решений разделяют на два направления:
• область разработки прикладных систем;
• портфель прикладных систем.
Область разработки прикладных систем описывает технологическую часть архитектуры прикладных решений и включает программные продукты; модели данных; интерфейсы; пользовательские интерфейсы.
Область разработки прикладных систем является техническим описанием конкретных приложений. Соответственно, информацию о данных модулях проще всего представить в виде двух следующих схем:
• компоненты и структура системы – внутренняя структура системы, включающая информацию о программных модулях и базах данных;
• взаимодействие с другими системами (интерфейсы) – описывает взаимодействие приложения с внешними объектами (программными продуктами, пользователями).
Архитектура прикладных решений описывает ситуацию, сложившуюся в ИТ-подразделении на текущий момент времени (т. е. это картина, демонстрирующая «технологическое обеспечение» бизнес-процессов, где каждой основной бизнес-функции соответствуют определенные приложения). На основе архитектуры прикладных решений строятся планы последующего развития информационных технологий в компании, разрабатываются планы мероприятий и проектов, необходимых для достижения стратегических целей.
На данном уровне лучше всего отслеживается взаимодействие бизнес-архитектуры предприятия и ИТ – архитектуры, так как можно определить взаимосвязи между организационной структурой предприятия и используемыми приложениями. В этом случае для оптимизации управления приложениями их разделяют на определенные группы (домены) в соответствии с функциональными возможностями. Следует отметить, что подобное разделение позволяет проще идентифицировать владельца приложения, определять его соответствие бизнес-требованиям.
Ответ:
Прежде всего необходимо понять, какие факторы подталкивают предприятие к рассмотрению вопросов разработки архитектуры. Это могут быть, например, макроэкономические факторы, требующие переосмысления вклада ИТ в бизнес, или конкурентная ситуация, требующая новых прикладных систем и обеспечивающей инфраструктуры (например, децентрализации процесса приема заказов). Факторы могут быть связаны с изменениями в бизнес-стратегиях, например, с принятием решения об организации более индивидуализированной работы с клиентами, что потребует внедрения целого ряда новых информационных систем. Важно понимать, как эти факторы могут быть использованы при обосновании проекта разработки архитектуры перед высшим руководством.
Основная сложность обоснования необходимости архитектурного проекта и выделения соответствующих инвестиций связана с тем, что прогнозируемые результаты обычно предполагают косвенное улучшение бизнеса организации, то есть являются, как правило, качественными и редко могут быть связаны с конкретными финансовыми выгодами. Даже в том случае, когда бизнес-показатели типа "увеличение стоимости акций компании" или "доля на рынке" измеримы, конкретные связи между ними и проведенным реформированием архитектуры предприятия обычно бывают трудно доказуемы. Доля таких компаний не превышает величины порядка 5%. При этом аналитики МЕТА отмечают, что в настоящее время более чем в 70% компаний ИТ-служба все еще является центром затрат, а более 90% ИТ-служб не имеют согласованных с бизнес-руководством финансовых моделей, позволяющих количественно измерить эффект от внедрения ИТ для бизнеса.
С точки зрения обоснования цифр экономии практически невозможно дать какие-то общие, применимые на все случаи, оценки затрат, связанных с отсутствием архитектуры ИТ. Это зависит от уникальности ситуации в каждой конкретной организации. Экономия может быть достигнута, в частности, за счет сокращения расходов, связанных с повторным использованием оборудования или программного обеспечения, за счет сокращения времени разработки, оптимизации расходов на ведение проектов, снижения стоимости технической поддержки, приобретения новых активов или экономии за счет более простой адаптируемости системы, построенной на базе единой архитектуры, к изменению требований бизнеса. Последняя составляющая выгоды обычно становится заметной при сравнении затраченных усилий, средств и времени для проведения изменений в различных подразделениях организации с отличающимися исходными архитектурами. В целом, по данным опроса META, снижение величины расходов на ИТ в расчете на одного сотрудника в случае реализации единой корпоративной архитектуры может достигать величины порядка 30%. По оценке Gartner отсутствие архитектуры приводит к 12-18% дополнительных затрат, связанных только с эксплуатацией ИТ-инфраструктуры.
Важно иметь в виду, что учет только прямых финансовых выгод зачастую оказывается недостаточным для оправдания инвестиций, так что приходится использовать более сложные методики, чтобы включить в обоснование проекта косвенные выгоды для бизнеса организации. С другой стороны, еще одним существенным аспектом, который необходимо принимать во внимание при переходе к новой архитектуре, является увеличение рисков, связанное с тем, что ко всем рискам, постоянно присутствующим в ИТ-системе (такими, как выход из строя оборудования или ошибка персонала), добавляются еще и риски, связанные с изменениями.
Во многих организациях информационные технологии уже исчерпали возможности по повышению продуктивности в таких областях, как скорость выполнения транзакций и бизнес-процессов. Поэтому традиционное обоснование инвестиций в информационные технологии, заключающееся в подсчете возврата на инвестиции (ROI – Return on Investment), может не обеспечить должного результата. Показатель ROI требует возврата инвестиций в рамках рассматриваемого проекта, поэтому этот показатель является тактическим по своей природе и не адекватным для задачи обоснования инвестиций в архитектуру информационных технологий.
Инвестиции в архитектуру предприятия, эффект от использования которой может быть не столь очевиден в течение трех-пяти лет, требуют иных мер оценки эффективности. Возможной стратегической альтернативой является величина "Возврата на основные фонды" (ROA – Return on Assets), которая будет стимулировать компанию оценивать архитектуру ИТ с точки зрения повышения эффективности своих основных фондов. Другим полезным показателем может быть "Возврат на возможность" (Return on opportunity). Он не является формальной финансовой метрикой, но описывает влияние инвестиций на бизнес. Подробнее обсуждение возможных финансовых инструментов содержится в курсе "ИТ-стратегия".
По оценкам Gartner, именно продуктивность информационных технологий как основных фондов в среднесрочной перспективе (2007 год) будет определять рыночную капитализацию компаний. Поэтому рыночная ценность организаций, которые обеспечивают эффективность использования ИТ как основных фондов и тем самым получают более высокую прибыль на единицу инвестированного капитала, будет возрастать. По тем же прогнозам, к 2007 году корпоративная архитектура будет критическим фактором в области управления рисками. Скорость реагирования, динамичность (agility) и гибкость организации, а также прозрачность отчетности будет оцениваться через наличие архитектуры предприятия. Именно архитектура будет задавать уровень риска, которым организация должна управлять. При этом управление рисками осуществляется как на микро-уровне, то есть уровне отдельных проектов, где основной фокус связан с выработкой конкретных мер для снижения определенного риска или с противодействием ему, так и на макро-уровне портфеля ИТ-проектов в целом. На этом макро-уровне должен достигаться определенный компромисс между инвестициями в связанные с высоким риском инновационные проекты и традиционными стандартными решениями, у которых как отдача, так и риск невысоки. Общей задачей будет являться формирование такого портфеля, когда эффекты от ИТ в целом превысят риски потерь.
Если бизнес-руководители (которые, в конце концов, выделяют все необходимые финансовые ресурсы) не поддержат усилия по выработке архитектуры ИТ, то им стоит готовить себя к еще большим затратам в будущем, поскольку они неизбежно окажутся в ситуации, когда они зададут себе вопрос: "Почему же мы тратим так много средств для получения таких посредственных услуг от ИТ-службы?"
При обосновании проекта разработки архитектуры полезными может быть перечисление тех преимуществ, которые были приведены в лекции 2.
Следует иметь в виду, что при принятии решения о необходимости разработки архитектуры предприятия – пока эффект от нее не доказан практикой, – следует избегать отнесения расходов по ее разработке на бизнес-подразделения организации или на бюджет конкретного ИТ-проекта. Оптимальным является использование централизованного бюджета, находящегося в распоряжении CIO.
Ответ:
В 1987 году Джон Захман опубликовал полезную схему развития архитектуры информационной системы. Захмановская схема создает контекст для описания различных представлений архитектуры разрабатываемой системы. Эти представления соответствуют тому, как видят систему ее заказчик, проектировщик и разработчик, причем в разрезе трех выбранных аспектов. Эти три аспекта: данные, функции и сетевая структура.
В схеме Захмана строке соответствует точка зрения какого-либо участника проекта по созданию системы. Аспекты представлены в схеме колонками. Архитектурное представление - это ячейка таблицы, соответствующая пересечению выбранного столбца и выбранной строки. Например, с точки зрения разработчика (технологическая модель) информационное архитектурное представление (данные) - это проект структуры данных. Взгляд какого-либо лица - это совокупность ячеек в пределах одной строки (точки зрения), то есть совокупность архитектурных представлений с выбранной точки зрения, соответствующая выбранным аспектам системы. Захман определяет архитектуру как представление конечного продукта (в данном случае информационной системы) с точки зрения одного из заинтересованных лиц. Таким образом, существует не одна архитектура, а некое множество архитектур. В зависимости от того, кем Вы являетесь и на каком аспекте фокусируете внимание, Вы видите архитектуру системы по-разному. Это не в чистом виде методология описания архитектуры, а скорее некоторая практика или способ классификации архитектурных описаний некой системы или приложения, позволяющий взглянуть на архитектуру под разными углами зрения и получить максимально полную картину. Описание архитектуры по Захману представляет собой матрицу или таблицу Захмана. В строках таблицы расположены основные представления (или точки зрения) на архитектуру, а в столбцах архитектурные аспекты выраженные простыми вопросами, почему, как, что, кто, где, когда и т.п. Каждая ячейка таблицы представляет собой уникальное, не пересекающееся с остальными, описание архитектурного аспекта на заданном уровне представления, выраженное при помощи соответствующей модели. Расшифровка строк таблицы: Planner's View (Scope, Contextual level) - общее, высокоуровневое видение архитектуры решения с точки зрения инвестора или заказчика. Owner's View (Enterprise or Business Model, Conceptual level) - уровень бизнеса, бизнес-сущностей и бизнес-процессов, то есть взгляд с точки зрения пользователей данного решения. Designer's View (Information Systems Model, Logical level) - представление системного аналитика о решении на уровне информационных моделей, функциональных требований к решению и потоков данных. Builder's View (Technology Model, Physical level) - представление архитектора, нацеленное на использование конкретных технологий, языков программирования, устройств и платформ. Subcontractor View (Detailed Specifications, Detailed level) - уровень детализированного представления о внутреннем устройстве всех компонентов решения, нацеленный на разработчиков и программистов. Расшифровка столбцов таблицы: What - описание данных How - описание поведения и функциональности Where - описание компонентов и их размещения Who - описание участников и ролей When - описание временных аспектов Why - описание поведенческих аспектов Формализация данной модели базируется на наборе следующих правил: Столбцы таблицы равнозначны и их положение взаимозаменяемо. Количество столбцов не может быть увеличено или уменьшено. Каждый столбец определяет простую общую модель и обладает собственной метамоделью. Базовая модель для каждого столбца должна быть уникальна. Каждая строка описывает уникальное представление архитектуры и бизнес группу, которой это представление интересно. Описанные представления присутствуют в большинстве иерархически организованных бизнесах. Каждая ячейка таблицы уникальна и описывает конкретный кейс. Полный набор моделей из всех ячеек одной строки формируют полную модель архитектуры с данной точки зрения.
Ответ:
Одним из возможных, достаточно простых форматов описания архитектуры является простое матричное представление, которое для каждой из основных областей архитектуры ИТ, таких как данные, приложения, интеграция, общие сервисы, и инфраструктура, "последовательно накладывает" несколько спецификаций, отличающихся по уровню детализации и конкретизации: Бизнес-потребности, которые определяют ключевые требования к конкретной технологии для данной индустрии и организации. Фактически здесь определяется индивидуальность архитектуры. Другой важный аспект связан с позиционированием ИТ в организации – либо ИТ-архитектура формируется для максимального уменьшения издержек, либо она должна обеспечивать возможности быстрых изменений и высокую гибкость. Другие примеры могут включать быстрое распространение информации, высокую безопасность, простоту использования и требуемую степень надежности. Принципы, которые включают в себя те основополагающие подходы, которых придерживается руководство. Например, это может быть принцип максимального использования стандартных приложений вместо заказных разработок, правила относительно того, кто владеет данными и пр. Большинство организаций могут иметь от 20 до 30 таких базовых принципов. Процессы и руководства во всех областях жизненного цикла элементов архитектуры. Этот раздел может охватывать такие области как документирование требований пользователей, стили программирования, процессы обеспечения качества или управление конфигурациями устройств и систем. Здесь также могут быть определены "эталонные модели" для организации пользовательского интерфейса, доступа к данным, управления содержанием. Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями. Раздел Используемые продукты и технологии является, по сути дела, утвержденным для организации списком продуктов или технологий. Они закупаются и используются как для создания приложений, так и для формирования инфраструктуры и обеспечения интеграции с внешними системами. Эта часть содержит взвешенную оценку всех "за" и "против" о конкретных поставщиках. Таким образом, данный подход позволяет обеспечить отслеживание логической связи между выбранными технологиями, их ценностью для бизнеса и потребностями бизнеса. Выбор не должен быть сделан просто по той причине, что это "крутая" технология или что эта технология уже фактически используется. В 2002 году Gartner сформулировала новую концепцию архитектуры предприятия, которая стала определенным обобщением рассмотренной ранее модели ИТ-архитектуры на уровень Бизнес-архитектуры, косвенным отражением растущей важности вопросов взаимодействия предприятий между собой, влияния концепций сервис-ориентированной архитектуры, осознания того факта, что существуют различные стили архитектуры информационных систем, соответствующие различным стилям бизнес-процессов. Мы уже отмечали выше, что типичными стилями бизнес-процессов являются массовая обработка транзакций, операции в реальном времени, аналитические процессы и бизнес-анализ, совместная работа. Эта модель в какой-то степени расширяет рассмотренные выше представления, а также подчеркивает взаимосвязь между понятиями "Электронной нервной системы" предприятия, которые были сформулированы в свое время Биллом Гейтсом, основателем, а ныне Председателем и Главным архитектором программного обеспечения компании Microsoft, и практической реализации этих идей в рамках современных подходов к проектированию архитектуры ИТ предприятия. Кстати, обратите внимание, как называется должность Билла Гейтса. Не является ли это еще одним подтверждением важности вопросов систематического построения и описания архитектуры? Билл Гейтс в своей книге "Бизнес со скоростью мысли" [5.12] дал следующее определение: "электронная нервная система есть совокупность электронных процессов, с помощью которых организации воспринимают мир и адекватно реагируют на изменения, происходящие в нем". Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:
yaneuch.ru
Служебный сегмент — это сегмент, который является фундаментальным если не для всех, то для большинства политических организаций. Например, управление финансами является служебным сегментом, обязательным для всех федеральных агентств.
Другим типом активов в архитектуре предприятия являются службы предприятия. Служба предприятия — это четко определенная функция в границах политико-административного деления. В качестве примера службы предприятия можно привести управление безопасностью. Управление безопасностью — это служба, единообразно реализованная по всему предприятию.
Различие между службами предприятия и сегментами, особенно служебными сегментами, неочевидно. И службы, и сегменты охватывают все предприятие. Различие заключается в том, что область действия служебных сегментов распространяется только на одну политическую организацию. Область действия служб предприятия распространяется на все предприятие.
Например, и в Министерстве здравоохранения и социальных служб, и в Агентстве по охране окружающей среды федерального правительства США используется служебный сегмент трудовые ресурсы. Однако трудовые ресурсы для Министерства здравоохранения и социальных служб отличаются от трудовых ресурсов для Агентства по охране окружающей среды.
И в Министерстве здравоохранения и социальных служб, и в Агентстве по охране окружающей среды используется такая служба предприятия, как управление безопасностью. При этом учетные записи для безопасного доступа, используемые службой управления безопасностью, одинаковы для обоих агентств. Эффективное управление учетными записями для безопасного доступа обеспечивается только в том случае, если оно осуществляется на уровне предприятия.
Возникает соблазн приравнять сегменты или службы к службам, используемым в сервис-ориентированных архитектурах. Такой подход небезупречен по двум причинам. Во-первых, службы предприятия, служебные и базовые сегменты намного шире по охвату, чем службы в сервис-ориентированных архитектурах. Во-вторых, сегменты являются организационной единицей для архитектуры предприятия, а службы — организационной единицей для технической реализации. Что касается организационных единиц для архитектуры предприятия, они охватывают не только технологическую архитектуру, но и архитектуры бизнеса и данных.
Последнее примечание относительно сегментов. Хотя сегменты функционируют на политическом уровне (то есть на уровне агентств), они определяются на уровне предприятия (то есть на уровне правительства). Службы предприятия, естественно, функционируют и определяются на уровне предприятия.
Тот факт, что сегменты определяются глобально, упрощает их повторное использование в границах политико-административного деления. Можно спланировать использование сегментов в границах политико-административного деления предприятия, а затем воспользоваться этим планом для поиска возможностей повторного использования разработанной архитектуры. Например, на рис. 8 приведена схема сегментов федерального правительства из «Практического руководства по FEA» [27]. Из рисунка видно, что многие сегменты (вертикальные столбцы) используются во многих агентствах и все или почти все эти сегменты можно использовать повторно.
Рис. 8. Схема сегментов федерального правительства
Эталонные модели FEA
Все пять эталонных моделей FEA предназначены для формирования единого языка. Цель — упростить взаимодействие, сотрудничество и совместную работу, минуя границы политико-административного деления. Согласно заявлению управления по реализации программы FEA (FEAPMO):
«Методология FEA включает в себя набор взаимосвязанных "эталонных моделей", предназначенных для упрощения анализа деятельности агентств и выявления дублирующих инвестиций, несоответствий и возможностей для совместной работы внутри агентств и между ними. Совместно эталонные модели [образуют] структуру для единообразного описания важных элементов методологии FEA». [28]
Зачем нужен общий язык? Рассмотрим следующий диалог:
Джеймс: «Не дашь мне на время лампу?»
Роджер: «У меня ее нет».
Джеймс: «А где ее можно купить?»
Роджер: «В магазине бытовой техники».
Итак, Джеймс отправляется в магазин и покупает то, что хотел. Он возвращается к Роджеру.
Роджер: «Ну что, купил лампу?»
Джеймс: «Да, вот она».
Роджер: «Это же не лампа! Это фонарик. Почему ты сразу не сказал? Я бы дал тебе на время свой».
Джеймс: «А почему ты не сказал, что он у тебя есть?»
Проблема заключается в том, что Джеймс приехал из Англии, где фонарь (англ. flashlight) называют лампой (англ. torch). Когда же я слышу слово лампа (англ. torch), я представляю паяльнуюлампу(англ. blowtorch). Хотя мы оба говорим по-английски, это не значит, что мы говорим на одном и том же языке. В результате Джеймс зря сходил в магазин и потратил деньги на то, что мог бы позаимствовать у меня.
Именно эту проблему, только в гораздо более крупном масштабе, и призваны устранить эталонные модели FEA. Предположим, что руководство Налогового управления США решило, что ему необходима демографическая система для отслеживания данных по налогоплательщикам. Сотрудники управления опросили знакомых, пытаясь узнать, нет ли у кого-нибудь подобной системы, которую можно было бы изменить под их потребности. Ни у кого такой системы не оказалось.
А буквально за соседней дверью, в Управлении правительственной печати США, уже использовалась отличная демографическая система, практически полностью удовлетворяющая требованиям Налогового управления. Нужно было просто направить запрос в аналитическую систему.
В итоге Налоговое управление разрабатывает систему с нуля вместо того, чтобы просто изменить уже готовую (и оплаченную) систему, используемую в Управлении правительственной печати. При этом Налоговое управление выбрасывает на ветер гораздо больше денег, чем потратил Джеймс на ненужный фонарь.
Так вкратце можно описать назначение пяти эталонных моделей FEA: дать стандартные термины и определения для архитектуры предприятия и упростить таким образом совместную работу и обмен данными в федеральном правительстве. Эти пять моделей перечислены ниже.
Эталонная модель бизнеса (BRM) дает бизнес-представление различных функций федерального правительства. Например, в этой модели определяется стандартная функция бизнеса использование водных ресурсов, которая, в свою очередь, является функцией природных ресурсов, являющейся критически важной для более широкой области обслуживания населения. [29]
Эталонная модель компонентов (CRM) дает ИТ-представление систем, поддерживающих бизнес. Например, в эталонной модели компонентов определяется аналитическая система, упомянутая выше в гипотетическом описании взаимодействия между Налоговым управлением и Управлением правительственной печати. [30]
В Технической эталонной модели (TRM) определяются различные технологии и стандарты, используемые при построении ИТ-систем. Например, в этой модели HTTP определяется как протокол, который является подмножеством служебного транспорта, который, в свою очередь, является подмножеством служебного доступа и доставки. [31]
В эталонной модели данных (DRM) определяются стандартные способы описания данных. Например, сущность в этой модели определяется как нечто, обладающееатрибутами и участвующее в отношениях. [32]
В эталонной модели производительности (PRM) определяются стандартные способы описания полезности, обеспечиваемой архитектурами предприятий. Например, качество в этой модели определяется как область измерений, которая, в свою очередь, определяется как «степень соответствия технологии требованиям к функциональности или возможностям». [33]
Процесс FEA
Процесс FEA в основном направлен на создание архитектуры сегмента для подмножества общей архитектуры предприятия (в случае с FEA предприятием является федеральное правительство, а подмножеством — правительственное агентство). Описание процесса приведено в «Практическом руководстве по FEA» [34]. Сегменты предприятия в рамках методологии FEA были рассмотрены выше. Общий процесс разработки архитектуры сегмента (на самом верхнем уровне) выглядит следующим образом.
Этап 1. Анализ архитектуры: формирование простого и лаконичного представления сегмента с привязкой к плану организации.
Этап 2. Архитектурное определение: задание желаемого состояния сегмента, документация целевых показателей производительности, рассмотрение альтернатив и разработка архитектуры предприятия для сегмента, в том числе архитектуры бизнеса, архитектуры данных, архитектуры служб и технологической архитектуры.
Этап 3. Стратегия инвестиций и финансирования: рассмотрение способов финансирования проекта.
Этап 4. План управления программой и реализация проектов: создание плана управления проектом и его реализации, включающего контрольные точки и показатели производительности для оценки успешности проекта.
Оценка успешности в методологии FEA
Структура FEA для оценки успеха в использовании архитектуры предприятия описана в документе «Структура оценки архитектуры предприятия по программе FEA 2.1» [35]. Уровень готовности федеральных агентств оценивается по трем категориям:
· Завершенность архитектуры — уровень готовности собственно архитектуры
· Использование архитектуры — эффективность использования агентством архитектуры при принятии решений
· Результаты использования архитектуры — преимущества, достигнутые благодаря использованию архитектуры
Административно-бюджетное управление присваивает каждому агентству рейтинг успеха на основе оценок по каждой категории и совокупному показателю следующим образом.
Зеленый — агентство показало хорошие результаты в области завершенности (имеет развитую архитектуру предприятия). Агентство также добилось хороших показателей в области использования (эффективно использует архитектуру предприятия для реализации текущей стратегии) и в области результатов (использование архитектуры способствовало увеличению ценности бизнеса).
Желтый — агентство показало хорошие результаты в области завершенности. Оно также добилось хороших показателей либо в области использования, либо в области результатов.
Красный — агентство либо не завершило разработку архитектуры, либо неэффективно использует разработанную архитектуру.
Эта структура применима и за пределами государственного сектора экономики. Рейтинги по категориям можно эффективно адаптировать ко многим предприятиям для оценки степени готовности их архитектуры. Например, на рис. 9 приведены рейтинги Административно-бюджетного управления для завершенности архитектуры, адаптированные мной для частного сектора экономики. Аналогичным образом можно адаптировать рейтинги для использования архитектуры и результатов использования архитектуры.
Рис. 9. Рейтинги Административно-бюджетного управления для оценки завершенности архитектуры, адаптированные автором (Роджером Сешнсом) для частного сектора экономики
Применение методологии FEA к компании MedAMore
Теперь, когда мы изучили методологию FEA, давайте посмотрим, как ее можно применить к компании MedAMore. Предположим, что Кэт (исполнительный директор MedAMore) узнала о методологии FEA и об оптимизации с помощью этой технологии работы федерального правительства. «Если эта методология помогла федеральному правительству, — думает Кэт, — значит она поможет и моей компании».
Кэт обращается к Фреду, эксперту по FEA (предположим, что такие эксперты существуют, хотя на момент написания этой статьи методологии FEA еще не исполнилось и года!). Задача Фреда заключается в том, чтобы показать компании MedAMore, как можно применить методологию FEA — конечно, не в чистом виде, а в том виде, в каком она применима к частному сектору экономики. Кэт знакомит Фреда с Бретом (вице-президентом по бизнесу) и Ирмой (директором по информационным технологиям) и ставит им задачу разработать anMEA — методологию FEA, адаптированную для компании MedAMore.
Помните, что Кэт довольно сильно рискует. На сегодняшний день ни одна компания не пыталась применить методологию FEA в частном секторе экономики, а опыт использования FEA в государственном секторе можно назвать в лучшем случае номинальным.
Первое, что собирается сделать Фред, — это заставить сотрудников поверить в методологию MEA. Помните, что он пришел в организацию, в которой сотрудники бизнес-подразделения практически не разговаривают с ИТ-специалистами. Для успешного применения методологии MEA необходимо изменить не только процессы, но и самих сотрудников. Фред собирается провести несколько семинаров, посвященных преимуществам разрабатываемой методологии MEA, на которых он хочет показать, что MEA принесет пользу не только компании MedAMore в целом, но и ее отдельным подразделениям.
Далее Фред займется построением в MedAMore управляющей структуры, эквивалентной FEAPMO. Эта структура будет называться MEAPMO. Методология MEA, включая процессы, модели и собственно архитектуру, будет находиться в ведении MEAPMO.
После этого Фред займется созданием эталонных моделей, которые будут использоваться во всех организациях, входящих в MedAMore. Отправной точкой послужат пять эталонных моделей методологии FEA. В некоторые модели, например в техническую эталонную модель, будут внесены незначительные изменения. Другие модели, например эталонная модель бизнеса, подвергнутся существенной переработке. Фред не собирается прорабатывать модели до мелочей, он собирается заложить фундамент для дальнейшего развития.
yaneuch.ru
ИНСТИТУТ МИРОВОЙ ЭКОНОМИКИ И ИНФОРМАТИЗАЦИИ
НЕГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«Архитектура предприятия»
Студент: Зорина Лежбита Вадимовна
МОСКВА – 2013
Контрольная работа по предмету
«Архитектура предприятия»
ВАРИАНТ 1
Ответ:
Существует несколько определений и моделей архитектуры, предлагаемых в различных национальных и международных стандартах. Приведем одно из них, дополнив комментариями из других, которые расширяют и уточняют понятие архитектуры.
Архитектура системы (предприятия) представляет стратегическую информационную основу, которая определяет:
структуру бизнеса;
информацию, необходимую для проведения этого бизнеса;
технологии, применяемые для поддержания деловых операций;
переходные процессы преобразования, развития, которые необходимы для реализации новых технологий в ответ на появление новых изменяющихся бизнес - потребностей.
Таким образом, архитектура системы (предприятия) представляет модель основного расположения и взаимосвязей внутренних частей системы (физического либо концептуального объекта или сущности).
Эта модель должна отвечать определенным требованиям полезности. Поэтому качество описательных представлений должно быть настолько конструктивным, чтобы на их основе можно было создать (продуцировать) описанный объект и поддерживать его на дальнейшем протяжении жизненного цикла.
Предприятие является гибридной системой, определяемой свойствами людей и машин. Люди как объекты модели или ресурсы характеризуются поведением (они обучаются, решают различные задачи). Машины осуществляют действия или реагируют на другие действия. В этой связи подчеркнем, что эти объекты системы нуждаются в различных видах информации.
Приведенное определение качественно описывает базовое понятие архитектуры.
Для представления общей архитектуры предприятия используются модели, содержащие слои отдельных архитектурных представлений. Как правило, в верхнем слое отражены функциональные требования к предприятию, связанные с его деятельностью. В нижних слоях отражаются технические особенности используемых информационных систем и технологий.
Ответ:
Архитектуру предприятия необходимо рассматривать в контексте всех остальных процессов и дисциплин управления информационными технологиями. В связи с этим центральной, объединяющей темой и точкой зрения в последнее время стала точка зрения на информационные технологии как на некоторый актив, которым необходимо управлять через процесс принятия решений о соответствующих инвестициях – точно так же, как это делается с финансовыми и иными активами.
Под управлением портфелем информационных технологий понимается процесс отбора, управления и оценки инвестиций, связанный как с ИТ-активами, так и с портфелем ИТ-проектов. Управление портфелем ИТ-активов позволяет организациям категоризировать, оценивать, расставлять приоритеты, покупать и управлять ИТ-активами и проектами в соответствии с текущими и будущими потребностями бизнеса с учетом приемлемой степени риска. Таким образом, управление портфелем ИТ по своей сути является дисциплиной в области планирования инвестиций. Управление портфелем ИТ должно преследовать три цели: максимизация ценности (стоимости) портфеля, синхронизация портфеля ИТ с целями бизнеса и поиск оптимального баланса между риском и потенциальной отдачей от портфеля ИТ.
В связи с этим описание желаемого состояния архитектуры ИТ обеспечивает представление о необходимых инвестициях в технологии и навыки ИТ-персонала.
Эффективное управление портфелем информационных технологий на уровне предприятия в целом должно обеспечиваться за счет совместного использования ряда дисциплин и процессов, среди которых главными являются следующие:
стратегия и планирование на уровне предприятия.
архитектура предприятия.
управление ИТ-программами и проектами.
ИТ-программы и проекты – это основной механизм реализации архитектуры в рамках выбранной стратегии. Дисциплина управления ИТ-программами и проектами связана с навыками управления портфелем взаимосвязанных программ и проектов на корпоративном уровне, с управлением процессами, финансовыми и человеческими ресурсами, которые требуются для реализации проектов, с управлением графиками реализации проектов и т.д. Управление ИТ-программами и проектами и архитектура предприятия взаимно дополняют друг друга, обеспечивая, в конечном итоге, интеграцию различных процессов, связанных с использованием ИТ на предприятии. При этом сутью управления программами/проектами является реализация, в то время как архитектура обеспечивает основу для выработки стратегии.
Процессы выработки стратегии и планирование обеспечивают основу для отбора, управления и оценки ИТ-ресурсов и проектов.
Управление ИТ-программами и проектами, стратегия и планирование, а также архитектура предприятия не только обеспечивают основу для процессов управления ИТ-активами, но как бы частично пересекаются с этими процессами. Например, архитектура предприятия не только является основой для разработки портфеля проектов, но также обеспечивает весь жизненный цикл многих ИТ-активов через управление принятыми на предприятии стандартами. Пересечение дисциплины и практики управления ИТ-программами и проектами с управлением ИТ-активами и проектами – еще более существенное.
Рис.1 Интеграция ключевых процессов управления информационными технологиями предприятия
В связи с этим соотношение между сегодняшним состоянием архитектуры предприятия (архитектура "как есть"), будущим желаемым состоянием архитектуры (архитектура "как должно быть"), портфелем ИТ-активов и портфелем ИТ-проектов можно также условно отобразить в виде следующей схемы[3.22]:
Рис. 2 . Архитектура, ИТ-активы и ИТ-проекты
Портфель ИТ-активов отражает сегодняшнее состояние архитектуры и является основой для выбора направлений инвестиций для миграции архитектуры в будущее, желаемое состояние. Выбор инвестиций в информационные технологии и процесс миграции архитектуры начинается с детального анализа имеющегося портфеля технологий и оценки способностей существующего портфеля с точки зрения стратегических целей и задач, потребностей бизнеса в выполнении своих функций. Оценка, как правило, принимает форму "GAP-анализа" (поиска расхождений и различий между текущим и желаемым состояниями). Результатом является идентификация проектов и потребностей во внедрении и закупке технологий для перевода организации и ее ИТ-архитектуры в будущее желаемое состояние.
Ответ:
Информационная архитектура (англ.: Information Architecture, IA) — выделившаяся в рамках информационных технологий совокупность методов организации и представления информации, направленных на обеспечение эффективного удовлетворения информационных нужд пользователей системы.
В настоящее время информационная архитектура считается в меньшей степени приближенной к дизайну, а в большей степени - к организации и структурированию информации.
Несмотря на отсутствие полностью устоявшегося определения ИА и её предмета, можно выделить основные подходы к их определению.
Введение термина датируется 1976 г. и приписывается Ричарду Вурману (Richard S. Wurman), определявшему задачу информационной архитектуры в организации эффективного визуального представления больших массивов данных.[1]
В настоящее время информационная архитектура считается в меньшей степени приближенной к дизайну, а в большей степени --- к организации и структурированию информации. Так, по определению The Information Architecture Institute, информационная архитектура — искусство и наука организации и предметизации веб-сайтов, интранет-сетей, онлайн-сообществ и программного обеспечения, преследующая целью обеспечение удобства использования (usability).[2]
Выделяют три основных определения информационной архитектуры:
Сочетание схем организации, предметизации и навигации, реализованных в информационной системе.
Структурное проектирование информационного пространства, способствующее выполнению задач и интуитивному доступу к содержимому.
Развивающаяся дисциплина и сообщество практиков, ставящее своей задачей распространение принципов и правил проектирования информационных систем.[3]
Смежными с информационной архитектурой областями являются:
дизайн интерфейсов (веб-дизайн), определяющий графический облик решений, заложенных информационной архитектурой;
маркетинг, так как информационная архитектура ставит целью удовлетворение нужд потребителей информации;
разработка ИС, так как реализация информационной архитектуры ИС сопряжена с применением соответствующих технологий и моделей данных;
управление знаниями (knowledge management), так как оно базируется на обеспечении лёгкости коллективного использования информации, одним из шагов в достижении которого является применение методов информационной архитектуры.
Потребность в выделении совокупности методов информационной архитектуры в отдельное направление обусловлена тем, что лавинообразный рост объемов информации в информационных системах разного уровня, Интернете, локальных сетях, существенно затрудняет свободную навигацию по источникам информации. В этом смысле информационная архитектура призвана обеспечить повышение эффективности использования информационных источников, а также комфортности работы с ними для пользователя.
Для этого информационная архитектура ориентируется на особенности человеческой логики и восприятия и использует современные подходы и технологии к организации информации, в том числе многоаспектную (фасетную) классификацию, слои пользовательской классификации (фолксономию) и т. д., обеспечивая интуитивный, предсказуемый доступ к содержимому информационных систем.
Несмотря на то, подходы в классификации (таксономия, предполагающая иерархическую классификацию, а также фолксономия, предполагающая задание неиерархических меток пользователями ИС) конкурируют в рамках ИА, и число сторонников фолксономии нарастало в связи с развитием концепции Web 2.0, информационная архитектура не предполагает наличия однозначно правильных во всех случаях подходов, рассматривая достоинства и недостатки, а также границы применимости каждого из них. Компромиссным подходом к классификации можно считать фасетный (многоаспектный) подход, предполагающий несколько оснований классификации с метками в рамках каждого из них, возможно --- иерархически организованными. Такой подход позволяет обеспечить индивидуальный подход к пользователю, которому не навязывается единого основания классификации и пути поиска информации и обеспечивается многоаспектный взгляд на контент, при этом наличие внутренней структуры в классификации предполагает прослеживаемость ее логики, в пику фолксономии, часто утрачивающей ценность в качестве основания навигации при росте объемов информации.
Морвиль кроме того выдвигает[4] концепцию слоев метаданных, в рамках которой различные классификационные подходы образуют слои, характеризующиеся большей устойчивостью (фундамент: таксономии и онотологии) или большей гибкостью (фолксономии), при этом, по мере эволюции системы происходит обмен данными между слоями.
Помимо инструментов классификации и подходов семантической сети, информационная архитектура всё более оперирует и механизмами обеспечения интеллектуального поиска, коллаборативной фильтрации, пользовательских профилей и персонализации.
Важным направлением рассмотрения являются и вопросы интеграции объектов реального мира в информационные сети, навигации на стыке представлений, в том числе интеграции GPS, RFID и т. д. как пограничных технологий.
Стоит отметить, что, несмотря на основной акцент на ориентирование в рамках информационных сетей, по мере роста количества информации в рамках информационных систем, а также по мере их интеграции с сетевыми службами и сервисами, подходы, разработанные в рамках информационной архитектуры становятся всё более актуальными и для традиционных информационных систем, в первую очередь, являющихся ключевыми компонентами бизнес-инфраструктуры предприятия, так как эффективность работы пользователей с такими системами имеет экономическую значимость для бизнеса.
Вместе с тем, применимы подходы ИА и в разработке приложений, ориентированных на массовых пользователей, в первую очередь, связанных с обработкой потока данных (например, персональные органайзеры, RSS-агрегаторы и т. д.), так как одна из задач ИА --- обеспечение интуитивного доступа к содержимому --- способна при адекватном решении повысить комфорт и эффективность использования продукта, а, значит, и обеспечить конкурентное преимущество по сравнению с аналогами.
yaneuch.ru
После этого Фред создаст описание архитектуры сегмента в применении к компании MedAMore. Обратите внимание, что он не собирается разрабатывать полную архитектуру сегмента — только высокоуровневое описание. Реальный процесс разработки архитектуры представляет собой постоянно развивающийся проект.
К этому моменту уже проделана большая работа и получены первые результаты. Далее Фред, скорее всего, начнет первую итерацию процесса разработки архитектуры сегмента. Процесс FEA является хорошей отправной точкой, однако требует изменений с учетом специфики MedAMore на уровне деталей (например, необходимо указать состав рабочей группы и форму представления артефактов).
Теперь Фред может приступить к тестированию процесса на основе первой версии архитектуры сегмента. Ему необходимо собрать рабочую группу, которая будет заниматься анализом сегментов и упорядочением их по приоритетам: для каждого сегмента необходимо определить ценность для бизнеса, задать архитектурные параметры, назначить работу и, возможно, самое главное, оценить результаты. Эти оценки критически важны при формировании основы для будущей работы.
После завершения работы над первым сегментом Фред принимает решение оценить эффективность использования методологии MEA в других группах в компании MedAMore. Ему необходим критерий оценки эффективности различных групп в компании MedAMore. Для этого Фред поручает MEAPMO разработать эквивалент «Структуры оценки архитектуры предприятия по программе FEA» [35]. Этот критерий будет для Кэт основным индикатором того, что обе группы воспринимают методологию MEA всерьез, а деньги потрачены не зря.
По завершении этого процесса Фред начнет его заново. На каждой итерации разрабатываются новые сегменты, увеличивается ценность бизнеса, а в методологию MEA добавляются новые детали. По крайней мере, так это выглядит в теории. Как я уже говорил, работая с методологией MEA, мы имеем дело с передовой развивающейся технологией.
Ответ:
Прорывом в области проектирования ИТ-среды предприятия стала методология построения сервис-ори-ентированной архитектуры (Service Oriented Architecture, SOA). SOA – это модель взаимодействия различных при-ложений, не зависящих от специфики реализации ин-терфейса и учета программно-аппаратных платформ. Идеология SOA обеспечивает универсальность взаи-модействия сервисов в разнородной среде и снижает
затраты на интеграцию. Ее концепция ориентирована на взаимодействие бизнеса и информационных техно-логий и определяет решение большого количества как технических, так и бизнес-проблем за счет разработки более гибких бизнес-процессов, приложений, внедре-ния гибких технологий. Эффективность SOA определяет-ся прежде всего сокращением времени развертывания решений, обеспечивающих автоматизацию бизнес-про-цессов компании. Архитектура SOA ориентирована в первую очередь не на программно-аппаратные средства, а на макси-мальную поддержку бизнес-процессов. Если в прило-жениях, построенных по классической архитектуре,логика распределена произвольным образом между различными компонентами (что затрудняет повторное их использование), то в концепции SOA логика каждого компонента разрабатывается в соответствии с бизнес-
процессом, который рассматривается в виде совокуп-ности нескольких составляющих элементов, реализуе-мых в виде отдельных программных модулей. SOA – это сервисный компонент приложения. Его можно использо-вать как элемент уже существующего бизнес-процесса, а также для реализации с его помощью разных приложе-ний для поддержки других бизнес-процессов. Появление методологии SOA обеспечивает быструю адаптацию информационных технологий в соответствии с текущими
нуждами предприятия. В настоящий момент в рамках SOA выработан про-мышленный стандарт для архитектуры, управляемой мо-делями (Model Driven Architecture, MDA). Ее появление обусловлено существованием ряда уже апробированных технологий, стандартов и спецификаций, а реальное фи-зическое воплощение стало возможно благодаря реали-
зации принципиально новых технологий программирова-ния. MDA является новой ступенью развития технологий программирования благодаря описанному в ней про-цессу разработки приложений, использующему различ-ные современные средства визуализации, что позволяет автоматизировать создание программных продуктов. В составе современных инструментов моделирования чаще всего рассматриваются следующие группы: объект-но-ориентированный анализ и разработки, инструменты архитектуры предприятия, анализ бизнес-процессов.Большие возможности построения архитектуры предприятия открывает использование другого подхода, рассматриваемого как продолжение развития методики SOA. Это архитектура, управляемая событиями (Event Driven Architecture, EDA), она является распределенной и построена на очень слабых связях. Архитектура предприятия реального времени объединяет возможности
SOA и EDA для создания гибкой архитектуры, которая является уже сегодня основой для бизнеса в реальном времени. Такое видение позволяет современным пред-приятиям эффективно поддерживать новые цели бизнеса,увеличить жизненный цикл многих существующих приложений (модернизировать их в соответствии практически с любыми бизнес-требованиями), уменьшить стоимость риска вывода на рынок новых продуктов и услуг. Требования оптимизации структуры обуславливают цикличность процесса формирования архитектуры пред-приятия. Архитектура является инструментом, позволяю-щим провести и отследить взаимосвязи между стратегией развития предприятия, существующими конкурентными стратегиями, состоянием отрасли и информационными технологиями, найти решения, обеспечивающие гибкость, и, соответственно, повысить эффективность компании. Архитектура предприятия обычно нестабильна, посто-янно меняется в соответствии с отраслевыми и прочими изменениями, постепенно превращаясь в инструмент, собственно, и позволяющий создавать предприятие ре-ального времени, функционирующее на принципиально более высоком уровне эффективности контроля и управ-ления по сравнению с уровнем, обеспечиваемым извест-ными классическими схемами управления.
Ответ:
Создание модели бизнес-архитектуры является непростым процессом не только с технологической, но и с организационной точки зрения. Модель бизнес-архитектуры – это примерно 20 % проектного видения, а на 80 % – кропотливая работа, в том числе организационная по реализации проектного видения. С другой стороны, нельзя впадать в другую крайность и преувеличивать связанные с этим процессом сложности. Принципиально важно понимать, что, приобретя качественно спроектированную и «наполненную» актуальной информацией модель бизнес-архитектуры, организация получает существенные преимущества.
Зачастую в качестве первоочередной задачи по проекту создания модели бизнес-архитектуры выступает формирование среды моделирования, предусматривающей выбор необходимых методик и инструментальных средств. В самом начале проекта (процесса) разработки архитектуры организации очень часто стремятся как можно скорее выбрать одну из известных на рынке методик или создать на их основе свою собственную. Вместе с тем гораздо более важными для успеха проекта являются:
¦ корректное обоснование необходимости проекта, целей и задач, факторов, влияющих на разработку бизнес-архитектуры;
¦ формирование команды проекта разработки бизнес-архитектуры;
¦ определение границ моделирования бизнес-архитектуры;
¦ формирование структур и процессов управления и контроля (governance) модели бизнес-архитектуры.
Одним из условий эффективной организации проекта является позиционирование на таких работах, которые в ближайшие сроки могут дать отдачу. Необходимо исходить из понимания того факта, что значительное количество ценной информации может быть получено без выполнения анализа бизнес-процессов с «парализующей» степенью детализации. В этой ситуации целесообразно руководствоваться правилом «80/20», а именно достаточно знать 80 % необходимых деталей о процессах – и эта информация может быть получена 20 % возможных усилий на анализ этих процессов. Это же правило применимо и к бизнес-архитектуре предприятия в целом.
При планировании проекта по моделированию бизнес-архитектуры необходимо исходить из понимания, что получаемый результат в большей степени является некоторым «развивающимся организмом», чем статическим предметом. Наработанный методический аппарат, инструментальные средства по моделированию бизнес-процессов позволяют обеспечить старт проекта даже при минимальных объемах исходной информации. При этом реализуемый процесс моделирования происходит в интуитивно понятной и естественной форме. Технологические возможности инструментальной среды позволяют осуществлять постепенное наращивание полноты и детальности функциональной, организационной, информационной и технологической структуры организации.
Благодаря отсутствию таких жестких ограничений на первоначальные объемы исходных данных, полноты и детальности описания бизнес-процессов имеются широкие возможности по оптимизации организации проекта по моделированию. В первую очередь появляется более широкий маневр в выборе бизнес-процессов и составных компонент, которые прежде всего будут охватываться проектом, исходя из реально сложившихся на начало проекта условий, связанных с исходными данными и исполнительскими ресурсами.
Принципиально важным для организации исполнения проекта является понимание того обстоятельства, что разработка модели бизнес-архитектуры не является строго технологическим процессом, связанным с использованием инструментальных средств и привлечением специалистов по информационным технологиям. Безусловно, в современных условиях инструментальная среда и технологический консалтинг по ее настройке являются обязательным атрибутом бизнес-моделирования. Вместе с тем значительная часть работ по сбору информации, ее интерпретации, анализу результатов моделирования, постановке задач по построению моделей могут быть выполнены только специалистами-предметниками, и эта работа носит творческий характер.
Можно утверждать, что доля «не ИТ-специалистов» в проектах по созданию модели бизнес-архитектуры существенно больше, чем в обычных проектах по созданию автоматизированных информационных систем. Причем эти специалисты несут основную нагрузку и ответственность за получение практически значимого результата. Очевидно, что данная специфика в обязательном порядке должна учитываться при организации проекта, и от того, насколько она эффективно будет учтена, зависит успешность проекта.
Порядок и специфика исполнения организации по бизнес-моделированию во многом определяются типами реализуемых проектов. Выделяют следующие основные типы проектов по моделированию.
1. Описание (документирование) деятельности организации (процессы, производственные и информационные ресурсы, документы и данные, персонал и т. д.).
2. Анализ и совершенствование бизнес-процессов и деятельности организации в целом.
3. Описание деятельности организации при построении систем менеджмента качества.
4. Подготовка к внедрению систем управления предприятием.
5. Подготовка к внедрению систем класса Workflow.
6. Построение системы стратегического управления на основе сбалансированных показателей.
7. Проведение организационных изменений.
8. Управление операционными рисками и др.
Вне зависимости от типа проект по моделированию бизнес-архитектуры состоит из следующих основных этапов.
1. Подготовительный этап. На данном этапе определяются и утверждаются цели проекта моделирования и приоритеты, проблемные области организации, выбираются методология и средство моделирования. Также прикидывается общая архитектура процессов, выделяются ключевые бизнес-процессы и их взаимосвязи. Формируются план проекта, проектная команда, подготавливается документ «Соглашение о моделировании».
2. Описание и анализ процессов «как есть». На этом этапе осуществляются описание процессов «как есть» в выбранном средстве моделирования, выбор критериев оценки процессов, выявление и оценка «узких» мест и потенциала для совершенствования. Уточняется план работ по дальнейшим этапам.
3. Построение процессов «как должно быть». На этом этапе определяются и оцениваются альтернативные сценарии процессов, моделируются процессы «как должно быть» с новой организационной структурой и операционным окружением, планируются потребности в персонале и формулируются требования к их квалификации и знаниям. Уточняется план работ по дальнейшим этапам.
4. Подготовка к переходу к оптимизированной модели. На этом этапе разрабатывается план перехода от текущего состояния к целевому:
– создание новых должностных инструкций;
– разработка тренинг-курсов и выработка показателей (метрик) уровня квалификации исполнителей;
– описание временных решений и т. п.
5. Реализация. На этом этапе реализуются и/или автоматизируются необходимые процессы с помощью заказного или стандартного ПО, осуществляются перестройка организационной структуры, переквалификация персонала, а также мониторинг.
Общая логика организации разработки модели бизнес-архитектуры в самом общем виде представлена на рис. 7. Принципиально важно отметить наличие двух составляющих в проекте, а именно определения вида целевой бизнес-архитектуры и разработки стратегии достижения.
Общим фоном для построения модели бизнес-архитектуры является мониторинг существующих тенденций в предметной области деятельности организации, направления развития ИТ-сферы. В рамках определения современных требований по оценке состояния бизнес-процессов в организации формируются иерархия целей и система показателей, которые трансформируются в требования к основным компонентам – организационной, функциональной, информационной, технологической. В контексте бизнес-требований параллельно осуществляется системный анализ всех перечисленных основных компонент.
yaneuch.ru
Рис. 7. Методика разработки архитектуры (ADM) в модели TOGAF
Как показано на рис. 7, методика разработки архитектуры в модели TOGAF состоит из восьми этапов, которые циклически повторяются после первой «накачки». Далее эти этапы будут рассмотрены на примере MedAMore. Однако перед тем как компания MedAMore сможет приступить к использованию методики разработки архитектуры, ей необходимо изучить модель TOGAF. Изучить модель TOGAF можно двумя способами.
Во-первых, компания MedAMore может изучить модель TOGAF самостоятельно. Компания MedAMore может загрузить документацию по TOGAF [20] — в ней достаточно подробно описаны все возможности TOGAF, в том числе методика разработки архитектуры. Также можно приобрести книги по TOGAF [21]. О модели TOGAF доступно больше информации (как бесплатной, так и за умеренную цену), чем обо всех остальных методологиях построения архитектуры вместе взятых.
Во-вторых, компания MedAMore может обратиться к экспертам по TOGAF. На рынке работает множество консультантов по TOGAF, обладающих сертификатами Open Group [22]. Поскольку руководство компании MedAMore хочет свести все риски к минимуму, оно принимает решение обратиться к консультанту по TOGAF. Компания MedAMore обратилась к Тэри, которая является архитектором TOGAF с сертификатом Open Group. Напомним, что другими игроками в компании MedAMore являются Кэт, исполнительный директор MedAMore, Брет, вице-президент по бизнесу, и Ирма, директор по информационным технологиям.
На подготовительном этапе Тэри встречается с основными игроками в компании MedAMore и рассказывает им о процессе TOGAF. Она преследует три основные цели:
Убедиться в том, что процесс устраивает всех игроков
Если необходимо, изменить процесс TOGAF в соответствии с корпоративной культурой MedAMore
Разработать систему управления для надзора за последующей разработкой архитектуры в MedAMore
Тэри будет тесно сотрудничать с Бретом, чтобы понять философию бизнеса, изучить бизнес-модели и стратегические задачи MedAMore. Ей также придется тесно взаимодействовать с Ирмой, чтобы определить архитектурные принципы, лежащие в основе используемых в MedAMore технологий, и задокументировать эти принципы в формате, рекомендуемом моделью TOGAF.
В некоторых организациях осознание необходимости создания архитектуры предприятия дается с большим трудом. Такая ситуация возникает, когда инициатива исходит от ИТ-подразделения, и особенно в случае продолжительного противостояния бизнес- и ИТ-подразделений организации. В компании MedAMore сложилась именно такая ситуация. Однако Тэри придется учитывать еще один факт: инициатива исходит не от ИТ-отдела, а от исполнительного директора Кэт. Этот факт придает проекту высокую прозрачность и стимулирует всех участников к сотрудничеству.
По завершении подготовительного этапа Тэри готова перейти к этапу А. Этот этап начинается, по крайней мере в теории, с Запроса на разработку архитектуры от какого-либо подразделения компании MedAMore. В этом документе излагаются причины запроса с точки зрения бизнеса, приводится бюджет и сведения о персонале, а также указываются ограничения, которые необходимо учитывать. Поскольку в компании MedAMore никогда не создавались Запросы на разработку архитектуры, Тэри придется помочь организации в создании подобного запроса.
После получения «Запроса на разработку архитектуры» (или аналогичного документа) Тэри (консультант по TOGAF) переходит к этапу А. На этом этапе Тэри предстоит убедиться в том, что проект надлежащим образом поддерживается компанией MedAMore, определить область действия проекта, выявить ограничения, задокументировать бизнес-требования и разработать высокоуровневые определения как для базовой (начальной), так и для целевой (желаемой) архитектуры.
Эти базовые и целевые определения включают высокоуровневые определения для всех архитектур, составляющих архитектуру предприятия, приведенных на рис. 5, а именно для архитектуры бизнеса, технологической архитектуры, архитектуры данных и архитектуры приложений.
Основным документом, создаваемым на этапе А, является «Постановление о разработке архитектуры», которое должно быть утверждено всеми заинтересованными лицами. После этого можно переходить к следующему этапу. В конце этого этапа формируется архитектурное представление для первой итерации цикла разработки архитектуры. Тэри поможет компании MedAMore выбрать проект, проверить проект на соответствие архитектурным принципам, сформулированным на подготовительном этапе, и убедиться в том, что были определены все заинтересованные лица, а обозначенные этими лицами проблемы были устранены.
Архитектурное представление, созданное на этапе А, является основой для этапа Б. Цель Тэри на этапе Б заключается в создании детализированной базовой и целевой архитектур бизнеса и всестороннем анализе различий между этими архитектурами. Для достижения этой цели Тэри в основном будет работать с Бретом (или его подчиненными).
Этап Б довольно сложен: он включает бизнес-моделирование, подробный анализ бизнеса и документирование технических требований. Для успешной реализации этапа Б необходимо участие многих заинтересованных лиц. Основным результатом является подробное описание базовых и желаемых бизнес-целей, а также описание различий между двумя архитектурами бизнеса.
На этапе В выполняются все те же действия, что и на этапе Б, только для архитектуры информационных систем. На этом этапе Тэри работает в основном с Ирмой (или ее подчиненными). В модели TOGAF определено девять этапов, каждый из которых разбит на несколько подэтапов:
Разработка описания базовой архитектуры данных
Просмотр и проверка принципов, эталонных моделей, точек зрения и средств
Создание архитектурных моделей, в том числе логических моделей данных, моделей управления данными и моделей отношений, в которых бизнес-функции сопоставляются операциям над данными (создание, чтение, обновление и удаление)
Выбор компонентов архитектуры данных
Формальный анализ контрольных точек модели архитектуры и ее компонентов вместе с заинтересованными лицами
Анализ качественных критериев (например, производительности, надежности, безопасности и целостности)
Завершение архитектуры данных
Анализ контрольных точек и последствий
Анализ различий
Наиболее важным результатом этого этапа является информация о целях и архитектура приложений.
На этапе Г формируется технологическая архитектура — инфраструктура, необходимая для поддержки новой архитектуры. На этом этапе в основном задействуются технические специалисты Ирмы.
На этапе Д выполняется оценка различных возможностей реализации, определяются основные проекты по внедрению, которые необходимо выполнить, а также связанные с каждым проектом возможности для бизнеса. Стандартом TOGAF на этапе Д рекомендуется «сосредоточиться на проектах, которые дадут результаты в краткосрочной перспективе и позволят реализовать долгосрочные проекты».
Это хороший совет для любой методологии построения архитектуры. Таким образом, Тэри следует выделить проекты, которые можно реализовать с минимальными затратами и максимальной отдачей. Для поиска таких проектов рекомендуется изучить «болевые точки» организации, изначально обозначенные Кэт (исполнительным директором MedAMore). Это позволит принять стратегию развития предприятия на базе архитектуры. Описанные выше «болевые точки» включают трудности в обеспечении поддержки специализации на уровне регионов и складов и ненадежный обмен данными.
Этап Е тесно связан с этапом Д. На этом этапе Тэри работает с руководством компании MedAMore's, чтобы упорядочить по приоритетам проекты, выбранные на этапе Д, с учетом не только затрат и выхода (определенных на этапе Д), но и факторов риска.
На этапе Ж Тэри на основе упорядоченного по приоритетам списка проектов создает спецификации архитектуры для проектов реализации. Эти спецификации включают критерии приемки и списки рисков и проблем.
Последним этапом является этап З. На этом этапе Тэри корректирует процесс управления архитектурными изменениями с учетом новых артефактов, созданных на последней итерации, и новых данных.
После этого цикл повторяется. Одной из целей первого цикла является передача информация, поэтому с каждой новой итерацией потребность в услугах Тэри снижается.
Многие результаты процесса TOGAF можно получить как с помощью Тэри (консультанта), так и на основе собственно спецификации TOGAF. Методология TOGAF весьма гибкая, а детали реализации архитектурных артефактов могут быть различны. В одной из книг по TOGAF говорится:
«Методология TOGAF — это не только и не столько создаваемые документы; фактически она в меньшей степени ориентирована на шаблоны документов, а в большей — на то, что мы получаем на входе и на выходе». [23]
Спецификация TOGAF также позволяет гибко работать с этапами. В самой спецификации говорится следующее:
Перед применением методики разработки архитектуры необходимо проверить компоненты на применимость, а затем связать их с конкретными обстоятельствами отдельного предприятия. Это позволяет создать методику разработки архитектуры для конкретного предприятия. [24]
Модель TOGAF позволяет выполнять этапы частично, пропускать их, объединять, изменять порядок и вносить изменения в соответствии с конкретными требованиями. Неудивительно, что два сертифицированных консультанта по TOGAF могут разработать два совершенно различных процесса — даже при работе с одной и той же организацией.
Модель TOGAF обладает еще большей гибкостью в отношении созданной архитектуры. Фактически TOGAF, как это ни удивительно, «ничего не знает» об архитектуре. Окончательная архитектура может с одинаковым успехом быть хорошей, плохой или неопределенного качества. В TOGAF описывается, как создать архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит от опыта персонала компании и консультанта по TOGAF. Те, кто внедряет TOGAF в надежде получить чудодейственное средство, будут жестоко разочарованы (впрочем, как и при использовании любой одной методологии).
Архитектура федеральной организации (FEA)
Архитектура федеральной организации (FEA) — это последняя попытка федерального правительства привести бесчисленное множество агентств к единой и повсеместно используемой архитектуре. FEA по-прежнему находится в самой ранней стадии развития: большинство компонентов этой методологии стали доступны только в 2006 г. Тем не менее, как отмечалось в разделе, посвященном истории, за этой методологией стоит длительная традиция и множество неудачных попыток, из которых были извлечены полезные уроки.
FEA является наиболее полной методологией из всех упомянутых. Она включает и всеобъемлющую таксономию, как в методологии Захмана, и архитектурный процесс, как в модели TOGAF. FEA можно рассматривать и как методологию создания архитектуры предприятия, и как результат применения этой процедуры к конкретной организации — Правительству США. Я буду рассматривать FEA с точки зрения методологии. Нас интересует, как можно применить методологию FEA к коммерческим организациям.
Большинство авторов описывают FEA как набор из пяти эталонных моделей: модель бизнеса, модель обслуживания, модель компонентов, технологическая модель и модель данных. FEA действительно включает эти пять моделей, однако представляет собой нечто намного большее, чем просто набор эталонных моделей. Исчерпывающее описание методологии FEA должно включать следующие пункты:
Точка зрения, с которой будут рассматриваться архитектуры предприятия (модель сегмента, которая вкратце будет рассмотрена ниже)
Набор эталонных моделей, описывающих различные точки зрения на архитектуру предприятия (пять перечисленных выше моделей)
Процесс создания архитектуры предприятия
Процесс перехода от старой парадигмы (до создания архитектуры предприятия) к новой (после создания архитектуры предприятия)
Таксономия для классификации активов, которые попадают в область действия архитектуры предприятия
Методика, позволяющая оценить успешность использования архитектуры предприятия для повышения ценности бизнеса
Очевидно, что FEA представляет собой нечто большее, чем набор моделей. Эта методология включает в себя все необходимое для построения архитектуры предприятия даже для самой сложной, пожалуй, организации в мире — Правительства США. По заявлению управления по реализации программы FEA (FEAPMO), методология FEA в целом обеспечивает:
«...общий язык и структуру для описания и анализа инвестиций в ИТ, повышает эффективность совместной работы и позволяет преобразовать федеральное правительство в организацию, ориентированную на граждан, направленную на достижение высоких результатов и отвечающую требованиям рынка в соответствии с программой президента США». [25].
Хотя на первый взгляд разве что вмешательство высших сил позволит «преобразовать федеральное правительство в организацию, ориентированную на граждан, направленную на достижение высоких результатов и отвечающую требованиям рынка», есть надежда, что методология FEA может помочь нашей многострадальной корпорации MedAMore справиться с гораздо менее глобальными проблемами. Так что же может предложить методология FEA при ближайшем рассмотрении?
Архитектура предприятия с точки зрения FEA
С точки зрения FEA, архитектура предприятия состоит из отдельных сегментов. Эта идея была впервые изложена в FEAF [26]. Сегмент представляет собой один из основных аспектов бизнеса, например трудовые ресурсы. Сегменты подразделяются на два типа: базовые и служебные.
Базовый сегмент представляет собой ключевой аспект деятельности предприятия в границах политико-административного деления. Например, для Министерства здравоохранения и социальных служб США базовым сегментом является здоровье.
yaneuch.ru
