Example TOGAF 9 Template – Architecture Definition

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 DefinitionDocument Version Date: 
Reviewed By: Review Date: 

Distribution List

FromDatePhone/Fax/Email
   
   
ToAction*Due DatePhone/Fax/Email
    
    
    
    

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

Document Version History

Version
Number
Version
Date
Revised ByDescriptionFilename
     
     

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

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>>
ConcernDoes the architect understand what I (sponsor) want to be able to do with the architecture?
DescriptionThere 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
GuidanceThis View is a simple selection of the architecture objectives or strategies as appropriate. See the architecture objectives artifact template.
Reference-IDTitleClassArchitecture 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

ConcernDo the constraints represent the agreed limitations? Are they stated clearly and in such a way that design decisions can be made appropriately?
DescriptionA 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.
GuidanceConstraints 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-IDTitleArchitecture ConstraintPriorityConsequences
     

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

ConcernDo the principles represent the agreed decision criteria? Are they stated clearly and in such a way that design decisions can be made appropriately?
DescriptionA 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.
GuidancePrinciples 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.>
StatementThe 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.
RationaleThe 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.
ImplicationsThe 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

IDAssumption ItemDescriptionDateSourceOwner
      
      

5.2            Risks

ConcernAre the risks clearly described and communicated? Do agreed mitigations exist for all stated risks?
DescriptionA 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).
GuidanceThis 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
TitleDescriptionImpactMeasuresMitigation
Plan
      

5.3            Issues

IDIssueStatusInput DateDue DateClosed DateOwnerWork Group OwnerMeeting Notes/
Comments
         
         
         

5.4            Dependencies

Reference-IDTitleDescriptionImpactMeasuresComment
      

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) IDBusiness Function CategoryBusiness FunctionBusiness 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) IDBusiness Service CategoryBusiness ServiceBusiness 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 ServiceBusiness Service CharacteristicBusiness 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 IDBusiness Service ContractBusiness Service 1Business Service 2Business 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 ContractBusiness Service Contract CharacteristicBusiness 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*SubjectConfidentiality ClassificationIntegrity ClassificationAvailability 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 IDOrganization UnitOrganization Unit ParentOrganization 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 ServiceUser 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 1X  
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 1X  
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
ActivityActor 1Actor 2Actor 3Actor 4Actor 5Actor 6Actor 7
Activity 1ARC     
Activity 2ARC  CCI
Activity 3AC  RI 
Activity 4    AR  
Activity 5RCAIC  
Activity 6CCI CARI

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 1X  
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 CategoryBusiness FunctionBusiness Service GroupBusiness 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 IdInformation Subject AreaInformation 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 IDInformation Subject Area 1Information Subject Area 2Information Subject Area CardinalityInformation 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 IDBusiness ObjectBusiness 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 IDBusiness Object 1Business Object 2Business Object CardinalityBusiness 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 AreaUser 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 ComponentTitle* ComponentReference ID*Title*SubjectConfiden­tiality Classi­ficationIntegrity Classi­ficationAvailability 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 IDLogical Data EntityLogical 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 EntityLogical Data Entity CharacteristicLogical 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 EntityLogical Data Entity AttributeLogical 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 IDLogical Data Entity 1Logical Data Entity 2Logical Data Entity CardinalityLogical 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 IDApplication ServiceApplication 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 ServiceApplication Service CharacteristicApplication 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 NameContract IDDefinitionIS Service 1IS 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 ServicesUser 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* ComponentTitle* ComponentReference ID*Title*SubjectConfiden­tiality Classi­ficationIntegrity Classi­ficationAvailability 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 IDLogical 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 CharacteristicLAC 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 IDLAC ContractLogical Application Component 1Logical Application Component 2LAC 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 ContractLAC Contract CharacteristicLAC 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 IDPhysical Application Component (PAC)Physical Application Component (PAC) DescriptionImplementation FeaturesTechnical 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 IDInfrastructure ServiceInfrastructure 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 ServiceInfrastructure Service CharacteristicInfrastructure 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 NameContract IDDefinitionIS Service 1IS 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 ServicesUser 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 IDLogical 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 CharacteristicLIC 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 IDLogical Infrastructure Component 1Logical Infrastructure Component 2LIC 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 ContractLIC Contract CharacteristicLIC 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 IDPhysical Infrastructure Component (PIC)Physical Infrastructure Component (PIC) DescriptionImplementation FeaturesTechnical 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 NameDescriptionTypeBaseline Specification:
Policy Reference
    
    

7                  Rationale and Justification for Architectural Approach

7.1            Rationale

7.2            Approach

7.3            Architecture Decisions

