Architecture Definition

Project XXXX
Client YYYY

<<Note: This document provides a generic template. It may require tailoring to suit a specific client and project situation.>>

Table of Contents

1        Purpose of this Document 3

2        Scope. 4

3        Goals, Objectives, and Constraints. 5

4        Compliance. 8

5        Risks and Issues. 9

6        Baseline Architecture. 10

7        Rationale and Justification for Architectural Approach. 35

8        Mapping to Architecture Repository. 36

9        Target Architecture. 40

10      Gap Analysis. 67

11      Impact Assessment 70

Document Information

Project Name:	Project XXX
Prepared By:		Document Version No:	0.1
Title:	Architecture Definition	Document Version Date:
Reviewed By:		Review Date:

Distribution List

From	Date	Phone/Fax/Email

To	Action*	Due Date	Phone/Fax/Email

* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)

Document Version History

Version Number	Version Date	Revised By	Description	Filename

1                  Purpose of this Document

< This document packages the baseline, target, and gap analysis for <<insert>>.

The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, interim state(s), and target).

The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective:

• The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects.
• The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.

It is suggested that this document reference the various deliverables in the container. For instance, the Architecture Principles will be documented in an Architecture Principles document and that document referenced here. It may be that this container is implemented using a wiki or as an intranet rather than a text-based document. Even better would be to use a licensed TOGAF tool that captures this output.

This template shows “typical” contents of an Architecture Definition Document and can be adapted to align with any TOGAF adaptation being implemented.>>

2                  Scope

<<The purpose of this section is to outline the scope of the architecture for the domains as well as the scope of this document.

In terms of quality criteria, this section should make clear:

• Parts of the architecture which are in scope
• Parts of the architecture which are out of scope
• Parts of the architecture which are in scope for this document; the scope may be the entire architecture within a domain, or a subset of the architecture within a domain
• Parts of the architecture which are out of scope for this document>>

Description

Scope can have many attributes, not all of which will always be required and can be regarded as optional and circumstance-dependent. The scope statement details the architecture deliverables, helps describe the major objectives, and describes the boundaries of the architecture. As a baseline, scope statements must contain: The architecture sponsors, and stakeholdersA statement of requirementsThe architecture goals and objectives The architecture non-goals (what is out of scope)The business processes, locations, and organizations (e.g., business areas) within scopeThe constraints, limitations, and boundaries Additional scope descriptions may exist in other documents (e.g., the project brief and PID) and can potentially be referenced here. Examples include: The project nameThe project charterMilestonesCost estimates

Guidance

(Part of) the scope can be clarified with a Context Diagram. Many of the attributes of a baseline statement of scope will exist elsewhere in an architecture deliverable (e.g., architecture objectives, context, constraints, etc.) and can be referenced in preference to repetition where it is appropriate. It is not appropriate to reference in such a way if it can confuse (e.g., reference to a list of 20 constraints when only 5 of them help define the scope) and a separate View should be created. References to other documents, even documents within the same project, may not be beneficial and, as above, it is often better to repeat information to ensure that the architecture scope is clearly and completely defined in one easily consumed View.

Reference-ID	Title	Scope

3                  Goals, Objectives, and Constraints

<<The purpose of this section is to outline the architectural goals, objectives, and constraints for the architecture and this document.

In terms of quality criteria, this section should make clear:

• High-level business and technology goals that are driving this exercise and thus which this business architecture and document are meant to help achieve
• Precise objectives (derived from the goals) that are driving this exercise and thus which this business architecture and document are meant to help achieve
• Business or technology constraints that need to be taken into consideration as they may influence the decisions made when defining the business architecture
• Other constraints that need to be taken into consideration as they may impact the delivery (e.g., timescales) of this document and thus exercise>>

3.1            Business and Technology Goals

<<The purpose of this section is to outline the business and technology goals for the business architecture and this document.

In terms of quality criteria, this section should make clear:

• High-level business and technology goals that are driving this exercise and thus which this business architecture and document are meant to help achieve>>

3.2            Objectives Derived from the Goals

<<The purpose of this section is to outline the objectives for the business architecture and this document.

In terms of quality criteria, this section should make clear:

• Precise objectives (derived from the goals) that are driving this exercise and thus which this business architecture and document are meant to help achieve>>

Concern	Does the architect understand what I (sponsor) want to be able to do with the architecture?
Description	There are two classes of architecture objective. There are objectives which are aligned to the project delivery, for which the project manager and the sponsor are key owners. There are also objectives which are aligned to broader strategic and enterprise goals, for which the IMS strategy & architecture is a key owner. A View of both classes enables the understanding of strategic versus project deliverables. In the first class are: Ensure the optimum approach to achieving the project goalsReduce project costs through the adoption of appropriate products and servicesAlignment with the design authority In the second class are: Alignment with the Business Mission and StrategyAlignment with Business Partners and (other) business areasEnsure consistency across all delivery projects in the organizationReduce costs through the adoption of standards
Guidance	This View is a simple selection of the architecture objectives or strategies as appropriate. See the architecture objectives artifact template.

Reference-ID	Title	Class	Architecture Objective/Strategy description

<<May reference the business goals and drivers documentation.>>

3.3            Stakeholders and their Concerns

<<The purpose of this section is to identify the stakeholders for the business architecture and this document.

In terms of quality criteria, this section should make clear:

• The RACI (Responsible, Accountable, Consulted, Informed) stakeholders for the business architecture and this document:
  • Responsible stakeholders are those that undertake the exercise/action; i.e., do the work.
  • Accountable stakeholders are those that own the exercise/deliverable. Only one stakeholder should be accountable for an exercise/deliverable. They may own the budget (i.e., purse strings) and/or have overall management responsibility for the exercise/deliverable.
  • Consulted stakeholders are those from whom input is gathered in order to produce the deliverable. They tend to be subject matter experts in specific business areas or technologies.
  • Informed stakeholders are those to whom the deliverable is distributed as they tend to have a dependency on its content.
• Stakeholders who need to review the business architecture and this document
• Stakeholders who need to approve the business architecture and this document
• Decision-making stakeholders in terms of governance and management such as scope confirmation, issue escalation, and issue resolution (if not already defined elsewhere; for example, in a project initiation document (PID))
• Concerns of these stakeholders with regards to the business architecture or this exercise
• Issues of these stakeholders with regards to the business architecture or this exercise>>

3.4            Constraints

Concern	Do the constraints represent the agreed limitations? Are they stated clearly and in such a way that design decisions can be made appropriately?
Description	A constraint is a basic rule or statement that MUST be followed to ensure that the organizational and IT strategy/aspirations and the architectural objectives can be met. Constraints are similar to principles but they have no weighting. Constraints cannot be violated, they must all be met, so there cannot be a trade-off mechanism to evaluate conflicting constraints. If the constraints conflict, then a solution alternative or a design decision is not possible and the constraints must be revisited to identify if any can be removed.
Guidance	Constraints must be unambiguous and have certain attributes. This View is a simple selection of the architecture constraints. See the architecture constraints artifact template for a list of attributes.

Reference-ID	Title	Architecture Constraint	Priority	Consequences

3.5            Capabilities

<<The purpose of this section is to identify the capabilities <<the client>> needs to have to achieve their business goals. Capabilities include both business services and application services.

In terms of quality criteria, this section should make clear:

• The capabilities and their descriptions
• The priority of the capabilities in a list>>

4                  Compliance

4.1            Architecture Principles

<<May reference the architecture principles documentation.>>

Concern	Do the principles represent the agreed decision criteria? Are they stated clearly and in such a way that design decisions can be made appropriately?
Description	A principle is a basic rule or statement that should be followed to ensure that the organizational and IT strategy/aspirations and the architectural objectives can be met. Principles give direction to the choices and solution directions that are applicable. They make the arguments and decisions more explicit and traceable, so they are a guide in decision- making and an aid for structuring services. Principles may contradict and priorities need to be set for them.
Guidance	Principles must be unambiguous and have certain attributes. This View is a simple selection of the architecture principles. See the architecture principles artifact template for a list of attributes.

Name	<Name of Principle>
Reference	<Unique identifier for the principle.>
Statement	The Statement should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement be unambiguous.
Rationale	The Rationale should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.
Implications	The Implications should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: “How does this affect me?” It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed.

4.2            Policies and Standards

5                  Risks and Issues

5.1            Assumptions

ID	Assumption Item	Description	Date	Source	Owner

5.2            Risks

Concern	Are the risks clearly described and communicated? Do agreed mitigations exist for all stated risks?
Description	A risk is a description of an issue or problem that may arise related to the architecture development. Risks that are related to the architecture result are mandatory here; project risks are out of scope.  A risk that has arisen or been realized must be described as an issue (for the project) and/or a constraint (within the architecture as an artifact).
Guidance	This View is a simple selection of the architecture risks. The number of risks being documented within the architecture should reduce during the lifetime of an architecture project.

Reference ID	Title	Description	Impact	Measures	Mitigation Plan

5.3            Issues

ID	Issue	Status	Input Date	Due Date	Closed Date	Owner	Work Group Owner	Meeting Notes/ Comments

5.4            Dependencies

Reference-ID	Title	Description	Impact	Measures	Comment

6                  Baseline Architecture

6.1            Business Architecture Models

<<The purpose of this section is to define the current business architecture that is in scope for this exercise.

Note: This section may be refined once the business architecture team has been set up.

Note 2: The level of granularity at which the artifacts need to be defined is dependant on the level of detail that is required from the business architecture, and thus is a decision for the individual domains.

Mandatory/optional: This section is optional as the domain may only wish to produce a target business architecture. Also, a degree of flexibility exists when documenting each of the sub-sections within this section. The domain only needs to produce the relevant artifacts from those highlighted in this section as per their needs. They do not need to produce all the artifacts, views, tables, etc. presented in this section.

In terms of quality criteria, this section may make clear:

• Any other relevant business architecture documentation
• Context around any such relevant business architecture documentation; e.g., validity, ownership, purpose
• Any assumptions regarding the business architecture documentation
• Relevant views (diagrams) illustrating the business functions in scope for the current business architecture
• Description of the business function view(s)
• Definitions for the business functions (in table format) in scope for the current business architecture
• Relevant views (diagrams) illustrating the organization structure and units in scope for the current business architecture
• Description of the organization structure and units view(s)
• Definitions for the organization structure and units (in table format) in scope for the current business architecture
• Relevant views (diagrams) at the conceptual level illustrating the conceptual business services and their contracts (interactions) in scope for the current business architecture
• Description of the conceptual- level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the conceptual business services (in table format) in scope for the current business architecture
• Characteristics of the conceptual business services (in table format) in scope for the current business architecture
• Descriptions of the contracts (interactions) between the conceptual business services (in table format) in scope for the current business architecture
• If required, characteristics of the contracts (interactions) between the business services (in table format) in scope for the current business architecture
• Relevant views (diagrams) at the logical level illustrating the business processes in scope for the current business architecture
• Description of the logical level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the business processes (in table format) in scope for the current business architecture
• Any relationships between the business function categories, business functions, business service categories, and business services that are in scope for the current business architecture
• Any assumptions that have been used to define the current business architecture>>

6.1.1         Conceptual Baseline Business Architecture

6.1.1.1       Baseline Business Functions

<<Business Architecture Function View Example: This section needs to provide one or more business function views for the baseline business architecture. The diagram below provides a view of the baseline business function categories and business functions. This particular example illustrates some of the possible business function categories and business functions. However, the definition of business function categories and business functions can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Business Architecture Function View Description: This section needs to provide a description of the business function view(s) for the baseline business architecture in order to understand the key messages for the stakeholders.>>

<Business Architecture Function Definitions: This section needs to provide (in table format) definitions for the business function categories and business functions in scope for the baseline business architecture.>>

Business Function (Category) ID	Business Function Category	Business Function	Business Function Description

6.1.1.2       Baseline Business Services

<<Business Architecture Conceptual Level View Example: This section needs to provide one or more conceptual-level views for the current business architecture. The diagram below provides a view of the current business architecture at the conceptual level which consists of business services categories and business services. This particular example illustrates some of the business services within XXXX. However, the definition of business services can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Business Architecture Conceptual-Level View Description: This section needs to provide a description of the conceptual-level view(s) for the current business architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<Business Architecture Conceptual-Level Artifact Definitions: This section needs to provide (in table format) definitions for the business service categories and business services in scope for the current business architecture.>>

Business Service (Category) ID	Business Service Category	Business Service	Business Service Description

<<Business Architecture Conceptual-Level Artifact Characteristics: This section may provide (in table format) characteristics for the business services in scope for the current business architecture.>>

Business Service	Business Service Characteristic	Business Service Characteristic Value

<<Business Architecture Conceptual-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e., interactions/relationships) between the business services in scope for the current business architecture.>>

BS Contract ID	Business Service Contract	Business Service 1	Business Service 2	Business Service Contract Description

<Business Architecture Conceptual-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the contracts (i.e., interactions/relationships) between the business services in scope for the current business architecture. The domain needs to determine which characteristics they wish to capture.>>

Business Service Contract	Business Service Contract Characteristic	Business Service Contract Characteristic Value

6.1.1.3       Business Service Security Classification View

<<Business Service Security Classification View Example: This section may provide one or more views of security classification for the baseline business services.>>

<<Business Service Security Classification View Description: Business services have attributes that can describe various functional and non-functional aspects. Among these attributes is the security classification. The context within which a business service operates can be derived from the information objects, as these objects can have a CIA classification.

The definition of the business service security should be carried out before a project is initiated as part of a Business Impact Analysis.

Project architecture documents must take the security classifications of the artifacts that will be impacted by the project and ensure both that the intended solution is using appropriately secure artifacts and that it will not have a negative impact on the security of those artifacts.>>

Reference-ID*	Title*	Subject	Confidentiality Classification	Integrity Classification	Availability Classification

6.1.1.4       Organization Structure and Units

<<Business Architecture Organization View Example: This section may provide one or more views of organizational structure and units for the baseline business architecture.>>

<<Business Architecture Organization View Description: This section needs to provide a description of the organizational structure and units view(s) for the baseline business architecture in order to understand the key messages for the stakeholders.>>

<<Business Architecture Organization Definitions: This section needs to provide (in table format) definitions for the organizational structure and units in scope for the baseline business architecture.>>

Organization Unit ID	Organization Unit	Organization Unit Parent	Organization Unit Description

6.1.1.5       User Satisfaction

<<Business Architecture Services User Satisfaction: This section provides a view of current user satisfaction rates for the services. It contains detailed information about complaints and positive features of the current services.>>

Business Service	User Satisfaction (Scale 1-10)	Notes, Specific Issues

6.1.1.6       Roles

<<The purpose of this section is to describe the roles in the baseline architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Human (system) roles in the baseline architecture
• Computer (system) roles in the baseline architecture>>

6.1.2         Logical Baseline Business Architecture

6.1.2.1       Actors

<<The purpose of this section is to describe the system users/actors in scope for the target architecture. System actors/users are those users who interact with a system. They can be human or a system/computer.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Human (system) actors in scope for the baseline architecture
• Computer (system) actors in scope for baseline architecture
• Any other system actor oriented requirements in scope for the target architecture>>

6.1.2.2       Human Actors

<<The purpose of this section is to define the human actors in scope for the target architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Human actors in scope for the target architecture>>

6.1.2.3       Computer Actors

