Примеры принципов в области управления данными.

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

Примеры принципов, связанных с прикладными системами

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

Примеры принципов, связанных с управлением контроля.

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

При разработке стандартов используют:

• Нужно уделить больше внимания, которые обеспечивают эффективное использование базовых систем;

• Определяйте стандарты процессов (процесс бизнес моделирования, метод разработки систем)

• Уделяйте внимание интерфейсам;

• Необходимо тесно сотрудничать с бизнес системами;

• Используйте списки конкретных версий техн. , утилит;

• Должен включать версии на соответствие;

• Стандарт должен содержать описание того, как обеспечивается поддержка.

17.05.12

Архитектура приложений.

Контексты и основные элементы архитектуры приложений.

В домене архитектуры выделяется 2 отрасли:

• Формирование и управление портфелем прикладных систем предприятия

• Разработка прикладных систем

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

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

ППС интегрирует набор информационных систем предприятия, обеспечивает потребности бизнеса и включает в себя следующие аспекты:

- имеющийся ППС (каталог имеющихся приложений и компонент, который отражает их связи с поддерживаемыми ими процессами, интерфейс с другими системами);

- планирование ППС (представляет функциональность которая требует для обеспечения желаемого состояния бизнес – архитектуру, архитектуру информации предприятия);

- план миграции (процесс перехода от текущего портфеля к будущему в рамках ИТ- проекта)

1-ый шаг в планировании ППС: оценка текущего состояния портфеля и того насколько он соответствует потребностям организации со стратегической( задачи стратегий бизнеса) и технологической точек зрения( техническая составляющая стратегий, использует технологии предприятия).

Технологическое составляющее оценивается на основе анализа того насколько ПС соответствуют принципам и технологическим стандартам принятым в технологии АП.

Модели и инструменты управления портфелем приложений:

- ценность точек зрения бизнеса;

- техническое состояние.

1-ый шаг.

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

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

2-ой шаг.

1. Оценить потребности со стороны бизнеса, которые никак не обслуживают ППС; Бизнес архитектура должна обеспечить список таких требований, архитектура информации уточнять эти требования с точки зрения информации обеспечивания;

2. Необходимо провести сравнение технологических и операционных требований (надежность, масштабирование) ППС с имеющейся технологической архитектурой для индефикации тех возможных инфраструктур, которых в данный момент нет, но они могут потребоваться;

3. Согласования проекта в области внедрения ПС и развития инфраструктур с учетом анализа на предыдущих 2-х шагах, в результате получаем синхронизированный план

миграции технологической архитектуры и архитектуры ПС с расстановкой приоритетов на основе определения ценностей проекта для бизнеса.

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

Влияние архитектуры приложений на инфраструктуры.

По методике Gartnew ПС классифицируется по 5 различным стилям:

1. Приложение, обслуживающее большое количество транзакций

2. Операция реального времени

3. Аналитическое приложение, бизнес аналитика, поддержка принятия решений

4. Приложение поддержки совместной работы

5. Корпоративные и обслуживающие приложения

Понимание специфики архитектурных стилей помогают для принятия решений следующим образом:

- помогает формировать требования будущей архитектуры ИТ

- анализ стилей процессов и приложений помогает понять требования к общей инфраструктуре и технологической архитектуре

- развитие технологической архитектуры, способсвует стандартизации технологий и применению экспертизы в этих областях

- различные архитектурные стили предъявляют различные требования и технологии используемые для интеграции систем.

Для выбора архитектурного стиля ключевыми являются следующие вопросы

1)Какие из 5 категорий приложений играют существенную роль в обеспечении общего успеха органиации

2)Обеспечивает ли архитектура ИТ соответствующее сочетание цены и производительности для обслуживания приложений наиболее критических с точки зрения успеха деятельности организации.