IDDecision ItemDecision MadeCompletion DateSourceOwner/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) IDBusiness Function CategoryBusiness FunctionBusiness 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) IDBusiness Service CategoryBusiness ServiceBusiness Service Description
    
    

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

Capability IDCapabilityBusiness 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 ServiceBusiness Service CharacteristicBusiness 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 IDBusiness Service ContractBusiness Service 1Business Service 2Business 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 ContractBusiness Service Contract CharacteristicBusiness 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*SubjectConfidentiality ClassificationIntegrity ClassificationAvailability 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 IDOrganization UnitOrganization Unit ParentOrganization Unit Description
    
    
    
Org. Comp Business Service  Org. Comp 1  Org. Comp 2  Org. Comp 3
BS 1X  
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 1X  
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 1X 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 1X 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 1X  
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 ActorsThird-Party
Actors
Implementation Actors
ActivityActor 1Actor 2Actor 3Actor 4Actor 5Actor 6Actor 7
Activity 1ARC     
Activity 2ARC  CCI
Activity 3AC  RI 
Activity 4    AR  
Activity 5RCAIC  
Activity 6CCI CARI

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 1X  
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 CategoryBusiness FunctionBusiness Service GroupBusiness 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 1X 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 IDInformation Subject AreaInformation 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 IDInformation Subject Area 1Information Subject Area 2Information Subject Area CardinalityInformation 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 IDBusiness ObjectBusiness 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 IDBusiness Object 1Business Object 2Business Object CardinalityBusiness 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* ComponentTitle* ComponentReference ID*Title*SubjectConfiden­tiality Classi­ficationIntegrity Classi­ficationAvailability 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 IDLogical Data EntityLogical 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 EntityLogical Data Entity CharacteristicLogical 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 EntityLogical Data Entity AttributeLogical 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 IDLogical Data Entity 1Logical Data Entity 2Logical Data Entity CardinalityLogical 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 IDApplication ServiceApplication Service Description
   
   

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

Capability IDCapabilityBusiness ServiceApplication 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 ServiceApplication Service CharacteristicApplication 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 IDCAS ContractLogical Application Service 1Logical Application Service 2CAS 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 ContractCAS Contract CharacteristicCAS 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 ComponentTitle* ComponentReference ID*Title*SubjectConfiden­tiality Classi­ficationIntegrity Classi­ficationAvailability 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 IDLogical 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 CharacteristicLAC 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 IDLAC ContractLogical Application Component 1Logical Application Component 2LAC 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 ContractLAC Contract CharacteristicLAC 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/ProductComponentConsiderations
   
   

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 IDInfrastructure ServiceInfrastructure 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 ServiceInfrastructure Service CharacteristicInfrastructure 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 IDCIS ContractLogical Infrastructure Component 1Logical Infrastructure Component 2LIC 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 ContractCIS Contract CharacteristicCIS 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 IDLogical 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 CharacteristicLIC 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 IDLIC ContractLogical Infrastructure Component 1Logical Infrastructure Component 2LIC 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 ContractLIC Contract CharacteristicLIC 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/ProductComponentConsiderations
   
   

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

How do you interpret Domains, Control Objectives and Controls in ISO 27001 standard?

ISO 27001 has for the moment 11 Domains, 39 Control Objectives and 130+ Controls. Following is a list of the Domains and Control Objectives.

1. Security policy
Information security policy
Objective: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.
2. Organization of information security
Internal organization
Objective: To manage information security within the organization.
External parties
Objective: To maintain the security of the organization’s information and information processing facilities that are accessed, processed, communicated to, or managed by external parties.

3. Asset management
Responsibility for assets
Objective: To achieve and maintain appropriate protection of organizational assets.
Information classification
Objective: To ensure that information receives an appropriate level of protection.

4. Human resources security
Prior to employment
Objective: To ensure that employees, contractors and third party users understand their responsibilities, and are suitable for the roles they are considered for, and to reduce the risk of theft, fraud or misuse of facilities.
During employment
Objective: To ensure that all employees, contractors and third party users are aware of information security threats and concerns, their responsibilities and liabilities, and are equipped to support organizational security policy in the course of their normal work, and to reduce the risk of human error.
Termination or change of employment
Objective: To ensure that employees, contractors and third party users exit an organization or change employment in an orderly manner.

5. Physical and environmental security
Secure areas
Objective: To prevent unauthorized physical access, damage and interference to the organization’s premises and information.
Equipment security
Objective: To prevent loss, damage, theft or compromise of assets and interruption to the organization’s activities.