<<The purpose of this section is to define the computer actors in scope for target architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Computer actors and roles in scope for target architecture>>

Actor Business Role	Actor 1	Actor 2	Actor 3
Role 1	X
Role 2
Role 3
Role 4

6.1.2.4       Other Requirements

<<The purpose of this section is to define any other actor-oriented requirements in scope for the target architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Any other actor-oriented requirements in scope for the target architecture>>

6.1.2.5       Baseline Business Architecture (Processes)

<<Business Architecture Process View Example: This section may provide one or more logical-level views for the baseline business architecture. These views will illustrate the business processes in the baseline business architecture. Text describing the key concepts and notation used within the diagram(s) will also need to be included so that users can easily read and understand the view.>>

<<Business Architecture Process View Description: This section may provide a description of the business process view(s) in scope for the baseline business architecture in order to understand the key messages for the stakeholders.>>

<<Business Architecture Process Definitions: This section may provide (in table format) definitions for the business processes in scope for the baseline business architecture.>>

6.1.2.6       Logical Business Top-Level View

<<Logical Business Top-Level View Example: This section may provide one or more top-level logical views for the target business architecture.>>

<<Logical Business Top-Level View Description:

Concern: What are the highest-level structuring principles we have to obey?

Description: Defines and shows the highest aggregation level to be used for the business architecture, often the business domains, based on a high-level structuring of services delivered to the outside world by the business. Often one level more detailed than the context diagram.

Guidance: This view helps ensure correct sponsor communication of the architecture. It demonstrates the products and/or services that the business is delivering to the customers grouped per business domain. This is often one level more detailed than the context diagram.>>

6.1.3         Physical Target Business Architecture

6.1.3.1       Process Allocation

<<Key locations can be represented geographically, functionally, or structurally. The choice of representation depends on the key point(s) of the model. A text-based template is provided.>>

Location Physical Process	Location 1	Location 2	Location 3
Process 1	X
Process 2
Process 3
Process 4

6.1.3.2       Physical Business Component RACI View

<<View that demonstrates the accountability and responsibility of physical business components, containing business services by business areas or other external organizational units.

The presented Information can be very sensitive. This scope and circulation of this view must be agreed in advance.>>

	Business Unit Actors	Third-Party Actors	Implementation Actors
Activity	Actor 1	Actor 2	Actor 3	Actor 4	Actor 5	Actor 6	Actor 7
Activity 1	AR	C
Activity 2	AR	C			C	C	I
Activity 3	A	C			R	I
Activity 4					AR
Activity 5	R	C	A	I	C
Activity 6	C	C	I		C	AR	I

6.1.3.3       Role/Actor Allocation

<<The assignment of roles and responsibilities to staff is a very sensitive issue. For this reason this View is rarely included within an architecture document, but it is sometimes required as an additional View that will be circulated under a separate cover. Such Views will always require the involvement of the HR department and senior managers and such stakeholders are often the sponsors for the extra document that contains the View.>>

Staff Type Physical Process	Staff Type 1	Staff Type 2	Staff Type 3
Actor/Role 1	X
Actor/Role 2
Actor/Role 3
Actor/Role 4

6.1.3.4       Physical Organization Model

<<The creation of a physical organizational model is a very sensitive issue. For this reason this View is rarely included within an architecture document, but it is sometimes required as an additional View that will be circulated under a separate cover. Such Views will always require the involvement of the HR department and senior managers and such stakeholders are often the sponsors for the additional documentation.>>

6.1.4         Cross-References within the Business Architecture

<Business Architecture Cross-References Example: This section may populate the spreadsheet below which enables the definitions and relationships between business function categories, business functions, business service categories, and business services to be captured and documented.

Business Function & Service Descriptions
Business Function Category	Business Function	Business Service Group	Business Service
<Business Function Category Name>	<Business Function Description>
	<Business Function Name>	<Business Function Description>
		<Business Service Category Name>	<Business Service Category Description>
			<Business Service Name>	<Business Service Description>
			<Business Service Name>	<Business Service Description>
			<Business Service Name>	<Business Service Description>

6.2            Data Architecture Models

<<The purpose of this section is to define the baseline data architecture for the domain/sub-domain.

Mandatory/optional: This section is optional. The data domain team will only produce a detailed set of target data architecture documentation at the planning, conceptual, and logical levels. Thus, the relevant domain only needs to produce relevant artifacts from those highlighted in this section as per their needs.

In terms of quality criteria, this section may make clear:

• Relevant views (diagrams) at the planning level illustrating the information subject areas in scope for the baseline data architecture, as well as the relationships between them
• Description of the planning-level view(s) for the baseline data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the information subject areas (in table format) in scope for the baseline data architecture
• Descriptions of the relationships and cardinality (if relevant) between the information subject areas (in table format) in scope for the baseline data architecture
• Relevant views (diagrams) at the conceptual level illustrating the business objects in scope for the baseline data architecture, as well as the relationships between them; these medium-level business objects will have been derived from the high-level information subject areas
• Description of the conceptual-level view(s) for the baseline data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the business objects (in table format) in scope for the baseline data architecture
• Descriptions of the relationships and cardinality (if relevant) between the business objects (in table format) in scope for the baseline data architecture
• Relevant views (diagrams) at the logical level illustrating the logical data entities in scope for the baseline data architecture, as well as the relationships between them. These lower-level logical data entities will have been derived from the medium-level business objects
• Description of the logical-level view(s) for the baseline data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the logical data entities (in table format) in scope for the baseline data architecture
• Characteristics of the logical data entities (in table format) in scope for the baseline data architecture
• Descriptions of the relationships and cardinality (if relevant) between the logical data entities (in table format) in scope for the baseline data architecture
• Any additional viewpoints and thus views that are required for this section due to new stakeholder requirements; these views will then be followed by descriptions for the views and definitions for the view artifacts
• Any assumptions that have been used to define the baseline data architecture>>

6.2.1         Conceptual Baseline Data Architecture

<<Data Architecture Planning-Level View Example: This section may provide one or more planning-level views for the baseline data architecture. The diagram below provides a view of the baseline data architecture at the planning level which consists of information subject areas and the relationships between them. The view also shows the decomposition of information subject areas into business objects. This particular example illustrates some example information subject areas. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Data Architecture Planning-Level View Description: This section may provide a description of the planning-level view(s) for the baseline data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<Data Architecture Planning Level Artifact Definitions: This section may provide (in table format) definitions for the information subject areas in scope for the baseline data architecture.>>

Information Subject Area Id	Information Subject Area	Information Subject Area Description

<<Data Architecture Planning-Level Artifact Relationships: This section may provide (in table format) definitions and cardinality for the relationships between the information subject areas in scope for the baseline data architecture.>>

ISA Relationship ID	Information Subject Area 1	Information Subject Area 2	Information Subject Area Cardinality	Information Subject Area Relationship Description

<<Data Architecture Conceptual-Level View Example: This section may provide one or more conceptual level views for the baseline data architecture. The diagram below provides a view of the baseline data architecture at the conceptual level which consists of business objects and the relationships between them. This particular example illustrates the business objects within the marketing information subject area. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Data Architecture Conceptual-Level View Description: This section may provide a description of the conceptual -level view(s) for the baseline data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Data Architecture Conceptual-Level Artifact Definitions: This section may provide (in table format) definitions for the business objects in scope for the baseline data architecture. An optional attribute is information classification. With this attribute it is possible to classify the business objects.>>

Business Object ID	Business Object	Business Object Description

<<Data Architecture Conceptual-Level Artifact Relationships: This section may provide (in table format) definitions and cardinality for the relationships between the business objects in scope for the baseline data architecture.>>

BO Relationship ID	Business Object 1	Business Object 2	Business Object Cardinality	Business Object Relationship Description

6.2.1.1       User Satisfaction

<<Data Architecture Services User Satisfaction: This section provides a view of current user satisfaction rates for the subject areas. It contains detailed information about complaints and positive features of the current subject areas.>>

Information Subject Area	User Satisfaction (Scale 1-10)	Notes, Specific Issues

6.2.1.2       Data Service Security Classification View

<<Data Service Security Classification View Example: This section may provide one or more views of security classification for the baseline data services.>>

<<Data Service Security Classification View Description: Data services have attributes that can describe various functional and non-functional aspects. Among these attributes is the security classification. The context within which a data service operates can be derived from the information objects, as these objects can have a classification.

The definition of the data service security should be carried out before a project is initiated as part of a Data Impact Analysis.

Project architecture documents must take the security classifications of the artifacts that will be impacted by the project and ensure both that the intended solution is using appropriately secure artifacts and that it will not have a negative impact on the security of those artifacts.>>

Reference-ID Component	Title* Component	Reference ID*	Title*	Subject	Confiden­tiality Classi­fication	Integrity Classi­fication	Availability Classi-fication

6.2.2         Logical Baseline Data Architecture

<<Data Architecture Logical-Level View Example: This section may provide one or more logical-level views for the baseline data architecture. The diagram below provides an example view of the baseline data architecture at the logical level which consists of logical data entities and the relationships between them. This particular example illustrates the logical data entities derived from the customer business object. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Data Architecture Logical-Level View Description: This section may provide a description of the logical-level view(s) for the baseline data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Data Architecture Logical-Level Artifact Definitions: This section may provide (in table format) definitions for the logical data entities in scope for the baseline data architecture.>>

Logical Data Entity ID	Logical Data Entity	Logical Data Entity Description

<<Data Architecture Logical-Level Artifact Characteristics: This section may provide (in table format) characteristics for the logical data entities in scope for the baseline data architecture. The domain needs to determine which characteristics they wish to capture.>>

Logical Data Entity	Logical Data Entity Characteristic	Logical Data Entity Characteristic Value

<<Data Architecture Logical-Level Artifact Attribute Definitions: This section may provide (in table format) definitions for the attributes of the logical data entities in scope for the baseline data architecture. A separate table may be produced per logical data entity. An optional attribute is information classification. With this attribute it is possible to classify the Logical Data Entities.>>

Logical Data Entity	Logical Data Entity Attribute	Logical Data Entity Attribute Description

<<Data Architecture Logical-Level Artifact Relationships: This section may provide (in table format) definitions and cardinality for the relationships between the logical data entities in scope for the baseline data architecture.>>

LDE Relationship ID	Logical Data Entity 1	Logical Data Entity 2	Logical Data Entity Cardinality	Logical Data Entity Relationship Description

6.2.3         Physical Baseline Data Architecture

<<This section describes the interaction between data models that cross ownership boundaries.>>

<<Data Architecture Physical-Level View Example: This section may provide one or more logical-level views for the baseline data architecture. The diagram below provides an example view of the baseline data architecture at the physical level which consists of physical data entities and the relationships between them. This particular example illustrates the physical instance of logical data entities derived from the customer business object. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.

Determine the interaction between the data entities; select and visualize the interactions that cross logical ownership boundaries. Determine the impact of information ownership on these interactions.>>

<<Data Architecture Physical-Level View Description: This section may provide a description of the physical-level view(s) for the baseline data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Data Architecture Physical-Level Artifact Definitions: This section may provide (in table format) definitions for the physical data entities in scope for the baseline data architecture.>>

<<Example: Is this interaction caused by the fact that the other owns the object that has caused the interaction? Is the ownership defined correctly? If we changed ownership of one of the elements, would that lead to a better result?

Often models like that shown below are used for this View.>>

6.2.4         Baseline Data Architecture Cross-References

<<Data Architecture Cross-References: This section provides, if necessary or when available, some cross-references for the data architecture.>>

6.3            Application Architecture Models

<<The purpose of this section is to define the baseline application architecture for the domain/sub-domain.

Mandatory/optional: If this document is to be produced, this section is mandatory. However, the domain only needs to produce the relevant artifacts from those highlighted in this section as per their needs.

In terms of quality criteria, this section may make clear:

• Relevant views (diagrams) at the conceptual level illustrating the application services and their contracts (interactions) in scope for the baseline application architecture
• Description of the conceptual-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the application services (in table format) in scope for the baseline application architecture
• Characteristics of the application services (in table format) in scope for the baseline application architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both
• Descriptions of the contracts (interactions) between the application services (in table format) in scope for the baseline application architecture
• If required, characteristics of the contracts (interactions) between the application services (in table format) in scope for the baseline application architecture
• Relevant views (diagrams) at the logical level illustrating the logical application components and their contracts (interactions) in scope for the baseline application architecture; these logical application components group application services together based on common requirements/characteristics
• Description of the logical-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the logical application components (in table format) in scope for the baseline information architecture
• Characteristics of the logical application components (in table format) in scope for the baseline application architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both
• Descriptions of the contracts (interactions) between the logical application components (in table format) in scope for the baseline application architecture
• Characteristics of the contracts (interactions) between the logical application components (in table format) in scope for the baseline application architecture
• Any relationships between the business function categories, business functions, logical application components, and application services that are in scope for the baseline architecture
• Any relationships between the business services and application services that are in scope for the baseline architecture
• Any additional viewpoints and thus views that are required for this section due to new stakeholder requirements; these views will then be followed by descriptions for the views and definitions for the view artifacts
• Any assumptions that have been used to define the baseline application architecture; for example, one assumption (recommendation) that has already been stated is that the physical application architecture is out of scope for the enterprise architecture>>

6.3.1         Conceptual Baseline Application Architecture

<<Application Architecture Conceptual-Level Example: This section may provide one or more conceptual- level views for the baseline application architecture. The diagram below provides an example view of the baseline application architecture at the conceptual level which consists of application services. This particular example illustrates some of the application services, grouped by domain, within xxxx. However, the definition of application services can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Application Architecture Conceptual-Level View Description: This section may provide a description of the conceptual-level view(s) for the baseline application architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

6.3.1.1       Baseline Application Services

<<Application Architecture Conceptual-Level Artifact Definitions: This section may provide (in table format) definitions for the application services in scope for the baseline application architecture.>>

Application Service ID	Application Service	Application Service Description

<<Application Architecture Conceptual-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the application services in scope for the baseline application architecture. However, the domain will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to capture.>>

Application Service	Application Service Characteristic	Application Service Characteristic Value

6.3.1.2       Application Services Contracts

<<Application Architecture Conceptual Service Contracts: This section provides (in table format) the contracts between application services and the characteristics of those contracts for the application services in scope for the baseline application architecture. However, the domain will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to capture.>>

Contract Name	Contract ID	Definition	IS Service 1	IS Service 2

6.3.1.3       User Satisfaction

<<Application Architecture Services User Satisfaction: This section provides a view of current user satisfaction rates for the subject areas. It contains detailed information about complaints and positive features of the current subject areas.>>

Application Services	User Satisfaction (Scale 1-10)	Notes, Specific Issues

6.3.1.4       Application Service Security Classification View

<<Application Service Security Classification View Example: This section may provide one or more views of security classification for the baseline application services.>>

<< Application Service Security Classification View Description: Application services have attributes that can describe various functional and non-functional aspects. Among these attributes is the security classification.

Project architecture documents must take the security classifications of the artifacts that will be impacted by the project and ensure both that the intended solution is using appropriately secure artifacts and that it will not have a negative impact on the security of those artifacts.>>

Reference-ID* Component	Title* Component	Reference ID*	Title*	Subject	Confiden­tiality Classi­fication	Integrity Classi­fication	Availability Classi­fication

6.3.2         Logical Baseline Application Architecture

