Методики создания бизнес архитектуры содержат список

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

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

Разработка архитектуры предприятия включает в себя компоненты, связанные с функциональной архитектурой (бизнесом), информационными технологиями и управлением архитектурным процессом. Приведенная ниже диаграмма отражает подход NASCIO (Национальной Ассоциации CIO США), которая наглядно отражает то, как различные компоненты взаимодействуют и влияют друг на друга.

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

Методы построения архитектуры бизнес процессов компании

Существуют различные подходы или рамочные модели, методики (frameworks) к описанию архитектуры предприятия.:

методики, опубликованные аналитическими компаниями, такими как Gartner, GigaGroup, META Group и другими;

методика POSIX 1003.23, которая основывается на разработках компании CapGemini, переданных для публичного использования в 1996 году.

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

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

Методы построения архитектуры бизнес-процессов компании

Если говорить формально, то существуют индустриальные стандарты на описание архитектуры предприятия, принятые такими организациями, как Институт инженеров электрики и электроники (IEEE – InstituteofElectricalandElectronicsEngineers), международная организация стандартизации (ISO – InternationalOrganizationforStandardization), TheOpenGroup и т.д.

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

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

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

простоту для понимания бизнес-аудиторией;

динамику рассмотрения (т.е. «Архитектура как есть» – «Краткосрочные и среднесрочные задачи» – «Стратегические планы»);

возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных (ad-hoc) проектов.

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

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

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

Модель Захмана

Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (John A.Zachman).С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира, такими, например, как GeneralMotors, BankofAmerica и др.

Модель Захмана также послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США, Методика описания архитектуры OpenGroup, Методика описания архитектуры министерства обороны США. Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем.

Итак, в своей работе Дж. Захман определил Архитектуру предприятия как «набор описательных представлений (моделей), которые применимы для описания предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)». Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (ZachmanFrameworkforEnterpriseArchitecture). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.

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

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

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

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

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

используемые данные (что?)

процессы и функции (как?)

места выполнения этих процессов (где?)

организации и персоналии–участники (кто?)

управляющие события (когда?)

цели и ограничения, определяющие работу системы (зачем?)

В конце концов, как отмечает Захман, коммерческие предприятия и государственные организации должны понимать, что путь к эффективным информационным системам требует систематических подходов в проектировании (engineering). Если вы, например, занимаетесь большими проектами, связанными с интеграцией государственных информационных систем, то «. назначить одного ответственного человека – это еще не решение проблемы. Никакого чуда просто так не произойдет. В какой-то момент вы поймете, что настоящий процесс проектирования должен быть реализован для того, чтобы интегрировать эти объекты».

Основные правила заполнения таблицы следующие:

каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы («базис»);

порядок следования колонок несущественен;

каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);

базовые модели для каждой из колонок являются уникальными;

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

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

Основные понятия модели Захмана: аспекты, заинтересованные лица («игроки»), «взгляд» («перспектива»), элемент архитектурного представления.Вторая редакция модели Захмана — архитектура предприятия (EnterpriseArchitecture).

В 1987 году Джон Захман опубликовал полезную схему развития архитектуры информационной системы. Она создает контекст для описания различных представлений архитектуры разрабатываемой системы. Эти представления соответствуют тому, как видит систему (точка зрения какого-либо участника(игрока) проекта по созданию системы — строка) ее

причем в разрезе трех выбранных аспектов (колонок). Эти три аспекта:

Это первая редакция:

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

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

Модель Захмана – модель информационной структуры. Он рассматривает ее с различных «перспектив» (точек зрения) различных «игроков», заинтересованных и участвующих в создании ИС.

Строки – это результат такого рассмотрения. Их 2 вида. Верхняя группа 2-3 отражает функциональные слои бизнеса (заказчика)(взгляды топ-менеджеров и экспертов). Нижняя группа (оставшееся) – представления профессиональной иерархии исполнителя.

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

Логическое объединение этих различных «видений» системы в единую структуру, осуществлено Захманом за счёт общей для всех точек зрения используемой совокупности так называемых архитектурных «аспектов», каждый их которых является ответом на один из вопросов, определяющих любой вид деятельности: что, как, где, (в первом варианте модели Захмана) кто, когда, с какой целью? (дополнительно включены во втором варианте модели).