6. Communications and operations management
Operational procedures and responsibilities
Objective: To ensure the correct and secure operation of information processing facilities.
Third party service delivery management
Objective: To implement and maintain the appropriate level of information security and service delivery in line with third party service delivery agreements.
System planning and acceptance
Objective: To minimize the risk of systems failures.
Protection against malicious and mobile code
Objective: To protect the integrity of software and information.
Back-up
Objective: To maintain the integrity and availability of information and information processing facilities.
Network security management
Objective: To ensure the protection of information in networks and the protection of the supporting infrastructure.
Media handling
Objective: To prevent unauthorized disclosure, modification, removal or destruction of assets, and interruption to business activities.
Exchange of information
Objective: To maintain the security of information and software exchanged within an organization and with any external entity.
Electronic commerce services
Objective: To ensure the security of electronic commerce services, and their secure use.
Monitoring
Objective: To detect unauthorized information processing activities.

7. Access control
Business requirement for access control
Objective: To control access to information.
User access management
Objective: To ensure authorized user access and to prevent unauthorized access to information systems.
User responsibilities
Objective: To prevent unauthorized user access, and compromise or theft of information and information processing facilities.
Network access control
Objective: To prevent unauthorized access to networked services.
Operating system access control
Objective: To prevent unauthorized access to operating systems.
Application and information access control
Objective: To prevent unauthorized access to information held in application systems.
Mobile computing and teleworking
Objective: To ensure information security when using mobile computing and teleworking facilities.

8. Information systems acquisition, development and maintenance
Security requirements of information systems
Objective: To ensure that security is an integral part of information systems.
Correct processing in applications
Objective: To prevent errors, loss, unauthorized modification or misuse of information in applications.
Cryptographic controls
Objective: To protect the confidentiality, authenticity or integrity of information by cryptographic means.
Security of system files
Objective: To ensure the security of system files.
Security in development and support processes
Objective: To maintain the security of application system software and information.
Technical Vulnerability Management
Objective: To reduce risks resulting from exploitation of published technical vulnerabilities.

9. Information security incident management
Reporting information security events and weaknesses
Objective: To ensure information security events and weaknesses associated with information systems are communicated in a manner allowing timely corrective action to be taken.
Management of information security incidents and improvements
Objective: To ensure a consistent and effective approach is applied to the management of information security incidents.

10. Business continuity management
Information security aspects of business continuity management
Objective: To counteract interruptions to business activities and to protect critical business processes from the effects of major failures of information systems or disasters and to ensure their timely resumption.

11. Compliance
Compliance with legal requirements
Objective: To avoid breaches of any law, statutory, regulatory or contractual obligations, and of any security requirements.
Compliance with security policies and standards, and technical compliance
Objective: To ensure compliance of systems with organizational security policies and standards.
Information systems audit considerations
Objective: To maximize the effectiveness of and to minimize interference to/from the information systems audit process.

What is “The Open Group Architecture Framework (TOGAF)”?

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.

PCI SSC [Payment Card Industry Security Standard Council]Data Security Standards Overview

The PCI Security Standards Council offers robust and comprehensive standards and supporting materials to enhance payment card data security. These materials include a framework of specifications, tools, measurements and support resources to help organizations ensure the safe handling of cardholder information at every step. The keystone is the PCI Data Security Standard (PCI DSS), which provides an actionable framework for developing a robust payment card data security process — including prevention, detection and appropriate reaction to security incidents.

Tools to assist organizations validate their PCI DSS compliance include Self Assessment Questionnaires. The chart linked here shows some of the tools available to help organizations become PCI DSS-compliant.

For device vendors and manufacturers, the Council provides the PIN Transaction Security (PTS) requirements, which contains a single set of requirements for all personal identification number (PIN) terminals, including POS devices, encrypting PIN pads and unattended payment terminals. A list of approved PIN transaction devices can be accessed here.

To help software vendors and others develop secure payment applications, the Council maintains the Payment Application Data Security Standard (PA-DSS) and a list of Validated Payment Applications.

The Council also provides training to professional firms and individuals so that they can assist organizations with their compliance efforts. The Council maintains public resources such as lists of Qualified Security Assessors (QSAs), Payment Application Qualified Security Assessors (PA-QSAs), and Approved Scanning Vendors (ASVs). Large firms seeking to educate their employees can take advantage of the Internal Security Assessor (ISA) education program.