<<Application Architecture Logical-Level Example: This section may provide one or more logical-level views for the baseline application architecture. The diagram below provides a view of the baseline application architecture at the logical level which consists of logical application components (although without their associated application services). However, the definition of logical application components can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Application Architecture Logical-Level View Description: This section may provide a description of the logical-level view(s) for the baseline application architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Application Architecture Logical-Level Artifact Definitions: This section may provide (in table format) definitions for the logical application components in scope for the baseline application architecture.>>

LAC ID	Logical Application Component (LAC)	Logical Application Component (LAC) Description

<<Application Architecture Logical-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the logical application components in scope for the baseline application architecture. However, the domain will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to capture.>>

Logical Application Component (LAC)	LAC Characteristic	LAC Characteristic Value

<<Application Architecture Logical-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e., interactions/relationships) between the logical application components in scope for the baseline application architecture.>>

LAC Contract ID	LAC Contract	Logical Application Component 1	Logical Application Component 2	LAC Contract Description

<<Application Architecture Logical-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the contracts (i.e., interactions/relationships) between the logical application components in scope for the baseline application architecture. The domain needs to determine which characteristics they wish to capture.>>

LAC Contract	LAC Contract Characteristic	LAC Contract Characteristic Value

6.3.3         Physical Baseline Application Architecture

<<Application Architecture Physical Applications Catalogue: This section provides a catalog of the currently used applications.>>

PAC ID	Physical Application Component (PAC)	Physical Application Component (PAC) Description	Implementation Features	Technical Fitness Score (1-10)	Business Fitness Score (1-10)	Business Importance (1-10)

6.3.4         Baseline Application Architecture Cross-References

<<Application Architecture Cross-References: This section provides, if necessary or when available, some cross-references for the application architecture. Like application service and infrastructure service cross-references or business service and application service cross-references. See the target template for descriptions of those.>>

6.4            Technology Architecture Models

<<The purpose of this section is to provide a high-level view of the baseline technology architecture for the domain.

Mandatory/optional: This section is optional. If produced, the domain only needs to produce the relevant artifacts from those highlighted in this section as per their needs.

In terms of quality criteria, this section may make clear:

• Relevant views (diagrams) at the conceptual level illustrating the infrastructure services and their contracts (interactions) in scope for the baseline technology architecture
• Description of the conceptual-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the infrastructure services (in table format) in scope for the baseline technology architecture
• Characteristics of the infrastructure services (in table format) in scope for the baseline technology architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both
• Descriptions of the contracts (interactions) between the infrastructure services (in table format) in scope for the baseline technology architecture
• If required, characteristics of the contracts (interactions) between the infrastructure services (in table format) in scope for the baseline technology architecture
• Relevant views (diagrams) at the logical level illustrating the logical infrastructure components and their contracts (interactions) in scope for the baseline technology architecture; these logical infrastructure components group infrastructure services together based on common requirements/characteristics
• Description of the logical-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the logical infrastructure components (in table format) in scope for the baseline technology architecture
• Characteristics of the logical infrastructure components (in table format) in scope for the baseline technology architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both
• Descriptions of the contracts (interactions) between the logical infrastructure components (in table format) in scope for the baseline technology architecture
• Characteristics of the contracts (interactions) between the logical infrastructure components (in table format) in scope for the baseline technology architecture
• Any relationships between the business function categories, business functions, logical infrastructure components, and infrastructure services that are in scope for the baseline architecture
• Any relationships between the business services and infrastructure services that are in scope for the baseline architecture
• Any additional viewpoints and thus views that are required for this section due to new stakeholder requirements; these views will then be followed by descriptions for the views and definitions for the view artifacts
• Any assumptions that have been used to define the baseline technology architecture; for example, one assumption (recommendation) that has already been stated is that the physical technology architecture is out of scope for the enterprise architecture>>

6.4.1         Conceptual Baseline Technology Architecture

<<Technology Architecture Conceptual-Level Example: This section may provide one or more conceptual-level views for the baseline technology architecture. The diagram below provides a view of the baseline technology architecture at the conceptual level which consists of infrastructure services. This particular example illustrates some of the infrastructure services within xxxxx. However, the definition of infrastructure services can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Technology Architecture Conceptual-Level View Description: This section may provide a description of the conceptual-level view(s) for the baseline technology architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

6.4.1.1       Technology Services

<<Technology Architecture Conceptual-Level Artifact Definitions: This section may provide (in table format) definitions for the infrastructure services in scope for the baseline technology architecture.>>

Infrastructure Service ID	Infrastructure Service	Infrastructure Service Description

<<Technology Architecture Conceptual-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the infrastructure services in scope for the baseline technology architecture. However, the domain will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to capture.>>

Infrastructure Service	Infrastructure Service Characteristic	Infrastructure Service Characteristic Value

6.4.1.2       Technology Services Contracts

<<Technology Architecture Conceptual Service Contracts: This section provides (in table format) the contracts between infrastructure services and the characteristics of those contracts for the infrastructure services in scope for the baseline technology architecture. However, the domain will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to capture.>>

Contract Name	Contract ID	Definition	IS Service 1	IS Service 2

6.4.1.3       User Satisfaction

<<Technology Architecture Services User Satisfaction: This section provides a view of current user satisfaction rates for the subject areas. It contains detailed information about complaints and positive features of the current subject areas.>>

Technology Services	User Satisfaction (Scale 1-10)	Notes, Specific Issues

6.4.2         Logical Baseline Technology Architecture

<<Technology Architecture Logical-Level Example: This section may provide one or more logical-level views for the baseline technology architecture. The diagram below provides a view of the baseline technology architecture at the logical level which consists of logical infrastructure components with their associated infrastructure services. This particular example illustrates some of the logical infrastructure components and associated infrastructure services within xxxx. However, the definition of logical infrastructure components can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Technology Architecture Logical-Level View Description: This section may provide a description of the logical-level view(s) for the baseline technology architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Technology Architecture Logical-Level Artifact Definitions: This section may provide (in table format) definitions for the logical infrastructure components in scope for the baseline technology architecture.>>

LIC ID	Logical Infrastructure Component (LIC)	Logical Infrastructure Component (LIC) Description

<<Technology Architecture Logical-Level Artifact Characteristics: This section may provide (in table format) characteristics for the logical infrastructure components in scope for the baseline technology architecture.>>

Logical Infrastructure Component (LIC)	LIC Characteristic	LIC Characteristic Value

<<Technology Architecture Logical-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e., interactions/relationships) between the logical infrastructure components in scope for the baseline technology architecture.>>

LIC Contract ID	Logical Infrastructure Component 1	Logical Infrastructure Component 2	LIC Contract Description

<<Technology Architecture Logical-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the contracts (i.e., interactions/relationships) between the logical infrastructure components in scope for the baseline technology architecture.>>

Logical Infrastructure Component (LIC)	LIC Contract	LIC Contract Characteristic	LIC Contract Characteristic Value

6.4.3         Physical Baseline Technology Architecture

<<Technology Architecture Physical Infrastructure Component Catalog: This section provides a catalogue of the currently used applications.>>

PIC ID	Physical Infrastructure Component (PIC)	Physical Infrastructure Component (PIC) Description	Implementation Features	Technical Fitness Score (1-10)	Business Fitness Score (1-10)	Business Importance (1-10)

6.4.4         Baseline Technology Architecture Cross-References

<<Technology Architecture Cross-References: This section provides, if necessary or when available, some cross-references for the technology architecture. See the target template for descriptions of those.>>

6.5            Security Architecture Models

Service Name	Description	Type	Baseline Specification: Policy Reference

7                  Rationale and Justification for Architectural Approach

7.1            Rationale

7.2            Approach

7.3            Architecture Decisions

ID	Decision Item	Decision Made	Completion Date	Source	Owner/Major Contributors

7.4            Architecture Governance

8                  Mapping to Architecture Repository

<<The purpose of this section is to highlight (not describe in detail) patterns, standards, products, technologies that are relevant for or from the business architecture.

Mandatory/optional: This section is mandatory. Also, each of the sub-sections (for this section) may either provide references to the relevant documentation that has been produced separately by the domains, or provide the necessary information.

In terms of quality criteria, this section should make clear:

• Any domain-specific, other domain-specific, or enterprise architecture-level patterns that have been used to help define the business architecture
• Any domain-specific, other domain-specific, or enterprise architecture-level patterns that can be derived from the business architecture
• Any deviance from existing patterns and the reasons why
• Any domain-specific, other domain-specific, or enterprise architecture-level standards that have been used to help define the business architecture
• Any domain-specific, other domain-specific, or enterprise architecture-level standards that can be derived from the business architecture
• Any deviance from existing standards and the reasons why
• Any assumptions regarding the use of patterns or standards

8.1            Artifacts

<<The purpose of this section is to describe the artifacts that are relevant for or from the business architecture.

Mandatory/optional: This section is optional as there may not be any used artifacts. However, if they are relevant, this section may either provide references to the relevant documentation that has been produced separately by the domains, or provide the necessary information.

If the relevant artifact(s) are described in other documentation, in terms of quality criteria, this section should make clear:

• The relevant business architecture artifact documentation
• Context around any such relevant business architecture artifact documentation; e.g., validity, ownership, purpose
• Any deviance from existing business artifacts and the reasons why
• Any assumptions regarding business architecture artifacts, or their documentation

If the relevant business pattern(s) are not described in other documentation, in terms of quality criteria, this section should make clear:

• Any domain-specific, other domain-specific, or xxxx enterprise architecture-level artifacts that have been used to help define the business architecture
• Any domain-specific, other domain-specific, or xxxx enterprise architecture-level artifacts that can be derived from the business architecture
• Any deviance from existing business artifacts and the reasons why
• Any assumptions regarding business architecture artifacts, or their documentation>>

8.2            Mapping to Architecture Landscape

<<The purpose of this section is to highlight any business patterns that are relevant for or from the business architecture.

Mandatory/optional: This section is optional as there may not be any relevant business patterns. However, if they are relevant, this section may either provide references to the relevant documentation that has been produced separately by the domains, or provide the necessary information.

If the relevant business pattern(s) are described in other documentation, in terms of quality criteria, this section should make clear:

• The relevant business architecture pattern documentation
• Context around any such relevant business architecture pattern documentation; e.g., validity, ownership, purpose
• Any deviance from existing business patterns and the reasons why
• Any assumptions regarding business architecture patterns, or their documentation

If the relevant business pattern(s) are not described in other documentation, in terms of quality criteria, this section should make clear:

• Any domain-specific, other domain-specific, or xxxx enterprise architecture-level patterns that have been used to help define the business architecture
• Any domain-specific, other domain-specific, or xxxx enterprise architecture-level patterns that can be derived from the business architecture
• Any deviance from existing business patterns and the reasons why
• Any assumptions regarding business architecture patterns, or their documentation>>

8.3            Mapping to Reference Models

<<The purpose of this section is to highlight any products and technologies that are relevant to the baseline architecture.

Mandatory/optional: This section is optional as there may not be any relevant products and technologies. However, if they are relevant, this section may either provide references to the relevant documentation that has been produced separately by the domains, or provide the necessary information.

If the relevant product(s) and technology(s) are described in other documentation, in terms of quality criteria, this section should make clear:

• The relevant products and technologies documentation
• Context around any such relevant products and technologies documentation; e.g., validity, ownership, purpose
• Any deviance from existing products and technologies and the reasons why
• Any assumptions regarding the products and technologies, or their documentation

If the relevant product(s) and technology(s) are not described in other documentation, in terms of quality criteria, this section should make clear:

• Any domain-specific, other domain-specific, or xxxx enterprise architecture-level products and technologies that have been used to help define the current architecture
• Any deviance from existing products and technologies and the reasons why
• Any assumptions regarding the products and technologies, or their documentation>>

8.4            Mapping to Standards

<<The purpose of this section is to highlight any business standards that are relevant for or from the business architecture.

Mandatory/optional: This section is optional as there may not be any relevant business standards. However, if they are relevant, this section may either provide references to the relevant documentation that has been produced separately by the domains, or provide the necessary information.

If the relevant business standards(s) are described in other documentation, in terms of quality criteria, this section should make clear:

• The relevant business architecture standards documentation
• Context around any such relevant business architecture standards documentation; e.g., validity, ownership, purpose
• Any deviance from existing business standards and the reasons why
• Any assumptions regarding the business architecture standards, or their documentation

If the relevant business standards(s) are not described in other documentation, in terms of quality criteria, this section should make clear:

• Any domain-specific, other domain-specific, or xxxx enterprise architecture-level standards that have been used to help define the business architecture
• Any domain-specific, other domain-specific, or xxxx enterprise architecture-level standards that can be derived from the business architecture
• Any deviance from existing business standards and the reasons why
• Any assumptions regarding the business architecture standards, or their documentation>>

8.5            Re-Use Assessment

<<The purpose of this section is to highlight any re-usable aspects of the business architecture.

Mandatory/optional: This section is optional as there may not be any re-usable aspects of the business architecture.

If there are re-usable aspects, in terms of quality criteria, this section should make clear:

• Drivers for re-use in different business areas
• Any re-usable artifacts that have been used to help define the business architecture
• Any re-usable artifacts that can be derived from the business architecture
• Extensions to existing artifacts in order to make them re-usable
• Any non-usage of re-usable artifacts and the reasons why
• Deployment options for re-use which an indication of priorities
• Any assumptions regarding re-usability>>

8.5.1         Use of Existing Components

<<Brief summary of how the solution architecture proposes to re-use existing components (if any). Include re-use of licences, infrastructure, support services (e.g., DR) as well as software components.>>

8.5.2         Opportunities for Re-Use

<<Summarize those components that have been designed for re-use.>>

9                  Target Architecture

9.1            Business Architecture Models

<<The purpose of this section is to define the target business architecture that is in scope for this exercise.

Note: This section may be refined once the business architecture team has been set up.

Note 2: The level of granularity at which the artifacts need to be defined is dependent on the level of detail that is required from the business architecture, and thus is a decision for the individual domains.

Mandatory/optional: This section is optional as the domain may only wish to produce a current business architecture. Also, a degree of flexibility exists when documenting each of the sub-sections within this section. The domain only needs to produce the relevant artifacts from those highlighted in this section as per their needs. They do not need to produce all the artifacts, views, tables, etc. presented in this section.

In terms of quality criteria, this section may make clear:

• Any other relevant business architecture documentation
• Context around any such relevant business architecture documentation; e.g., validity, ownership, purpose
• Any assumptions regarding the business architecture documentation
• Relevant views (diagrams) illustrating the business functions in scope for the target business architecture
• Description of the business function view(s)
• Definitions for the business functions (in table format) in scope for the target business architecture
• Relevant views (diagrams) illustrating the organization structure and units in scope for the target business architecture
• Description of the organization structure and units view(s)
• Definitions for the organization structure and units (in table format) in scope for the target business architecture
• Relevant views (diagrams) at the conceptual level illustrating the conceptual business services and their contracts (interactions) in scope for the target business architecture
• Description of the conceptual- level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the conceptual business services (in table format) in scope for the target business architecture
• Characteristics of the conceptual business services (in table format) in scope for the target business architecture
• Descriptions of the contracts (interactions) between the conceptual business services (in table format) in scope for the target business architecture
• If required, characteristics of the contracts (interactions) between the business services (in table format) in scope for the target business architecture
• Relevant views (diagrams) at the logical level illustrating the business processes in scope for the target business architecture
• Description of the logica- level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the business processes (in table format) in scope for the target business architecture
• Any relationships between the business function categories, business functions, business service categories, and business services that are in scope for the target business architecture
• Any assumptions that have been used to define the target business architecture>>