Вторая редакция таблицы, показанная на рисунке ниже, предложеннаЗахманом в 1992 году, она дополнена тремя новыми аспектами:

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

1. Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк.

2. Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.

3. Третий уровень (логическая модель) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.

4. На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.

5. Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.

Источник: infopedia.su

Контекст разработки архитектуры предприятия

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

Витрувий, архитектор времен Римской империи

Разработка архитектуры предприятия включает в себя компоненты, связанные с функциональной архитектурой (бизнесом), информационными технологиями и управлением архитектурным процессом. Приведенная ниже диаграмма отражает подход NASCIO (Национальной Ассоциации CIO США), которая наглядно отражает то, как различные компоненты взаимодействуют и влияют друг на друга.

Рис. 8.1. Общий контекст разработки Архитектуры предприятия

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

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

· методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими;

· методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.

Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве Обороны США DoDAF (Department of Defence Architecture Framework).

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

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

Если говорить формально, то существуют индустриальные стандарты на описание архитектуры предприятия, принятые такими организациями, как Институт инженеров электрики и электроники (IEEE – Institute of Electricaland Electronics Engineers), международная организация стандартизации (ISO – International Organization for Standardization), The Open Group и т.д. Но ни один из этих стандартов не занимает доминирующего положения. Более того, ни один из них, взятый в отдельности, не дает группам, ответственным за разработку архитектуры, всех инструментов, необходимых с методической точки зрения и с точки зрения шаблонов, используемых для описания архитектуры. Однако этот накопленный арсенал методик и стандартов предоставляет архитекторам широкие возможности выбора архитектурных моделей, примеров и опыта различных индустрий [5.2].

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

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

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

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

· простоту для понимания бизнес-аудиторией;

· динамику рассмотрения (т.е. «Архитектура как есть» – «Краткосрочные и среднесрочные задачи» – «Стратегические планы»);

· возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных (ad-hoc) проектов.

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

В следующих разделах этой лекции мы рассмотрим наиболее распространенные методики описания архитектур. При этом мы не делаем принципиального различия между теми из них, которые ориентированы на описание архитектуры предприятия как целого, и теми, которые рассматривают более узкий контекст ИТ-архитектуры. Заметим, что достаточно важная и хорошо проработанная методика Федеральной архитектуры США FEAF, документы с описанием которой к тому же находятся в публичном доступе.

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

Первое определение говорит о том, что » архитектура – это описание некоторой сложной системы в определенный момент времени». Оно аналогично схемам описания и чертежам здания, города, сада или компьютерной сети. Этому определению архитектуры соответствует центральная секция таблицы. Данная часть таблицы описывает два представления архитектуры: существующее и будущее состояния. В лекциях 10-12, посвященных организации архитектурного процесса, мы отдельно обсудим, как должны, с точки зрения затрачиваемых усилий, соотноситься эти два представления архитектуры.

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

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

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

Источник: studopedia.su

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

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

· Структура Захмана для архитектуры предприятий – 6 вопросов по уровням детализации предприятия. Является таксономией(практика классификации и систематизации)

· TOGAF (The Open Group Architectural Framework) — Модель TOGAF описывает процесс создания артефактов.

· Архитектура федеральной организации – обобщённая модель geramи захмана. Является полной методологией.

· Методология Gartner — рекомендации, касающиеся разработки архитектуры.

· Методика META Group — более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих.

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

Стандарт iso 15704:2000, методика geram.

Стандарт ISO 15704 нацелен на решение задач трех типов: создание предприятия, его реструктуризация и инкрементальные изменения.

Схема GERAM предусматривала:

• четыре группы аспектов архитектуры предприятия, названных представлениями (Views) – типы моделей («функции», «данные», «ресурсы», «организация»), назначения (может быть ассоциировано со столбцом «ЗАЧЕМ» Захмана), реализации и «физические представления» (аппаратура, НО) и возможность определять дополнительные аспекты;
• описание всех аспектов или какой-то их части на каждой из семи или восьми фаз формирования архитектуры и функционирования предприятия;
• конкретизацию модели архитектуры на трех уровнях – обобщенном, уровне частичных моделей и конкретных моделей.

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