General audit terms defined in ISO 27001

  • Audit – the process by which a subject area is independently reviewed and reported on by one or more competent auditors on behalf of stakeholders
  • Audit checklist – a structured questionnaire or workplan to guide the auditors in testing the area being audited
  • Audit evidence – information gathered from the area being audited such as written documentation, computer printouts, interviews and observation
  • Audit finding – the auditor’s summary/description and analysis of an inadequately mitigated risk to the organization
  • Audit observation – an optional or advisory audit recommendation which carries less weight than an audit recommendation
  • Audit plan or programme – a project plan for an audit laying out the main audit activities and heir timing
  • Audit recommendation – a corrective action that is proposed to address one or more identified audit findings, that must be addressed prior to certification or recertification of the ISMS
  • Audit report – a formal report to management documenting the key findings and conclusions of the audit
  • Audit risk – the potential for an audit to fail to meet its objectives, for example by using unreliable, incomplete or inaccurate information
  • Audit schedule – a diary of planned audits
  • Audit subject – the in-scope organization/s, or parts of an organization, which are being audited
  • Audit test – a check conducted by the auditors to verify whether a control is effective, efficient and adequate to mitigate one or more risks to the organization
  • Audit work papers – documents written by the auditors recording their examination, findings and analysis of the ISMS, including completed audit checklists
  • Compliance audit – a type of audit specifically designed to assess the extent to which the audit subject conforms to stated requirements
  • ISMS audit – an audit centred on the organization’s Information Security Management System (ISMS)
  • Risk-based audit – an audit planned on the basis of an assessment of risks

Are you for ISO/IEC 27001:2013? Self Assessment

1. The organization and its context…
-Have the internal and external issues that are relevant to the ISMS, and that impact on the achievement of its expected outcome, been determined?

2. Needs and expectations of interested parties
-Has the organization determined the interested parties that are relevant to the ISMS?
-Have the requirements of these interested parties been determined, including legal, regulatory and contractual requirements?

3. Scope of the ISMS
-Have the boundaries and applicability of the ISMS been determined to establish its scope, taking into consideration the external and internal issues, the requirements of interested parties and the interfaces and dependencies with other organizations?
-Is the scope of the ISMS documented?

4. Leadership and management commitment
Is the organization’s leadership commitment to the ISMS demonstrated by:
• Establishing the information security policy and objectives, in consideration of the strategic direction of the organization, and in promotion of continual improvement?
• Ensuring the integration of the ISMS requirements into its business processes?
• Ensuring resources are available for the ISMS, and directing and supporting individuals, including management, who contribute to its effectiveness?
• Communicating the importance of effective information security and conformance to ISMS requirements?

5. Information security policy
-Is there an established information security policy that is appropriate, gives a framework for setting objectives, and demonstrates commitment to meeting requirements and for continual improvement?
-Is the policy documented and communicated to employees and relevant interested parties?
6. Roles and responsibilities
-Are the roles within the ISMS clearly defined and communicated?
-Are the responsibilities and authorities for conformance and reporting on ISMS performance assigned?

7. Risks and opportunities of ISMS implementation
-Have the internal and external issues, and the requirements of interested parties been considered to determine the risks and opportunities that need to be addressed to ensure that the ISMS achieves its outcome, that undesired effects are prevented or reduced, and that continual improvement is achieved?
-Have actions to address risks and opportunities been planned, and integrated into the ISMS processes, and are they evaluated for effectiveness?

8. Information security risk assessment
-Has an information security risk assessment process that establishes the criteria for performing information security risk assessments, including risk acceptance criteria been defined?
-Is the information security risk assessment process repeatable and does it produce consistent, valid and comparable results?
-Does the information security risk assessment process identify risks associated with loss of confidentiality, integrity and availability for information within the scope of the ISMS, and are risk owners identified?
-Are information security risks analysed to assess the realistic likelihood and potential consequences that would result, if they were to occur, and have the levels of risk been determined?
-Are information security risks compared to the established risk criteria and prioritised?
-Is documented information about the information security risk assessment process available?

9. Information security risk treatment
-Is there an information security risk treatment process to select appropriate risk treatment options for the results of the information security risk assessment, and are controls determined to implement the risk treatment option chosen?
-Have the controls determined, been compared with ISO/IEC 27001:2013 Annex A to verify that no necessary controls have been missed?
-Has a Statement of Applicability been produced to justify Annex A exclusions, and inclusions together with the control implementation status?
-Has an information security risk treatment plan been formulated and approved by risk owners, and have residual information security risks been authorised by risk owners?
-Is documented information about the information security risk treatment process available?

10. Information security objectives and planning to achieve them
-Have measurable ISMS objectives and targets been established, documented and communicated throughout the organization?
-In setting its objectives, has the organization determined what needs to be done, when and by whom?

11. ISMS resources and competence
-Is the ISMS adequately resourced?
-Is there a process defined and documented for determining competence for ISMS roles?
-Are those undertaking ISMS roles competent, and is this competence documented appropriately?

12. Awareness and communication
-Is everyone within the organization’s control aware of the importance of the information security policy, their contribution to the effectiveness of the ISMS and the implications of not conforming?
-Has the organization determined the need for internal and external communications relevant to the ISMS, including what to communicate, when, with whom, and who by, and the processes by which this is achieved?

