Architecture Document Template

ARCHITECTURE DOCUMENT TEMPLATE


PROJECT NAME

Page 1


Versions of the document

Version N° Date Author Comments / Modifications

Validation list (last version)

Date Name Function Comments

Written by PMD

Checked by

Approved by

Diffusion list (last version)

Name Function Expected validation (Y/ N)

Last date for validation *

To All PM Y

Copy N

* In case of absence of any comments from you before the DD/MM/YY, the document will be considered as validated.

Reference document

Document Version N°

Page 2


PLAN

1 INTRODUCTION.................................................................................................................6

1.1 Purpose...................................................................................................................................................... 6

1.2 Tailoring the GAD...................................................................................................................................... 6

1.3 Scope.......................................................................................................................................................... 6

1.4 Definitions, acronyms & abbreviations...................................................................................................6

1.5 References................................................................................................................................................. 6

1.6 Overview..................................................................................................................................................... 6

2 BUSINESS ARCHITECTURE.............................................................................................7

2.1 Introduction................................................................................................................................................ 7

2.2 Business context....................................................................................................................................... 7

2.3 Business processes.................................................................................................................................. 7

2.4 Business events........................................................................................................................................ 8

2.5 Business impacts...................................................................................................................................... 8

3 FUNCTIONAL ARCHITECTURE........................................................................................8

3.1 Functional composition............................................................................................................................ 9

3.2 Most significant functionalities and use cases.......................................................................................9

3.3 Functional communication and interactions.........................................................................................10

3.4 Functional impacts.................................................................................................................................. 10

3.5 Business traceability............................................................................................................................... 10

3.6 Data model (optional).............................................................................................................................. 10

3.7 Object lifecycles (optional)..................................................................................................................... 11

3.8 Reference data......................................................................................................................................... 12

3.9 Functional traceability............................................................................................................................. 12

3.10 EA compliance..................................................................................................................................... 12

Page 3


4 APPLICATION ARCHITECTURE.....................................................................................12

4.1 Application composition......................................................................................................................... 12

4.2 Application dependencies...................................................................................................................... 13

4.3 Applications services.............................................................................................................................. 13

4.4 Applications flows and interactions......................................................................................................14

4.5 Descriptions of the logical modules......................................................................................................14

4.6 Application impacts................................................................................................................................. 14

4.7 Functional traceability............................................................................................................................. 14

4.8 Referential databases & nomenclatures................................................................................................14

4.9 EA compliance......................................................................................................................................... 14

5 SOFTWARE ARCHITECTURE REQUIREMENTS...........................................................15

5.1 Size and performance............................................................................................................................. 15

5.2 Other requirements and constraints......................................................................................................15

6 TECHNICAL ARCHITECTURE........................................................................................15

6.1 Technical composition............................................................................................................................ 15

6.2 Reuse........................................................................................................................................................ 16

6.3 Application traceability........................................................................................................................... 16

7 DEPLOYMENT ARCHITECTURE....................................................................................16

7.1 Geographical deployment....................................................................................................................... 16

7.2 Infrastructure........................................................................................................................................... 16

7.3 Operational constraints........................................................................................................................... 16

8 DEVELOPMENT STRATEGY (OPTIONAL)....................................................................16

9 DATA MIGRATION STRATEGY (OPTIONAL)................................................................17

10 DEPLOYMENT STRATEGY (OPTIONAL)....................................................................17

11 CONFIGURATION AND VERSION MANAGEMENT STRATEGY (OPTIONAL)..........17

Page 4


12 SECURITY & CONFORMANCE CONSTRAINTS.........................................................17

13 RISKS............................................................................................................................17

14 APPENDICES................................................................................................................18

14.1 EA Functional Architecture Compliance............................................................................................18

14.2 EA Application Architecture Compliance..........................................................................................21

14.3 EA Rules Compliance.......................................................................................................................... 23

14.4 Norms & Standards compliance.........................................................................................................23

14.5 IT Risks.................................................................................................................................................. 24

Page 5


1 INTRODUCTION

1.1 Purpose

This Global Architecture Document (GAD) provides an architectural overview of the solution , depicting its different aspects using different views. It is intended to capture and convey the significant architectural decisions made.

