СРО5. Самостоятельная работа реферат по дисциплине it инфраструктура работы 5 Тема Современные методики описания архитектуры предприятия
 Скачать 91.44 Kb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РЕСПУБЛИКИ КАЗАХСТАН НАО «АТЫРАУЙСКИЙ УНИВЕРСИТЕТ НЕФТИ И ГАЗА ИМЕНИ САФИ УТЕБАЕВА»  ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ САМОСТОЯТЕЛЬНАЯ РАБОТА РЕФЕРАТ По дисциплине «IT-инфраструктура» № работы: 5 Тема: «Современные методики описания архитектуры предприятия» Выполнила: обучающийся Бекеев Нуржан группа КСиУР – 20 р.о. факультет информационных технологий Проверила: старший преподаватель факультета «Информационные технологии» Кубашева А.А. Атырау- 2022 г План Введение Модель Захмана Основные методики описание архитектур Структура и модель описания ИТ-архитектуры Gartner Методика META Group Лучшие практики Методика TOGAF Заключение Список используемой литературы Введение Понятие «архитектура предприятия» впервые появилось в 1987 г. в статье Дж. А. Захмана «Структура архитектуры информационных систем», опубликованной в журнале IBM Systems Journal. В этой статье Дж. А. Захман изложил свое видение архитектур предприятий и связанных с ними проблем. В качестве проблемы было обозначено управление сложностью распределенных систем. Видение Захмана заключалось в том, что для обеспечения высокой ценности и гибкости бизнеса необходим целостный подход к архитектуре систем, в рамках которого каждая существенная проблема рассматривается со всех точек зрения. Такой подход к созданию архитектуры систем представляет собой то, что Захман изначально называл архитектурной структурой информационных систем, а впоследствии — структурой архитектуры предприятия. Захман внес основной вклад в разработку архитектуры предприятия Министерством обороны США. Эта попытка была предпринята в 1994 г., а сама концепция получила название «Базовая архитектура технического обеспечения для управления информацией» (TAFIM). Преимущества, обеспечиваемые такими архитектурами предприятий, как TAFIM (например, приведение в соответствие технических проектов с потребностями бизнеса), не были отмечены никем, кроме Конгресса США. Конгресс США в 1996 г. принял закон, известный как акт Клингера — Коэна от 1996 г., а также как реформа управления информационными технологиями, в котором всем федеральным агентствам было предписано принять меры по повышению эффективности инвестиций в ИТ. Для надзора за выполнением этого закона был сформирован совет директоров по информационным технологиям, в который вошли директора по информационным технологиям из всех основных правительственных органов. В апреле 1998 г. совет директоров по информационным технологиям начал работу над первым крупным проектом, структурой архитектуры федеральной организации (FEAF). Версия 1.1 данной структуры была выпущена в сентябре 1999 г. В этом документе содержался ряд инновационных идей, например идея «сегментированных архитектур» — то есть рассмотрение в архитектурном аспекте сегментированных подмножеств крупного предприятия. Через некоторое время полномочия совета директоров по информационным технологиям по архитектуре федеральной организации были переданы Административно-бюджетному управлению. В 2002 г. Административно-бюджетное управление переработало методологию FEAF и переименовало ее в архитектуру федеральной организации (FEA). Несмотря на весьма продуктивную деятельность федерального правительства по разработке архитектуры предприятия, прогресс практически отсутствовал, а успехи были незаметны на фоне крупных неудач. В 2004 г., восемь лет спустя после принятия акта Клингера — Коэна, предписывающего использовать эффективные процессы планирования ИТ, Бюджетно-контрольное управление представило следующий отчет. Только 20 из 96 проверенных агентств заложили у себя хотя бы основу для эффективного управления архитектурой. Более того, хотя в 22 агентствах увеличили степень соответствия требованиям с 2001 г., в 24 степень соответствия снизилась, а в 47 осталась без изменений. С января 2005 г. Бюджетно-контрольное управление (не путать с Административно-бюджетным управлением) серьезно наказало ряд правительственных агентств за невыполнение предписаний по внедрению и использованию архитектуры предприятия. В качестве примера можно привести ФБР, Министерство обороны, Министерство национальной безопасности и НАСА. В 1998 г., четыре года спустя после разработки TAFIM и два года спустя после оформления этой методологии в виде акта Клингера — Коэна, методология TAFIM была официально отменена Министерством обороны. Все наработки по TAFIM были преобразованы в открытую группу, а затем — в новый стандарт, известный в настоящее время под названием TOGAF (The Open Group Architectural Framework). Стандарт TOGAF будет рассмотрен ниже в соответствующем разделе. В 2005 г., примерно в то же время, когда Административно-бюджетное управление стало доминирующей силой в области разработки архитектуры предприятия в государственном секторе экономики, другая организация стала доминировать в частном секторе экономики. Это была группа Gartner. К 2005 г. компания Gartner стала одной из наиболее влиятельных организаций, занимающихся консалтингом на уровне директоров по информационным технологиям. Однако в области разработки архитектуры предприятия наиболее известной ИТ- и консалтинговой компанией была не Gartner, а Meta Group. Компания Gartner пыталась создать рекомендации по разработке архитектуры предприятия, однако ей не удалось превзойти Meta Group. В 2005 г. компания Gartner решила, что, раз ей не удается конкурировать с Meta Group, можно поступить иначе: компания Gartner приобрела компанию Meta Group. После приобретения Meta Group компания Gartner/Meta потратила год на то, чтобы разобраться, какой вклад внесла каждая из компаний в методологию разработки архитектуры предприятия. Две компании обсуждали, как наилучшим образом объединить свои заметно различающиеся подходы. В конце концов был применен достаточно простой алгоритм: если компания Meta Group одобряла какой-либо пункт, он включался в методологию, если не одобряла, соответствующий пункт исключался. Компании Gartner нравились архитектурные структуры. Компании Meta Group нравился архитектурный процесс. Таким образом, структуры были исключены, а процессы включены. Процесс взаимодействия компаний Gartner и Meta будет подробно рассмотрен ниже, в разделе, посвященном методологии Gartner. эта история представлена по этапам на фоне временной шкалы. Мы переходим к современному этапу развития архитектуры предприятия. Рассмотрим более подробно основные современные методологии.  1. МОДЕЛЬ ЗАХМАНА. Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж.Захманом (John A. Zachman). С момента публикации «модель Захмана для описания архитектуры предприятия» прошла определенную эволюцию в своем развитии и стала основой, на базе которой многие организации создавали свои собственные методики описания информационной инфраструктуры предприятия. С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира, такими, например, как General Motors, Bank of America и др. Модель Захмана также послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF – Federal Enterprise Architecture Framework), Методика описания архитектуры Open Group (TOGAF – The Open Group Architecture Framework), Методика описания архитектуры министерства обороны США (DoDAF – Department of Defence Architecture Framework). Отметим, что в данном случае в исторически сложившемся переводе названия на русский язык используется именно термин «модель», отражающий прежде всего четкую формальную структуру предложенной Захманом конструкции, хотя по глубине подхода и значимости, скорее, должен был быть применен перевод оригинала «framework» как «методики». Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем. По большому счету, описание Архитектуры предприятия следовало, как будет видно далее, принципам, заложенным в модели Захмана. Итак, в своей работе Дж. Захман определил Архитектуру предприятия как «набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)». Термин «архитектура» здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия и сложного искусственного объекта, такого как здание или орбитальная международная космическая станция (МКС). Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции. В то время, когда были опубликованы работы Захмана, традиционным подходом при формировании описания системы являлось использование концепции «жизненного цикла», включающего такие этапы, как планирование, анализ, проектирование, разработка, документирование, внедрение и промышленная эксплуатация. На каждом из этих этапов рассматриваются вопросы, связанные как с функциями системы, так и с данными. Захман предложил вместо традиционного подхода, связанного с рассмотрением отдельных аспектов работы системы как бы в различные моменты времени, использовать рассмотрение системы с различных перспектив. Исторически модель Захмана впервые была создана именно для ИТ-систем. Этот подход в последующей работе был обобщен для рассмотрения не только ИТ-систем, но и для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа. Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации. Джон Захман так описал свою работу: «Структура [архитектуры предприятия] по отношению к предприятиям представляет собой просто логическую структуру для классификации и упорядочения описательных представлений предприятия, существенно важных для управления предприятием, а также для разработки корпоративных систем». Многие сторонники структуры Захмана рассматривают ее как междисциплинарную, распространяющуюся далеко за пределы ИТ. Например, в одной популярной книге, посвященной методологии Захмана, говорится следующее: «...рано или поздно вы обнаружите, что структура Захмана присутствует во всем, чем вы занимаетесь, а не только в ИТ-проектах. Когда вы поймете структуру Захмана, вы станете более эффективным во всем. Во всем, не больше и не меньше. Это утверждение абсолютно серьезно». Сам Джон Захман сказал следующее: «...схема структуры использовалась несколько тысяч лет, и я уверен, будет использоваться еще несколько тысяч лет. Меняется только наше понимание структуры и принципы ее использования в проектировании предприятий и производстве». Захман изначально объяснил ИТ-таксономию на примере строительной отрасли. В этой отрасли архитектурные артефакты неявным образом организованы в двумерную структуру. Одним измерением являются различные «игроки». В случае здания такими игроками являются владелец (тот, кто оплачивает проект), строитель (тот, кто координирует процесс постройки) и специалист по планированию (тот, кто обеспечивает соблюдение строительных норм и правил). Архитектор здания подготавливает для каждого из игроков различные артефакты. Каждому игроку необходима полная информация, однако понятие полноты для каждого игрока свое. Владелец заинтересован в полном описании функциональности и эстетики здания. Строитель заинтересован в полном описании строительных материалов и процесса постройки. Владельца не интересуют гвозди в стенах. Строителя не интересует, виден ли из окон спальни восход солнца. В исходной статье Захман говорит следующее: «...каждое архитектурное представление отличается от других по существу, а не только уровнем детализации». Вторым измерением классификации архитектурных артефактов являются описательные аспекты: КТО, ЧТО, ГДЕ, КОГДА, КАК И ПОЧЕМУ. Второе измерение не зависит от первого. И строитель, и владелец должны знать что, но это что для владельца отличается от что для строителя. Конкретное что зависит от того, кто задает вопрос. В первой статье и последующей работе в 1992 г. Захман предложил шесть описательных аспектов: (данные, функция, сеть, люди, время и мотивация) и шесть игроков: (планировщик, владелец, проектировщик, строитель, субподрядчик и предприятие). Эти два измерения можно представить в виде таблицы, как показано на рисунке 2. С точки зрения владельца бизнеса, «данные» — это бизнес-объекты. Эти данные могут включать сведения как о самих объектах, например о клиентах и продукции, так и об отношениях между этими объектами, например о демографических группах и складских запасах. В разговоре о данных с владельцем бизнеса следует использовать именно этот язык. С точки зрения разработчика базы данных, «данные» — это не бизнес-объекты, а строки и столбцы, объединенные в таблицы и связанные друг с другом с помощью математических операций соединения и проекции. В разговоре о данных с разработчиком баз данных следует говорить не о демографических группах клиентов, а о реляционных таблицах в третьей нормальной форме. Ни одна из этих точек зрения не является более предпочтительной или детализированной. Обе эти точки зрения на данные критически важны для целостного понимания архитектуры системы. Захман говорит: «Мы испытываем трудности при обсуждении друг с другом архитектуры информационных систем, поскольку вместо единой архитектуры используется набор архитектурных представлений. При таком положении дел неправы оба участника обсуждения. Архитектуры различны. Они взаимно дополняют друг друга. Существуют веские причины выделить ресурсы на разработку каждого архитектурного представления. Если какие-либо архитектурные представления не разработаны, организация подвергается риску». Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов. Заметим, что в модели именно пять строк, просто отображенная на рисунке 2 шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом. Перспективы (строки в таблице) могут, в частном случае, соответствовать различному уровню управления предприятием, если речь идет об архитектуре предприятия или использования информационной системы. Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. Если проводить аналогию со строительством, то эти уровни содержат сведения о местонахождении и назначении постройки («особняк» для отдыха в престижном коттеджном поселке в элитной зоне), а также диаграммы, планы и картинки, которые архитектор обсуждает с хозяином будущего дома. Следующий уровень «логической модели» уже является более конкретным, но все равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен показывать подрядчикам. Аналогично, в применении к деятельности предприятия верхняя строка «Контекст» соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует интересам бизнес-менеджеров и владельцев процессов. Третий уровень – тот, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков. На каждом из этих уровней участники, вообще говоря, рассматривают одни и те же категории вопросов, соответствующих столбцам в таблице, – только с различным уровнем абстракции и детализации. В содержание этих колонок входят: используемые данные (что?) процессы и функции (как?) места выполнения этих процессов (где?) организации и персоналии–участники (кто?) управляющие события (когда?) цели и ограничения, определяющие работу системы (зачем?) Сам Захман в своем интервью он-лайновому журналу «Enterprise Architect Online» без ложной скромности сравнил свою модель с периодической таблицей элементов Менделеева и назвал ее «периодической таблицей описательных представлений предприятия или двумерной системой, схемой классификации». Это действительно ко многому обязывающее сравнение, но Захман привел следующие аргументы в его пользу: «Вопросы что, как, где, кто, когда и зачем существуют тысячи лет. И они будут существовать еще тысячи лет. Требования к системам, процесс проектирования, производства или концептуальный, логический и физический уровень описания также существуют в течение тысяч лет и будут существовать еще тысячи лет. Логическая структура классификации, схема – неизменны». В конце концов, как отмечает Захман, коммерческие предприятия и государственные организации должны понимать, что путь к эффективным информационным системам требует систематических подходов в проектировании (engineering). Если вы, например, занимаетесь большими проектами, связанными с интеграцией государственных информационных систем, то «...назначить одного ответственного человека – это еще не решение проблемы. Никакого чуда просто так не произойдет. В какой-то момент вы поймете, что настоящий процесс проектирования должен быть реализован для того, чтобы интегрировать эти объекты». Основные правила заполнения таблицы следующие: - каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы («базис»); - порядок следования колонок несущественен; - каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа); - базовые модели для каждой из колонок являются уникальными; - соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы; - заполнение клеток должно проводиться последовательно «сверху вниз», попытка пропуска одного из рядов является, скорее, «шаманством» (в том плане, что нельзя создать хорошо работающую систему, «перепрыгнув» определенные уровни ее описания на этапе проектирования). Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк. Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов. Третий уровень (логическая модель) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций. На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды. Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками. Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы с системой, фактические базы данных, работа службы HelpDesk. Надо заметить, что в исходной работе Захмана содержание этого уровня не детализируется. При развитии модели, как будет показано ниже, отмечены возможности рассмотрения аспектов функционирования работающей системы с точки зрения, например, конечного пользователя или эксплуатирующих служб. Рассмотрим теперь, как осуществляется последовательная детализация отдельных аспектов описания системы, для чего обратим внимание на различные колонки таблицы. Напомним, что порядок расположения колонок в таблице, вообще говоря, произволен. Так, первая колонка отвечает на вопрос «ЧТО?» и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы «сущности-связи» (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п. Конечно, можно отметить определенное несовершенство данной модели при использовании объектно-ориентированного подхода – фактически модель предписывает раздельное рассмотрение данных (свойств) и функций (методов) классов. Колонка функций (ответ на вопрос «КАК?») предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям. Следующая колонка (вопрос «ГДЕ?») определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое «middleware»), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети. Колонка таблицы, отвечающая на вопрос «КТО?», определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли (в RUP используются диаграммы событий и описание вариантов использования), требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы. Пятая колонка отвечает на вопрос «КОГДА?» и определяет временные характеристики бизнес-процессов и работы системы. Опять-таки детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы. Последняя колонка («ПОЧЕМУ?» или «ЗАЧЕМ?») служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию. Такая модель описания в целом полезна для идентификации возможных ограничений. Эти ограничения могут «распространяться» как от верхних уровней к нижним (например, указание руководства компании о выборе тех или иных средств, продуктов или принципов работы), так и в обратном направлении – например, возможности существующих технологий беспроводной связи в значительной степени определяют спектр предлагаемых услуг и организацию бизнес-процессов у провайдеров этих услуг. Важным принципом предложенной модели является необходимость последовательного перехода при углублении детализации рассмотрения. Пропуск отдельных элементов, например, прямой переход от описания модели бизнес-процесса к физической реализации системы требует «привлечения магии» и почти всегда приводит к неудаче. На практике это часто случается при попытке разработки программы на основании только устного описания требований пользователя. Основными характеристиками данной модели Захмана являются следующие: - простота для понимания как техническими, так и нетехническими специалистами; - целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с предприятием в целом; - поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий; - возможность применения для планирования, позволяющего лучше принимать решения за счет того, что решение никогда не будет выноситься «в пустоте» (в отрыве от остальных аспектов деятельности предприятия); - применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия Предприятия как целого; - нейтральность, то есть независимость от каких-либо инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают. Созданная модель архитектуры служила простым, но мощным инструментом по применению системного подхода для планирования работ по созданию и использованию информационных систем и их стыковки. Захман писал, что схема архитектуры позволяет концентрироваться на отдельных аспектах системы и в то же время не терять ощущения общего контекста или «холистической» перспективы (то есть, взгляда на предприятие в целом). Он подчеркивал, что именно потеря такой перспективы, в частности, разработка систем субподрядчиками, находящимися «вне контекста», уже около пятидесяти лет составляет причину появления неинтегрируемых и не поддерживающих предприятие должным образом систем, которые к тому же весьма дорого заменять. Баланс между сущностью реализации отдельных ячеек и интегрированным взглядом на систему поддерживается моделью Захмана за счет того, что она: - облегчает понимание и общение людей, имеющих разные роли в процессах создания, развития и использования системы; - ясно определяет фокус внимания на (относительно) независимых параметрах для целей анализа; - но в то же время обеспечивает поддержку контекстных взаимосвязей, важных для сохранения целостности системы. Рассмотрим, как может использоваться подход, предложенный Захманом, на практике. Во-первых, данную модель удобно применять для классификации всей информации, описывающей предприятие и информационные системы этого предприятия, выявления «белых пятен» и координации работ. Во-вторых, данную модель можно использовать на метауровне – для сравнения различных реализаций создания архитектур предприятия. Наконец, она может являться удобным средством для использования в отдельных проектах. Например, в проекте по созданию корпоративного информационного портала необходимо определить элементы в строках 3-5 колонки 4 – соответственно, требования пользователей к представлению данных, интерфейсы и спецификацию по разграничению доступа с учетом существующих «унаследованных» компонент информационной системы. Эта существующая технологическая архитектура, в свою очередь, рассматривается в ячейке на пересечении четвертой строки и третьего столбца таблицы. Нельзя, конечно, считать, что данная модель лишена недостатков. Один из них заключается в том, что при применении ее на практике возникают определенные трудности, связанные с отсутствием «встроенного механизма» распространения изменений между элементами таблицы. Действительно, предположим, что изменилась организация процесса поставок в компании (схема логистики). Это потребует отслеживания «вручную» всех взаимосвязей, проверки актуальности и внесения изменений в модели и другие артефакты во всех потенциально «затрагиваемых» ячейках. Другим ограничением модели является отсутствие рассмотрения системы в динамике. Действительно, каждый элемент таблицы может содержать как описание существующего состояния («как есть»), так и целевого, а также всех промежуточных состояний. При этом сама модель не содержит средств для четкого разделения этих различных «временных срезов». Тем не менее, существуют специализированные продукты, такие как Popkin Software Architect, которые фактически основаны на модели Захмана и позволяют достаточно эффективно управлять созданием моделей и артефактов описания архитектуры предприятия. Соответствующее обобщение подхода Захмана было предложено в работах Е.Б. Зиндера. Основная идея заключается в обеспечении возможностей отражения постоянного развития предприятия (и его информационных систем) как непрерывной последовательности трансформаций. Вместо традиционной двумерной таблицы было предложено ввести трехмерную схему, добавив к плоским схемам ось стратегического времени. На этой оси располагаются отрезки времени осуществления различных проектов и стадий развития информационных систем и всего предприятия. Таким образом, была создана «объемная» схема архитектуры предприятия или модель «3D-предприятие», которая строится в трех измерениях с учетом временного пространства. При этом, по предложению автора данной работы, первые два измерения аналогичны тем, которые использовал Захманом, но не совпадают с оригиналом полностью по содержанию и трактовке. Третья ось позволяет явно определять те изменения, которые происходили и будут происходить с предприятием, его существующими информационными системами, а также с различными проектами развития и трансформации. Стоит отметить, что предложенный вариант развития исходного подхода Захмана не является единственно возможным. Существует большое количество модельных схем, которые в той или иной мере используют данный подход, хотя визуальное представление модели в целом может достаточно сильно отличаться. Одним из таких примеров может служить предложенная Институтом разработок архитектуры предприятия модель Extended Enterprise Architecture Framework (E2AF). Эта модель содержит 4 области рассмотрения (бизнес, информация, информационная система, технологическая инфраструктура) и следующие 6 уровней абстракции: - контекстуальный (Зачем?) - уровень взаимодействия (с Кем?) - концептуальный (Что?) - логический (Как?) - физический (с помощью Чего?) - трансформационный (Когда?) Другой пример – это так называемая модель 4-доменной архитектуры (Four Domains architecture, FDA), в которой предлагается, в частности, провести как бы условное разбиение ячеек исходной модели Захмана на 2 компоненты – архитектуру описания (Architecture-in-Design) и архитектуру исполнения (Architecture-in-Operation). При этом первая компонента описывает ход, средства и артефакты процесса разработки архитектуры предприятия, в то время как вторая предназначена для описания непосредственно бизнес-процессов и реализации ИТ-систем. ОСНОВНЫЕ МЕТОДИКИ ОПИСАНИЯ АРХИТЕКТУР. 3.Структура и модель описания ИТ-архитектуры Gartner. в данном разделе мы кратко изложим подходы к описанию архитектуры, предложенные Gartner и представленные в материалах открытого доступа. Одним из возможных, достаточно простых форматов описания архитектуры является простое матричное представление, которое для каждой из основных областей архитектуры ИТ, таких как данные, приложения, интеграция, общие сервисы, и инфраструктура, «последовательно накладывает» несколько спецификаций, отличающихся по уровню детализации и конкретизации: Бизнес-потребности, которые определяют ключевые требования к конкретной технологии для данной индустрии и организации. Фактически здесь определяется индивидуальность архитектуры. Другой важный аспект связан с позиционированием ИТ в организации – либо ИТ-архитектура формируется для максимального уменьшения издержек, либо она должна обеспечивать возможности быстрых изменений и высокую гибкость. Другие примеры могут включать быстрое распространение информации, высокую безопасность, простоту использования и требуемую степень надежности. Принципы, которые включают в себя те основополагающие подходы, которых придерживается руководство. Например, это может быть принцип максимального использования стандартных приложений вместо заказных разработок, правила относительно того, кто владеет данными и пр. Большинство организаций могут иметь от 20 до 30 таких базовых принципов. Процессы и руководства во всех областях жизненного цикла элементов архитектуры. Этот раздел может охватывать такие области как документирование требований пользователей, стили программирования, процессы обеспечения качества или управление конфигурациями устройств и систем. Здесь также могут быть определены «эталонные модели» для организации пользовательского интерфейса, доступа к данным, управления содержанием. |