Architecture Document Template

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 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

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
1INTRODUCTION
1.1Purpose
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.2Tailoring 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.3Scope
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.4Definitions, acronyms & abbreviations
List all definitions, acronyms & abbreviations referenced in the GAD.
DSI Direction des Systèmes d’Information
EA Enterprise (IT) Architecture
IIA International IT Architecture
IITDInternational IT Department
IS Information System
IT Information Technology
1.5References
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.6Overview
Describe what the rest of the GAD contains and explain how it is organized.
Page 4

5. ARCHITECTURE DOCUMENT TEMPLATE
2BUSINESS ARCHITECTURE
Purpose: to recall the business context, scope and processes of the solution:
2.1Introduction
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.2Business 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.3Business 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 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.4Business 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
Stakeholders
Sending
Activities
Receiving
Stakeholders
Receiving
Activities
<event
name>
<event
definition>
<stakeholder list><activity list><stakeholder list><activity list>
2.5Business 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?
3FUNCTIONAL ARCHITECTURE
Purpose: to describe the high level functions or use cases of the solution.
Page 6

7. ARCHITECTURE DOCUMENT TEMPLATE
3.1Functional 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 block1 Functional block2
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.2Most 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.3Functional 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 block1
External
functional
block1
External
functional
block2
External
entity1
Functional block1
Functional block2
Functional block3
Target solution
Message1
Message2
Message3
Message5
Message4
Message6
Message10
Message7
Message8
Message9
Message11
Functional block1.3
Functional block1.2
Functional block1.1
Functional block3.2
Functional block3.1
Functional block1
External
functional
block1
External
functional
block2
External
entity1
Functional block1
Functional block2
Functional block3
Target solution
Message1
Message2
Message3
Message5
Message4
Message6
Message10
Message7
Message8
Message9
Message11
Figure 5. Communication diagram example
In-scope functional flows:
Senders Receivers Name Description
<sender list
>
<receiver list
>
<functional flow
name>
<functional flow
description>
3.4Functional 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.5Business traceability
Trace the business architecture to the functional architecture. Which functional blocks support each
in-scope business process/activity?
3.6Data 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
Information
theme
Information item
Application
component
Data
structure
Data item
Macro-function
Functional
exchange
Class
Attribute
Package
contains*
1
contains
iscontainedin
*
1
iscontainedin
creates
0..1
iscreatedfrom
creates
0..1
1
1
iscreatedfrommapsfrom
0..1
mapsto
*
owns*
isownedby0..1
uses
1..*
0..1
isusedby
contains*
1iscontainedin
sends
receives
Isreceivedby
issent by
1..*
1
*
*
contains
iscontainedin
*
1
owns*
isownedby0..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.7Object 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 9

10. ARCHITECTURE DOCUMENT TEMPLATE
3.8Reference data
Identify and list the reference data used or needed. Are there information structures that could or
should be promoted as reference data?
3.9Functional traceability
Trace the information structures to the functional architecture. Which information structures support
each in-scope functional block?
3.10EA 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.
4APPLICATION 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.1Application 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 inPIMed(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).
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.2Application 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 moduleUsed moduleReasons 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.3Applications 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 Description Required/Offered
<logical
module>
<service
name>
<service
description>
4.4Applications 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
mts. pick MessageToTransmit.create
cm:=CollectedMessage.create
cm.getValue
cm.accept
cm.delivered

timeToPickMessages

timeToIssueMessages
<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
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.5Descriptions 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.6Application 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.7Functional traceability
Trace the functional architecture to the application architecture. Describe how the in-scope functional
blocks are implemented in the application architecture.
4.8Referential 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.9EA 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.
5SOFTWARE ARCHITECTURE REQUIREMENTS
Purpose: to describe the requirements that have an impact on the software architecture.
5.1Size and performance
Describe the major quantitative features and constraints of the solution (its performance constraints
for instance) that impact the architecture.
5.2Other 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.
6TECHNICAL ARCHITECTURE
Purpose: to describe the technical components which make up the solution.
6.1Technical 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
IHM
réservationsOrdonnanceur
mettreAJourAgenda
IHMIHM
réservationsOrdonnanceur réservationsOrdonnanceurOrdonnanceurOrdonnanceur
mettreAJourAgenda mettreAJourAgendaAgendaAgenda
Figure 11
6.2Reuse
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.3Application traceability
Trace the functional architecture to the technical architecture. Describe how the application services of
the solution are implemented in the technical architecture.
7DEPLOYMENT ARCHITECTURE
Purpose: to describe the locations and physical nodes on which the solution is deployed.
7.1Geographical deployment
Identify and localize the sites where the solution is deployed? What are the impacts of this
geographical deployment? Are there regional platforms?
7.2Infrastructure
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
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.3Operational 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 …).
8DEVELOPMENT 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?
9DATA MIGRATION STRATEGY (OPTIONAL)
Describe the constraints and scenarios for the data migration towards the solution.
10DEPLOYMENT STRATEGY (OPTIONAL)
Describe the constraints and scenarios for the deployment of the solution and required infrastructure.
11CONFIGURATION AND VERSION MANAGEMENT STRATEGY (OPTIONAL)
Describe the approach of the Software Configuration and Version Management of the solution.
12SECURITY & 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.
13RISKS
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
14APPENDICES
14.1EA 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 (“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-functionName New
(Y/N)
Definition Using Activities
<Macro-function> <Function
name>
<Function
definition>
<List of
activities>
Page 17

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 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 ExchangeFunctional 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)
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.2EA 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
(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 20

21. ARCHITECTURE DOCUMENT TEMPLATE
14.3EA Rules Compliance
State compliance with EA Rules, or explain the reasons for not being compliant.
EA rule compliance:
EA Rules Compliant
(Y/N)
Reasons for non-
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.4Norms & Standards compliance
State how the solution is compliant with the Norms and Standards, or comment the gaps.
Page 21

22. ARCHITECTURE DOCUMENT TEMPLATE
14.5IT 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:
oCorruption of the software used by the Application
oBad design or parameterization of the software
oPossible existence of hidden functions introduced during design and development
stages
oUse error
oOperating error
oProgram Error
oBad Configuration Management of programs and software used by the Application
oMalicious alteration of the data by the network, the internet access, …
oViral Infection
oRisks due to the external maintenance (risks of modifications of the data)
-Confidentiality
oConfidential information gathered in an illicit way (theft or photocopy of listings,
documents)
oDisclosure of confidential information (internal or external)
oPossibility of file or programs copy
oAppropriation of rights of access (weak passwords)
oDuplication or illicit copy of software for the Application
oThefts of laptops or PCs used for the Application
oThe network (internet or wireless) offers to unauthorized tiers the possibility to access
to the Application
oApplication allowing easy exchanges of information (floppy disk, messaging, fax, EDM)
oExchanges of information without proof of the origin
oExchanges of information without receipt
oUnsafe authentication
oLogs not allowing to detect a fraud
-General risks having a probability to affect the Application
oLack of consistency of the rules emitted for physical security on the site (fire, damages
of waters, pollution, protection against electrical disruption)
oEasy intrusion inside the site and in premises, weak access controls, indirect accesses
oStaff is not aware in computer security, especially in the confidentiality of the
passwords
oUn-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