The GAD provides a comprehensive overview of the architecture of the solution. It is a communication medium between the sponsor and the architects regarding significant points of the project. The GAD is an input to an architecture review process.

1.2 Tailoring the GAD

The outline of the GAD may be adjusted to suit the nature of the project. Some of the sections may be irrelevant or shortened. Some specific aspects may require their own supplemental section. Some appendices have to be added to explain certain aspects. List and justify here the tailoring decisions you have taken. Otherwise, delete this paragraph.

1.3 Scope

Describe what the GAD applies to: What are the covered business needs? What are the involved main business processes/activities and stakeholders? Are there connections with other business domains, business partners, final clients, or external systems?Which applications does the project create, replace, or modify? Are they internal, B2B, B2C applications?Is the project an opportunity to build a new architectural framework or a new infrastructure?Are there pre-requisites to the project, or connections with other projects? Can the project be de-synchronized from other projects?Is it an emergency project, a classical project (improvement), an ERP project? What are the main issues raised by the project’s emergency?What does the project or solution do not? (Say it explicitly). What is out of scope?Is the intended solution general or disposable?

1.4 Definitions, acronyms & abbreviations

List all definitions, acronyms & abbreviations referenced in the GAD.DSI Direction des Systèmes d’InformationEA Enterprise (IT) ArchitectureIIA International IT ArchitectureIITD International IT DepartmentIS Information SystemIT Information Technology

1.5 References

Project Opportunity Document [reference]List all documents referenced in the GAD. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which it can be obtained.

1.6 Overview

Describe what the rest of the GAD contains and explain how it is organized.

Page 6


2 BUSINESS ARCHITECTURE

Purpose: to recall the business context, scope and processes of the solution:

2.1 Introduction

Answer the following questions:- From a business model point of view, what are the business changes supported by the

project? In which ways, does it change?- Is it compliant with the Business Strategy?- What are the links with the business? Is it a strategic project for the business? Why?- Are there impacts on the organization and its procedures? What are they?- If it is a project for a product, what are the product families, product types, product

management modes and risks types, the distribution channels, and the marketing targets?

The business architecture is described by broken down and orchestrated business processes and activities which are triggered by and generate business events. Those processes and activities operate in a human, organizational, and technical context that has to be delineated.

2.2 Business context

List all the human, organizational or technical (e.g. IT systems, applications, devices) entities and stakeholders involved in the business solution (the “In-Scope Stakeholders”).

In-Scope Stakeholders:Name Definition<stakeholder name> <stakeholder definition>

You may formalize the business context of the solution: using a top-level flow diagram: the business solution symbol is connected with external entity symbols formalizing the In-Scope Stakeholders around. Besides formalizing the context, this top-level flow diagram shows external exchanges. It formalizes the information flows between the business solution and In-Scope Stakeholders.

Alternatively, you may formalize the business context using a top-level UML business use case diagram. The business solution is denoted by a single business use case symbol. All In-Scope Stakeholders are denoted by business actors. (Recall that business actors do not denote only human beings, but any kind of external entities, organizations for instance.). The exchanges may be denoted as information flows between the business solution and the In-Scope Stakeholders. They may also be formalized in UML communication or collaboration diagrams.

2.3 Business processes

List the broken down business macro-processes, processes and activities involved in the business solution (the “In-Scope Processes”) grouped by owning processes.

In-Scope Processes/Activities: Owning Process/Activities Name Definition<process/activity> <process/activity name> <process/activity definition>

You may present this list in hierarchical process diagrams using process symbols.

Page 7


Technical AccountsClosure Elaboration

Macro Processes

Budget and MTP(mid term plan) Elaboration

Reinsurance Management(Only in quote share)

Figure 1. Process symbol

Outline the covered business processes and activities. The description of the processes and activities can be drawn from (or inspired of) the Business Model available in the “Process on-Line” website.Alternatively, business processes and activities may be described with the use case technique, and/or using UML activity diagrams.

Figure 2. Activity diagram example.

2.4 Business events