Модель Gartner.

Методология Gartner не является ни таксономией (как модель Захмана), ни процессом (как TOGAF), ни полной методологией (как FEA). Эта методология представляет собой набор практических рекомендаций по построению архитектуры предприятия, разработанных одной из наиболее известных в мире исследовательских и консалтинговых ИТ-организаций – компанией Gartner. Компания Gartner считает, что архитектура предприятия должна начинаться с того, чего организация собирается достичь, а не с текущего положения дел. После того как в организации будет сформировано единое представление о ее развитии, можно рассматривать влияние этого представления на архитектуру бизнеса, технологическую архитектуру, информационную архитектуру и архитектуру решений.

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

Методика описания архитектуры Gartner представляет собой как бы трехмерный куб, состоящий из следующих элементов:

• горизонтальные слои – бизнес-архитектура. Это четыре связанных, взаимозависимых и усложняющихся уровня;

• вертикальные домены – информационная архитектура, включающая Приложения, Данные, Интеграцию, Доступ;

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

Методика meta Group.

Отличительной особенностью методики МЕТА является более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих.

Архитектура реализуется на практике через процесс управления ИТ-программами и проектами.

Предусматривает совместное участие представителей безнес-подразделений и ИТ в выработке общего понимания набора требований.

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

1. Видение общих требований в архитектуре.

2. Разработка концепции архитектуры.

3. Архитектурное моделирование.

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

Методика togaf.

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

В модели TOGAF архитектура предприятия подразделяется на четыре категории.

1. Архитектура бизнеса – описывает процессы, используемые для достижения бизнес-целей.

2. Архитектура приложений – описывает структуру конкретных приложений и их взаимодействие друг с другом.

3. Архитектура данных – описывает структуру корпоративных хранилищ данных

и процедуры доступа к ним.

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

Анализ и выбор инструментальных средств моделирования архитектуры предприятия.

EA tools (Enterprise Architecture tools)- это набор инструментов, ориентированный на моделирование архитектуры предприятия. Инструменты этой группы должны позволить связывать различные разрозненные типы данных в единое целое. Одной из основных особенностей продуктов класса Enterprise Architecture Tools является возможность не только моделировать различные элементы деятельности компании (программно-аппаратные средства, бизнес-процессы, приложения, интерфейсы, организационная структура, стратегические цели), но и интегрировать их.

Enterprise Architecture Tools должны включать в себя следующие компоненты: репозиторий (repository), обеспечивающий структурированное хранение всех данных, описывающих состояние компании; метамодель (metamodel), которая поддерживает возможность описания всех слоев архитектуры предприятия (бизнес, информация, приложения, технологии) и обеспечивает связи между всеми объектами; возможность создавать и импортировать модели; возможность извлекать информацию из репозитория и предоставлять ее пользователям, как в текстовом, так и в графическом виде.

BPA (Business Process Analyze)- это набор инструментов, ориентированный на моделирование и управление бизнес-процессами. При описании приложений этой группы часто используют термин BPMS (Business Process Management System) или BPM-система. BPA Tools (BPMS) позволяют не только моделировать бизнес-процессы, но и проводить мониторинг их количественных параметров, что позволяет выявлять узкие места и оптимизировать бизнес-процессы. BPA Tools ориентированы на анализ, моделирование, оптимизацию конкретных бизнес-процессов.

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

Metadata Repositories– это хранилище информации о текущей структуре предприятия. Подобные хранилища данных включают в себя информацию о бизнес- процессах, приложениях, интерфейсах, программно-аппаратных средствах. Информация, хранящаяся в такой базе данных, собирается из различного количества источников и, как правило, частично совпадает с информацией, находящейся в CMDB (configuration management databases).

Хранилище информации, как правило, не существует само по себе и является элементом инструментов, ориентированных на использование Business Process Analyze или Enterprise Architecture tools.

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

OOAhttps://www.evkova.org/referaty/kriterii-vyibora-i-klassifikatsiya-metodologij-sozdaniya-arhitektur-predpriyatij» target=»_blank»]www.evkova.org[/mask_link]