9.1.1         Conceptual Target Business Architecture

9.1.1.1       Target Business Functions

<<Business Architecture Function View Example: This section needs to provide one or more business function views for the target business architecture. The diagram below provides a view of the target business function categories and business functions. This particular example illustrates some of the business function categories and business functions within xxxx. However, the definition of business function categories and business functions can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Business Architecture Function View Description: This section needs to provide a description of the business function view(s) for the target business architecture in order to understand the key messages for the stakeholders.>>

<<Business Architecture Function Definitions: This section needs to provide (in table format) definitions for the business function categories and business functions in scope for the target business architecture.>>

Business Function (Category) ID	Business Function Category	Business Function	Business Function Description

9.1.1.2       Target Business Services

<<Business Architecture Conceptual-Level View Example: This section needs to provide one or more conceptual-level views for the target business architecture. The diagram below provides a view of the target business architecture at the conceptual level which consists of business service categories and business services. This particular example illustrates some of the business services within XXXX. However, the definition of business services can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Business Architecture Conceptual-Level View Description: This section needs to provide a description of the conceptual-level view(s) for the target business architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Business Architecture Conceptual-Level Artifact Definitions: This section needs to provide (in table format) definitions for the business service categories and business services in scope for the target business architecture.>>

<<Governance Services: The services must cover the complete scope of the architecture, including governance and service management. Additional services can be identified by considering how the main services, when implemented, will be instantiated, started up, shut down, configured, monitored, and how faults will be diagnosed, users maintained, new business configuration items added (e.g., products) and so on. For more technical services, management functions such as provisioning, key management, identity management, backup, recovery, and business continuity should be considered.>>

Business Service (Category) ID	Business Service Category	Business Service	Business Service Description

<<Business Services Capability Mapping: This table provides a mapping between the capabilities and the business services.>>

Capability ID	Capability	Business Service

<<Business Architecture Conceptual-Level Artifact Characteristics: This section may provide (in table format) characteristics for the business services in scope for the target business architecture.>>

Business Service	Business Service Characteristic	Business Service Characteristic Value

<<Business Architecture Conceptual-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e., interactions/relationships) between the business services in scope for the target business architecture.>>

BS Contract ID	Business Service Contract	Business Service 1	Business Service 2	Business Service Contract Description

<<Business Architecture Conceptual-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the contracts (i.e., interactions/relationships) between the business services in scope for the target business architecture. The domain needs to determine which characteristics they wish to capture.>>

Business Service Contract	Business Service Contract Characteristic	Business Service Contract Characteristic Value

9.1.1.3       Business Service Security Classification View

<<Business Service Security Classification View Example: This section may provide one or more views of security classification for the target business services.>>

<<Business Service Security Classification View Description: Business services have attributes that can describe various functional and non-functional aspects. Among these attributes is the security classification. The context within which a business service operates can be derived from the information objects, as these objects can have a CIA classification.

The definition of the business service security should be carried out before a project is initiated as part of a Business Impact Analysis.

Project architecture documents must take the security classifications of the artifacts that will be impacted by the project and ensure both that the intended solution is using appropriately secure artifacts and that it will not have a negative impact on the security of those artifacts.>>

Reference-ID*	Title*	Subject	Confidentiality Classification	Integrity Classification	Availability Classification

9.1.1.4       Organization Structure and Units

<<Target Architecture Organization View Example: This section may provide one or more views of organizational structure and units for the target business architecture.>>

<<Target Architecture Organization View Description: This section needs to provide a description of the organizational structure and units view(s) for the target business architecture in order to understand the key messages for the stakeholders.>>

<<Target Architecture Organization Definitions: This section needs to provide (in table format) definitions for the organizational structure and units in scope for the target business architecture.>>

Organization Unit ID	Organization Unit	Organization Unit Parent	Organization Unit Description

Org. Comp Business Service	Org. Comp 1	Org. Comp 2	Org. Comp 3
BS 1	X
BS 2
BS 3
BS 4

9.1.1.5       Roles

<<The purpose of this section is to describe the roles in the baseline architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Human (system) roles in the baseline architecture
• Computer (system) roles in the baseline architecture>>

9.1.2         Logical Target Business Architecture

9.1.2.1       Actors

<<The purpose of this section is to describe the system users/actors in scope for the target architecture. System actors/users are those users who interact with a system. They can be human or a system/computer.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Human (system) actors in scope for the baseline architecture
• Computer (system) actors in scope for baseline architecture
• Any other system actor oriented requirements in scope for the target architecture>>

9.1.2.2       Human Actors

<<The purpose of this section is to define the human actors in scope for the target architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Human actors in scope for the target architecture>>

9.1.2.3       Computer Actors

<<The purpose of this section is to define the computer actors in scope for target architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Computer actors and roles in scope for target architecture>>

Actor Business Role	Actor 1	Actor 2	Actor 3
Role 1	X
Role 2
Role 3
Role 4

9.1.2.4       Other Requirements

<<The purpose of this section is to define any other actor-oriented requirements in scope for the target architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Any other actor-oriented requirements in scope for the target architecture>>

9.1.2.5       Logical Business Top-Level View

<<Logical Business Top-Level View Example: This section may provide one or more top-level logical views for the target business architecture.

<<Logical Business Top-Level View Description:

Concern: What are the highest-level structuring principles we have to obey?

Description: Defines and shows the highest aggregation level to be used for the business architecture, often the business domains, based on a high-level structuring of services delivered to the outside world by the business. Often one level more detailed than the context diagram.

Guidance: This view helps ensure correct sponsor communication of the architecture. It demonstrates the products and / or services that the business is delivering to the customers grouped per business domain. This is often one level more detailed than the context diagram.>>

9.1.2.6       Target Business Architecture (Processes)

<<The purpose of this section is to outline the environment and process models that are in scope for the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

• Business processes that are in scope for the vision
• Business and technology environment in scope for the vision
• Users who interact with the business process
• Information flows for the business processes>>

9.1.2.7       Process Outline

<<The purpose of this section is to outline the business processes that are in scope and thus impacted by the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

• Business processes that are in scope for the vision
• If required, high-level diagram(s) of business processes
• Descriptions for the business process diagrams>>

9.1.2.8       Process Steps Mapped to Environment

<<The purpose of this section is to cross-reference the business processes, in scope, to the business and technology environments.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

• Business environment in scope for the vision
• Technology environment in scope for the vision>>

Process Comp Environment	Process Comp 1	Process Comp 2	Process Comp 3
Environment 1	X		X
Environment 2		X
Environment 3		X
Environment 4			X

9.1.2.9       Process Steps Mapped to People

<<The purpose of this section is to cross-reference the business processes to business actors; i.e., business users. Business actors/users are those users who interact with a business process.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

• Business users involved with the business processes in scope>>

Process Comp Business Users	Process Comp 1	Process Comp 2	Process Comp 3
User 1	X		X
User 2		X
User 3		X
User 4			X

9.1.2.10     Information Flows

<<The purpose of this section is to describe the information flows that correspond to the business processes in scope for the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

• Information flows for the business processes in scope>>

9.1.2.11     Business Architecture Process View

<<Business Architecture Process View Example: This section may provide one or more logical-level views for the target business architecture. These views will illustrate the business processes in the target business architecture. Text describing the key concepts and notation used within the diagram(s) will also need to be included so that users can easily read and understand the view.>>

<<Business Architecture Process View Description: This section may provide a description of the business process view(s) in scope for the target business architecture in order to understand the key messages for the stakeholders.>>

<<Business Architecture Process Definitions: This section may provide (in table format) definitions for the business processes in scope for the target business architecture.>>

9.1.3         Physical Target Business Architecture

9.1.3.1       Process Allocation

<<Key locations can be represented geographically, functionally, or structurally. The choice of representation depends on the key point(s) of the model. A text-based template is provided.>>

Location Physical process	Location 1	Location 2	Location 3
Process 1	X
Process 2
Process 3
Process 4

9.1.3.2       Physical Business Component RACI View

<<View that demonstrates the accountability and responsibility of physical business components, containing business services by business areas or other external organizational units.

The presented information can be very sensitive. This scope and circulation of this view must be agreed in advance.>>

	Business Unit Actors	Third-Party Actors	Implementation Actors
Activity	Actor 1	Actor 2	Actor 3	Actor 4	Actor 5	Actor 6	Actor 7
Activity 1	AR	C
Activity 2	AR	C			C	C	I
Activity 3	A	C			R	I
Activity 4					AR
Activity 5	R	C	A	I	C
Activity 6	C	C	I		C	AR	I

9.1.3.3       Role/Actor Allocation

<<The assignment of roles and responsibilities to staff is a very sensitive issue. For this reason this View is rarely included within an architecture document, but it is sometimes required as an additional View that will be circulated under a separate cover. Such Views will always require the involvement of the HR department and senior managers and such stakeholders are often the sponsors for the extra document that contains the View.>>

Staff Type Physical Process	Staff Type 1	Staff Type 2	Staff Type 3
Actor/Role 1	X
Actor/Role 2
Actor/Role 3
Actor/Role 4

9.1.3.4       Physical Organization Model

<<The creation of a physical organizational model is a very sensitive issue. For this reason this View is rarely included within an architecture document, but it is sometimes required as an additional View that will be circulated under a separate cover. Such Views will always require the involvement of the HR department and senior managers and such stakeholders are often the sponsors for the additional documentation.>>

9.1.4         Cross-References within the Business Architecture

<<Business Architecture Cross-References Example: This section may populate the spreadsheet below which enables the definitions and relationships between business function categories, business functions, business service categories, and business services to be captured and documented.>>

Business Function & Service Descriptions
Business Function Category	Business Function	Business Service Group	Business Service
<Business Function Category Name>	<Business Function Description>
	<Business Function Name>	<Business Function Description>
		<Business Service Category Name>	<Business Service Category Description>
			<Business Service Name>	<Business Service Description>
			<Business Service Name>	<Business Service Description>
			<Business Service Name>	<Business Service Description>

Process Comp Business Service	Process Comp 1	Process Comp 2	Process Comp 3
BS 1	X		X
BS 2		X
BS 3		X
BS 4			X

9.2            Data Architecture Models

<<The purpose of this section is to define the target data architecture for the domain/sub-domain.

Mandatory/optional: This section is mandatory as all the domain teams need to produce a target data architecture for their respective domains. However, a degree of flexibility exists when documenting the target data architecture. The data domain team will produce a detailed set of data architecture documentation at the planning, conceptual, and logical levels, whereas the other domain teams will produce views and define information artifacts at one or more of the stated three levels depending on their requirements. The other domain teams may decide to just copy views and definitions and relationships from the master data architecture documentation.

In terms of quality criteria, this section should make clear:

• Relevant views (diagrams) at the planning level illustrating the information subject areas in scope for the target data architecture, as well as the relationships between them
• Description of the planning-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the information subject areas (in table format) in scope for the target data architecture
• Descriptions of the relationships and cardinality (if relevant) between the information subject areas (in table format) in scope for the target data architecture
• Relevant views (diagrams) at the conceptual level illustrating the business objects in scope for the target data architecture, as well as the relationships between them; these medium-level business objects will have been derived from the high-level information subject areas
• Description of the conceptual-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the business objects (in table format) in scope for the target data architecture
• Descriptions of the relationships and cardinality (if relevant) between the business objects (in table format) in scope for the target data architecture
• Relevant views (diagrams) at the logical level illustrating the logical data entities in scope for the target data architecture, as well as the relationships between them; these lower-level logical data entities will have been derived from the medium-level business objects
• Description of the logical-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the logical data entities (in table format) in scope for the target data architecture
• Characteristics of the logical data entities (in table format) in scope for the target data architecture
• Descriptions of the relationships and cardinality (if relevant) between the logical data entities (in table format) in scope for the target data architecture
• Any additional viewpoints and thus views that are required for this section due to new stakeholder requirements; these views will then be followed by descriptions for the views and definitions for the view artifacts
• Any assumptions that have been used to define the target data architecture; for example, one assumption (recommendation) that has already been stated is that the physical data architecture is out of scope for the enterprise architecture>>

9.2.1         Conceptual Target Data Architecture

<<Data Architecture Planning Level View Example: This section needs to provide one or more planning–level views for the target data architecture. The diagram below provides a view of the target data architecture at the planning level which consists of information subject areas and the relationships between them. The view also shows the decomposition of information subject areas into business objects. This particular example illustrates some of the information subject areas that exist. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Data Architecture Planning-Level View Description: This section needs to provide a description of the planning-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Data Architecture Planning-Level Artifact Definitions: This section needs to provide (in table format) definitions for the information subject areas in scope for the target data architecture.>>

<<Governance Subject Areas: The subject areas must cover the complete scope of the architecture, including governance and service management. Additional areas can be identified by considering how the main areas, when implemented, will be instantiated, started up, shut down, configured, monitored, and how faults will be diagnosed, users maintained, new business configuration items added (e.g., products), and so on.>>

Information Subject Area ID	Information Subject Area	Information Subject Area Description

<<Data Architecture Planning-Level Artifact Relationships: This section needs to provide (in table format) definitions and cardinality for the relationships between the information subject areas in scope for the target data architecture.>>

ISA Relationship ID	Information Subject Area 1	Information Subject Area 2	Information Subject Area Cardinality	Information Subject Area Relationship Description

<<Data Architecture Conceptual-Level View Example: This section needs to provide one or more conceptual-level views for the target data architecture. The diagram below provides a view of the target data architecture at the conceptual level which consists of business objects and the relationships between them. This particular example illustrates the business objects within the marketing information subject area. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Data Architecture Conceptual-Level View Description: This section needs to provide a description of the conceptual-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Data Architecture Conceptual-Level Artifact Definitions: This section needs to provide (in table format) definitions for the business objects in scope for the target data architecture. An optional attribute is information classification. With this attribute it is possible to classify the business objects.>>

Business Object ID	Business Object	Business Object Description

<<Data Architecture Conceptual-Level Artifact Relationships: This section needs to provide (in table format) definitions and cardinality for the relationships between the business objects in scope for the target data architecture.>>

BO Relationship ID	Business Object 1	Business Object 2	Business Object Cardinality	Business Object Relationship Description

9.2.1.1       Data Service Security Classification View

<<Data Service Security Classification View Example: This section may provide one or more views of security classification for the target data services.>>

<<Data Service Security Classification View Description: Data services have attributes that can describe various functional and non-functional aspects. Among these attributes is the security classification. The context within which a data service operates can be derived from the information objects, as these objects can have a classification.

The definition of the data service security should be carried out before a project is initiated as part of a Data Impact Analysis.

Project architecture documents must take the security classifications of the artifacts that will be impacted by the project and ensure both that the intended solution is using appropriately secure artifacts and that it will not have a negative impact on the security of those artifacts.>>

Reference ID* Component	Title* Component	Reference ID*	Title*	Subject	Confiden­tiality Classi­fication	Integrity Classi­fication	Availability Classi­fication

9.2.2         Logical Target Data Architecture