The In-Scope Stakeholders and Processes communicate through triggering business events. List the business events exchanged between In-Scope Stakeholders and Processes (“In-Scope Events”).

In-Scope Events:Name Definition Sending

StakeholdersSending Activities

Receiving Stakeholders

Receiving Activities

<event name>

<event definition>

<stakeholder list> <activity list> <stakeholder list> <activity list>

2.5 Business impacts

Which stakeholders and current business processes are impacted or modified? Are there new business processes or activities to implement or to provide with tools? What are the other business processes impacted?

3 FUNCTIONAL ARCHITECTURE

Purpose: to describe the high level functions or use cases of the solution.

Page 8


3.1 Functional composition

Identify and describe the high-level nested functional blocks or high-level use cases of the solution that support the in-scope business processes/activities. You may formalize these functional blocks using UML package diagrams, and the use cases in use case diagrams.

Functional block1.3

Functional block1.2

Functional block1.1

Functional block3.2

Functional block3.1

Functional block1

Functional block1 Functional block2

Functional block3

Target solution

Functional block1.3

Functional block1.2

Functional block1.1

Functional block3.2

Functional block3.1

Functional block1


Functional block3

Target solution

Figure 3. Package diagram example

Target Solution

UC1

UC5

UC2

UC3

UC4

Actor1

Actor2

Actor3

Actor4

UC6

Target Solution

UC1

UC5

UC2

UC3

UC4

Actor1

Actor2

Actor3

Actor4

UC6

Figure 4. Use case diagram example

In-scope functional blocks or use cases:Name Description<functional block/use case name> <functional block/use case description>

3.2 Most significant functionalities and use cases

List the most significant functionalities and use cases of the solution. What are the more demanding, design-stressing functionalities and use cases? What are the specific, delicate points of the solution?

Page 9


3.3 Functional communication and interactions

Identify and describe the functional flows between the in-scope functional blocks and with other functional blocks of the IS. Describe how they interact with each other and with other functional blocks. You may formalize this using UML collaboration or communication diagrams.

Functional block1.3

Functional block1.2

Functional block1.1

Functional block3.2

Functional block3.1

Functional block1External

functional block1

External functional

block2

External entity1


Functional block3

Target solution

Message1

Message2

Message3

Message5

Message4

Message6

Message10

Message7

Message8

Message9Message11

Functional block1.3

Functional block1.2

Functional block1.1

Functional block3.2

Functional block3.1

Functional block1External

functional block1

External functional

block2

External entity1


Functional block3

Target solution

Message1

Message2

Message3

Message5

Message4

Message6

Message10

Message7

Message8

Message9Message11

Figure 5. Communication diagram example

In-scope functional flows:Senders Receivers Name Description<sender list > <receiver list > <functional flow name> <functional flow description>

3.4 Functional impacts

Describe the functional impacts of the solution on the IS: What does remain unchanged? What is removed? What is replaced? What is adapted? What is new?

3.5 Business traceability

Trace the business architecture to the functional architecture. Which functional blocks support each in-scope business process/activity?

3.6 Data model (optional)

Identify and describe the conceptual entities of the domain of the solution, and their relations. You may formalize this using high-level simplified UML class diagrams. If there are different subject matters or domains in the solution, each one has a separate data model. If there are few entities and relations, provide their description here, otherwise in Appendix.

Page 10


Informationtheme

Information item

Applicationcomponent

Data structure

Data item

Macro-function

Functional exchange

Class

Attribute

Package

contains *

1

contains

is contained in

*

1

is contained in

creates

0..1

is created from

creates

0..1

1

1

is created frommaps from

0..1

maps to

*

owns *

is owned by 0..1

uses

1..*

0..1

is used by

contains *

1is contained in

sends

receives

Is received by

is sent by

1..*

1

*

*

contains

is contained in

*

1

owns *

is owned by 0..1

Figure 6. Class diagram example

Domain entities:Name Description<entity name> <entity description>

Domain relations:Number Meaning Description<relation number> <couple of

phrases to read the relation in both directions>

<relation description>

3.7 Object lifecycles (optional)

If relevant, identify the entities with a lifecycle and formalize it using a simplified UML statechart.

Created

Ready