13. Documented information
-Has the organization determined the documented information necessary for the effectiveness of the ISMS?
-Is the documented information in the appropriate format, and has it been identified, reviewed and approved for suitability?
-Is the documented information controlled such that it is available and adequately protected, distributed, stored, retained and under change control, including documents of external origin required by the organization for the ISMS?

14. Operational planning and control
-Has a programme to ensure the ISMS achieves its outcomes, requirements and objectives been developed and implemented?
-Is documented evidence retained to demonstrate that processes have been carried out as planned?
-Are changes planned and controlled, and unintended changes reviewed to mitigate any adverse results?
-Have outsourced processes been determined and are they controlled?
-Are information security risk assessments performed at planned intervals or when significant changes occur, and is documented information retained?
-Has the information security risk treatment plan been implemented and documented information retained?

15. Monitoring, measurement and evaluation
-Is the information security performance and effectiveness of the ISMS evaluated?
-Has it been determined what needs to be monitored and measured, when, by whom, the methods to be used, and when the results will be evaluated?
-Is documented information retained as evidence of the results of monitoring and measurement?

16. Internal audit
-Are internal audits conducted periodically to check that the ISMS is effective and conforms to both ISO/IEC 27001:2013 and the organization’s requirements?
-Are the audits conducted by an appropriate method and in line with an audit programme based on the results of risk assessments and previous audits?
-Are results of audits reported to management, and is documented information about the audit programme and audit results retained?
-Where non conformities are identified, are they subject to corrective action (see section 18)?

17. Management review
-Do top management undertake a periodic review of the ISMS?
-Does the output from the ISMS management review identify changes and improvements?
-Are the results of the management review documented, acted upon and communicated to interested parties as appropriate?

18. Corrective action and continual improvement
-Have actions to control, correct and deal with the consequences of non-conformities been identified?
-Has the need for action been evaluated to eliminate the root cause of non-conformities to prevent reoccurrence?
-Have any actions identified been implemented and reviewed for effectiveness and given rise to improvements to the ISMS?
-Is documented information retained as evidence of the nature of non-conformities, actions taken and the results?

19. Security controls – as applicable, based on the results of your information security risk assessment
-Are information security policies that provide management direction defined and regularly reviewed?
-Has a management framework been established to control the implementation and operation of security within the organization, including assignment of responsibilities and segregation of conflicting duties?
-Are appropriate contacts with authorities and special interest groups maintained?
-Is information security addressed in Projects?
-Is there a mobile device policy and teleworking policy in place?
-Are human resources subject to screening, and do they have terms and conditions of employment defining their information security responsibilities?
-Are employees required to adhere to the information security policies and procedures, provided with awareness, education and training, and is there a disciplinary process?
-Are the information security responsibilities and duties communicated and enforced for employees who terminate or change employment?
-Is there an inventory of assets associated with information and information processing, have owners been assigned, and are rules for acceptable use of assets and return of assets defined?
-Is information classified and appropriately labelled, and have procedures for handling assets in accordance of their classification been defined?
-Are there procedures for the removal, disposal and transit of media containing information?
-Has an access control policy been defined and reviewed, and is user access to the network controlled in line with the policy?
-Is there a formal user registration process assigning and revoking access and access rights to systems and services, and are access rights regularly reviewed, and removed upon termination of employment?
-Are privileged access rights restricted and controlled, and is secret authentication information controlled, and users made aware of the practices for use?
-Is access to information restricted in line with the access control policy, and is access controlled via a secure log-on procedure?
-Are password management systems interactive and do they enforce a quality password?
-Is the use of utility programs and access to program source code restricted?
-Is there a policy for the use of cryptography and key management?
-Are there policies and controls to prevent unauthorised physical access and damage to information and information processing facilities?
-Are there policies and controls in place to prevent loss, damage, theft or compromise of assets and interruptions to operations?
-Are operating procedures documented and are changes to the organization, business processes and information systems controlled?
-Are resources monitored and projections made of future capacity requirements?

-Is there separation of development, testing and operational environments?
-Is there protection against malware?
-Are information, software and systems subject to back up and regular testing?
-Are there controls in place to log events and generate evidence?
-Is the implementation of software on operational systems controlled, and are there rules governing the installation of software by users?
-Is information about technical vulnerabilities obtained and appropriate measures taken to address risks?
-Are networks managed, segregated when necessary, and controlled to protect information systems, and are network services subject to service agreements?
-Are there policies and agreements to maintain the security of information transferred within or outside of the organization?
-Are information security requirements for information systems defined and is information passing over public networks and application service transactions protected?
-Are systems and rules for the development of software established and changes to systems within the development lifecycle formally controlled?
-Are business critical applications reviewed and tested after changes to operating system platforms and are there restrictions to changes to software packages?
-Have secure engineering principles been established and are they maintained and implemented, including secure development environments, security testing, the use of test data and system acceptance testing?
-Is outsourced software development supervised and monitored?

