что такое модель захмана
Схема Захмана при разработке требований к ИС
Схема Захмана [2] – одна из первых работ в области разработки архитектурных каркасов информационных систем.
Архитектурный каркас информационной системы — это структура свойств системы, которые должны быть заданы в ходе ее проектирования. Например, цели создания, роли и функции — всё это свойства системы, а заодно и требования к ней. Поэтому архитектурный каркас — это также и классификация требований к информационной системе.
Спрос на архитектурные каркасы возник в связи с многогранностью систем, которые приходится создавать. Задачи проектирования развернулись от разработки локальных алгоритмов расчета — систем одного пользователя — к организации взаимодействия распределенных предприятий с сотнями вовлеченных ролей. Для проектирования каждой такой информационной системы необходимо задать тысячи вопросов, прокрутить ее с разных точек зрения, а затем структурированно изложить результаты тем, кто будет реализовывать ее в коде. Чтобы свободно ориентироваться в этом и не проморгать опорные свойства, системным аналитикам понадобилась систематизация — архитектурный каркас.
Схема Захмана является наиболее полным архитектурным каркасом и определяет общие свойства информационных систем на том уровне, когда они еще не зависят от парадигмы проектирования, технологии и средств разработки. Она систематизирует знания об архитектуре информационной системы, охватывая все аспекты проектирования за счет использования системы шести универсальных вопросов «Что? Кто? Где? Когда? Как? Почему?».
Рисунок 1. Столбцы схемы Захмана
Захман адаптировал эти вопросы к проектированию информационных систем и уточнил срезы проектирования.
Срезы Что и Как отдаются для описания Данных и Функций информационной системы — объективному ядру систем этого класса.
Зачем и Кто — Мотивация и Люди вынесены вперед, это концентрирует внимание на том, что прежде всего должны быть определены цели создания системы, а потом уже конкретные функции и способы их реализации. Люди — это и заказчики системы, чьи цели должны быть достигнуты, и пользователи, выполняющие функции. Именно для них создается система и под их цели проектируются структуры данных и функций.
Следующие срезы — это Место и Время, соответствующие вопросам Где и Когда. Анализ информационной системы по этим срезам позволяет сформулировать нефункциональные требования, без учета которых можно попасть в просак и не достигнуть поставленных целей.
Наши цели всегда привязаны к конкретному месту и времени и не имеют смысла без них. Чтобы это лучше запомнить, просто замкните схему Захмана вот так:
Рисунок 2. Свертка схемы Захмана
и читайте следующим образом: информационная система — это система, в которой люди оперируют данными, выполняя функции с определенной целью в конкретном месте и заданном времени.
Интересно, что Захман не включил в исходную версию схемы три среза: «люди», «время», «мотивация» — они появились только во втором, расширенном варианте [5]. Захман был обеспокоен тем, что люди не захотят принять то, что это такие же опорные срезы проектирования, как и остальные. Сравните это с современной ситуацией — большинство методологий управления проектами фокусируются именно на Людях и Мотивации.
Разработка требований по Вигерсу
Можно читать книгу и делать проект в профессиональном инструменте
После того как основные ракурсы проектирования установлены, схема Захмана раскладывает знания об информационной системе по шести слоям, которые ведут нас от целей бизнеса, ради которой затевается разработка ИС, к конкретной технологии их достижения. Чем ниже уровень — тем сильнее зависимость от решений, принятых ранее.
Рисунок 3. Уровни детализации требований к ИС по схеме Захмана
Чтобы добраться до модели системы, необходимо сформировать требования двух предыдущих уровней — предметной области автоматизации и модели работы предприятия для которого разрабатывается ИС. Далее, чтобы реализация разработанной модели системы стала возможной, необходимо проработать технологическую модель и разработать конкретные компоненты.
Для разработки спецификации требований к ИС необходимо ответить на каждый из шести универсальных вопросов для каждого из шести слоев. Разумеется, эта разработка выполняется итеративно и порядок выявления свойств будущей системы чаще всего не совпадает с последовательностью ячеек в схеме Захмана. Но важно понимать, что изменения требований в каждом верхнем слое с большой вероятностью приведут к изменениям в последующих слоях. Может быть и обратная ситуация — изменения, например, в технологической модели, могут привести к изменению требований верхнего уровня — бизнес-правил и функций. Поэтому проведя изменения в одной из ячеек, необходимо оценить их влияние на все ячейки схемы.
В каждой ячейке Захман приводит ключевые понятия, которые используются для спецификации свойств проектируемой системы. К таким понятиям он относит, например, «вещи, важные для бизнеса», «бизнес-процессы», «бизнес-ограничения», «ресурсы», «элементы данных» и «отношения на данных», «функции приложений» и т.д. Основное требование Захмана — каждое понятие должно быть уникально и использоваться для описания системы только в одной из ячеек.
Также в схеме приводятся, но не навязываются, типы моделей для описания каждого среза системы. При этом связи между ними не предопределены.
Рисунок 4. Расширенная схема Захмана в русском адаптированном переводе
Рисунок 5. Фрагмент расширенной схемы Захмана
Движение в сторону проработки связей между ячейками исходной схемы имеет важное значение. Хотя все ячейки имеют самостоятельную ценность — они не могут существовать обособленно. Для каждого требования к ИС, соответствующего какой-либо ячейке, должны быть определены связи с требованиями из других ячеек. Например, бизнес-процесс (КАК) всегда работает с данными (ЧТО), и мы не сможем спроектировать систему, описав структуру бизнес-процессов отдельно от данных, которые они используют. И, конечно, эти связи хотелось бы понимать уже на уровне архитектурного каркаса.
В своей статье о расширенной схеме [3] Захман подчеркивает важность описания связей между моделями различных слоев. Это необходимо, чтобы сохранить представление о системе в целом и о контексте ее использования в ходе всех циклов проектирования. Фактически, он говорит о необходимости обеспечения сквозной трассировки требований и расширенная схема — это и есть попытка разработать модель такой трассировки.
Однако выбранный в расширенной схеме уровень детализации не позволил довести эту работу до конца — она переложена на плечи конкретной команды проектировщиков. Именно это, на мой взгляд, снижает ценность данной схемы и осложняет ее применение на практике.
Интересно отметить, что в 2008 году Захман в своей публикации «Точное определение схемы Захмана» определяет свою схему как онтологию [4]. Возможно это дань моде, а возможно необходимо, чтобы точнее классифицировать работу и выделить ее из серии новых архитектурных каркасов, которые стали включать не таксономию архитектуры, а процесс по ее разработке. Сам автор мотивирует это тем, что процессы, основанные на онтологической структуре, будут более предсказуемы и будут выдавать повторяемые результаты. Заметим, что сама схема при этом не изменена.
Схема Захмана — отличное средство для обучения начинающих аналитиков-постановщиков, а также механизм тестирования требований и контроля качества проектирования.
Работая над требованиями к системе, держите распечатку схемы под рукой и «прокатывайте» каждое требование по каждому срезу. Эта не займет много времени, но за счет активации ассоциативных связей позволит выявлять требования за меньшее число шагов взаимодействия с заказчиком. Фактически, многие техники креативности и мозгового штурма используют именно такой подход.
Хотите сослаться на эту статью? Используйте правильную ссылку:
Мадорская Ю.М., Схема Захмана при разработке требований к ИС //Практика проектирования систем.-2015. [электронный ресурс] — Режим доступа: http://reqcenter.pro/zachman-framework/, свободный. — Загл. с экрана
Литература
[11] Данилин А. Архитектура и стратегия / А. Данилин, А. Слюсаренко. – М. Интернет-Ун-т Информ. Технологий, 2005. – 504 с.
Преобразование подхода Захмана
Доброго времени чтения, уважаемые участники habrahabr.ru
В статье 2001 года Леонид Черняк — Архитектура систем по Захману
http://www.osp.ru/os/2001/12/180711/
приводится цитата:
вот уже более сорока лет применение технологий к решению корпоративных проблем стало чем-то вроде поиска Священной чаши Грааля
а архитектура Захмана и сейчас считается интересным направлением поиска https://msdn.microsoft.com/ru-ru/library/ee914379.aspx
Анализ модели Захмана на 2013 год можно прочитать по ссылке http://ailev.livejournal.com/951732.html
другие подходы опубликованы в http://www.intuit.ru/studies/courses/995/152/lecture/4236?page=2
Первую попытку анализа я пытался выполнить в статье http://habrahabr.ru/post/176935/ на основе терминологии книги Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия: Интернет-Ун-т Информ. Технологий, 2005
Схема Захмана 6 на 6 пользуется заслуженным уважением, однако с точки зрения туннельного моделирования целесообразно её преобразование в расширяемую систему.
В данной теме предлагается система координат для моделирования предприятия.
Измерение времени разнесено по всей модели с позиции туннельного моделирования http://habrahabr.ru/post/259291/
В верхней части предполагается область будущего или абстрактного, в нижней — прошлого или конкретного.
Так же рекомендуется восприятие циклического времени: жизненного цикла продукта, цикла управления качеством PDCA, прямого времени выполнения проекта Ганта, оси времени описания исторических событий.
Ниже представлена схема Онтологии предприятия Захмана с привязкой к симметричной туннельной модели
Предполагается, что время участвует во всех проявлениях моделируемой области, хотя полностью отрицать возможность выделения времени в отдельную вертикаль, как предлагает Захман, я не возьмусь 🙂
Методики описания архитектур. Модели Захмана и 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 ). Если вы, например, занимаетесь большими проектами, связанными с интеграцией государственных информационных систем, то «. назначить одного ответственного человека – это еще не решение проблемы. Никакого чуда просто так не произойдет. В какой-то момент вы поймете, что настоящий процесс проектирования должен быть реализован для того, чтобы интегрировать эти объекты».
Что такое архитектура предприятия, и почему Захман ошибся?
Вторая статья про мифологическое сознание тоже будет короткой. Сегодня я расскажу, к каким проблемам приводит мифологическое сознание при моделировании архитектуры предприятия.
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Читатель, натренированный в описании архитектур предприятий, быстро меня поправит. Он скажет, что я неправильно ставлю вопросы. Надо спрашивать: кто выращивает, почему он выращивает, что выращивает. Но тогда получается, что я могу описать деятельность субъекта, который выращивает кукурузу, но не могу описать сам рост. Смирившись с тем, что я не могу описать процесс роста, у меня все равно остаются неразрешенные вопросы: кто и почему выращивает кукурузу (см. выше)?
Получается, что, задавая вроде бы логичные вопросы, я в лучшем случае получаю несколько ответов, а в худшем, не получаю их вообще. Если взять предельный случай, когда у нас есть полностью роботизированное предприятие, на котором вообще нет людей, то ответом на вопрос «кто?» будет — «никто». В результате мы вообще ничего не можем сказать об этом предприятии! Правда, есть один выход из этой ситуации, немного лукавый, – надо лишь воспользоваться мифическим сознанием и одушевить роботов. Тогда, одушевив неодушевленное, мы сможем ответить на вопрос: кто? Робот. Почему? Потому что так устроен этот робот, или потому что программист его так запрограммировал. На второй вопрос мы снова получаем странные ответы. Почему же так получилось, и какие вопросы на самом деле стоит задавать? Я попытаюсь кратко изложить свое мнение на этот счет, рассказав о тех логических ошибках, которые я нашел в модели Захмана.
Если посмотреть на вопросы, которые задаются в модели Захмана, можно убедиться, что они в точности соответствуют теории деятельности. Деятельность – это психическая функция субъекта (группы субъектов). Поэтому, отвечая на вопросы Захмана, мы строим модель психической функции субъекта (субъектов). Наука, изучающая психические функции субъектов, называется психология. Получается, что Захман отвечает на вопросы, которыми задаются психологи: зачем субъект делает то или иное действие? Или как мотивировать субъекта на выполнение тех или иных действий? Эти вопросы, безусловно, интересные и важные, но являются ли ответы на них описанием архитектуры предприятия? Чтобы ответить на этот вопрос, надо понять, что же такое предприятие?
Как же на самом деле происходит проектирование предприятия и какие артефакты при этом возникают? Прежде чем проектировать предприятие, строится модель требований к нему. Модель требований формируется на основе требований, которые предъявлены к этому предприятию со стороны всех его участников, контрагентов и стейкхолдеров. Аналог в ИТ — требования к программному продукту. Далее на основе этих требований строится модель процессов предприятия с необходимой степенью детализации. Аналогом в ИТ будет перечень функций программного продукта. Далее строится модель функциональных объектов, или, говоря специализированным языком, технических мест, которые должны участвовать в перечисленных ранее процессах. Аналогом в ИТ будет описание процедур, и объяснение какие процедуры в каких функциях участвуют. Далее подбираются те единицы оборудования, которые могут выполнять роли перечисленных технических мест. Аналог в ИТ — это программный код.
Предприятие – это функциональный объект, который создан удовлетворяющим определенным требованиям. В этом смысле предприятие ничем не отличается от такого объекта, как часы, или производственная линия. Часто вместо термина функциональный объект можно услышать термин техническое место. Техническое место отличается от единицы оборудования тем, что единица оборудования выполняет роль технического места. Например, трансформатор выполняет роль преобразователя напряжения, при этом в разное время разные трансформаторы могут выполнять роль одного и того же преобразователя. Еще одним примером технического места является должность, отдел, подразделение, штат. Например, токарь участвует в функции изготовления деталей. Это — техническое место, роль которого в разное время могут выполнять разные единицы оборудования (физические лица). О сложностях моделирования технических мест и единиц оборудования я кратко написал в статье Моделирование активов предприятия: современные стандарты и практика.
При моделировании технических мест, мы описываем процессы и участников этих процессов. Замечу, что именно участников, а не исполнителей, — трансформатор не может преобразовывать напряжение, потому что он не является одушевленным существом. Об этом я писал в прошлой статье Моделирование активности и мифологическое сознание. Если все же сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения. О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон. Другой распространенной метонимией будет высказывание: «компьютер решает задачи». Те же, кто действительно считают, что трансформатор, или компьютер что-то делает на самом деле, одушевляют неодушевленное, пользуясь мифическим сознанием.
Заметим, что до сего момента мы ни слова не сказали о целях, об исполнителях и причинно-следственных связях. Мы лишь говорили о требованиях, о функциях и участниках этих функций – технических местах. Цели остались на этапе формирования требований к предприятию и далее они не пошли. Мы можем знать эти цели, а можем не знать, — для модели предприятия это не имеет никакого значения. Модель предприятия отвечает на вопрос: как мы удовлетворяем требования, а не то, откуда взялись эти требования. Исполнителей тоже нет, потому что нам не надо пользоваться теорией деятельности, чтобы описать участников активности. Мы не строим причинно-следственные связи. Если же надо построить модель причинно-следственных связей, то это еще одна дополнительная модель. Это знания, которыми пользуются технологи при проектировании предприятия, и я не видел, чтобы кто-то строил такие модели. Это — отраслевые знания, и учат им в институтах по много лет. Смоделировать, почему летит самолет – нереально трудно, и никто этого не делает. Просто моделируют полет самолета.
Итак, модель Захмана не включает в себя требования к предприятию, включает в себя модель процессов, но довольно специфическим способом — с указанием на исполнителей процесса, которых, как я уже сказал можно найти только в теории деятельности, и не разделяет модель технических мест и модель единиц оборудования.
Как я сказал ранее, модель Захмана скорее про деятельность. При этом было бы неплохо, если бы модель Захмана использовалась по назначению, — как способ описания деятельности. Это давало бы возможность анализировать мотивы и заинтересованность людей в их работе, но беда в том, что эта модель используется неверно. Например, на вопрос «почему токарь точит деталь?» можно получить ответ: «она нужна в сборочном цехе». Но необходимость ее в сборочном цехе не отвечает на вопрос, почему токарь точит деталь. Ответ был не на поставленный вопрос, а на какой-то другой. Например, для такого ответа правильным был бы вопрос: в каком процессе, или в какой операции должна участвовать выточенная деталь? Или на каком рабочем месте она нужна? Вы видите, что это совсем не вопрос «почему?». Кроме того, меня сильно смущает наделение Захманом компьютера или информационной системы способностью что-то делать. Скорее всего, он не одушевляет их, но использует метонимию в моделировании, что на мой взгляд, недопустимо.
Правильными вопросами будут: Какие существуют требования к предприятию? Какие процессы протекают на предприятии? Какие технические места в каких процессах участвуют? Какие единицы оборудования выполняют роли каких технических мест и когда?
Собственно, все. С наступающим, и до новых встреч!