Архитектурный подход в проектировании

инструментальных методов в экономике»

8 декабря 2016 г.

то физический или концептуальный объект / сущность).

Архитектура системы –(ANSI/IEEE Std

1471-2000)
«основы устройства системы, воплощенные в ее компонентах, их взаимосвязях между собой и с окружением, и в принципах, управляющих ее конструированием и эволюцией»

«Архитектура и методики уровня предприятия должны включать в свое содержание роли людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия» (по ISO 15704)

объединение, не обязательно связанное с коммерческой деятельностью. Это может быть

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

целому предприятию, подразделению или даже к отдельной прикладной системе.
Архитектура

предприятия является одним из инструментов организационных изменений и всего предприятия в целом с использованием ИТ, и особенно той части организации, которая отвечает за информационные технологии.
Существуют два основных подхода к организационным изменениям. Первый подход связан с реорганизацией, реинжинирингом процессов, а второй – с управлением знаниями.
По большому счету, архитектура предприятия – это прежде всего управление знаниями, т.е. процесс сбора и распространения информации о том, как организация использует и должна использовать ИТ в своей деятельности. Включение же в архитектуру предприятия представлений о бизнес - архитектуре обеспечивает связь с возможностями оптимизации бизнес-процессов.

архитектуры «Гауди» (Philips).

3. Модель RM-ODP (ISO).

4. Архитектура DoDAF

(Министерство обороны США).

5. Методика построения архитектуры C4ISR (Министерство обороны США).

6. Архитектура TEAF (казначейство США).

7. Методика FEAF (федеральная архитектура правительства США).

8. Метод планирования архитектуры организации EAP.

9. Методика разработки SAM.

10. Модели «4+1».

11. Методика NASCIO.

12. Методики TOGAF.

13. Методики META Group.

14. Архитектурные методики Gartner.

15. Инфраструктура (схема) Захмана (Zachman Framework).

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

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

очередь, на деятельностях, а не на артефактах, он может быть

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

менеджеров есть стратегическое видение. Понимание которого важно для составления плана-графика

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

Выявить срочные потребности Бизнес-сообщество больше знает текущем состоянии. Ваша задача - получить эти факты и уравновесить их с набором ожиданий стратегического видения.

это главная движущая сила бизнес-процессов. Вы не сможете двигаться вперед

без надлежащего знания своего основного инструмента.
5. Составьте план-график модернизации.
6. Поддерживайте актуальность архитектурной модели предприятия.

отличаются большей длительностью, чем итерации RUP, и объединяют несколько фаз

реализации и обслуживания архитектуры предприятия. Область охвата архитектуры предприятия шире области охвата одного проекта RUP

ADM работает с любыми видами требований, особенно с требованиями к

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

процессом, управляемым архитектурой технологии, в то время как TOGAF управляется

архитектурой бизнеса. В RUP, бизнес-требования собираются для того, чтобы спроектировать и поставить систему на основе программного обеспечения, тогда как в TOGAF технология рассматривается как способ реализовать бизнес-представление.
Целью RUP как методологии жизненного цикла разработки программного обеспечения (Software Development Life Cycle, SDLC) является поддержка поставки приложений. Это контрастирует с целью TOGAF, которая заключается в поддержке реализации и обслуживания архитектуры предприятия.