<<Data Architecture Logical-Level View Example: This section needs to provide one or more logical-level views for the target data architecture. The diagram below provides a view of the target data architecture at the logical level which consists of logical data entities and the relationships between them. This particular example illustrates the logical data entities derived from the customer business object. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Data Architecture Logical-Level View Description: This section needs to provide a description of the logical-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<Data Architecture Logical-Level Artifact Definitions: This section needs to provide (in table format) definitions for the logical data entities in scope for the target data architecture.>>

Logical Data Entity ID	Logical Data Entity	Logical Data Entity Description

<<Data Architecture Logical-Level Artifact Characteristics: This section needs to provide (in table format) characteristics for the logical data entities in scope for the target data architecture. The domain needs to determine which characteristics they wish to capture.>>

Logical Data Entity	Logical Data Entity Characteristic	Logical Data Entity Characteristic Value

<<Data Architecture Logical-Level Artifact Attribute Definitions: This section needs to provide (in table format) definitions for the attributes of the logical data entities in scope for the target data architecture. A separate table may be produced per logical data entity. An optional attribute is information classification. With this attribute it is possible to classify the Logical Data Entities.>>

Logical Data Entity	Logical Data Entity Attribute	Logical Data Entity Attribute Description

<<Data Architecture Logical-Level Artifact Relationships: This section needs to provide (in table format) definitions and cardinality for the relationships between the logical data entities in scope for the target data architecture.>>

LDE Relationship ID	Logical Data Entity 1	Logical Data Entity 2	Logical Data Entity Cardinality	Logical Data Entity Relationship Description

9.2.3         Physical Target Data Architecture

<<This section describes the interaction between data models that cross ownership boundaries.>>

<<Data Architecture Physical-Level View Example: This section may provide one or more logical-level views for the target data architecture. The diagram below provides an example view of the target data architecture at the physical level which consists of physical data entities and the relationships between them. This particular example illustrates the physical instance of a logical data entities derived from the customer business object. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.

Determine the interaction between the data entities, select and visualize the interactions that cross logical ownership boundaries. Determine the impact of information ownership on these interactions.>>

<<Data Architecture Physical-Level View Description: This section may provide a description of the physical-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Data Architecture Physical-Level Artifact Definitions: This section may provide (in table format) definitions for the physical data entities in scope for the target data architecture.>>

<<Example: Is this interaction caused by the fact that the other owns the object that has caused the interaction? Is the ownership defined correctly? If we changed ownership of one of the elements, would that lead to a better result?

Often models like shown below are used for this View>>

9.2.4         Target Data Architecture Cross-Reference

<<Data Architecture Cross-References: This section provides, if necessary, some cross-references for the data architecture.>>

9.3            Application Architecture Models

<<The purpose of this section is to define the target application architecture for the domain/sub-domain.

Mandatory/optional: This section is mandatory as all the domain teams (excluding the data and infrastructure domains) need to produce a target application architecture at the conceptual and logical levels for their respective domains.

In terms of quality criteria, this section should make clear:

• Relevant views (diagrams) at the conceptual level illustrating the application services and their contracts (interactions) in scope for the target application architecture
• Description of the conceptual-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the application services (in table format) in scope for the target application architecture
• Characteristics of the application services (in table format) in scope for the target application architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both
• Descriptions of the contracts (interactions) between the application services (in table format) in scope for the target application architecture
• If required, characteristics of the contracts (interactions) between the application services (in table format) in scope for the target application architecture
• Relevant views (diagrams) at the logical level illustrating the logical application components and their contracts (interactions) in scope for the target application architecture; these logical application components group application services together based on common requirements/characteristics
• Description of the logical-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the logical application components (in table format) in scope for the target information architecture
• Characteristics of the logical application components (in table format) in scope for the target application architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both
• Descriptions of the contracts (interactions) between the logical application components (in table format) in scope for the target application architecture
• Characteristics of the contracts (interactions) between the logical application components (in table format) in scope for the target application architecture
• Any relationships between the business function categories, business functions, logical application components, and application services that are in scope for the target architecture
• Any relationships between the business services and application services that are in scope for the target architecture
• Any additional viewpoints and thus views that are required for this section due to new stakeholder requirements; these views will then be followed by descriptions for the views and definitions for the view artifacts
• Any assumptions that have been used to define the target application architecture; for example, one assumption (recommendation) that has already been stated is that the physical application architecture is out of scope for the enterprise architecture>>

9.3.1         Conceptual Target Application Architecture

<<Application Architecture Conceptual-Level Example: This section needs to provide one or more conceptual-level views for the target application architecture. The diagram below provides a view of the target application architecture at the conceptual level which consists of application services. This particular example illustrates some of the possible application services, grouped by domain. However, the definition of application services can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Application Architecture Conceptual-Level View Description: This section needs to provide a description of the conceptual-level view(s) for the target application architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Application Architecture Conceptual-Level Artifact Definitions: This section needs to provide (in table format) definitions for the application services in scope for the target application architecture.>>

<<Governance Services: The services must cover the complete scope of the architecture, including governance and service management. Additional services can be identified by considering how the main services, when implemented, will be instantiated, started up, shut down, configured, monitored, and how faults will be diagnosed, users maintained, new business configuration items added (e.g., products), and so on. For more technical services, management functions such as provisioning, key management, identity management, backup, recovery, and business continuity should be considered.>>

Application Service ID	Application Service	Application Service Description

<<Application Services Capability Mapping: This table provides a mapping between the capabilities and the business services.>>

Capability ID	Capability	Business Service	Application Service

<<Application Architecture Conceptual-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the application services in scope for the target application architecture. However, the domain will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to capture. They may wish to include additional characteristics. Governance and service management characteristics should be included here.>>

Application Service	Application Service Characteristic	Application Service Characteristic Value

<<Application Architecture Conceptual-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e., interactions/relationships) between the services in scope for the target application architecture.>>

CAS Contract ID	CAS Contract	Logical Application Service 1	Logical Application Service 2	CAS Contract Description

<<Application Architecture Conceptual-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the contracts (i.e., interactions/relationships) between the application services in scope for the target application architecture. The domain needs to determine which characteristics they wish to capture.>>

CAS Contract	CAS Contract Characteristic	CAS Contract Characteristic Value

9.3.1.1       Application Service Security Classification View

<<Application Service Security Classification View Example: This section may provide one or more views of security classification for the target application services.>>

<<Application Service Security Classification View Description: Application services have attributes that can describe various functional and non-functional aspects. Among these attributes is the security classification.

Project architecture documents must take the security classifications of the artifacts that will be impacted by the project and ensure both that the intended solution is using appropriately secure artifacts and that it will not have a negative impact on the security of those artifacts.>>

Reference ID Component	Title* Component	Reference ID*	Title*	Subject	Confiden­tiality Classi­fication	Integrity Classi­fication	Availability Classi­fication

9.3.2         Logical Target Application Architecture

<<Application Architecture Logical-Level Example: This section needs to provide one or more logical-level views for the target application architecture. The diagram below provides a view of the target application architecture at the logical level which consists of logical application components with their associated application services. This particular example illustrates some of the possible logical application components and associated application services. However, the definition of logical application components can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Application Architecture Logical-Level View Description: This section needs to provide a description of the logical-level view(s) for the target application architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.

More than one logical component architecture can be created by an architecture project, and then the different options evaluated and a recommended option chosen. If more than one option is considered, the document structure for the logical application architecture should be repeated for each option. In addition, a section to evaluate the options must be added and a section containing the recommendations. This applies to unbranded and branded architectures.>>

<<Application Architecture Logical-Level Artifact Definitions: This section needs to provide (in table format) definitions for the logical application components in scope for the target application architecture.>>

LAC ID	Logical Application Component (LAC)	Logical Application Component (LAC) Description

<<Application Architecture Logical-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the logical application components in scope for the target application architecture. However, the domain will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to capture.>>

Logical Application Component (LAC)	LAC Characteristic	LAC Characteristic Value

<<Application Architecture Logical-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e., interactions/relationships) between the logical application components in scope for the target application architecture.>>

LAC Contract ID	LAC Contract	Logical Application Component 1	Logical Application Component 2	LAC Contract Description

<<Application Architecture Logical-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the contracts (i.e., interactions/relationships) between the logical application components in scope for the target application architecture. The domain needs to determine which characteristics they wish to capture.>>

LAC Contract	LAC Contract Characteristic	LAC Contract Characteristic Value

9.3.3         Physical Target Application Architecture

<<Application Architecture Physical-Level View Description: This section can provide, if necessary, a description of the physical-level view(s) for the target application architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders. This section should follow the same structure as the logical target application architecture.>>

9.3.3.1       Vendor Consideration List

<<This section provides a list with relevant suppliers and brands for providing the physical components and the considerations for selecting or using them.>>

Vendor/Product	Component	Considerations

9.3.4         Target Application Architecture Cross-Reference

<<Business Function and Business Service Cross-References: This section needs to provide (in table format) any relationships between the business function categories, business functions, logical application components, and application services that are in scope for the target architecture. It thus enables the assessment of the application landscape across business functions.>>

<<Business Service and Application Service Cross-References: This section needs to provide (in table format) any relationships between the business services and application services that are in scope for the target architecture. It thus provides traceability between the business and application architectural domains which allows the impact of change in the business architecture domain to be assessed in the application architecture domain and vice versa.>>

<<Application Service and Infrastructure Service Cross-References: This section needs to provide (in table format) any relationships between the application services and infrastructure services that are in scope for the target architecture. It thus provides traceability between the application and technology architectural domains which allows the impact of change in the application architecture domain to be assessed in the technology architecture domain and vice versa.>>

<<Application Component and Infrastructure Component Cross-References: This section needs to provide (in table format) any relationships between the application components and infrastructure components that are in scope for the target architecture. It thus provides traceability between the application and technology architectural domains which allows the impact of change in the application architecture domain to be assessed in the technology architecture domain and vice versa.>>

9.4            Technology Architecture Models

<<The purpose of this section is to either provide references to the relevant technology architecture documentation that complements the target architecture and/or this document, or to provide a high-level view of the technology architecture if it has not been defined in the technology architecture documentation.

Mandatory/optional: This section is mandatory as this section will either provide references if the relevant technology architecture is described in other documentation or a description of the technology architecture if the relevant technology architecture is not described in other documentation.

If the relevant technology architecture is described in other documentation, in terms of quality criteria, this section should make clear:

• The relevant technology architecture documentation
• Context around the relevant technology architecture documentation; e.g., validity, ownership, purpose
• Any assumptions regarding the technology architecture documentation

However, if the relevant technology architecture is not described in other documentation, in terms of quality criteria, this section should make clear:

• Relevant views (diagrams) at the conceptual level illustrating the infrastructure services and their contracts (interactions) in scope for the target technology architecture
• Description of the conceptual-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the infrastructure services (in table format) in scope for the target technology architecture
• Characteristics of the infrastructure services (in table format) in scope for the target technology architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both
• Descriptions of the contracts (interactions) between the infrastructure services (in table format) in scope for the target technology architecture
• If required, characteristics of the contracts (interactions) between the infrastructure services (in table format) in scope for the target technology architecture
• Relevant views (diagrams) at the logical level illustrating the logical infrastructure components and their contracts (interactions) in scope for the target technology architecture; these logical infrastructure components group infrastructure services together based on common requirements/characteristics
• Description of the logical-level view(s) in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders
• Definitions for the logical infrastructure components (in table format) in scope for the target technology architecture
• Characteristics of the logical infrastructure components (in table format) in scope for the target technology architecture; the domains will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both
• Descriptions of the contracts (interactions) between the logical infrastructure components (in table format) in scope for the target technology architecture
• Characteristics of the contracts (interactions) between the logical infrastructure components (in table format) in scope for the target technology architecture
• Any relationships between the business function categories, business functions, logical infrastructure components, and infrastructure services that are in scope for the target architecture
• Any relationships between the business services and infrastructure services that are in scope for the target architecture
• Any additional viewpoints and thus views that are required for this section due to new stakeholder requirements; these views will then be followed by descriptions for the views and definitions for the view artifacts
• Any assumptions that have been used to define the target technology architecture; for example, one assumption (recommendation) that has already been stated is that the physical technology architecture is out of scope for the Reference Architecture.>>

9.4.1         Conceptual Target Technology Architecture

<<Technology Architecture Conceptual-Level Example: This section needs to provide one or more conceptual-level views for the target technology architecture. The diagram below provides a view of the target technology architecture at the conceptual level which consists of infrastructure services. This particular example illustrates some of the infrastructure services within xxxx. However, the definition of infrastructure services can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Technology Architecture Conceptual-Level View Description: This section needs to provide a description of the conceptual-level view(s) for the target technology architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.>>

<<Technology Architecture Conceptual-Level Artifact Definitions: This section needs to provide (in table format) definitions for the infrastructure services in scope for the target technology architecture.>>

<<Governance Services: The services must cover the complete scope of the architecture, including governance and service management. Additional services can be identified by considering how the main services, when implemented, will be instantiated, started up, shut down, configured, monitored, and how faults will be diagnosed, users maintained, new business configuration items added (e.g., products), and so on. For more technical services, management functions such as provisioning, key management, identity management, backup, recovery, and business continuity should be considered.>>

Infrastructure Service ID	Infrastructure Service	Infrastructure Service Description

<<Technology Architecture Conceptual-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the infrastructure services in scope for the target technology architecture. However, the domain will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to capture..>>

Infrastructure Service	Infrastructure Service Characteristic	Infrastructure Service Characteristic Value

<<Technology Architecture Logical-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e., interactions/relationships) between the logical infrastructure components in scope for the target technology architecture.>>

CIS Contract ID	CIS Contract	Logical Infrastructure Component 1	Logical Infrastructure Component 2	LIC Contract Description

<<Technology Architecture Conceptual-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the contracts (i.e., interactions/relationships) between the conceptual infrastructure services in scope for the target technology architecture. The domain needs to determine which characteristics they wish to capture.>>

CIS Contract	CIS Contract Characteristic	CIS Contract Characteristic Value

9.4.2         Logical Target Technology Architecture

<<Technology Architecture Logical-Level Example: This section needs to provide one or more logical-level views for the target technology architecture. The diagram below provides a view of the target technology architecture at the logical level which consists of logical infrastructure components with their associated infrastructure services. This particular example illustrates some of the logical infrastructure components and associated infrastructure services within xxxx. However, the definition of logical infrastructure components can only be confirmed during the architectural analysis for each domain. Text describing the key concepts and notation used within the diagram will also need to be included so that users can easily read and understand the view.>>

<<Technology Architecture Logical-Level View Description: This section needs to provide a description of the logical-level view(s) for the target technology architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.

More than one logical component architecture can be created by an architecture project, and then the different options evaluated and a recommended option chosen. If more than one option is considered, the document structure for the logical technology architecture should be repeated for each option. In addition, a section to evaluate the options must be added and a section containing the recommendations. This applies to unbranded and branded architectures.>>

<<Technology Architecture Logical-Level Artifact Definitions: This section needs to provide (in table format) definitions for the logical infrastructure components in scope for the target technology architecture.>>

LIC ID	Logical Infrastructure Component (LIC)	Logical Infrastructure Component (LIC) Description

<<Technology Architecture Logical-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the logical infrastructure components in scope for the target technology architecture. However, the domain will need to decide whether characteristics are needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to capture.>>

Logical Infrastructure Component (LIC)	LIC Characteristic	LIC Characteristic Value

<<Technology Architecture Logical-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e., interactions/relationships) between the logical infrastructure components in scope for the target technology architecture.>>