-Are there policies and agreements in place to protect information assets that are accessible to suppliers, and is the agreed level of information security and service delivery monitored and managed, including changes to provision of services?
-Is there a consistent approach to the management of security incidents and weaknesses, including assignment of responsibilities, reporting, assessment, response, analysis and collection of evidence?

-Is information security continuity embedded within the business continuity management system, including determination of requirements in adverse situations, procedures and controls, and verification of effectiveness?
-Are information processing facilities implemented with redundancy to meet availability requirements?
-Have all legislative, statutory, regulatory and contractual requirements and the approach to meeting these requirements been defined for each information system and the organization, including but not limited to procedures for intellectual property rights, protection of records, privacy and protection of personal information and regulation of cryptographic controls?
-Is there an independent review of information security?
-Do managers regularly review the compliance of information processing and procedures within their areas of responsibility?
-Are information systems regularly reviewed for technical compliance with policies and standards?

The role of Enterprise Architecture

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.

Developing an Enterprise Level Architectural Description

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.

Why Produce an Enterprise Architecture Model ?

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.

List of Enterprise Application Architecture Patterns

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

Example/sample ISO/IEC 27001:2013 ISMS scoping statements

Sample 1

The Information Security Management System (ISMS) applies to the provision of trusted and managed information security services to internal and external customers of <ORGANIZATION> in accordance with the ISMS Statement of Applicability revision xx, dated xx-xxx-xxxx

Sample 2

As stated in the Information Security Management System (ISMS) Statement of Applicability, revision xx, dated xx-xxx-xxxx, the ISMS encompasses <ORGANIZATION>’s Information Technology Division Office, Computer Lab, Storehouse and Computer Classroom, covering business activities relating to the provision of operation, maintenance and management of Internet and Web services and systems.

Sample 3

The provision of e-Business solutions that are fully integrated to deliver the complete process and management of e-Business components including: workflows; contacts; e-mail; bulletin boards; news; events; traffic analysis and audits on a secure hosted platform, 24 hours a day, 365 days a year, as per the Statement of Applicability approved by senior management on xx-XXX-xxxx.

 

Note: be aware that if you narrow the scope of your ISMS, you are also going to:

  • Reduce the implementation costs to some degree, although you will still need to implement a comprehensive management system to be certified compliant to ISO/IEC 27001;
  • Reduce the business benefits compared to a more broadly-scoped ISMS; and
  • Have to define security interfaces for information flows and processes that span or extend beyond the in-scope area to the remainder, since everything outside the scoped area is relatively untrustworthy.

Mandatory requirements for ISO/IEC 27001:2013 certification

Mandatory requirements for certification

ISO/IEC 27001 is a formalized specification for an ISMS with two distinct purposes:

  1. It lays out, at a fairly high level, what an organization can do in order to implement an ISMS;
  2. It can (optionally) be used as the basis for formal compliance assessment by accredited certification auditors in order to certify an organization.

The following mandatory documentation (or rather “documented information” in the curiously stilted language of the standard) is explicitly required for certification:

  1. ISMS scope (as per clause 4.3)
  2. Information security policy (clause 5.2)
  3. Information security risk assessment process (clause 6.1.2)
  4. Information security risk treatment process (clause 6.1.3)
  5. Information security objectives (clause 6.2)
  6. Evidence of the competence of the people working in information security (clause 7.2)
  7. Other ISMS-related documents deemed necessary by the organization (clause 7.5.1b)
  8. Operational planning and control documents (clause 8.1)
  9. The results of the risk assessments (clause 8.2)
  10. The decisions regarding risk treatment (clause 8.3)
  11. Evidence of the monitoring and measurement of information security (clause 9.1)
  12. The ISMS internal audit program and the results of audits conducted (clause 9.2)
  13. Evidence of top management reviews of the ISMS (clause 9.3)
  14. Evidence of nonconformities identified and corrective actions arising (clause 10.1)
  15. Various others: Annex A, which is normative, mentions but does not fully specify further documentation including the rules for acceptable use of assets, access control policy, operating procedures, confidentiality or non-disclosure agreements, secure system engineering principles, information security policy for supplier relationships, information security incident response procedures, relevant laws, regulations and contractual obligations plus the associated compliance procedures and information security continuity procedures.

Certification auditors will almost certainly check that these fifteen types of documentation are (a) present, and (b) fit for purpose.  The standard does not specify precisely what form the documentation should take, but section 7.5.2 talks about aspects such as the titles, authors, formats, media, review and approval, while 7.5.3 concerns document control, implying a fairly formal ISO 9000-style approach.