Picked

new

setValue

pick

Created

Ready

Picked

new

setValue

pick

Figure 7. Statechart example

Page 11


3.8 Reference data

Identify and list the reference data used or needed. Are there information structures that could or should be promoted as reference data?

3.9 Functional traceability

Trace the information structures to the functional architecture. Which information structures support each in-scope functional block?

3.10 EA compliance

State the compliance of the business solution with the EA Functional Model. Which are the functions referenced in this Functional Model? Which aren’t? State the compliance with the EA Informational Model. Which is the information referenced in this Informational Model? Which aren’t? Comment the gaps. See in the Appendix how to state this compliance.

4 APPLICATION ARCHITECTURE

Purpose: to identify and describe the logical modules which make up the solution, as well as their dependencies and interactions. A comprehensive platform-independent model (PIM) of each logical module describing their structure (classes, typed attributes, and relations) and behavior (object lifecycles, operations) may be provided in Appendix.

4.1 Application composition

Identify and describe the logical modules that support the functional architecture required and make up the solution. Each logical module is an isolated subject matter that the solution needs to integrate. Each one has a mission statement. It can be already realized or not. You may illustrate the application architecture of the solution and its layered logical architecture in an UML package diagram.

Figure 8. Layered application architecture

Logical modules:Name Mission Reused (Y/N) Implemented in PIMed(Y/N)< module name> <mission statement> <language>The logical module is “PIMed” if it has a complete platform-independent model (the highest form of portability and reusability).

Questions that can help you to identify the logical modules of the solution:Page 12


- Is the solution based on (a) commercial package(s)? Which one(s)?- Are there logical modules that must be developed from scratch?- Are there logical modules that can be reused?- Does the solution need to exchange data (or services) with other applications? If yes, does it

use an existing exchange infrastructure (middleware …) or does it need a new one?- Does the solution need reporting (and should use a reporting logical module)?- Does it need logging (and should use a logging component)?- Does it need security, traceability or audit trail (and should use …)?- Internationalization?- Purge and archiving?- To alarm someone or something?- To set parameters?- An on-line help?- To send e-mails?- To manage workflows?- To manage user-defined classifications, lists, decision tables, properties?- Does a logical component need to use another underlying one?

4.2 Application dependencies

Identify and describe the usage dependencies between the logical modules of the solution and with other logical modules, applications, or systems. It can be structural links or communication links.

Usage dependencies between in-scope logical modules:Using module Used module Reasons for use<module1> <module2> <reasons why module1 uses module2>

You may illustrate these dependencies and using an UML package diagram.

<Receiver> Application Block

<Sender> Application Block

<Sender> Application Component <Sender’s> Issuer Application Component

Exchange Application Block

Mediator Application Component

< Receiver‘s> Collector Application Component<Receiver> Application Component

To be developed

To be developed

To be developed

Arrows represent usage dependencies,NOT FLOWS

<Receiver> Application Block

<Sender> Application Block

<Sender> Application Component <Sender’s> Issuer Application Component

Exchange Application Block

Mediator Application Component

< Receiver‘s> Collector Application Component<Receiver> Application Component

To be developed

To be developed

To be developed

Arrows represent usage dependencies,NOT FLOWS

Figure 9. Dependencies between logical modules

4.3 Applications services

Identify and describe the required and offered services of the logical modules of the solution.

Application services:Owning module Name Description Required/Offered<logical module> <service name> <service description>

Page 13


4.4 Applications flows and interactions

Identify and describe the sent and received application flows between the logical modules of the solution and with other logical modules of the IT systems. Identify and describe the interactions between the in-scope logical modules and services and with other logical modules and services. You may formalize application flows and interactions using UML interaction diagrams: communication or collaboration diagrams, or sequence diagrams.

<Sender> ApplicationComponent

<Sender’s> Issuer

ApplicationComponent

Mediator ApplicationComponent

< Receiver‘s> Collector


<Receiver> ApplicationComponent

mts:=MessageToSend.create

mts.setValue

mts. valued

mts. pick MessageToTransmit.create

cm:=CollectedMessage.create

cm.getValue

cm.accept

cm.delivered