LIC Contract ID	LIC Contract	Logical Infrastructure Component 1	Logical Infrastructure Component 2	LIC Contract Description

<<Technology Architecture Logical-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the contracts (i.e., interactions/relationships) between the logical infrastructure components in scope for the target technology architecture. The domain needs to determine which characteristics they wish to capture.>>

LIC Contract	LIC Contract Characteristic	LIC Contract Characteristic Value

9.4.3         Physical Target Technology Architecture

<<Technology Architecture Physical-Level View Description: This section can provide, if necessary, a description of the physical-level view(s) for the target technology architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders. This section should follow the same structure as the logical target technology architecture.>>

9.4.3.1       Vendor Consideration List

<<This section provides a list with relevant suppliers and brands for providing the physical components and the considerations for selecting or using them.>>

Vendor/Product	Component	Considerations

9.4.4         Target Technology Architecture Cross-Reference

<<Technology Architecture Cross-References: This section provides, if necessary, some cross-references for the technology architecture. The IS-TI services and components cross-references are included in the application architecture.>>

9.5            Security Architecture Models

Service Name	Description	Type	Target Specification: Policy Reference

10             Gap Analysis

<<The purpose of this section is to define the gap between the current (as-is) and target (to-be) state business architectures.

Mandatory/optional: This section is optional as not all the domain teams need to produce a business architecture for their respective domains. However, it can also be used by the domains that do not produce a full (current and target) or current state business architecture but still want to know the (priority) areas on which to concentrate, and thus minimise effort.

In terms of quality criteria, this section should make clear:

• Description of the gap between the current (as-is) and target (to-be) state business architectures. This difference, or delta, defines the scope of work that needs to be undertaken in order to transition from the current to the target business architecture. This scope is thus the scope of the program(s) or project(s) that need to be completed in order to reach the target business architecture.

The suggested steps are as follows:

• Draw up a matrix with all the Architecture Building Blocks (ABBs) of the baseline architecture on the vertical axis, and all the ABBs of the target architecture on the horizontal axis.
• Add to the baseline architecture axis a final row labeled ‘‘New’’, and to the target architecture axis a final column labeled ‘‘Eliminated’’.
• Where an ABB is available in both the baseline and target architectures, record this with ‘‘Included’’ at the intersecting cell.
• Where an ABB from the baseline architecture is missing in the target architecture, each must be reviewed. If it was correctly eliminated, mark it as such in the appropriate ‘‘Eliminated’’ cell. If it was not, an accidental omission in the target architecture has been uncovered that must be addressed by reinstating the ABB in the next iteration of the architecture design – mark it as such in the appropriate ‘‘Eliminated’’ cell.
• Where an ABB from the target architecture cannot be found in the baseline architecture, mark it at the intersection with the ‘‘New’’ row as a gap that needs to filled, either by developing or procuring the building block.

When the exercise is complete, anything under ‘‘Eliminated’’ or ‘‘New’’ is a gap, which should either be explained as correctly eliminated, or marked as to be addressed by reinstating or developing/procuring the function.

Potential sources of gaps include:

• Business domain gaps:
  • People gaps (e.g., cross-training requirements)
  • Process gaps (e.g., process inefficiencies)
  • Tools gaps (e.g., duplicate or missing tool functionality)
  • Information gaps
  • Measurement gaps
  • Financial gaps
  • Facilities gaps (buildings, office space, etc.)
• Data domain gaps:
  • Data not of sufficient currency
  • Data not located where it is needed
  • Not the data that is needed
  • Data not available when needed
  • Data not created
  • Data not consumed
  • Data relationship gaps
• Applications impacted, eliminated, or created
• Technology impacted, eliminated, or created>>

11             Impact Assessment

<<The purpose of this section is to assess and document the impact (on the organization) of the change required in order to transition from the current to the target state business architectures.

Mandatory/optional: This section is optional as not all the domain teams need to assess the organizational impact of change within their respective domains.

In terms of quality criteria, this section should make clear:

• Description of the organizational impact at a level that enables the organization to determine the change management requirements for program(s)/project(s)>>

11.1       Reference to Specific Requirements

11.2       Stakeholder Priority of the Requirements To-Date

11.3       Phases to be Revisited

11.4       Conclusions

<<The purpose of this section is to draw conclusions about the architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Overall conclusions that can be drawn>>

11.5       Recommendations

<<The purpose of this section is make recommendations about the architecture.

Mandatory/optional: This section is optional.

In terms of quality criteria, this section should make clear:

• Recommendations for implementing this architecture>>

The Open Group Architecture Framework, or TOGAF, is intended to provide a structured approach for organizations seeking to organize and govern their implementation of technology, particularly software technology. In that sense, its objective is to employ an encompassing conceptual framework to try to ensure that software development projects meet business objectives, that they are systematic and that their results are repeatable.

TOGAF was created and is maintained by The Open Group, an independent industry association. It builds on an earlier framework known as TAFIM, or Technical Architecture Framework for Information Management, originally devised by the U.S. Defense Dept. In early 2009, The Open Group released TOGAF version 9. The Open Group and others commonly lead TOGAF certification and educational programs today. Typically, enterprise architects lead use of TOGAF within organizations.

Like its TAFIM forerunner and many other frameworks, TOGAF owes a debt to the work of John Zachman, who created the Zachman Framework, a related schema to facilitate discussion between different software development stakeholders and improve software project and program outcomes. This and similar frameworks seek to effectively organize requirements gathering,to make sure what is built is what is needed. Zachman’s landmark work in the 1980’s while at IBM, brought context to the development process without endorsing a specific software language or methodology. Like TOGAF today, it clarified terms and roles, focusing on the ”What, How, When, Who, Where and Why” of technology implementation.

The basic TOGAF 9 document contains descriptions of an architecture development method and related techniques, an architecture content framework, an enterprise continuum, TOGAF reference models and a capability framework. Version 9 creates a model for extensibility, among other enhancements.

TOGAF need not be used ”whole hog.” While the basic TOGAF document runs to many pages, a pocket-book version is available too. Experienced professionals can focus on the aspects of TOGAF that work best for their organization as they pursue business benefits derived from software innovation.

TOGAF has enjoyed considerable adoption in organizations of diverse character. Its use is seen as a potential systematization of efforts – in the wake of high-profile failures – by governments, businesses and others to apply structured enterprise architecture principles to the still somewhat ”black arts” of software development and IT operations. TOGAF can be used with – or without – service-oriented architecture (SOA), UML and various frameworks, methodologies and tools of modern software development.

In the development of a house, building or any object we can always identify the following main steps:
• A discovery process to identify the needs and requirements in the context of a certain situation;
• A design process which leads to a design of the object in the form of drawings and/or models;
• A transformation process to plan the realisation of the object in its environment;
• A construction process that regards the realisation of the actual object based on the design and realisation plan.

The principles, guidelines and rules identified in the discovery phase are used in both the design, transformation and construction process. As such, the architecture impacts all processes.

The architecture constraints the freedom of the designer and constructor of the object and guides them towards a structure that complies with the business vision and concepts of the architecture. The architecture serves as a prescription for the
design, transformation and construction of the object. As a result the object will be recognised as being ‘designed and constructed under architecture’. The object will inherit the added value of the architecture and will support the (cultural) values, goals and objectives of the organisation. The described role of architecture originates from the building industry. In prescribing the structure, function and style of a building the architecture defines principles, guidelines and rules for:

• The type of components of which the building may be composed; • How these components must fit together; • What assemblies of the components are allowed;

• What functions (usage, living, and working) do the components and component assemblies support;

• And how the style represents the values of the owner. The prescription concerns the overall architecture as well as the design models and the actual construction of the building. IFEAD uses the same approach by defining the architectural steps for architecting business / organisations and IT systems. In prescribing the structure of an organisation and its related business or an IT system the architecture defines principles, guidelines and rules for:

• The type of components of which the business or system may be composed;

• How these components must fit together;

• How the components communicate and co-operate;

• What assemblies of the components are allowed;

• What functions (communication, control, security, and information) the components and component assemblies support;

• And how the style expresses the (cultural) values of the stakeholders of that organisation.

Paramount to the enterprise architecture is the identification of the sponsor, his/her mission, vision and strategy and the governance framework to define all roles, responsibilities and relationships involved in the anticipated transition.
As the purpose of architecture is: “INSIGHT, TO DECIDE, FOR ALL STAKEHOLDERS”, enterprise architects work very closely with the enterprise sponsor and key stakeholders, internal and external to the enterprise. The architect understands the enterprise mission, vision and strategy and the sponsor’s ideas about the approach. The architect articulates the existing enterprise infrastructure value-chain: market, business, systems and technology. Architects present and discuss the technology, systems, business and market options to fulfill the enterprise mission. Insight is improved by using the ‘solution architecture’ which is, relative to the decisions ahead, a specific blend of technology, systems, business and market options. Together with the sponsor and the main stakeholders, they make informed choices about the options. For large transitions, architectural decisions are supported by proofs-of-concept and/or business pilots.
Enterprise architects use various methods and tools to capture the structure and dynamics of an enterprise. In doing so, they produce taxonomies, diagrams, documents and models, together called artifacts. These artifacts describe the
logical organization of business functions, business capabilities, business processes, people, information resources, business systems, software applications, computing capabilities, information exchange and communications
infrastructure within the enterprise. A collection of these artifacts, sufficiently complete to describe the enterprise in useful ways, is considered by EA practitioners an ‘enterprise’ level architectural description, or enterprise architecture, for short. The UK National Computing Centre EA best practice guidance states Normally an EA takes the form of a comprehensive set of cohesive models that describe the structure and functions of an enterprise. and continues
The individual models in an EA are arranged in a logical manner that provides an ever-increasing level of detail about the enterprise: its objectives and goals; its processes and organization; its systems and data; the technology used and any other relevant spheres of interest. This is the definition of enterprise architecture implicit in several EA frameworks including the popular TOGAF architectural framework. An enterprise architecture framework bundles tools, techniques, artifact descriptions, process models, reference models and guidance used by architects in the production of enterprise-specific architectural description. Several enterprise architecture frameworks break down the practice of enterprise architecture into a number of practice areas or domains.

It is tempting to say that if the head of an organization doesn’t see the need for an EA model, then it is probably a simple enough organization not to need one. However, the truth is that most enterprises started out small and simple, where one person could genuinely understand the whole thing, but grew to the point where no single person could describe the whole. The same can be said of the corresponding IT systems that support the enterprise. The problem is that the people who
run these enterprises are loathe to admit (or often don’t even realise) that the level of complexity has grown beyond their ability to comprehend. This culture of denial is behind many of the management disasters of the information age – assumptions based on poor understanding of the key dependencies, weaknesses and bottlenecks in an organization have resulted in poor decision making. In the last few years, there has been a spate of corporate mergers of very large companies. The merged organizations each had their own cultures, processes, terminology and technology. Understanding how best to rationalise these organizations is only possible using models at an enterprise level – hence the recent upsurge in interest in EA. The benefits of EA are not always easy to measure – anyone with experience of change projects in large organizations can see that an EA approach is valuable, but it is hard to put a monetary figure on the benefits. Even just concentrating on tangible projects such as IT delivery, it is hard to put a figure on the benefits of EA. There are many opinions on why large IT projects tend to fail so spectacularly, but running through all of them are some key threads:

• Gaps in understanding – the business community are unable to elucidate their requirements to the technology providers, and the technology providers are unable to describe the impact of technology changes in such a way that the business community can understand the risk.
• Weakness of verbal requirements – written specifications are open to interpretation and contribute to gaps in understanding
• Lack of project cohesion – it is very difficult to coordinate a large development team to work towards a singular goal when their allotted tasks are specialised and isolated

It is clear that a well executed EA approach helps to overcome all these problems, but this still a “good feeling” rather than anything that can be measured. The only way to measure the benefits is to compare two almost identical projects, one which used an EA approach and one which did not.

Domain Logic Patterns: Transaction Script , Domain Model , Table Module, Service Layer .

Data Source Architectural Patterns: Table Data Gateway , Row Data Gateway, Active Record , Data Mapper .

Object-Relational Behavioral Patterns: Unit of Work , Identity Map , Lazy Load

Object-Relational Structural Patterns: Identity Field , Foreign Key Mapping ,Association Table Mapping , Dependent Mapping , Embedded Value ,Serialized LOB , Single Table Inheritance , Class Table Inheritance ,Concrete Table Inheritance , Inheritance Mappers .

Object-Relational Metadata Mapping Patterns: Metadata Mapping , Query Object, Repository .

Web Presentation Patterns: Model View Controller , Page Controller , Front Controller , Template View , Transform View , Two-Step View ,Application Controller .

Distribution Patterns: Remote Facade , Data Transfer Object

Offline Concurrency Patterns: Optimistic Offline Lock , Pessimistic Offline Lock, Coarse Grained Lock , Implicit Lock .

Session State Patterns: Client Session State , Server Session State ,Database Session State .

Base Patterns: Gateway , Mapper , Layer Supertype , Separated Interface , Registry , Value Object , Money , Special Case ,Plugin , Service Stub , Record Set

Enterprise storage is a broad category that includes products and services designed to assist large organizations with saving and retrieving digital information. Unlike consumer or small business storage devices, enterprise storage can handle large volumes of data and large numbers of users. It usually involves centralized storage repositories, such as storage area networks (SANs) or network-attached storage (NAS) devices.

Enterprise storage can be broken down into several categories. Primary storage houses the data that end users are actively accessing. Backup storage contains copies of the information in primary storage for use in disaster recovery situations or in other circumstances where a secondary copy is necessary. Backup storage is closely related to archive storage, which is where enterprises keep outdated information that needs to be saved for compliance or other purposes.

Whether on-premise or cloud deployment

Organizations can choose to purchase and deploy on-premises enterprise storage systems, or they can choose to store their data with an external cloud computing service. The advantage of on-premises enterprise storage is that the organization retains complete control of the hardware and data, satisfying some security and compliance concerns. On the other hand, cloud-bases enterprise storage simplifies storage management and may lower costs in some cases. Some companies take a hybrid approach and use a combination of both on-premise and cloud-based storage.

One of the key benefits of enterprise storage solutions is that they enable file sharing and collaboration among workers. Many offer security features, such as user-based permissions, that aren’t commonly found in consumer storage solutions. Enterprise storage also offers better performance, reliability, availability and scalability than other types of storage solutions.

Storage Networking and Management

Enterprise storage devices utilize similar technology as consumer and small business storage solutions. However, enterprise data storage generally offers higher reliability, availability and scalability. As a result, enterprise storage generally costs more than consumer or small business storage. It also usually requires more time and expertise to set up, while many consumer storage vendors takes a plug-and-play approach, and enterprise storage networks are typically run by specialized personnel or administrators.

When we think of working on Enterprise Architecture, we start with few common mistakes which if can be avoided then the journey ahead is relatively less complex.

1. We think it’s a technical problem. We think it is solvable by API, Web services, XML, enterprise resource planning or some other technology that changes every six months. Fat chance.

2. We haven’t truly tackled the problem. Over the years, we’ve defined the enterprise integration problem scope as order fulfillment then supply chain management, more recently customer relationship management and product lifecycle management. But really those are parts of the problem.

If you want to integrate the enterprise, then the scope of your problem is the whole enterprise. Arguably that’s a big, complex problem. But so is building a skyscraper, a planned community and the Panama canal. Your enterprise is everything from human resource management to marketing, manufacturing, distribution and finance and everything in between. That’s the scope of the enterprise integration problem.

