NIST Enterprise Architecture Model
NIST Enterprise Architecture Model - это модель, иллюстрирующая взаимосвязь, взаимодействие и взаимозависимость различных видов обеспечения информационных систем.
Описание модели можно найти в википедии. Я бы посоветовал еще обратить внимание на статью про Enterprise architecture framework, поскольку в ней, по моему мнению, сделан акцент на использование этой модели на практике.
Модель так же прекрасна, как и очевидна. И так же очевидна, как и логична. Поэтому, когда смотришь на нее, первая мысль, которая приходит в голову, звучит так: "А что тут такого? Это ведь ежу понятно!".
Так-то оно может и да, но в жизни все иначе - множество проблем, связанных с некачественным проектированием информационных систем, связано с незнанием или непониманием проектировщиками (аналитиками и архитекторами) того посыла, который в себе несет эта модель:
Информационная модель не является моделью данных, которыми управляет система. Но поскольку данные, которыми манипулирует система, являются интерпретацией информации, то модель данных абсолютно точно должна учитывать все закономерности, определяемые информационной моделью.
Информационная модель определяет все сущности предметной области, которые должны найти свое отражение в проектируемой системе. Кроме того, информационная модель определяет минимальный набор функций, которые должны быть реализованы для обеспечения работоспособности системы (CRUD по каждой сущности, будь то справочники или оперативная информация + функциональность, реализующая взаимосвязи между сущностями и преобразование информации). Т.е. информационная модель является инструментом уточнения скоупа возможностей проектируемой системы.
В случае, если по какой-то причине команда отказывается от проведения информационного моделирования на проекте, она должна быть готова принять на себя следующие риски:
Описание модели можно найти в википедии. Я бы посоветовал еще обратить внимание на статью про Enterprise architecture framework, поскольку в ней, по моему мнению, сделан акцент на использование этой модели на практике.
Модель так же прекрасна, как и очевидна. И так же очевидна, как и логична. Поэтому, когда смотришь на нее, первая мысль, которая приходит в голову, звучит так: "А что тут такого? Это ведь ежу понятно!".
Так-то оно может и да, но в жизни все иначе - множество проблем, связанных с некачественным проектированием информационных систем, связано с незнанием или непониманием проектировщиками (аналитиками и архитекторами) того посыла, который в себе несет эта модель:
- Бизнес имеет архитектуру, которая являет собой совокупность взаимосвязанных взаимозависимых бизнес-процессов. Ни один процесс никогда не существует изолированно. Всегда есть смежные процессы, о существовании которых при проведении анализа необходимо как минимум знать.
- Всегда есть нормативная база, регламентирующая деятельность Бизнеса.
- Информация и данные - это разные вещи. Информация - это то, что живет в Бизнесе, данные - это представление информации в электронном виде. Информационная система не может управлять информацией, она управляет данными. А Бизнес работает с информацией. Поэтому эффективность системы существенно зависит от точности интерпретации информации в те данные, которыми управляет система.
- Система всегда работает на программно-аппаратной платформе, включающей в том числе каналы связи и смежные системы. Платформа всегда влияет на возможности системы (как правило, ограничивает их), поэтому важно знать это влияние.
- Информационная архитектура определяет архитектуру проектируемого решения. Но никак не архитектура данных, которыми система будет управлять.
Информационная модель не является моделью данных, которыми управляет система. Но поскольку данные, которыми манипулирует система, являются интерпретацией информации, то модель данных абсолютно точно должна учитывать все закономерности, определяемые информационной моделью.
Информационная модель определяет все сущности предметной области, которые должны найти свое отражение в проектируемой системе. Кроме того, информационная модель определяет минимальный набор функций, которые должны быть реализованы для обеспечения работоспособности системы (CRUD по каждой сущности, будь то справочники или оперативная информация + функциональность, реализующая взаимосвязи между сущностями и преобразование информации). Т.е. информационная модель является инструментом уточнения скоупа возможностей проектируемой системы.
В случае, если по какой-то причине команда отказывается от проведения информационного моделирования на проекте, она должна быть готова принять на себя следующие риски:
- Пропуск требований к реализации ключевого функционала, необходимого для нормального отражения предметной области в виде данных системы - причина в том, что банально забываются некоторые сущности, связи между ними. Иногда проблема кроется в неправильном представлении взаимосвязей между сущностями.
- Проблемы с внесением изменений в структуру базы данных (высокая стоимость, существенные регрессии) - вызван тем, что структура базы, построенная без четкого понимания информационной модели, является нелогичной. А внесение изменений во что-то нелогичное всегда приводит к непредсказуемому результату.
- Проблемы с удобством использования системы. Причина кроется в том, что информационная модель показывает как сущности, так и закономерности их взаимосуществования. Пользовательский интерфейс, спроектированный не только по пониманию динамической составляющей предметной области (процессы), но и учитывающий логику информации, является более гармоничным в своей развернутости к конечному пользователю лицом.
- Нечеткое определение скоупа. Мне кажется, с учетом всего вышесказанного причина понятна. Возможное следствие риска - неконтролируемое расползание границ проекта.