Что такое модель захмана
Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF
Модель Захмана
Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (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» как «методики».
Итак, в своей работе [5.3] Дж. Захман определил Архитектуру предприятия как «набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)». Термин » архитектура » здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия и сложного искусственного объекта, такого как здание или орбитальная международная космическая станция (МКС).
Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture ). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.
Исторически модель Захмана впервые была создана именно для ИТ-систем [5.4]. Этот подход в последующей работе [5.3] был обобщен для рассмотрения не только ИТ-систем, но и для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа.
Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рисунке 8.2. Заметим, что в модели именно пять строк, просто отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Перспективы (строки в таблице) могут, в частном случае, соответствовать различному уровню управления предприятием, если речь идет об архитектуре предприятия или использования информационной системы.
Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. Если проводить аналогию со строительством, то эти уровни содержат сведения о местонахождении и назначении постройки («особняк» для отдыха в престижном коттеджном поселке в элитной зоне), а также диаграммы, планы и картинки, которые архитектор обсуждает с хозяином будущего дома. Следующий уровень «логической модели» уже является более конкретным, но все равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен показывать подрядчикам.
Аналогично, в применении к деятельности предприятия верхняя строка » Контекст » соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует интересам бизнес-менеджеров и владельцев процессов. Третий уровень – тот, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков.
На каждом из этих уровней участники, вообще говоря, рассматривают одни и те же категории вопросов, соответствующих столбцам в таблице, – только с различным уровнем абстракции и детализации. В содержание этих колонок входят:
Сам Захман в своем интервью он-лайновому журналу » Enterprise Architect Online » без ложной скромности сравнил свою модель с периодической таблицей элементов Менделеева и назвал ее «периодической таблицей описательных представлений предприятия или двумерной системой, схемой классификации» [5.5]. Это действительно ко многому обязывающее сравнение, но Захман привел следующие аргументы в его пользу: «Вопросы что, как, где, кто, когда и зачем существуют тысячи лет. И они будут существовать еще тысячи лет. Требования к системам, процесс проектирования, производства или концептуальный, логический и физический уровень описания также существуют в течение тысяч лет и будут существовать еще тысячи лет. Логическая структура классификации, схема – неизменны».
В конце концов, как отмечает Захман, коммерческие предприятия и государственные организации должны понимать, что путь к эффективным информационным системам требует систематических подходов в проектировании ( engineering ). Если вы, например, занимаетесь большими проектами, связанными с интеграцией государственных информационных систем, то «. назначить одного ответственного человека – это еще не решение проблемы. Никакого чуда просто так не произойдет. В какой-то момент вы поймете, что настоящий процесс проектирования должен быть реализован для того, чтобы интегрировать эти объекты».
Что такое архитектура предприятия, и почему Захман ошибся?
Вторая статья про мифологическое сознание тоже будет короткой. Сегодня я расскажу, к каким проблемам приводит мифологическое сознание при моделировании архитектуры предприятия.
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Читатель, натренированный в описании архитектур предприятий, быстро меня поправит. Он скажет, что я неправильно ставлю вопросы. Надо спрашивать: кто выращивает, почему он выращивает, что выращивает. Но тогда получается, что я могу описать деятельность субъекта, который выращивает кукурузу, но не могу описать сам рост. Смирившись с тем, что я не могу описать процесс роста, у меня все равно остаются неразрешенные вопросы: кто и почему выращивает кукурузу (см. выше)?
Получается, что, задавая вроде бы логичные вопросы, я в лучшем случае получаю несколько ответов, а в худшем, не получаю их вообще. Если взять предельный случай, когда у нас есть полностью роботизированное предприятие, на котором вообще нет людей, то ответом на вопрос «кто?» будет — «никто». В результате мы вообще ничего не можем сказать об этом предприятии! Правда, есть один выход из этой ситуации, немного лукавый, – надо лишь воспользоваться мифическим сознанием и одушевить роботов. Тогда, одушевив неодушевленное, мы сможем ответить на вопрос: кто? Робот. Почему? Потому что так устроен этот робот, или потому что программист его так запрограммировал. На второй вопрос мы снова получаем странные ответы. Почему же так получилось, и какие вопросы на самом деле стоит задавать? Я попытаюсь кратко изложить свое мнение на этот счет, рассказав о тех логических ошибках, которые я нашел в модели Захмана.
Если посмотреть на вопросы, которые задаются в модели Захмана, можно убедиться, что они в точности соответствуют теории деятельности. Деятельность – это психическая функция субъекта (группы субъектов). Поэтому, отвечая на вопросы Захмана, мы строим модель психической функции субъекта (субъектов). Наука, изучающая психические функции субъектов, называется психология. Получается, что Захман отвечает на вопросы, которыми задаются психологи: зачем субъект делает то или иное действие? Или как мотивировать субъекта на выполнение тех или иных действий? Эти вопросы, безусловно, интересные и важные, но являются ли ответы на них описанием архитектуры предприятия? Чтобы ответить на этот вопрос, надо понять, что же такое предприятие?
Как же на самом деле происходит проектирование предприятия и какие артефакты при этом возникают? Прежде чем проектировать предприятие, строится модель требований к нему. Модель требований формируется на основе требований, которые предъявлены к этому предприятию со стороны всех его участников, контрагентов и стейкхолдеров. Аналог в ИТ — требования к программному продукту. Далее на основе этих требований строится модель процессов предприятия с необходимой степенью детализации. Аналогом в ИТ будет перечень функций программного продукта. Далее строится модель функциональных объектов, или, говоря специализированным языком, технических мест, которые должны участвовать в перечисленных ранее процессах. Аналогом в ИТ будет описание процедур, и объяснение какие процедуры в каких функциях участвуют. Далее подбираются те единицы оборудования, которые могут выполнять роли перечисленных технических мест. Аналог в ИТ — это программный код.
Предприятие – это функциональный объект, который создан удовлетворяющим определенным требованиям. В этом смысле предприятие ничем не отличается от такого объекта, как часы, или производственная линия. Часто вместо термина функциональный объект можно услышать термин техническое место. Техническое место отличается от единицы оборудования тем, что единица оборудования выполняет роль технического места. Например, трансформатор выполняет роль преобразователя напряжения, при этом в разное время разные трансформаторы могут выполнять роль одного и того же преобразователя. Еще одним примером технического места является должность, отдел, подразделение, штат. Например, токарь участвует в функции изготовления деталей. Это — техническое место, роль которого в разное время могут выполнять разные единицы оборудования (физические лица). О сложностях моделирования технических мест и единиц оборудования я кратко написал в статье Моделирование активов предприятия: современные стандарты и практика.
При моделировании технических мест, мы описываем процессы и участников этих процессов. Замечу, что именно участников, а не исполнителей, — трансформатор не может преобразовывать напряжение, потому что он не является одушевленным существом. Об этом я писал в прошлой статье Моделирование активности и мифологическое сознание. Если все же сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения. О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон. Другой распространенной метонимией будет высказывание: «компьютер решает задачи». Те же, кто действительно считают, что трансформатор, или компьютер что-то делает на самом деле, одушевляют неодушевленное, пользуясь мифическим сознанием.
Заметим, что до сего момента мы ни слова не сказали о целях, об исполнителях и причинно-следственных связях. Мы лишь говорили о требованиях, о функциях и участниках этих функций – технических местах. Цели остались на этапе формирования требований к предприятию и далее они не пошли. Мы можем знать эти цели, а можем не знать, — для модели предприятия это не имеет никакого значения. Модель предприятия отвечает на вопрос: как мы удовлетворяем требования, а не то, откуда взялись эти требования. Исполнителей тоже нет, потому что нам не надо пользоваться теорией деятельности, чтобы описать участников активности. Мы не строим причинно-следственные связи. Если же надо построить модель причинно-следственных связей, то это еще одна дополнительная модель. Это знания, которыми пользуются технологи при проектировании предприятия, и я не видел, чтобы кто-то строил такие модели. Это — отраслевые знания, и учат им в институтах по много лет. Смоделировать, почему летит самолет – нереально трудно, и никто этого не делает. Просто моделируют полет самолета.
Итак, модель Захмана не включает в себя требования к предприятию, включает в себя модель процессов, но довольно специфическим способом — с указанием на исполнителей процесса, которых, как я уже сказал можно найти только в теории деятельности, и не разделяет модель технических мест и модель единиц оборудования.
Как я сказал ранее, модель Захмана скорее про деятельность. При этом было бы неплохо, если бы модель Захмана использовалась по назначению, — как способ описания деятельности. Это давало бы возможность анализировать мотивы и заинтересованность людей в их работе, но беда в том, что эта модель используется неверно. Например, на вопрос «почему токарь точит деталь?» можно получить ответ: «она нужна в сборочном цехе». Но необходимость ее в сборочном цехе не отвечает на вопрос, почему токарь точит деталь. Ответ был не на поставленный вопрос, а на какой-то другой. Например, для такого ответа правильным был бы вопрос: в каком процессе, или в какой операции должна участвовать выточенная деталь? Или на каком рабочем месте она нужна? Вы видите, что это совсем не вопрос «почему?». Кроме того, меня сильно смущает наделение Захманом компьютера или информационной системы способностью что-то делать. Скорее всего, он не одушевляет их, но использует метонимию в моделировании, что на мой взгляд, недопустимо.
Правильными вопросами будут: Какие существуют требования к предприятию? Какие процессы протекают на предприятии? Какие технические места в каких процессах участвуют? Какие единицы оборудования выполняют роли каких технических мест и когда?
Собственно, все. С наступающим, и до новых встреч!
Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF
Контекст разработки архитектуры предприятия
Так как я заметил, что ты, Цезарь, уже много построил и продолжаешь строительство, я разработал определенные правила, чтобы ты сам смог оценить качество как уже существующих, так и будущих зданий.
Витрувий, архитектор времен Римской империи
Разработка архитектуры предприятия включает в себя компоненты, связанные с функциональной архитектурой (бизнесом), информационными технологиями и управлением архитектурным процессом. Приведенная ниже диаграмма отражает подход NASCIO (Национальной Ассоциации CIO США), которая наглядно отражает то, как различные компоненты взаимодействуют и влияют друг на друга.
С учетом полученных выше знаний и детализации представления об архитектуре предприятия мы можем сказать, что ее разработка является процессом, основанным на бизнес-стратегии, который координирует идущие параллельно процессы создания бизнес-архитектуры, архитектуры информации, архитектуры прикладных систем и технологической архитектуры [5.1]. Таким образом, архитектура предприятия является целостным описанием ключевых стратегий организации, связанных с бизнесом, информацией, прикладными системами и технологиями, а также их влиянием на функции и бизнес-процессы организации. Разработка архитектуры предприятия ведется в соответствующем контексте существующих в организации структур управления и взаимодействия.
Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве Обороны США DoDAF ( Department of Defence Architecture Framework).
Методика является инструментом для создания широкого спектра различных архитектур. Она, как правило, включает в себя описание методов проектирования архитектуры в терминах использования определенных «строительных блоков», описание того, как эти «строительные блоки» связаны между собой, набор инструментов для описания элементов архитектуры, общий словарь используемых терминов. Методики также могут содержать список рекомендуемых стандартов и совместимых продуктов, которые могут использоваться для реализации различных элементов архитектуры. Важно понимать, что методики не только задают набор документов и планов, необходимых для описания предприятия, но и определяют, как все эти элементы описания связаны между собой.
Методики описывают, как определяются и документируются основные элементы архитектуры предприятия. Они позволяют решить проблему плохого взаимопонимания между вовлеченными в этот процесс людьми, поскольку задают некий общий, одинаково понимаемый набор понятий и моделей для описания элементов архитектуры в интересах различных категорий заинтересованных сторон. Разработка одних методик была инициирована государственными структурами, других – частным сектором и представителями индустрии. Различные методики, как правило, ориентированы на разные аудитории потенциальных пользователей и отличаются широтой охвата проблемы, вниманием к определенным областям, хотя тенденция состоит в постепенной унификации определений, связанных с архитектурой. Некоторые из методик концентрируются на определенных секторах индустрии, преимущества других подходов состоят в более четком документировании, а третьи уделяют большее внимание процессу перехода от сегодняшнего в будущее состояние архитектуры.
При этом надо четко понимать, во-первых, отличие методики описания архитектуры от самой архитектуры как таковой, а во-вторых то, что использование одной и той же методики может приводить к созданию абсолютно непохожих между собой архитектур предприятия из-за различий в бизнесе и области деятельности организации, наличия определенного набора унаследованных систем и т.д.
Важным для понимания методик являются используемые в них модели, различные представления (view) или домены архитектуры.
Описание ИТ-архитектуры служит детальным руководством, которое определяет основные, стандартные или типовые элементы ИТ-систем, их взаимосвязи, а также процессы управления информационными системами. Что хотелось бы получить от такого документа? Можно сформулировать следующие, частично противоречивые, требования :
Для формализованного описания ИТ-архитектуры организации могут использовать различные форматы. Важно, чтобы организация использовала такой формат описания, который бы обеспечивал легкий для понимания способ руководства по развитию всех аспектов ИТ в организации. Поэтому закономерно возникает вопрос по поводу «оптимального» формата, который может использоваться для описания ИТ-архитектуры именно как подмножества Архитектуры предприятия.
В следующих разделах этой лекции мы рассмотрим наиболее распространенные методики описания архитектур. При этом мы не делаем принципиального различия между теми из них, которые ориентированы на описание архитектуры предприятия как целого, и теми, которые рассматривают более узкий контекст ИТ-архитектуры. Заметим, что достаточно важная и хорошо проработанная методика Федеральной архитектуры США FEAF, документы с описанием которой к тому же находятся в публичном доступе.
| Содержание (предмет) Архитектуры предприятия | Определения архитектуры | ||||
|---|---|---|---|---|---|
| Описания систем | Руководства, Правила и Стандарты | ||||
| Как есть | Как должно быть | ||||
| Бизнес-архитектура | Связи между бизнес-процессами | Принципы (система ценностей и постулатов) | |||
| Бизнес-функции | |||||
| Подфункции | |||||
| Новые функции | |||||
| Архитектура информации | Информация | Шаблоны, Правила (политики), Сервисы | Модели технологической архитектуры (список стандартных технологий и продуктов) | ||
| Архитектура приложений | Приложения | ||||
| Точки доступа | |||||
| Интеграция | |||||
| Технологическая архитектура | Инфраструктура | ||||
| Платформы | |||||
| Системы хранения | |||||
| Сети | |||||
| Безопасность | |||||
| Системное управление | |||||
| Описание текущей среды ИТ | Область управления и контроля архитектуры | ||||
| Движущие силы с точки зрения бизнеса и стратегии | |||||
Второе определение говорит, что » архитектура – это процесс, т.е. набор руководств, правил и/или стандартов, которые применяются в процессе построения новых систем» (правая секция таблицы ). То есть второй смысл архитектуры – в создании системы правил, обеспечивающих направленный переход из текущего состояния информационных систем в будущие. Одним из элементов архитектуры при этом является модель технологической архитектуры, которая задает список утвержденных для закупки технологий. Выбор этих правил, узаконенных архитектурой, определяется принципами, которые должны быть сформулированы как часть всего архитектурного процесса.
Опять-таки, необходимо отдавать себе отчет, что наличие этой модели не означает, что все описание архитектуры предприятия можно поместить в одну простую таблицу. Однако эта таблица наглядно отражает основные аспекты архитектуры и связи между ними.
Ранее мы уже пришли к заключению, что многие понятия ИТ-архитектуры являются частными применениями соответствующих более общих понятий, связанных с архитектурой предприятия в целом. Соответственно, для описания и моделирования ИТ-архитектуры могут быть, при определенных условиях, применимы подходы, методологии и инструментальные средства моделирования, разработанные для более общих задач. Поэтому в этих разделах мы еще раз попробуем проследить на более детальном уровне связи понятий бизнес-архитектуры и корпоративной ИТ-архитектуры.
Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF
Модель Захмана
Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (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» как «методики».
Итак, в своей работе [5.3] Дж. Захман определил Архитектуру предприятия как «набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)». Термин » архитектура » здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия и сложного искусственного объекта, такого как здание или орбитальная международная космическая станция (МКС).
Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture ). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.
Исторически модель Захмана впервые была создана именно для ИТ-систем [5.4]. Этот подход в последующей работе [5.3] был обобщен для рассмотрения не только ИТ-систем, но и для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа.
Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рисунке 8.2. Заметим, что в модели именно пять строк, просто отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Перспективы (строки в таблице) могут, в частном случае, соответствовать различному уровню управления предприятием, если речь идет об архитектуре предприятия или использования информационной системы.
Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. Если проводить аналогию со строительством, то эти уровни содержат сведения о местонахождении и назначении постройки («особняк» для отдыха в престижном коттеджном поселке в элитной зоне), а также диаграммы, планы и картинки, которые архитектор обсуждает с хозяином будущего дома. Следующий уровень «логической модели» уже является более конкретным, но все равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен показывать подрядчикам.
Аналогично, в применении к деятельности предприятия верхняя строка » Контекст » соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует интересам бизнес-менеджеров и владельцев процессов. Третий уровень – тот, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков.
На каждом из этих уровней участники, вообще говоря, рассматривают одни и те же категории вопросов, соответствующих столбцам в таблице, – только с различным уровнем абстракции и детализации. В содержание этих колонок входят:
Сам Захман в своем интервью он-лайновому журналу » Enterprise Architect Online » без ложной скромности сравнил свою модель с периодической таблицей элементов Менделеева и назвал ее «периодической таблицей описательных представлений предприятия или двумерной системой, схемой классификации» [5.5]. Это действительно ко многому обязывающее сравнение, но Захман привел следующие аргументы в его пользу: «Вопросы что, как, где, кто, когда и зачем существуют тысячи лет. И они будут существовать еще тысячи лет. Требования к системам, процесс проектирования, производства или концептуальный, логический и физический уровень описания также существуют в течение тысяч лет и будут существовать еще тысячи лет. Логическая структура классификации, схема – неизменны».
В конце концов, как отмечает Захман, коммерческие предприятия и государственные организации должны понимать, что путь к эффективным информационным системам требует систематических подходов в проектировании ( engineering ). Если вы, например, занимаетесь большими проектами, связанными с интеграцией государственных информационных систем, то «. назначить одного ответственного человека – это еще не решение проблемы. Никакого чуда просто так не произойдет. В какой-то момент вы поймете, что настоящий процесс проектирования должен быть реализован для того, чтобы интегрировать эти объекты».