3. We haven’t had a well-developed methodology for solving this problem. Enterprise architecture provides this methodology. Enterprise architecture provides a framework of principles, policies, models and standards.

The models break the enterprise down into distinct, manageable parts, one of the basics of problem solving. I’m not talking about the Holy Grail of reusable software components. I’m talking about the big picture. What are the business processes and data of the enterprise? And how do they fit together to create an integrated whole?

This is a thoughtful exercise, one best done by senior management with broad knowledge of the enterprise. Our enterprise “parts” are not arbitrary. If we do a good job, we will make it crystal clear what our enterprise “parts” are, where the integration points are, which ones should be common or standardized across our enterprise and which ones can be unique for each business unit.

For example, you may want common financial and HR business processes, but different manufacturing processes for each business unit. There is some brain-busting work that has to done in deciding what is in and out of each business process and how common you want that part of your enterprise to be. And it is critical to get the breakpoints between the parts right.

The principles, policies and standards of the enterprise architecture framework provide for some rigor and rules in how the individual parts are designed and built so that they will fit together in the end. All you third-party software developers out there, you’ll need to help us out by coming up with some standard definitions of your modules (parts) so you can become interchangeable. (Yes, we know this isn’t in your best interest). Don’t forget that the principles, policies and standards have to be developed not only for technology but also for data and business processes.

So…

First, let’s tackle the real integration problem: the enterprise. Second, let’s stop hoping that technology is going to solve the enterprise integration problem. Third, let’s use enterprise architecture to thoughtfully break the enterprise down into distinct, manageable parts and provide some principles, policies, models and standards so that we can turn people loose within an architected framework to integrate the enterprise.

“Avoiding the pitfalls in the first place is much easier than climbing out of a hole you’ve inadvertently tumbled into,” said Scott Bittler, research vice president at Gartner. “Applying the ways to avoid these pitfalls results in achieving EA benefits faster and reduced risk of programme failure. It will also improve the credibility of IT among business leaders.”

The ten EA pitfalls include:

1. The Wrong Lead Architect: Gartner identified the single biggest EA problem as a chief architect who is an ineffective leader. He or she may understand EA well but has ineffective leadership skills that even a good organisational structure and staffing levels cannot overcome. Gartner recommends that such a lead architect be replaced by someone with strong ‘soft’ skills such as enthusiasm, communication and passion, as well as being well respected and strategically minded.

2. Insufficient Stakeholder Understanding and Support: This happens when employees outside the EA team don’t participate in the EA programme, EA content is not used in projects and management questions its value. Gartner’s solution is to make EA education and communication a top priority to secure executive-team sponsorship. “The key is to ‘sell’ first and architect later,” said Mr Bittler.

3. Not Engaging the Business People: When IT and business goals are not aligned, resultant problems include non-technical people trying to make technical decisions while enterprise architects become too reactionary and tactical in response to projects. To overcome this, Gartner recommends that enterprise architects get involved in the development of the business context and engage jointly with other employees in the business architecture.

4. Doing Only Technical Domain-Level Architecture: This dated EA approach is still in use in some organisations and is even narrower in scope than technical architecture. Holistic EA best-practice is much broader as it includes business, information and solutions architecture.

5. Doing Current-State EA First: Successful EA provides prescriptive guidance but current-state EA does not, so it delays delivery of EA value and hinders the creation of good future-state EA. “The temptation is often to do the easy – current-state – EA first,” said Mr Bittler. “Instead, establish the business context and then focus first on future-state EA.”

6. The EA Group Does Most of the Architecting: This is a pitfall because the EA content is typically off the mark as it was not informed by those on the business side. There is also consequently no buy-in for the EA. The primary job of architects is to lead the EA process rather than impose EA content on the organisation. They should form virtual teams to create content and seek consensus on the content.

7. Not Measuring and Not Communicating the Impact: The value of EA is often indirect, so it may not be obvious to everyone in the organisation. This then exposes the EA programme to risk of failure. Gartner recommends that enterprise architects create a slide to demonstrate each success story of EA applied to a project. They should include measurement and documentation of EA in the programme plan.

8. Architecting the ‘Boxes’ Only: Enabling better business agility and integration is key but architecting standards for the ‘boxes’ (business units) in process, information, technical and solutions models doesn’t address this. Integration and interoperability standards are high EA priorities and must account for more than just technical architecture. Architects should focus more on the links between the boxes.

9. Not Establishing Effective EA Governance Early: Enterprisearchitects must resist the temptation to wait for more architecture content before setting governance processes and instead develop content and governance in parallel.

10. Not Spending Enough Time on Communications: Key messages about EA are not intuitively obvious, so enterprise architects must work to educate the business. It is critical that organisations develop and execute an EA communications plan with messages tailored to each audience.

“The key for enterprise architects is to create not the perfect or most elegant architecture for the moment, but the most adaptable architecture for the future,” said Mr Bittler. “EA is a challenging discipline and careful attention to the basics can mean the difference between failure and success.”

Compared to many industry practices, EA is considerably an emerging discipline which still take time to mature, in last two decades, there are many challenges literally EA programs face, organizations need to analyze them and understand the underlying causes

1. Fitness for purpose. Consistent definition and understanding of EA as a discipline adds to challenges. Most organizations stand up EA to “fix” an organization without giving it any purpose. Often, consultants/contractors try to sell the Titanic of EA before they can prove a sailboat which can float. This is what often results in annoying the clients and has lead to the view of EA being shelf-ware.
2. Senior executives buy-in and continuous focus and support upon the EA program. This is like a chicken and egg issue. Executives would have continuous support if EA can deliver value,  but EA need continuous executive supports to show value. EA is in a domain where you don’t find too many quick wins. In addition, a successful EA would often lead to corporate culture change. Without strong senior executives’ commitments, corporate culture change just won’t happen. Many feel that time and money is being wasted till they start seeing in the results.
3. Understand Stewardship and Ownership differences. Too often an EA attempts to take ownership of a business process and ends up getting blamed. An EA is a Steward to practice strategic EA Leadership & Operational Stewardship –> alignment of execution with Strategy is extremely critical for EA success.
4. EA Maturity: EA engagement model and governance. This gears toward corporate processes, politics and people issues. Enterprise Architecture is simply a heavy burden to a lot of people and projects if EA engagement and governance model is not efficient and effective. Somehow, fragmented EA engagement model and governance process is very common at work place. It seems taking forever to streamline. In other words, Governance and Compliance inward is extremely important.
5. Organizational Maturity. A mature organization is base to start a successful EA program; on the other side, an effective EA program improves organizational maturity. Too many organizations try to institute an EA program when the organization is not prepared to do so. Often, leadership hears or gets the pitch that EA will save the day and they start a program, without supporting the program, thinking that “doing” EA will fix everything. EA requires wide preparation and active participation.
6. Business/Architecture Alignment –> This has to be earned by EA Team and should not be considered a blank check or an entitlement, as this would require relationship management and transparency in delivery to match the business priorities. PMO and Architecture team are critical for earning and establishing the trust.
7. Move from Vendor/Group/Institute-centric EA to Customer-centric EA. Advance from just being DNAor “enterprise genotype” (a full nomenclature of enterprise artifacts) to provide a formal link with “enterprise phenotype” (a set of observable characteristics such as performance) and business ecosystem.
8. Constant jockeying with “tactical project savings” vs. “sustainable strategic advantage” argument…(classic misalignment of project team goals with architecture team goals!).  Starting too big,  that the EA initiative doesn’t get success as originally intended. It is extremely important to start small and produce results to gain trust. Planning and prioritizing some quick wins to demonstrate what change a complete EA can bring to a enterprise. Though it is very difficult since it can backfire at times. Still, EA needs to demonstrate directly quantifiable ($$$) value – contribution to company’s bottom line or direct savings as a result
9. Mature EA Team: The EA team which don’t just believe in Framework and Technology but also has the capability to carry the business with them and got a thick skin to sail through the politics and policies Staff. Also, it is not about the “chief architect,” it is about the team of architects/support staff, a mature EA team. 
10. EA Skills/Talent: Architecture is more of an art than a science and requires more skills than certifications. Enterprise Architect requires broad knowledge from many aspects of, business domains knowledge, technologies project management experience, and organizational skills. There are many channels to mature as an Enterprise Architect. Enterprise Architects with different maturing paths may see the same organization with very different challenges.

1. Lack Of Sponsorship.

Your architects need three tools to do a good job: access, leverage and goodies.

Access means the ability to interact with the appropriate stakeholders, often at the C-level.

Leverage includes the right place in the reporting chain, involvement in governance, ability to influence the technology budget, and authority to stop inappropriate technology implementations. Sometimes even the seemingly small change of a title from technical architect to chief enterprise architect can make a significant difference.

Goodies include the ability to give out new technologies for testing, “lend” technology experts to struggling projects, and get access to exclusive information that can be traded for favors.

Well-sponsored architects will be able to build trust by consistently delivering meaningful results. Lack of sponsorship will destine even the best architects to fail.

2. Hiring Or Promoting The Wrong Person.

The skills that earn someone the EA position don’t necessarily make the person a strong EA. Often the most technical people get promoted when they lack other important skills. These include interest in the business, the ability to translate technology into simple business outcomes, and the ability to listen, communicate, present and market infectious enthusiasm for new technologies.

3. Building An Ivory Tower.

Some EA programs hire a bunch of brilliant architects who retreat for a long time and return with sophisticated frameworks. They then present them to key members of the leadership and the organization, most of whom will have no clue what the architects are talking about, so their complex reference architectures will be ignored.

Ivory towers tend to increase the complexity and upset the stakeholders. The new CIO will gain immediate recognition among his business partners by firing the EA team, with the result that enterprise architecture becomes a “bad word” deeply embedded in the institutional memory. Roger Sessions wrote a great white paper on driving simplicity through connected enterprise architecture.

4. Policing And Insensitivity To Culture.

I have seen a project manager burst into tears in the crossfire of enterprise architects’ questions during a technical design review. I have been on a 2 a.m. call struggling to comply with unreasonable and obsolete technology standards just to get the chief architect’s signature and meet the budget deadline.

In that particular case, the turning of enterprise architecture into a policing function resulted in its failure. It takes a lot of effort to convince, and regularly re-convince, your business and IT partners of the value of enterprise architecture. A gentle approach makes the function more likely to succeed. The best architects I’ve known spoke softly and carried a really big carrot. They followed Exupery’s advice.

5. Maintaining The EA Artifact Factory.

Some EA teams keep busy documenting as-is states. They have an incredible array of diagrams at their disposal to represent the various aspects of everything. The world of diagrams is addictive, and perfect is the enemy of good when it comes to diagrams.

Instead, these teams should focus on producing frequent, meaningful and measureable business outcomes.

It isn’t easy to come up with good KPIs to measure enterprise architecture. This GAO report clearly shows the challenges of defining good EA metrics in the government sector.

6. Clinging To A Particular Framework Or Tool.

There are more than 80 EA frameworks, and you’ll find no silver bullets among them. The best approach is to read all of the major frameworks, discard most of what you have learned, and blend the remaining 10% in a way that fits your organization’s culture, maturity and business goals. As an example, here’s a lightweight, blended approach for tree huggers. When it comes to tools, go fancy if you have the money. But most of the time fancy isn’t necessary. Visio, Excel, Word, FreeMind, Prezi and a collaboration team site works well. Limit the time spent on selecting tools and frameworks and instead focus on using them.

7. Thinking Enterprise Architecture Equals Technology Architecture.

Most EA programs are initiated by IT and never progress beyond the technology domain. Although technology standards, technology roadmaps and solid engineering practices will produce simpler, cheaper, portable, reusable and more supportable solutions, they don’t align your IT investments with business goals and won’t power your business with technology innovation.

8. Taking The “Enterprise” Word Literally.

“Enterprise” does notnecessarily mean the entire enterprise. It means stepping back and taking a look at the higher-level context before making a decision. Moving architecture to the real enterprise level requires a mature and committed organization. If you try to push the enterprise aspect too far too early, you’ll crash and burn.

This is an example set of templates for TOGAF 9. It includes example artifacts for all catalogs, matrices, and diagrams, and template deliverables.

Example artifacts are as follows:

• Catalogs:
  • Application Architecture: Applications Portfolio Catalog, Interface Catalog
  • Business Architecture: Contract-Measure Catalog, Driver-Goal-Objective Catalog, Location Catalog, Organization-Actor Catalog, Process-Event-Control-Product Catalog, Role Catalog, Service-Function Catalog
  • Data Architecture: Data Entity-Data Component Catalog
  • Preliminary: Principles Catalog
  • Requirements: Requirements Catalog
  • Technology Architecture: Technology Portfolio Catalog, Technology Standards Catalog
• Core Diagrams:
  • Application Architecture: Application & User Location Diagram, Application Communication Diagram, System Use-Case Diagram
  • Architecture Vision: Solution Concept Diagram, Value Chain Diagram
  • Business Architecture: Business Footprint Diagram, Business Services and Information Diagram, Functional Decomposition Diagram, Product Lifecycle Diagram
  • Data Architecture: Class Diagram, Data Dissemination Diagram
  • Opportunities and Solutions: Benefits Diagram, Project Context Diagram
  • Technology Architecture: Environments & Location Diagram, Platform Decomposition Diagram
• Extension Diagrams:
  • Technology Architecture: Network Computing-Hardware Diagram, Processing Diagram
• Matrices:
  • Application Architecture: Application Interaction Matrix, Role-System Matrix, System-Function Matrix, System-Organization Matrix
  • Architecture Vision: Stakeholder Map Matrix
  • Business Architecture: Actor Role Matrix, Business Interaction Matrix
  • Data Architecture: Data Entity-Business Function Matrix, System-Data Matrix
  • Technology Architecture: System-Technology Matrix

Example deliverables are as follows:

• Preliminary Phase: Architecture Principles, Architecture Repository, Business Principles-Goals-Drivers, Organizational Model for Enterprise Architecture, Request for Architecture Work, Tailored Architecture Framework
• Phase A: Architecture Vision, Capability Assessment, Communications Plan, Statement of Architecture Work
• Phase B, C, D: Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap
• Phase E: Implementation and Migration Plan, Transition Architecture
• Phase F: Architecture Building Blocks, Architecture Contract with Business Users, Architecture Contract with Development Partners, Implementation Governance Model
• Phase G: Compliance Assessment, Solution Building Blocks
• Phase H: Architecture Change Request, Requirements Impact Assessment

Class Diagram

The key purpose of the class diagram is to depict the relationships among the critical data entities (or classes) within the enterprise. This diagram is developed to clearly present these relationships and to help understand the lower-level data models for the enterprise. This diagram is at a high level of representation (conceptual). We are interested here in modeling the main business entities, their properties and relationships.

The TOGAF class diagram as defined is situated at an early, conceptual stage. The highest level allows the essential business notions of enterprise to be represented, without being distracted by organizational or historical complexities specific to each organization. This conceptual level enables you to think about the business, in order to define an ideal organization with regard to this particular business. These entities will be used to define business processes (products handled by processes), and will be derived to define service application components, exchange data between services and repository data schemas.

Data Dissemination Diagram

