Day 1

Enterprise

• The TOGAF Standard considers an “enterprise” to be any collection of organizations that have common goals.
• The term “Enterprise” in the context of “Enterprise Architecture” can be applied to either an entire enterprise, or to one or more specific areas of interest within the enterprise.
• An enterprise may include partners, suppliers, and customers as well as internal business units.

Examples

• A whole corporation or a division of a corporation
• A government agency or a single government department
• A chain of geographically distant organizations linked together by common ownership
• Groups of countries, governments, or governmental organizations (such as militaries) working together to create common or shareable deliverables or infrastructures
• Partnerships and alliances of businesses working together, such as a consortium or supply chain

What is an Enterprise Architecture?

1. It’s the architecture of the enterprise!

   Lets say you wanted to build a house. You would need:

   • Building plans
   • Floor plans
   • Electricity plans
   • Plumbing plans

   To build a business you need:

   • Processes (what is done)
   • Organizations (employees)
   • location
   • Data
   • Applications
   • Technology

   These are usually referred to as P.O.L.D.A.T.; the basic elements of ‘EA’.

2. EA is the mapping of the present and future state of the business

   EA is the plan of transition.

3. EA is a management method

   EA aims to bridge the gap between:

   • Management decision stakeholders
   • Operational teams

What is Enterprise Architecture?

• The process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise’s future state and enable its evolution. (Source: Gartner®)
• A set of abstractions and models that simplify and communicate complex structures, processes, rules, and constraints to improve understanding, implementation, forecasting, and resourcing. (Source: DoDAF)

Purpose of Enterprise Architecture

• It provides a framework for change, linked to both strategic direction and business value, and a sufficient view of the organization to manage complexity, support continuous change, and manage the risk of unanticipated consequences.
• It enables the achievement of the right balance between business transformation and continuous operational efficiency.
• A good Enterprise Architecture facilitates effective governance, management, risk management, and exploitation opportunities.

Why is it Important?

• An Enterprise Architecture is developed to guide effective change. Guidance on effective change will take place during the activity to realize the approved Enterprise Architecture.
• During implementation, Enterprise Architecture is used by the stakeholders to govern change.

Key Benefits - More Effective

More effective strategic decision-making by C-Level executives and business leaders:

• Support for quick responses to change and support for enterprise agility

More effective and efficient business operations:

• Lower operational costs due to capabilities share across the organization

More effective and efficient Digital Transformation and operations:

• Bringing components of the enterprise into a harmonized environment

Key Benefits - ROI and Procurement

Better return on existing investment, reduced risk for future investment:

• Reducing complexity, maximizing return on investment

Faster, simpler, and cheaper procurement:

• Information governing procurement is more readily available

Key Benefits - Balancing Conflicting Demands

• A good EA enables the sponsors and the enterprise as a whole to achieve the right balance across conflicting demands.
• Without the EA, it is highly unlikely that all the concerns and requirements will be considered and addressed with an appropriate trade-off.

The TOGAF® Standard and the TOGAF® Library

A Framework Suitable for EA

• The TOGAF Standard is suitable for EA since it plays an important role in standardizing and de-risks the architecture development process.
• It provides a best practice framework for adding value, and enables the organization to build workable and economic solutions which address their business issues and needs.
• Using the TOGAF Standard results in Enterprise Architecture that is consistent, reflects the needs of stakeholders, employs best practice, and gives due consideration both to current requirements and the perceived future needs of the business.

A Framework for Identifying and Implementing Change

Four Architecture Domains

• Business Architecture (Entry point)
• Data Architecture
• Application Architecture
• Technology Architecture

Business and Data Architecture

• The Business Architecture defines the business strategy, governance, organization, and key business processes.
• The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources.

Application Architecture

The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.

Technology Architecture

The Technology Architecture describes the digital architecture and the logical software and hardware infrastructure capabilities and standards that are required to support the deployment of business, data, and applications services.

Architecture Abstraction

• An architectural technique for dividing a problem area into smaller problem areas that are easier to model and therefore easier to solve.

• Architecture effort can be divided into abstraction levels to answer the four fundamental questions about an architecture:

  • Why - why is the architecture needed?
  • What - what functionality and other requirements need to be met by the architecture?
  • How - how do we structure the functionality?
  • With what - with what assets shall we implement this structure?

Four Abstraction Levels

1. Contextual
2. Conceptual
3. Logical
4. Physical

Contextual Abstraction