timeToPickMessages

timeToIssueMessages

<Sender> ApplicationComponent

<Sender’s> Issuer


Mediator ApplicationComponent

< Receiver‘s> Collector


<Receiver> ApplicationComponent

mts:=MessageToSend.create

mts.setValue

mts. valued

mts. pick MessageToTransmit.create

cm:=CollectedMessage.create

cm.getValue

cm.accept

cm.delivered

timeToPickMessages

timeToIssueMessages

Figure 10. An interaction between logical modules illustrated by a sequence diagram

4.5 Descriptions of the logical modules

Provide here an outline description of the logical modules of the solution. You may put off in Appendix their complete use cases, structure (entities and relations) and behavior (object lifecycle) description. If a logical module is already realized or is a commercial package to buy, provide here an outline description of its functional architecture.

4.6 Application impacts

Describe the impacts of the solution on the application modules: What is new? What remains the same? What is removed? What is replaced? What is adapted?

4.7 Functional traceability

Trace the functional architecture to the application architecture. Describe how the in-scope functional blocks are implemented in the application architecture.

4.8 Referential databases & nomenclatures

Which data from other domains are needed? Which data must be shared with other domains? What are the data that could become referential data? Where could referential data be located? Which referential databases & nomenclatures are used? Are common referential databases & nomenclatures used? How or why not? Is it an opportunity to build new referential databases & nomenclatures that do not exist yet?

4.9 EA compliance

State how the solution is compliant with the EA Principles and Rules, or comment the gaps. See in the Appendix how to state this compliance.

Page 14


5 SOFTWARE ARCHITECTURE REQUIREMENTS

Purpose: to describe the requirements that have an impact on the software architecture.

5.1 Size and performance

Describe the major quantitative features and constraints of the solution (its performance constraints for instance) that impact the architecture.

5.2 Other requirements and constraints

Questions that can help you:- What are the off-the-shelf products and commercial packages used?- Is there distribution requirements?- What are the technologies used?- Has legacy code to be reused?- Which new architectural framework or new infrastructure can be used?- What about “mutualization”?- Regionalization?- What are the QoS constraints (quality of service)?- Has the solution to integrate with existing internal, B2B, B2C applications and external actors?- Is it integrated by data layer (file exchanges, same database, database replication …), service

layer, message layer, presentation layer …? Does it use a file-oriented middleware, a message-oriented middleware, an interoperability framework (RMI, CORBA, DCOM …), an EAI, a service-oriented integration (WSI …), an Enterprise Services Bus (ESB) …?

Describe all required capabilities (other than functionality) of the solution: extensibility, reliability, portability, reusability, and so on, the software architecture has to provide. If these features have special significance or implications, they must be clearly delineated.

6 TECHNICAL ARCHITECTURE

Purpose: to describe the technical components which make up the solution.

6.1 Technical composition

Identify and describe the libraries, packages, programs and other code artifacts, databases and files that support the application architecture required. Identify and describe the dependencies among these technical components, as well as between them and other ones. You may formalize the technical architecture using UML component diagrams.

IHM

réservationsOrdonnanceur

mettreAJourAgenda

IHMIHM

réservationsOrdonnanceur réservationsOrdonnanceurOrdonnanceurOrdonnanceur

mettreAJourAgenda mettreAJourAgendaAgendaAgenda

Figure 11

Page 15


6.2 Reuse

Which existing technical components, databases and files are reused in the solution? Which technical components, databases and files can be shared and reused in other applications or IT systems?

6.3 Application traceability

Trace the functional architecture to the technical architecture. Describe how the application services of the solution are implemented in the technical architecture.

7 DEPLOYMENT ARCHITECTURE

Purpose: to describe the locations and physical nodes on which the solution is deployed.

7.1 Geographical deployment

Identify and localize the sites where the solution is deployed? What are the impacts of this geographical deployment? Are there regional platforms?

7.2 Infrastructure