Structure of the ISO/IEC 27001:2013 standard

ISO/IEC 27001:2013 has the following sections:

0  Introduction – the standard uses a process approach.

1  Scope – it specifies generic ISMS requirements suitable for organizations of any type, size or nature.

2  Normative references – only ISO/IEC 27000 is considered absolutely essential to users of ’27001: the remaining ISO27k standards are optional.

3  Terms and definitions – a brief, formalized glossary, soon to be superseded by ISO/IEC 27000.

4  Context of the organization – understanding the organizational context, the needs and expectations of ‘interested parties’, and defining the scope of the ISMS.  Section 4.4 states very plainly that “The organization shall establish, implement, maintain and continually improve” a compliant ISMS.

5  Leadership – top management must demonstrate leadership and commitment to the ISMS, mandate policy, and assign information security roles, responsibilities and authorities.

6  Planning – outlines the process to identify, analyze and plan to treat information security risks, and clarify the objectives of information security.

7  Support – adequate, competent resources must be assigned, awareness raised, documentation prepared and controlled.

8  Operation – a bit more detail about assessing and treating information security risks, managing changes, and documenting things (partly so that they can be audited by the certification auditors).

9  Performance evaluation – monitor, measure, analyze and evaluate/audit/review the information security controls, processes and management system in order to make systematic improvements where appropriate.

10  Improvement – address the findings of audits and reviews (e.g. nonconformities and corrective actions), make continual refinements to the ISMS

Annex A  Reference control objectives and controls – little more in fact than a list of titles of the control sections in ISO/IEC 27002.  The annex is ‘normative’, implying that certified organizations are expected to use it, but they are free to deviate from or supplement it in order to address their particular information security risks.

Bibliography – points readers to five related standards, plus part 1 of the ISO/IEC directives, for more information.  In addition, ISO/IEC 27000 is identified in the body of the standard as a normative (i.e. essential) standard and there are several references to ISO 31000 on risk management.

Why Enterprise Storage? How to deploy on-premise Enterprise Storage?

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.

 Terms frequently associated with enterprise storage include storage networking, which is the linking of storage devices with each other and other computer systems, and storage management, which includes technology and processes that help organizations control and maintain their storage systems.
Enterprise Storage Implementation
When you decide to deploy a new enterprise storage system, you face a number of choices. First, you must decide whether to design and build your own storage system or to utilize a cloud-based storage service. If you decide to use a cloud computing service, you won’t have to make very many decisions about the hardware and network architecture, because the cloud vendor will handle those for you. Generally, the deployment steps for cloud storage will be fairly simple: Select a cloud service that meets your needs, sign up for the service and configure it to work with your existing applications and networks. Your most important task will be researching the services to make sure that you get one that can meet your needs and work with your current infrastructure.
How to deploy on-premise Enterprise Storage?

The following three steps for deploying on-premises storage networks involve setting up the physical hardware and cables, migrating data (if necessary), configuring the devices and testing the system.

1) Choose a Storage Media

If you decide to build your own storage system, you’ll have to make some additional decisions .For example, you’ll need to select which storage media to use: Tape, hard disk drives (HDDs) or solid state drives (SSDs). Tape is the least expensive medium, but its performance and capabilities generally make it suitable only for backup and archive applications. HDDs are more expensive than tape, but they offer the higher performance necessary for primary storage. SSDs cost the most of all, but they offer much better performance and reliability than either tape or HDDs. Many organizations use a mix of tape, HDDs and SSDs, and some storage devices themselves include a mix of HDDs and SSDs.

2) Choose a Storage Architecture

You’ll also need to decide on your storage architecture. Enterprise storage can include direct-attached storage (DAS), storage area networks (SANs) or network-attached storage (NAS) devices. DAS devices connect directly to an individual PC or server and don’t offer the same collaboration capabilities as networked storage. However, you do gain collaboration benefits from SAN and NAS devices. SANs provide block-level storage for access by servers, while NAS devices offer file-level storage for access by end users. Many organizations use a combination of DAS, NAS and SAN devices.

3) Choose a Network Protocol

You’ll also need to choose which network protocol you’ll use. Your options include the Internet Protocol Suite (TCP/IP), Fibre Channel Protocol (FCP) and Internet SCSI (iSCSI) protocol. The type of storage architecture you select will impact which network protocol(s) you can use. For example, Fibre Channel and iSCSI are SAN protocols, while NAS is an IP storage protocol. Fibre Channel over Ethernet (FCoE) has emerged as one way for Ethernet and Fibre Channel networks to converge.

 

Integration is the biggest challenge of Enterprise Architecture

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.