1. Contextual

   • Understanding the environment in which an enterprise operates and the context in which architecture work is planned and executed. It answers why an enterprise undertakes architecture work, what is the scope of work, and the motivation in terms of goals, drivers, and objectives.

   • driver (PESTLE, mergers, aquisitions) > assessent (SWOT)

2. Conceptual

   Decomposing the requirements to understand the problem, and what is needed to address the problem, without unduly focusing on how the architecture will be realized

3. Logical

   Identifying the kinds of business, data, application, and technology components needed to achieve the services identified in the conceptual level. It is about identifying how an architecture can be organized and structured, in an implementation-independent fashion

4. Physical

   The allocation and implementation of physical components to meet the identified logical components. It is about determining with what physical components the logical-level components can be realized.

The Enterprise Continuum

• Library for technical stuff
• The concept of the Enterprise Continuum sets the broader context for an architect and explains how architecture assets can be leveraged and specialized in order to support the requirements of an individual organization.
• It comprises two complementary concepts:
  • The Architecture Continuum
  • The Solutions Continuum

• Foundation Architecture: TRM (Technical reference model)
• Common Systems Architecture: III-RM (Integrated information infrastructure reference model)
• Industry Specific Architecture: BIAN (Banking Industry Architecture Network)
• Tailored to Enterprise’s Needs

The Architecture Repository

The TOGAF® Content Framework and Enterprise Metamodel

The Content Framework and Enterprise Metamodel define a formal structure and also provide guidance for organizations that wish to implement their architecture within an architecture tool.

Content Framework

A categorization framework to be used to structure the Architecture Descriptions, the work products used to express an architecture, and the collection of models that describe the architecture; this is referred to as the Content Framework.

Enterprise Metamodel

The Enterprise Metamodel defines the types of entities to appear in the models that describe the enterprise, together with the relationships between these entities. It allows architectural concepts to be captured, stored, filtered, queried, and represented in a way that supports consistency, completeness, and traceability.

• The Enterprise Metamodel is used to structure architectural information in an orderly way so that it can be processed to meet stakeholder needs.
• The TOGAF Enterprise Metamodel provides a good starting point for examining the information the Enterprise Architecture Capability requires.

Content Framework Overview

Architecture Capability (aka EA Capability)

• An Enterprise Architecture Capability is the ability to develop, use, and sustain the architecture of a particular enterprise, and use the architecture to govern change.
• In order to carry out architectural activity effectively within an enterprise, it is necessary to put in place an appropriate business capability for architecture, through organization structures, roles, responsibilities, skills, and processes.

Example: Enterprise Architecture Capability Model

What is expected of an Enterprise Architecture Capability Team?

• Enterprise Architecture is used to describe the future state of an enterprise to guide the change to reach the tuture state.
• The description of the future state enables key people to understand what must be in their enterprise to meet the enterprise’s goals, objective, mission, and vision in the context within which the enterprise operates.
• The gap between the enterprise’s current state and future state highlights what must change within the enterprise.
• This gap is a function of the enterprise context and the scope of changes the enterprise sees.

Risk Management

• The ISO 31000 definition of “risk” is the “effect of uncertainty on objectives”.
• The ISO 31000 definition of risk management is “coordinated activities to direct and control an organization with regard to risk”.
• Risk management is about striking a balance between positive and negative outcomes resulting from the realization of either opportunities or threats.

Risk Management and Mitigation

• There will always be risk with any architecture/business transformation effort.
• It is important to manage risks by identifying, classifying, and mitigating these risks before starting so that they can be tracked throughout the transformation effort.

• Mitigation is an ongoing effort and often the risk triggers may be outside the scope of the transformation planners (e.g., merger, acquisition) so planners must monitor the transformation context constantly.

• There are usually two levels of risk that should be considered:

  1. Initial Level of Risk: Risk categorisation prior to determining and implementing mitigating actions.
  2. Residual Level of Risk: Risk categorisation after implementation of mitigating actions.

• The process for risk management typically includes:

  • Risk identification
  • Risk assessment
  • Risk planning
  • Risk mitigation and residual risk assessment
  • Risk monitoring

“YOU CAN’T ELIMINATE RISK, BUT YOU CAN MANAGE IT INTELLIGENTLY.”

Gap Analysis

• A key step in developing an architecture is to identify changes between the baseline and target architectures using Gap Analysis.
• The Gap Analysis technique is used to consider what may have been forgotten or missed, as well as what is needed.
• A gap is simply everything that changes.

Potential Sources of Gaps

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

Technologies impacted, eliminated, or created

References

• TOGAF-EA-Foundation-M1
• TOGAF-EA-Foundation-Course-Handout-v1.0