If relevant, identify and describe the physical nodes (computers, devices, network) on which the technical architecture of the solution is deployed and run. For the hardware, what are their site, number, and features: configuration (CPU, memory size …), availability constraints, total cost ownership …? Identify and describe interconnections (bus, LAN, point-to-point …) and dependencies between these physical nodes and with other physical nodes. Map the technical components of the Technical View onto the physical nodes. You may formalize the infrastructure, as well as the deployment of the technical architecture upon it using UML deployment diagrams.

monPC:PC

:Agenda

Serveur Admin:Host

réservations:Ordonnanceur

« database »Réunions

monPC:PC

:Agenda:Agenda

Serveur Admin:Host

réservations:Ordonnanceur:Ordonnanceur:Ordonnanceur

« database »Réunions

Figure 12

7.3 Operational constraints

If relevant, describe the operational constraints of the deployed solution for TP, batch processing, editing, hardware and software technical infrastructure, service level required (availability, response time …).

8 DEVELOPMENT STRATEGY (OPTIONAL)

Describe the constraints and scenarios for the development of the solution: What are the constraints that may apply on software design and implementation, development tools, team structure, schedule,

Page 16


legacy code, and so on? How does the project team intend to develop the software solution? Are several increments and versions planned? What are their business, functional, and application scope?

9 DATA MIGRATION STRATEGY (OPTIONAL)

Describe the constraints and scenarios for the data migration towards the solution.

10 DEPLOYMENT STRATEGY (OPTIONAL)

Describe the constraints and scenarios for the deployment of the solution and required infrastructure.

11 CONFIGURATION AND VERSION MANAGEMENT STRATEGY (OPTIONAL)

Describe the approach of the Software Configuration and Version Management of the solution.

12 SECURITY & CONFORMANCE CONSTRAINTS

Identify the security requirements the solution has to comply with.- Availability (What is the acceptable mean time between failures?)- Integrity (Impact of incomplete, inconsistent or erroneous outcome when using the product?)- Confidentiality- Auditing or proof & control- Traceability- Continuity Plan- Other security constraints

Identify the applicable laws and regulations the solution has to conform: If the application deals with personal and nominative data, for instance, there are legal constraints to conform depending on which country the components are running. In case of doubt, contact your local lawyers.

13 RISKS

Identify the various risks (business, IT risks …) with the probability that the risk occurs. Should it be managed as a requirement? See examples of IT Risks in Appendix.

Page 17


14 APPENDICES

14.1 EA Functional Architecture Compliance

Position in the Functional MapPosition the functional blocks of the solution on the Functional Map.

The Functional Architecture is described by a Functional Architecture Model. This model contains Functional Blocks that are composed of Functional Domains that are composed of Function Groups. All these Functional Architecture Elements are laid down on the Functional Map below.

Figure SEQ Figure \* ARABIC 13. Functional Map

Functional scope

In the Functional Architecture Model, Function Groups are composed of Macro-functions which are composed of Functions. Functions are used by Business Architecture’s Activities.

Identify the functional scope of the Target Solution: find in the Function Catalog (ask for it to IIA) the involved Function Groups (“In-Scope Function Groups”) containing the involved Macro-functions (“In-Scope Macro-functions”) containing the involved Functions (“In-Scope Functions”) that are used by the In-Scope Activities.

1. Highlight the In-Scope Function Groups in the Functional Map.2. Cut and paste excerpts from the Function Catalog.3. Alternatively, you may list the In-Scope Function Groups, Macro-functions, and Functions

using the tables below.

The In-Scope Functional Architecture Elements should be compliant with the Functional Model or the Functional Model should be amended regarding new specific needs addressed by the Target Solution. If the Target Solution needs new Functional Architecture Elements, identify, name, and define them using the tables below. This may be done with IIA or TF-EA teams.

List the In-Scope Macro-functions grouped by owning Functional Block, Functional Domain, and Function Group.

In-Scope Macro-functions:Owning Functional Block

Owning Functional Domain

Owning Function Group

Name New (Y/N)

Definition

<Functional block>

<Functional domain>

<Function group>

<Macro-function name>

<Macro-function definition>

List the In-Scope Functions grouped by Macro-function giving the using In-Scope Activities.

In-Scope Functions:Owning Macro-function Name New (Y/N) Definition Using Activities<Macro-function> <Function name> <Function definition> <List of activities>

Page 18


Functional communication

In the Functional Architecture Model, Macro-functions send and receive Functional Exchanges, and Functions send and receive Functional Messages

Find in the Functional Exchange Catalog (ask for it to IIA), the involved Functional Exchanges between the In-Scope Macro-functions (“In-Scope Functional Exchanges”), or propose new ones. List them grouped by sending and receiving Macro-function.

In-Scope Functional Exchanges:Sending Macro-functions

Receiving Macro-functions

Name New (Y/N)

Description

<List of macro-functions>

<List of macro-functions>

<Functional exchange name>

< Functional exchange description>

Find in the Functional Message Catalog (ask for it to IIA), the involved Functional Messages between the In-Scope Functions (“In-Scope Functional Messages”), or propose new ones. List them grouped by sending and receiving Function.

In-Scope Functional Messages:Sending Functions

Receiving Functions

Name New (Y/N)

Description

<List of functions>

<List of functions>

<Functional message name>

<Functional message description>

Note: if Functions are linked by Functional Messages, their owning Macro-functions should be linked by Functional Exchanges, and conversely, if there is a Functional Message between Functions, there should be a containing Functional Exchange between their owning Macro-functions. Check it!

List the In-Scope Functional Messages grouped by containing In-Scope Functional Exchange.

In-Scope Functional Exchange/Functional Message consistency:Containing Functional Exchange Functional Messages<Functional exchange> <List of functional messages>

Informational Model

The Functional Architecture is described by an Informational Model. This model contains Concepts which are composed of Information Themes which are composed of Information Items. An Information Theme is owned by a Macro-function. A Functional Message conveys Information Items.

Identify in the Informational Model (ask for it to IIA), the Concepts, Information Themes, and Information Items (collectively called Informational Elements) used by the Target Solution (respectively “In-Scope Concepts”, “In-Scope Information Themes”, and “In-Scope Information Items”), or propose new ones.

1. Cut and paste excerpts from the Informational Model.2. Alternatively, you may list the In-Scope Informational Elements using the tables below.

The In-Scope Informational Elements should be compliant with the Informational Model or the Informational Model should be amended regarding the new specific needs of the Target Solution. If the Target Solution needs new Informational Elements, identify, name, and define them using the tables below. This may be done with IIA or TF-EA teams.

Page 19


List the In-Scope Concepts.

In-Scope Concepts:Name New (Y/N) Definition<Concept name> < Concept definition>

List the In-Scope Information Themes grouped by owning Concept, with responsible Macro-function.

In-Scope Information Themes:Owning Concept

Name New (Y/N)

Definition Responsible Macro-function

<Concept> <Information theme name>

<Information theme definition>

<Macro-function>

List the In-Scope Information Items grouped by owning Concept and Information Theme with conveying Functional Messages.

In-Scope Information Items:Owning Concept

Owning Information Theme

Name New (Y/N)

Definition Conveying Functional Messages

<Concept> <Information theme>

<Information item name>

<Information item definition>

<List of functional messages>

14.2 EA Application Architecture Compliance

Position in the Application Map

Position the logical modules on the Application Map. What is the position of the project within the current Application Map?

The Application Architecture is described by the Application Architecture Model. This model contains Application Components which are classified by Application Groups which are classified by Application Domains, which are classified by Application Blocks. All these Application Architecture Elements are laid down on the Application Map below.

Figure 13. Application Map

Application scope

If the Target Solution is aimed at replacing a previous one (the” Current Solution”), describe the application scope of the Current Solution: identify and lay down in the Application Map the Current Solution’s Application Components.

Note: Applications should all be componentized using Application Components. It is not the case for all the current Applications. Such monolithic Applications are considered as Application Components (the “Application-considered-as-Components”).

Page 20


Describe the application scope of the Target Solution: identify and highlight in the Application Map the involved Application Groups (“In-Scope Application Groups”) that are used by the In-Scope Activities.

Describe the Application Architecture Elements the Target Solution has to communicate with (the “Contextual Application Architecture Elements”): identify them in the Application Architecture Model (ask for it to IIA), or create new ones, and list them. Precise their type: Application, Application Component, Application-considered-as-Component?

Contextual Application Architecture Element:Name New

(Y/N)Type (A/AC/ACAC) Definition

<Application architecture element name>

<Application architecture element type>

< Application architecture element definition>

Type: A=Application, AC=Application Component, ACAC=Application-considered-as-component.

Composition

Describe the Target Solution at a high level: identify and describe the Application Components that make up the Target Solution (“In-Scope Application Components”), as well as their dependencies.List all the In-Scope Application Components associated with isolated subject matters that the Target Solution needs to integrate, and state their mission.

In-Scope Application Components:Name Realized

(Y/N)Platform-Independent (Y/N)

Mission

<Application component name>

< Application component’s mission statement>

List all the dependencies between In-Scope Application Components, and explain the reasons why (or the capabilities for which) the using Application Component uses the other one.

Usage dependencies between In-Scope Application Components:Using Application Component

Used Application Component

Reasons for use

<Application component1>

<Application component2>

<Reasons why Application component1 uses Application component2>

Page 21


14.3 EA Rules Compliance

State compliance with EA Rules, or explain the reasons for not being compliant.

EA rule compliance:EA Rules Complian

t (Y/N)Reasons for non-compliance

Modularity rulesER01 Determination of the application components rule ER02 Distribution-production decoupling rule ER03 Transverse business functions use rule ER04 Common mechanisms use rule

Reference data rulesER05 Reference data construction ruleER06 Reference data synchronization ruleER07 Reference data up-to-date-ness ruleER08 History intangibility ruleER09 Reference data use rule ER10 Nomenclature use ruleER11 Group nomenclature use rule

Exchange rulesER12 Information access ruleER13 Exchange standardization rule ER14 Exchange isolation rule ER15 Accounting feeding rule

Application component configuration rulesER16 Invariant identifier ruleER17 Currency ruleER18 Multi-channel ruleER19 Multi-organization ruleER20 Multi-languages rule

14.4 Norms & Standards compliance

State how the solution is compliant with the Norms and Standards, or comment the gaps.

Page 22


14.5 IT Risks

Failure of Technical Component on which the Application will work Serious accident in premises sheltering Technical Components being of use by the Application Technical Components supporting the Application are either obsolete or not in progressive

configuration Equipment of the Application are sensitive to the brilliances (thermic, electromagnetic) Technical Components of complex use or little ergonomic Dysfunction of the telecommunications network on several days (saturation, ...) Performances unsuitable during the growth period of the future system (response time) Maintenance of the Technical Components of the Application not done (lack of skills) Risks due to the external maintenance (Technical Components failure) Recovery plan of the application (software and hardware) not foreseen Integrity:

o Corruption of the software used by the Applicationo Bad design or parameterization of the softwareo Possible existence of hidden functions introduced during design and development

stages o Use erroro Operating erroro Program Erroro Bad Configuration Management of programs and software used by the Applicationo Malicious alteration of the data by the network, the internet access, … o Viral Infection o Risks due to the external maintenance (risks of modifications of the data)

Confidentialityo Confidential information gathered in an illicit way (theft or photocopy of listings,

documents)o Disclosure of confidential information (internal or external)o Possibility of file or programs copyo Appropriation of rights of access (weak passwords)o Duplication or illicit copy of software for the Applicationo Thefts of laptops or PCs used for the Applicationo The network (internet or wireless) offers to unauthorized tiers the possibility to access

to the Applicationo Application allowing easy exchanges of information (floppy disk, messaging, fax, EDM)o Exchanges of information without proof of the origino Exchanges of information without receipto Unsafe authentication o Logs not allowing to detect a fraud

General risks having a probability to affect the Applicationo Lack of consistency of the rules emitted for physical security on the site (fire, damages

of waters, pollution, protection against electrical disruption)o Easy intrusion inside the site and in premises, weak access controls, indirect accesseso Staff is not aware in computer security, especially in the confidentiality of the

passwordso Un-mature organization, lacks of displayed directives for logical security, charter, code

of security, …If appropriate, IT Risks may be mitigated in an applicative way, in which case the mitigation should be expressed.

Page 23