Gartner Identifies Ten Enterprise Architecture Pitfalls

“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.”

Top IT Service Management challenges…

  1. IT cost transparency. Something has still got to give in terms of what IT costs — IT is and will continue to be a sizable expense to the business. The IT organization is spending the business’ money, and so the business wants to know whether it is being spent wisely (and who can blame them). How many IT shops know if they are investing the business’ money wisely outside of projects?
  2. Value demonstration. Is IT still just a cost center or has your IT organization been able to translate IT investment into demonstrable business success? I still rather somewhat cheekily say that “if we could demonstrate the business value derived from IT, surely we would be being asked to spend more rather than having to respond to corporately mandated, quick fix, end-of-year budget cuts.”
  3. Agility. The speed of business change continues to dictate a rapid response from IT that many struggle with — as a simple example, yesterday my nephew told me of his five-week wait for a laptop at the bank he recently joined. Not only is it speed and flexibility, it is also “agility of mind.” A change in I&O mindset that asks “why not?” rather than “why?”
  4. Availability. Nothing new here (again). The business needs high quality, highly available IT (or business) services. The difference is in business expectations and available alternatives. For a number of reasons, the business continues to be less forgiving of IT failure and, again, who can blame them.
  5. “Personal hardware.”  End user devices will continue to be a big challenge for IT in 2013. Whether it is the fact that our “internal customers” are unhappy with their “outdated” corporate laptops or the fact that they can’t have corporate iPads or the whole “can of worms” that is BYOD (bring your own device), personal productivity hardware will again be a battleground of business discontent in 2013.
  6. Support and customer service. For me, support is one thing and customer service is another; ideally IT delivers both. That it is ultimately about supporting the consumption of IT services by people rather than just supporting the technology that delivers the IT services. And that service-centricity by frontline IT staff is not enough; it needs to be all IT staff. The same is true for customer-centricity.
  7. Cloud. As cloud adoption continues, are we looking at cloud as a technical or business solution, or both? Do we know enough about the status quo to make informed decisions about moving IT services to the cloud? Probably not; yet for many, cloud is the answer. But I still can’t help think that we haven’t really taken the time to fully understand the question.
  8. Mobility. BYOD comes into play here again, but I think that a bigger issue is at hand — that we are still technology-centric. We all hear talk about MDM (mobile device management) as “THE big issue.” IMO, however, this is old-skool-IT with the device a red herring and of little interest to the customer (unless IT is providing outdated devices). Your customers want (or at least we hope that they continue to want) to access your services any which way they can and need to. Mobility is about people.
  9. Compliance. Whether it’s internal or external regulatory compliance (or governance), most of the above will potentially have a negative knock on to compliance whether it be SOX, software compliance, or meeting internal requirements for “transparency and robustness.” With everything going on elsewhere, it is easy for me to imagine degradation in internal control, not reacting to new risks as a minimum.

How can organisations using ITIL adapt for Cloud Services?

The first point to make here, is that ITIL is, and will continue to be, an IT Service Management toolkit.

That means that you don’t have to be using ALL of ITIL, ALL of the time – the methodology can be adapted to suit the needs of organisations – the key thing is to put your organisational requirements first, and not follow bureaucracy for the sake of it.

Second, ITIL has been formed on IT Service Management best practice and will continue to evolve to reflect the needs of IT departments the world over.

Public vs Private Clouds:

Well run IT service Management systems have always had to apply different models to different systems – they will continue to evolve, The focus if IT teams will have to move away from operational aspects of infrastructure to managing the diverse environments that public, private and hybrid Cloud environments will bring.

Configuration Management Database:

Anyone who uses ITIL will know the importance of the CMDB – however doesn’t necessarily mean inflexibility. A well implemented CMDB can make things more agile in fact.

No doubt, the way organisations use the configuration management database will need to be tweaked for Cloud – however the message is the same – use ITIL as part of a sensible and flexible IT Service Management infrastructure and you will be able to account for any changes that new technology brings.

 

What issues does ITIL face with Cloud Computing?

Some of the problems that ITIL will face with Cloud Computing include:

  • Because Cloud and SaaS apps are based on a pay-as-you-go model, they have the potential to operate under the radar of ‘traditional’ IT service management infrastructure – particularly with relation to procurement
  • Dealing with Private and Public cloud services will require different approaches. Public clouds are great in terms of their cost savings but cab be less reliable, especially when you look at security, compliance and service level agreements. These problems are not there with Private cloud services – but they don’t come cheap. As a result, many organisations use hybrid services.
  • ITIL’s configuration management database (CMDB) – is designed to hold information about  assets and resources that exist in an IT environment – what happens when those resources don’t physically exist any more?!