Неправильним — усі три бек-офіси мають сервери виключно в PRO-FIT Headquarters

Правильним — централізація вже відбулася у поточному стані

Частково правильним — лише Home & Away має кластер, але Auto та Legal Expense мають власні окремі сервери у своїх штаб-квартирах

Правильним — після злиття вся інфраструктура була централізована

Фази E & F виконуються паралельно з фазами A–D, а не після них

Фази E & F є необов'язковими і використовуються лише при злитті компаній

Фази E & F є спрощеними версіями фаз A–D для малих проектів

Фази A–D описують ЩО потрібно збудувати (архітектурний задум: бізнес, застосунки, дані, технології). Фази E & F описують ЯК і КОЛИ це буде реалізовано: альтернативні шляхи міграції, порядок впровадження проектів та перехідні стани

Помилка у варіанті A

Помилка у варіанті B

Помилка у варіанті C — VERSA-CLAIM є системою обробки претензій, а не конфігурації продуктів. Конфігурацію продуктів виконує P-CONFIG

Помилки немає — всі описи правильні

Від Web Portal та Call Center Application

Від Document Management System та Legal Expense CRM System

Від Auto Insurance Application та Home & Away Policy Administration

Від Legal Expense Back Office System та Home & Away Financial Application

Document Management System реалізує сервіс для кожного застосунку бек-офісу через Serving relation

Document Management System та бек-офіс пов'язані через Assignment relation — SSC є частиною бек-офісу

Document Management System отримує Document Data від усіх застосунків бек-офісу — через Flow relation

Document Management System передає Customer Data до кожного застосунку бек-офісу

Правильним — General CRM System охоплює всі дивізіони

Правильним — після злиття всі CRM одразу були уніфіковані

Частково правильним — є загальний General CRM System, але для юридичного страхування паралельно існує окрема Legal Expense CRM System

Неправильним — кожен дивізіон має власну CRM без жодної спільної системи

Це технічне обмеження інструменту Archi, а не вимога специфікації

BusinessProcess може з'єднуватися напряму з ApplicationComponent через Flow relation — це допустимо

ApplicationService є «контрактом» між бізнес-рівнем та рівнем застосунків: він абстрагує деталі реалізації від бізнес-процесу. Зміна компонента не впливає на процес, якщо сервіс залишається незмінним

DataObject та ApplicationComponent знаходяться на різних архітектурних рівнях, тому між ними взагалі не може бути зв'язків

General CRM System → Realization → Customer Administration (сервіс); Customer Administration → Serving → Notify Additional Stakeholders (процес)

General CRM System → Flow → Customer Administration; Customer Administration → Assignment → Notify Additional Stakeholders

General CRM System → Serving → Notify Additional Stakeholders (напряму, без проміжного сервісу)

General CRM System → Realization → Customer Administration; Customer Administration → Realization → Notify Additional Stakeholders

Information Structure Viewpoint — вона відображає логічну структуру та зв'язки між бізнес-об'єктами (Composition, Aggregation, Specialization)

Data Dissemination Viewpoint — вона показує зв'язки між об'єктами даних

Application Cooperation Viewpoint — вона містить всі елементи одночасно

Application Behavior Viewpoint — вона показує внутрішню обробку даних

Обидві точки зору призначені виключно для IT-архітекторів та розробників

Application Usage є застарілою точкою зору і не використовується в TOGAF 10

Application Cooperation — для бізнес-аналітиків; Application Usage — для технічних адміністраторів

Application Cooperation — для IT-архітекторів та CIO (розуміння інтеграційних залежностей між системами); Application Usage — для операційних менеджерів та власників процесів (розуміння впливу змін у системах на бізнес-операції)