The purpose of the data dissemination diagram is to show the relationship between data entities, business services, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained. Additionally, the diagram may show data replication and system ownership of the master reference for data. In this instance, it can show two copies and the master-copy relationship between them. This diagram can include services; that is, services encapsulate data and they reside in an application, or services that reside in an application and access data encapsulated within the application.

Entity application component: An entity component is frequently derived from business entities, and is responsible for managing the access to the entity, and its integrity.

Interaction application component: Represents the top level components that manage the interaction with elements outside the IS. In most cases, it is a GUI component, such as here a web interface.

Process application component: A process application component is responsible for a business process execution. It orchestrates the tasks of the process.

Utility component: Represents an application component that is frequently reused, and most of the cases bought off the shelf.

Database application component: Represents a repository. In pure SOA architecture, these elements should not appear. However, for legacy analysis or technology architecture, modeling repositories or repository deployment can be useful.

System federation: A system federation is the coarser-grained application component. It assembles systems to federate them, such as in the example of cooperation between different information systems between different companies.

Application: This application component corresponds to legacy applications, off the shelf products, or can be an assembly of application components.

Business Entity: Describes the semantics of the entities in the business, independently of any IS consideration (e.g. storage, technology, etc).

Data flow: Expresses that data (for example business entity) is input or output from a dynamic entity.

Data Lifecyle Diagrams

The data lifecycle diagram is an essential part of managing business data throughout its lifecycle, from conception through disposal, within the constraints of the business process. The data is considered as an entity in its own right, detached from business processes and activities. Each change in state is represented in the diagram, which may include the event or rules that trigger that change in state. The separation of data from process allows common data requirements to be identified, thereby enabling more effective resource sharing to be achieved.

Defining the lifecycle of business entities enables better formalization of these business entities, as well as the determination of the steps that are essential to their management. This very simple state model will be a guide in the definition of business processes, since these processes will themselves have to respect the constraints defined for transitions between states: if a business entity has not passed through all its states within the business processes that handle it, then these are incomplete. If the business processes transgress the lifecyle of the business entities, then they are incorrect.

 

Data migration Diagram

The purpose of the data migration diagram is to show the flow of data from the source to the target applications. The diagram will provide a visual representation of the spread of sources/targets and serve as a tool for data auditing and establishing traceability. This diagram can be elaborated or enhanced as detailed as necessary. For example, the diagram can contain just an overall layout of migration landscape or could go into individual application metadata element level of detail.

Data security diagrams

IT-related 

Complexity management: Facilitate the scoping and coordination of programs and information systems projects. Manage complexity and describe the interdependencies in a usable manner.

Technical resource oversight: Identify and remove redundancy.

Knowledge management: Manage and share knowledge modularly so it can be visualized across different levels.

IT visibility:  IT resources and systems are more aligned to business strategies and are better placed for responsiveness.

Business-related

Reduction in impact of staff turnover : Capture knowledge from employees and consultants.Provide business solutions from third party organizations consistently so they can conform to the current models.

Faster adaptability: Facilitate knowledge acquisition necessary for changing systems and adopting new components.

Operating procedures improvement: Understand and model business processes. Review and re-engineer processes.

Decision making: Represent an enterprise’s layers and components modularly to let the organization make business decisions in the context of a whole instead of a stand-alone part.

Zachman’s   argument that you have to plan before you do and that you need a view across the whole enterprise is compelling. However, how much of a plan do you need and how much of a view do you need? The strategy of the organization should drive our efforts. The strategy will contain objectives, a statement of its appetite for risk, the timetable for achievement of the goals and the investment it is prepared to make. Architectural efforts must align and produce only the artifacts geared to strategy delivery. If the timescales are tight or money short, then we must be pragmatic and compromise.

However, what often happens is that the objective becomes populate the Zachman Framework for the entire enterprise. Each cell generates a task to create an “As-Is” model and a task to create a “To-Be” model. Each column is taken and given to an architect. The answer isn’t understood and there aren’t any standards for modeling strategy, so “best practice” becomes the guide for producing all the “To-Be” models. This isn’t arrogant, of course, because it is based on logic.

Transformational Architecture

Sometimes, the organization has a “big idea”, a transformation, a merger, a shared services structure, a major change of some sort that requires major investment in IT. The case for architecture is easy … Big change = big design = architecture.

A business transformation places “big architecture” in a clear context with clear objectives and timescales. It gives direction, visibility and urgency.

A major issue for architecture is keeping close enough to the business change to design a solution that meets the needs and has a feasible migration path. Get behind the curve and the consultants and vendors fill the vacuum with half baked solutions that you spend the next 5 years unraveling because they were poorly architected. Get too far ahead and you get accused of trying to bend the business to fit your own pet scheme. Highlight too many problems and you are seen to be “off message”.

How do you get involved? This comes down to influence, relationships and politics because you have no right to be there. Do some stakeholder analysis and plan a campaign to raise your profile in a sophisticated manner that gives credibility and influence as a business person who is worth listening to.

Project Architecture

The concept of an enterprise architect being controlled by a project is nonsense. The job title may include the word “architect” but it is not architecture if the project manager has control of the architect – role is actually a design role. A fundamental part of architecture is that architecting concerns balancing competing demands between projects, between long term and short term objectives, and between different areas of the enterprise. There is a conflict of interest if the project manager controls the architect.

Should architects be allocated to projects? Yes, but only when necessary. When is necessary? When the project may decisions, through pressure of objectives or through ignorance, that pose a significant threat to enterprise business goals. If there is no risk, then there is no need for architectural involvement.

In practice, there is always some risk. There are also constraints on resources, so risk drives the level of involvement required. A triage process is essential to identify up front where to put resources, and integrating architecture into the development process means that you should never lose a project.

Program Architecture
A transformation involves the whole business, doing transformational architecture is by definition enterprise scope. A program typically has a single business theme, e.g. customer service, which has a narrower scope and impact.

Program architecture is a mix between transformational involvement and project involvement. Architects work across the projects within the program to deliver program objectives. They also have a role to ensure that the program follows the enterprise agenda not the program agenda if it differs.

Portfolio Architecture

A program is a set of projects that are related at a business level and it is clear that there are significant inter-dependencies. A portfolio is a set of projects that are managed together for convenience, it may they share a resource pool or a set of business managers. But from a business point of view they are seen as largely independent.

The project management approach is typically to treat these projects as independent from a deliverable perspective but resource constrained. However, the reality is that they are likely to be using the same data, programs or infrastructure.

The architectural task is to carry out a technical impact analysis to understand where different projects hit the same IT asset. Databases and programs should be changed a minimum number of times to minimum costs and risk. Infrastructural changes need to planned as a single exercise to leverage shared infrastructure and to minimize procurement and implementation costs.

This puts timescale and resource constraints into the projects but it achieves greater quality and lower costs. You just have to persuade the project managers and the portfolio board of this.

Operational Architecture
Being service delivery oriented they have clearer and quicker paybacks. However, the skills base and interests of those typically in architecture roles often does not sit well with such an orientation.

An example of an operational architecture objective would be “reduce help desk calls”. If there are 10,000 calls a month and each call costs the IT function $25, then a 20% brings a cost benefit of $600,000 potentially realized by reducing IT headcount or reducing the need for contractors. The business benefit is much higher because each call is lost time to the organization which may mean increased operational costs or lost revenue. My team delivered this within 2 months by reviewing the use of the helpdesk system, implementing better solutions for frequent calls, and redesigning end to end processes. Was this IT focused? No, the organization gets an improved IT service which means it can use its resources to meet its objectives rather than to deal with IT problems.

Other examples could be:

• identify and eliminate repeated problems
• reduce release failures
• reduce call outs
• improve application performance
• improve security
• demise expensive platforms
• improve business intelligence
• speed up the turn around of small changes

Operational architecture is about getting IT’s house in order before pushing the business to do the same. It is about taking the medicine within IT before exposing the business to its rigors. It is about proving the value for money of an enterprise architecture team. It is about delivering tangible benefits to the organization in terms of improved IT service delivery and reduced IT costs. Six months of solid operational architecture performance gives credibility and a great foundation for extending the architectural objectives into the organization.

Procurement Oriented Architecture
Procurement oriented architecture focuses on the purchases that the IT function makes and attempts to optimize them from a financial point of view. Architects review application and infrastructure purchases.

With applications, reuse or extension of existing in house or licensed applications will typically be advised if possible. Minimizing the number of suppliers is also often a goal. The pitfalls are shoehorning needs into inappropriate applications and some suppliers terms have financial “steps” in them that make further licenses prohibitively expensive.

With infrastructure, consolidation is the key to minimizing costs which requires a good knowledge of capacity needs and actual performance. Infrastructure costs typically have financial “steps” which can be exploited. For example, my team saved $5M on an $8M proposal by changing the required spec from 3 top end servers to 5 mid range servers. Did the supplier like it? No. Did they offer the lower range solution? No. We had to do the detail to work out that our requirements could be met by the lower spec machines. The small amount of added complexity and marginally lower flexibility were not worth $5M.

Like operational architecture, this approach is largely confined to within IT but does have significant measurable benefits that can form a foundation for extending architectural work.

Policy Architecture
Architecture policies are the practical instructions for the implementation of architecture principles. They instruct those delivering applications and infrastructure on what they must deliver. They may also set out SLAs or contracts with the business e.g. for data quality.

Some architecture departments’ primary mode of governance of the IT function in relation to architecture policies. This is the creation and maintenance of policies, guidance on policies, policing the process, approving documents, issuing waivers, etc.

This is a very dry role. There is creativity in the research the goes into the formulation of a policy. There is human interaction in the dissemination and mentoring that goes into supporting policies. But often, the architecture function slips either into a police force or to a burdensome bureaucracy.

Sometimes this model is imposed, for example, by the group company on a subsidiary. In this case, efforts must be made to make the approach user-friendly. Architects should guide and support projects so that they automatically comply. They should identify the need for a waiver early and sponsor it. Project managers need to understand the impact of compliance on their projects so that their estimates take any adverse impacts into account. The rationale behind policies should be explained.

Model Based Architecture
The aim of model based architecture is to create models in the hope that they will prove useful. Unfortunately, the usage is often not clearly defined. This means that the models don’t have a real purpose, they don’t have an audience. The result is that they are not built to be used. They become write only models.

Models are tools for architects to do their jobs working with business and IT management and staff to achieve benefits for the organization in line with the objectives of the organization. Models are not an end in themselves.

Silo Based Architecture
A pet hate of mine is to divide architects into business architects, technical architects, data architects, infrastructure architects, solution architects, project architects, etc. It creates silos where the architectures don’t connect.

The application direction is intimately related to the process direction and the data direction and the infrastructure. We can’t pretend that they independent and set up different teams to work on each area separately.

Architects obviously have competencies and preferences in different areas but they must be able to operate competently across all domains otherwise they are not architects.

Another type of silo based architecture organization is to align with the business unit structure. This can result in architecture reinforcing business silos and fundamentally failing to support the enterprise agenda.

How do I organize? I operate a very fluid and flexible structure. I have two tier teams. One tier is the more experienced architects who are capable of running an initiative. Some of the architects have ongoing roles as single points of contact. The rest of the architects form the other tier.

I continually form and reform teams to address specific needs typically the structure changes every few weeks. Each person is generally in 2 or 3 teams simultaneously. Sometimes the teams include people from the business or from other IT areas.

My role is to make sure the approach is working, re-balance the load as necessary, set priorities, and to mentor all the architects to ensure they can deliver to each of the initiatives they are working on.

Opportunistic Architecture
When money is tight in an organization, architecture has a hard time. The number of architects is generally reduced, sometimes to zero. If architecture is still recognized as adding value then as architects we need to take the small opportunities that exist.

This means getting smart over communication. A typical architecture message is about strategy, the long term, flexibility, etc. An organization that has constrained investment is usually looking at short term actions to survive – the strategy is not to spend unnecessarily, the long term will be taken care if we get there. Architects need to get “on message” or lose credibility.

We have to get smart with payback, the organization is looking for rapid payback – 3 months, 6 months, definitely less than 12 months. Therefore, long projects are out, incremental delivery is in. Do something, get some payback, do some more, get some more payback, bring the benefits forwards. Doing this you are helping your organization meet its strategic need to survive, you are showing that you business savvy, you bringing forward the day when the investment constraints get lifted.

We have to get smart with suppliers. Some suppliers will play ball and use value based pricing. This means that they paid based on the value that you receive rather than the capability of the product i.e. you buy a strategic product that gives you a foundation for the future but only pay for what you use. The supplier wins because when you expand usage they additional revenue with minimal presales effort. You win because you get an architecturally sound base to build on. But, you need to get price protection on your future usage so you don’t get screwed on licenses or maintenance.

We have to get smart with projects. You are trying to get each project to put in place a small number of building blocks for the future. You need to persuade them that this is at no extra cost and requires no extra time – they are under pressure. You need a very clear vision, it needs to be pragmatic. If it’s too complex or too big then the small steps will give you too little progress.

Guerrilla Architecture
When you get down to zero and architecture is not seen to add value then the only thing left is guerilla action. You have to be opportunistic but you can’t do it openly. You may also have to resort to sabotage where short term parochial actions are damaging the organization.

You are now playing a dangerous political game. You are exploiting failures to promote more thoughtful planning. You are chipping away at the credibility of others who may have more power than you. You fail if you don’t survive.

You are the one who says “I told you so” and then have a recovery plan. You are the lone voice in the wilderness. Sometime in the future, people will realize and understand that you were right. These people are politicians so they will take your ideas and claim them for themselves. They may even try and discredit you.

Guerilla action is not easy, you will likely lose. But hey, you had already lost, guerilla architecture is a way of retaining your integrity and maybe there is a slim chance of winning.

 

[Ref: http://chiefarchitect.squarespace.com]

 

The Open Group Architecture Framework (TOGAF) is the leading enterprise architecture frame work. There are so many frameworks but it may be confusing which one is the best fit for your organization. Especially, when there are more than 20 frameworks that are used to do enterprise architecture. These frameworks can be categorized either as industry specific or corporate propriety. While, we are not arguing the value of these frameworks when they are put into practice in an organization. There have been many result oriented architectures which organizations can claim success from these frameworks.

What makes TOGAF important to the enterprise architecture community is that it is a framework which is built on open standards. This translates to organizations being able to use TOGAF as their enterprise architecture framework for free. They do not have to pay any organization maintenance cost or anything to implement this framework. Companies are always looking for ways to save money especially with cuts in corporate budgets and the need to do more work with less resources. The TOGAF framework has a strong user community who supports the development of the framework. This is one of most adopted frameworks by organizations across the globe. This leads to more opportunities for organizations to find resources in a domain which has been notoriously difficult to recruit qualified enterprise architects capable of understanding how their company does business. Since the company uses TOGAF then they build their architecture the same way that other organizations build their architecture using this framework. The ability of organizations to leverage their resources to capitalize on the benefits of TOGAF would truly make a difference in organizations making better decisions on their technology to support their business needs.

The TOGAF framework has been tried, tested, validated in many organizations around the world. This framework can be used with other existing management frameworks that your company may use. For example, if your company uses ITIL then you can also integrate the TOGAF into the practices of ITIL. There are many benefits from having a framework which is widely used, accepted, and an industry standard. Your organization should pick a framework which will develop the type of artifacts that are needed which are specific to your organization’s needs. When you implement processes, procedures, governance, and structure to manage your enterprise architecture then you should see greater corporate agility, communication, collaboration, and better decision making by corporate executives.