Enterprise Architecture

What is an Enterprise An “enterprise” is any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership. The term "enterprise" in the context of "enterprise architecture" can be used to denote: an entire enterprise encompassing all of its information and technology services, processes, and infrastructure a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.

Why do I need an enterprise architecture? The purpose of enterprise architecture is to optimize processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy. An enterprise architecture provides effective management and exploitation of information through IT This is by developing the IT system in response to the constantly changing needs of the business environment. A good enterprise architecture enables you to achieve the right balance between IT efficiency and business innovation.

Why do I need an enterprise architecture? A more efficient business operation; for example: Lower business operation costs More flexible workforce A more efficient IT operation; for example: Lower software development, support, and maintenance costs Increased portability of applications Improved ability to address critical enterprise-wide issues like security

Why do I need an enterprise architecture? Better return on existing investment, reduced risk for future investment; for example: Reduced complexity in the business and IT Maximum return on investment in existing business and IT infrastructure Reduced risk overall in new investments and their cost of ownership Faster, simpler, and cheaper procurement; for example: Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan The procurement process is faster - maximizing procurement speed and flexibility without sacrificing architectural coherence

What specifically would prompt me to develop an enterprise architecture? An enterprise architecture is developed for: preparation for business transformation needs or preparation for radical infrastructure changes. Often key people identify areas of change (required in order for new business goals to be met). Such people are commonly referred to as the "stakeholders". The role of the architect is to address stakeholders concerns by: Identifying and refining the requirements that the stakeholders have Developing views of the architecture that show how the concerns and requirements are going to be addressed Showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different stakeholders Without the enterprise architecture, it is highly unlikely that all the concerns and requirements will be considered and met.

What is an architecture framework? An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should include a list of recommended standards and compliant products that can be used to implement the building blocks.

What is TOGAF? TOGAF (The Open Group Architecture Framework) is a framework with a detailed method and a set of supporting tools for developing an enterprise architecture. In this course we will use TOGAF architecture framework when discussing enterprise architecture TOGAF provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. TOGAF is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets.

What is Architecture in the Context of TOGAF? In TOGAF, "architecture" has two meanings depending upon the context: A formal description of a system, or a detailed plan of the system at component level to guide its implementation The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

What Kind of Architecture Does TOGAF Deal With? There are four architecture domains that are commonly accepted as subsets of an overall enterprise architecture, all of which TOGAF is designed to support: 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. 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. The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.

Architecture Development Method (ADM) The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for developing architectures. The ADM includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures. All of these activities are carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities

Architecture Development Method (ADM) Phases within the ADM are as follows: The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability. Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development. Phase B: Business Architecture Phase C: Information Systems Architectures Phase D: Technology Architecture

Architecture Development Method (ADM) Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery for the architecture defined in the previous phases. Phase F: Migration Planning addresses how to move from the Baseline Architecture (current architecture) to the Target Architectures by finalizing a detailed Implementation and Migration Plan. Phase G: Implementation Governance provides an architectural oversight of the implementation. Phase H: Architecture Change Management establishes procedures for managing change to the new architecture. Requirements Management examines the process of managing architecture requirements throughout the ADM

Architecture Development Method (ADM)

Architecture output Architects executing the ADM will produce a number of outputs as a result of their efforts, such as process flows, architectural requirements, project plans, project compliance assessments, etc. The TOGAF Architecture Framework provides a structural model for architectural content that allows major work products to be consistently defined, structured, and presented. The Architecture Framework uses three categories to describe the type of architectural work product: deliverables, artifacts and building blocks.

Deliverables, Artifacts, and Building Blocks A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects. An artifact is an architectural work product that describes an aspect of the architecture. Artifacts are generally classified as catalogs (lists of things), matrices (showing relationships between things), and diagrams (pictures of things). Examples include a requirements catalog, business interaction matrix, and a use-case diagram. An architectural deliverable may contain many artifacts The artifacts form the content of the Architecture Repository. A building block represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions.

Building Blocks Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance: at an early stage, a building block can simply consist of a name or an outline description. later on, a building block may be decomposed into multiple supporting building blocks and may be accompanied by a full specification. Building blocks can relate to "architectures" or "solutions". Architecture Building Blocks (ABBs) describe required capability and shape the specification of Solution Building Blocks (SBBs). For example, a customer services capability may be required within an enterprise, supported by many SBBs, such as processes, data, and application software. Solution Building Blocks (SBBs) represent components that will be used to implement the required capability. For example, a network is a building block that can be described through complementary artifacts and then put to use to realize solutions for the enterprise.