Место архитектуры ЭП в концептуальном проектировании государственных информационных систем

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

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

Рис. 13. Схема взаимосвязи слоев архитектуры

В ходе реализации ФЦП «Электронная Россия» предпринималось несколько попыток создать общефедеральный репозиторий архитектуры электронного правительства, однако сегодня, к сожалению, не существует ни одного действующего репозитория.

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

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

Проработав архитектуру создаваемой системы, создайте ее архитектурную схему. Вы можете использовать для этого такие программные продукты, как ARIS Toolset, Microsoft Visio, Mind Manager, Rational Software Architect или любой стандартный, например, свободно распространяемый офисный пакет приложений в зависимости от принятых в Вашей организации стандартов. Рассмотренные нами модели дают Вам содержательную основу, на базе которой может быть написан текст проекта концепции и необходимое обоснование.

Основные выводы:

· Модель эффективности позволяет спроецировать показатели на конкретные решения.

· Модель функций задает, с одной стороны, рамки создаваемой системы, с другой — связку «сверху» между моделями нижних уровней, с третьей — дает инвариант для сравнения при внесении существенных изменений в процессы.

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

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

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

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

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

Дополнительные материалы по теме лекции

1. http://citeseer.ist.psu.edu/sametinger96taxonomy.html — одна из классификаций программных компонент.

2. www.fostas.ru — фонд ФОСТАС, занимающийся разработкой и адаптацией Ит-архитектур.

3. www.togaf.com — сайт The Open Group — разработчика одной из наиболее используемых в США архитектурных методологий.

4. http://www.zifa.com/ — Институт Захмана (англ.).

5. http://www.ewita.com — Enterprise-wide IT Architecture (EWITA) site.

6. http://www.nascio.org — NASCIO — информационная база программы разработки адаптивной архитектуры предприятия (англ.).

7. http://www.eacommunity.com — Enterprise Architecture Community.

8. http://www.geao.org — The Global Enterprise Architecture Organization.

9. http://www.bredemeyer.com — Bredemeyer Consulting.

10. http://www.enterprise-architecture.info/ — Institute for Enterprise Architecture Development (IFEAD).

Поиск по сайту: