1. ARCHITECTURE DOCUMENT TEMPLATE
ARCHITECTURE DOCUMENT
TEMPLATE
PROJECT NAME
Page 1

2. ARCHITECTURE DOCUMENT TEMPLATE
Versions of the document
Version N°
Date
Author
Comments / Modifications
Validation list (last version)
Date
Written by
Name
Function
Comments
PMD
Checked by
Approved by
Diffusion list (last version)
Name
To
Function
Expected
validation (Y/ N)
All PM
Last date for
validation *
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

3. ARCHITECTURE DOCUMENT TEMPLATE
PLAN
1 INTRODUCTION......................................................................................................................4
2 BUSINESS ARCHITECTURE.................................................................................................5
3 FUNCTIONAL ARCHITECTURE............................................................................................6
4 APPLICATION ARCHITECTURE.........................................................................................10
5 SOFTWARE ARCHITECTURE REQUIREMENTS...............................................................13
6 TECHNICAL ARCHITECTURE.............................................................................................13
7 DEPLOYMENT ARCHITECTURE........................................................................................14
8 DEVELOPMENT STRATEGY (OPTIONAL).........................................................................15
9 DATA MIGRATION STRATEGY (OPTIONAL)....................................................................15
10 DEPLOYMENT STRATEGY (OPTIONAL).........................................................................15
11 CONFIGURATION AND VERSION MANAGEMENT STRATEGY (OPTIONAL)..............15
12 SECURITY & CONFORMANCE CONSTRAINTS..............................................................15
13 RISKS..................................................................................................................................16
14 APPENDICES......................................................................................................................17
Page 3

4. ARCHITECTURE DOCUMENT TEMPLATE
1
1.1
INTRODUCTION
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 desynchronized 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
EA
IIA
IITD
IS
IT
1.5
Direction des Systèmes d’Information
Enterprise (IT) Architecture
International IT Architecture
International IT Department
Information System
Information Technology
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 4

5. ARCHITECTURE DOCUMENT TEMPLATE
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
<stakeholder name>
Definition
<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
<process/activity>
Name
<process/activity name>
Definition
<process/activity definition>
You may present this list in hierarchical process diagrams using process symbols.
Page 5

6. ARCHITECTURE DOCUMENT TEMPLATE
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
<event
name>
2.5
<event
definition>
Sending
Stakeholders
<stakeholder list>
Sending
Activities
<activity list>
Receiving
Stakeholders
<stakeholder list>
Receiving
Activities
<activity list>
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 6

7. ARCHITECTURE DOCUMENT TEMPLATE
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.
Target solution
Functional block1
Functional block2
Functional block1
Functional block1.1
Functional block3
Functional block1.2
Functional block3.1
Functional block1.3
Functional block3.2
Figure 3. Package diagram example
Target Solution

UC4
UC1

Actor3
Actor1
UC2

UC3
UC6
Actor2
UC5

Actor4
Figure 4. Use case diagram example
In-scope functional blocks or use cases:
Name
Description
<functional block/use case
<functional block/use case
name>
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 7

8. ARCHITECTURE DOCUMENT TEMPLATE
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.
Target solution
Message2
External
functional
block1
Functional block2
Functional block1
Message4
Message1
Functional block1
Functional block1.1
Message7
Functional block3
Functional block1.2
Message8
Message9
External
functional
block2
Message6
Message5
Functional block3.1
Message11
External
entity1
Message10
Message3
Functional block1.3
Functional block3.2
Figure 5. Communication diagram example
In-scope functional flows:
Senders
Receivers
<sender list
<receiver list
>
>
3.4
Name
<functional flow
name>
Description
<functional flow
description>
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 8

9. ARCHITECTURE DOCUMENT TEMPLATE
sends
*
Functional
exchange
receives
is used by
0..1
*
Is received by 1..*
is sent by
Macro-function
Application
component
Package
1
is owned by
owns
*
contains
Information
theme
is contained in
contains
is contained in 1
0..1
uses
*
Class
1..*
owns
is created from
1
is contained in
*
maps from
1
contains
1
Information item
is owned by
0..1
*
maps to
0..1
creates
*
Attribute
0..1
*
Data
structure
is contained in
contains
is created from
1
1
*
creates
0..1
Data item
Figure 6. Class diagram example
Domain entities:
Name
Description
<entity
<entity
name>
description>
Domain relations:
Number
<relation number>
3.7
Meaning
<couple of
phrases to
read the
relation in both
directions>
Description
<relation description>
Object lifecycles (optional)
If relevant, identify the entities with a lifecycle and formalize it using a simplified UML statechart.
new
Created
setValue
Ready
pick
Picked
Figure 7. Statechart example
Page 9

10. ARCHITECTURE DOCUMENT TEMPLATE
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
<mission
<language>
name>
statement>
The logical module is “PIMed” if it has a complete platform-independent model (the highest form of
portability and reusability).
Page 10

11. ARCHITECTURE DOCUMENT TEMPLATE
Questions that can help you to identify the logical modules of the solution:
- 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.
To be developed
<Sender> Application Block
<Sender> Application Component
<Sender’s> Issuer Application Component
To be developed
Exchange Application Block
Arrows represent usage dependencies,
NOT FLOWS
Mediator Application Component
To be developed
<Receiver> Application Block
<Receiver> Application Component
< Receiver‘s> Collector Application Component
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.
Page 11

12. ARCHITECTURE DOCUMENT TEMPLATE
Application services:
Owning module Name
<logical
<service
module>
name>
4.4
Description
<service
description>
Required/Offered
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>
Application
Component
<Sender’s>
Issuer
Application
Component
Mediator
Application
Component
< Receiver‘s>
Collector
Application
Component
<Receiver>
Application
Component
mts:=MessageToSend.create
mts.setValue
mts. valued

timeToPickMessages
mts. pick

MessageToTransmit.create
timeToIssueMessages
cm:=CollectedMessage.create
cm.delivered
cm.getValue
cm.accept
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?
Page 12

13. ARCHITECTURE DOCUMENT TEMPLATE
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.
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.
Page 13

14. ARCHITECTURE DOCUMENT TEMPLATE
Ordonnanceur
Agenda
réservations
mettreAJour
IHM
Figure 11
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.
Page 14

15. ARCHITECTURE DOCUMENT TEMPLATE
Serveur Admin:Host
« database »
Réunions
:Ordonnanceur
réservations
monPC:PC
:Agenda
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,
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
Page 15

16. ARCHITECTURE DOCUMENT TEMPLATE
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 16

17. ARCHITECTURE DOCUMENT TEMPLATE
14 APPENDICES
14.1 EA Functional Architecture Compliance
Position in the Functional Map
Position 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 (“InScope 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
Owning
Functional
Functional
Block
Domain
<Functional
<Functional
block>
domain>
Owning
Function
Group
<Function
group>
Name
<Macrofunction
name>
New
(Y/N)
Definition
<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
<Macro-function>
New
(Y/N)
Page 17
Using Activities
<Function
definition>
<Function
name>
Definition
<List of
activities>

18. ARCHITECTURE DOCUMENT TEMPLATE
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 MacroReceiving Macrofunctions
functions
<List of macro<List of macrofunctions>
functions>
Name
New
(Y/N)
<Functional
exchange name>
Description
< 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
Receiving
Functions
Functions
<List of
<List of
functions>
functions>
Name
New
(Y/N)
<Functional message
name>
Description
<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.
Page 18

19. ARCHITECTURE DOCUMENT TEMPLATE
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.
List the In-Scope Concepts.
In-Scope Concepts:
Name
New
(Y/N)
<Concept
name>
Definition
< Concept
definition>
List the In-Scope Information Themes grouped by owning Concept, with responsible Macro-function.
In-Scope Information Themes:
Owning
Name
Concept
<Concept>
<Information theme
name>
New
(Y/N)
Definition
<Information theme
definition>
Responsible Macrofunction
<Macro-function>
List the In-Scope Information Items grouped by owning Concept and Information Theme with
conveying Functional Messages.
In-Scope Information Items:
Owning
Owning
Concept
Information
Theme
<Concept>
<Information
theme>
Name
New
(Y/N)
<Information
item name>
Definition
<Information
item definition>
Conveying
Functional
Messages
<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.
Page 19

20. ARCHITECTURE DOCUMENT TEMPLATE
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”).
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
Type (A/AC/ACAC)
(Y/N)
<Application architecture
<Application architecture
element name>
element type>
Definition
< 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
Platform-Independent Mission
(Y/N)
(Y/N)
<Application component
< Application component’s
name>
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
Used Application
Reasons for use
Component
Component
<Application
<Application
<Reasons why Application component1 uses
component1>
component2>
Application component2>
Page 20

21. ARCHITECTURE DOCUMENT TEMPLATE
14.3 EA Rules Compliance
State compliance with EA Rules, or explain the reasons for not being compliant.
EA rule compliance:
EA Rules
Compliant Reasons for non(Y/N)
compliance
Modularity rules
ER01
Determination of the application components rule
ER02
Distribution-production decoupling rule
ER03
Transverse business functions use rule
ER04
Common mechanisms use rule
Reference data rules
ER05
Reference data construction rule
ER06
Reference data synchronization rule
ER07
Reference data up-to-date-ness rule
ER08
History intangibility rule
ER09
Reference data use rule
ER10
Nomenclature use rule
ER11
Group nomenclature use rule
Exchange rules
ER12
Information access rule
ER13
Exchange standardization rule
ER14
Exchange isolation rule
ER15
Accounting feeding rule
Application component configuration rules
ER16
Invariant identifier rule
ER17
Currency rule
ER18
Multi-channel rule
ER19
Multi-organization rule
ER20
Multi-languages rule
14.4 Norms & Standards compliance
State how the solution is compliant with the Norms and Standards, or comment the gaps.
Page 21

22. ARCHITECTURE DOCUMENT TEMPLATE
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 Application
o Bad design or parameterization of the software
o Possible existence of hidden functions introduced during design and development
stages
o Use error
o Operating error
o Program Error
o Bad Configuration Management of programs and software used by the Application
o 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)
Confidentiality
o 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 copy
o Appropriation of rights of access (weak passwords)
o Duplication or illicit copy of software for the Application
o Thefts of laptops or PCs used for the Application
o The network (internet or wireless) offers to unauthorized tiers the possibility to access
to the Application
o Application allowing easy exchanges of information (floppy disk, messaging, fax, EDM)
o Exchanges of information without proof of the origin
o Exchanges of information without receipt
o Unsafe authentication
o Logs not allowing to detect a fraud
General risks having a probability to affect the Application
o 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 accesses
o Staff is not aware in computer security, especially in the confidentiality of the
passwords
o Un-mature organization, lacks of displayed directives for logical security, charter, code
of security, …
Page 22

23. ARCHITECTURE DOCUMENT TEMPLATE
If appropriate, IT Risks may be mitigated in an applicative way, in which case the mitigation should be
expressed.
Page 23