Oadp User Guide(031611)

Oracle Architecture Development Process User Guide March 2011

Oracle Architecture Development Process User Guide ____________________________________________________________________________________

ii

Disclaimer The following is intended for information purposes only, and may not be incorporated into any contract. It

is not a commitment to deliver any material, code, or functionality, and should not be relied upon in

making purchasing decisions.


1

1 Executive Overview ...............................................................................................................................2 2 Enterprise Architecture Frameworks .....................................................................................................3 3 Oracle Enterprise Architecture Framework............................................................................................5

3.1 Business Architecture ..................................................................................................................6 3.2 Application Architecture ...............................................................................................................6 3.3 Information Architecture...............................................................................................................7 3.4 Technology Architecture ..............................................................................................................7 3.5 People, Process, and Tools.........................................................................................................8 3.6 Enterprise Architecture Governance ...........................................................................................9 3.7 EA Repository..............................................................................................................................9 3.8 OEAF Relationship to TOGAF...................................................................................................10

4 Oracle Architecture Development Process..........................................................................................11 4.1 Architecture Vision.....................................................................................................................12 4.2 Current State .............................................................................................................................16 4.3 Future State ...............................................................................................................................18 4.4 Strategic Roadmap ....................................................................................................................20 4.5 EA Governance .........................................................................................................................21 4.6 Business Case...........................................................................................................................23 4.7 OADP Relationship to TOGAF ..................................................................................................26

5 OADP and OEAF.................................................................................................................................27 6 Oracle Architecture Development Process Applied to IT Problems ....................................................28 7 Conclusion ...........................................................................................................................................30 8 Appendix ..............................................................................................................................................31

8.1 Discovery Questions..................................................................................................................32


2

1 Executive Overview The Oracle Architecture Development Process is an agile and streamlined method focused on creating

future state architectures for information-driven organizations. It was developed using an agile

architecture mindset where all activities and process steps were oriented towards delivering business

value quickly and repeatedly.

OADP acts as an enabler for change management programs that are focused on aligning business

operations and infrastructure (i.e. people, process and technology) with the business mission and

strategy.

The OADP is a highly iterative and adaptive process that can be applied to develop future state

architectures for individual functional segments in the business (e.g. supply chain, product lifecycle

management, sales and marketing) or to enterprise architecture domains (business, applications,

technology infrastructure, information, governance). The purpose of taking an agile approach to

architecture is to ensure that we are never making assumptions that are too big and therefore, we can

constantly course-correct ourselves to be able to arrive at our desired future state in the most effective

and efficient manner.


3

2 Enterprise Architecture Frameworks Creating an Enterprise Architecture from scratch can be a daunting task, so EA frameworks were created

to simplify the process and guide an architect through all areas of architecture development. An

Enterprise Architecture framework provides a collection of best practices, standards, tools, processes,

and templates to assist in the creation of the Enterprise Architecture and architectures of various scopes.

Enterprise Architecture frameworks typically include:

• Common vocabulary, models, and taxonomy

• Processes, principles, strategies and tools

• Reference architectures and models

• Prescriptive guidance (EA processes, architecture content, implementation roadmap, governance)

• Catalog of architecture deliverables and artifacts

• Enterprise Architecture Content Meta-model

• Recommended set of products and configurations (optional)

Utilizing an Enterprise Architecture framework streamlines the process for creating and maintaining

architectures at all levels (e.g. enterprise architectures, functional business segment architectures, cross-

cutting technology domain architectures, and solution architectures) and enables an organization to

leverage the value of architecture best practices.

A number of EA frameworks exist in the industry with the goal of addressing the basic challenge of

assessing, aligning, and organizing business objectives with technical requirements and strategies.

Examples include the Zachman Enterprise Framework, The Open Group Architecture Framework

(TOGAF), OMB Federal Enterprise Architecture (FEA), and The Gartner Methodology (formerly the Meta

Framework).

Each framework possesses different strengths and weaknesses, which makes it difficult to find any one

existing framework that is ideal for all situations. The following chart depicts how four Enterprise

Architecture Frameworks compare.


4


5

3 Oracle Enterprise Architecture Framework In an effort to provide an efficient, business-driven

framework to help our customers align their IT and

business strategies, Oracle created a hybrid EA

framework, influenced by TOGAF, FEA and Gartner. This

simple yet practical and prescriptive framework is called

the Oracle Enterprise Architecture Framework (OEAF).

The Oracle Enterprise Architecture Framework consists of

seven core components. Each of these seven core

components are explained in the following sections

To further increase the value of OEAF, Oracle also tailors prebuilt reference architectures that define

future state architectures. These proven reference architectures drill down from logical components (for

example, functional capabilities) to physical components (for example, Oracle technologies and products)

that complement a customer’s existing environment and can be used to minimize implementation risks.

The central theme of the Oracle Enterprise Application Framework is to provide “just enough” structure,

which can be created “just in time” to meet the business requirements of the organization. In addition, the

OEAF provides a well-known architectural structure for sharing Oracle’s vast intellectual capital around

enterprise IT solutions with its customers and partners, thereby, further enhancing Oracle’s strategic

business value proposition.

The Oracle Enterprise Application Framework encompasses nine key values.

• Driven by business strategy

• Standardizes and simplifies the technical architecture

• Comprises “just enough” modeling for enterprise solution architecture efforts

• Reuses best practice business models and reference architectures from industry and commercial vendors

• Focuses initially on speed of delivery for high level guidance

• Developed collaboratively with business owners, stakeholders, and skilled architects

• Developed iteratively and matures evolutionarily for breadth and depth

• Can be enforced

• Technology agnostic but leverages Oracle expertise and IP


6

These principles provide the foundation for agile enterprise architecture capabilities in mapping business

requirements to IT implementation.

3.1 Business Architecture

Any architectural discussion should begin with Business Architecture. The Business Architecture aligns an organization’s operating model, strategies, and objectives with IT; it also creates a business case for IT transformations and provides a business-centric view of the enterprise from a functional perspective.

This part of the framework provides the following three key areas of information about the business:

• Business Strategy: Key business requirements, objectives, strategies, key performance indicators, business risks, and the business-operating model (how processes and systems are centralized versus decentralized across the business).

• Business Function: The key business services, processes, and capabilities that will be affected by the enterprise architecture effort.

• Business Organization: The high-level nature of the organizational structures, business roles (internal audiences, external customers and partners), the decision-making process, and the organizational budget information.

3.2 Application Architecture

The Application Architecture provides an application- and services-centric view of an organization that ties business functions and services to application processes and services to application components in alignment with the application strategy. The Application Architecture’s scope, strategy, standards are a consequence of the Business Architecture.

The Application Architecture is composed of the following content categories:

• Application Strategy: The key application architecture principles (Build versus Buy, Hosted versus In-House, Open Standards versus .NET, etc.), application governance and portfolio management, and a set of reference application architectures relevant to the customer.

• Application Services: An inventory of the key application services exposed to internal and external audiences that support the business services.


7

• Application Processes: A series of application-specific processes that support the business processes in the Business Architecture.

• Logical Components: An inventory of the relevant product-agnostic enterprise application systems that is relevant to the stated business objectives.

• Physical Components: The actual products that support the logical application components and their relationships to the relevant components and services in the information and technology architectures.

3.3 Information Architecture

The Information Architecture describes all of the moving pieces and parts for managing information across the enterprise, and the sharing of that information to the right people at the right time to realize the business objectives stated in the business architecture.

The key components for describing the information architecture are:

• Information Strategy: The information architecture principles, information governance and compliance requirements, canonical data models, and industry data model support strategy and a set of reference information exchange as well as dissemination patterns and reference models.

• Information Assets: A catalog of critical business data types and models (such as customer profile, purchase order, product data, supply chain, etc.) and the relationships between those business data types and all the services and processes that interact with that data.

The Information Architecture provides an information- and data-centric view of an organization, focusing on key information assets that are used to support critical business functions.

3.4 Technology Architecture

The Technology Architecture describes how the infrastructure underlying the business, application, and information architectures is organized. The key components are:

• Technology Strategy: The technology architecture principles, technology asset governance and portfolio management strategy, and technology standards, patterns, and reference architectures used for developing specific technology solutions.


8

• Technology Services: An inventory of the specific technology services and their relationships and the business services, application services, information assets and logical or physical technology components that realize those services.

• Logical Components: The product-agnostic components that exist at the technology infrastructure tier to support each technology service.

• Physical Components: The set of technology products that exists behind each of the logical technology components to implement the technology service.

The Technology Architecture provides a technical reference model, as documented in Oracle’s Enterprise Software Framework (ESF), that is used to align technology purchases, infrastructure, and solution implementations with the enterprise IT strategies, architecture principles, standards, reference architectures, and governance model.

3.5 People, Process, and Tools

This area of the framework identifies the people, processes, and tools used to define enterprise architectures and architecture solutions.

• People: Teams and individuals who are chartered with enterprise architecture responsibilities from several perspectives–architecture development, maintenance, implementation and governance.

• Process: A selection and adherence to a set of architectural processes that are tailored to guide an architecture engagement through a path that maximizes the chance of a successful implementation and minimizing resource expenditure. The next section describes several applied processes offered by the OEAF.

• Tools: A set of tools and technologies that accelerate the process of developing and managing enterprise architecture. Most of these tools fall under the category of modeling (for example, Troux, Oracle BPA Suite), portfolio management (for example, Oracle Primavera), and architecture asset repositories (for example, Oracle Enterprise Repository).


9

3.6 Enterprise Architecture Governance

Enterprise Architecture governance provides the structure and processes for implementing an organization’s businesses strategy and objectives through an Enterprise Architecture. An EA governance body is used to guide each project and ensure its alignment with the EA during IT transformations and solution implementations. Successful EA governance includes:

• People: Teams, individuals, roles, and responsibilities of the governance board(s)

• Processes and Policies: Architecture lifecycle management, change management, review cycles, etc.

• Technology: Infrastructure for implementing the processes and policies of enterprise architecture governance

• Financial: IT cost allocation, project-funding models, business case tools to continuously monitor a positive return on investment, etc.

3.7 EA Repository The EA Repository is an Oracle internal repository for all

the architecture artifacts and deliverables that are

captured and developed throughout the lifecycle of an

Enterprise Architecture. The purpose of this repository is

to provide information describing the current-state

architecture and a library of reference architectures,

models, and principles that describes the target desired

state of the architecture, given the business objectives.

This includes Oracle EA intellectual property for jump-

starting customer EA initiatives and architecting

enterprise solutions.


10

3.8 OEAF Relationship to TOGAF The Oracle Enterprise Architecture Framework is complementary to other EA frameworks, with clear

mappings to TOGAF and FEA, such that customers can use the EA framework of their choice.

TOGAF Oracle Enterprise Architecture Framework

Part II: Architecture Development Method (ADM) Oracle Architecture Development Process (OADP)

Part III: ADM Guidelines & Techniques • Oracle Architecture Development Process (OADP)

• Applied EA Processes

Part IV: Architecture Content Framework – Content Meta Model • Business Architecture • IS Data Architecture • IS Application Architecture • Technology Architecture

OEA Content Meta Model • Business Architecture • Information Architecture • Application Architecture • Technology Architecture

Part V: Enterprise Continuum: Architecture Repository

EA Repository

Part VI: Reference Models and Technology Reference Model

Technology Architecture (Note: Oracle Artifacts are stored in the EA Repository)

Part VII: Architecture Capability Framework EA Governance The intent of building the OEAF was to leverage the strengths of TOFAF and other industry frameworks

and marry them with Oracle’s experience in developing enterprise solutions.

Our best-of-breed approach overcomes many of the complexities associated with other frameworks. The

OEAF is designed to provide quick, incremental results. Each process and artifact has been carefully

analyzed to reduce waste and provide the appropriate level of detail required to meet the objectives of the

business.


11

4 Oracle Architecture Development Process

To create these Enterprise Architecture components,

Oracle has created a streamlined process to facilitate

their development. The Oracle Architecture

Development Process (OADP) defines a practical

approach for working with customers collaboratively to

align their enterprise and solution architectures to their

business strategies and goals.

The OADP provides a generic, base process for

developing architectures as part of the Oracle

Enterprise Architecture Framework. The OADP

contains the following components:

• Six High-level Phases: Architecture Vision, Current State Architecture, Future State Architecture, Strategic Roadmap, EA Governance, and Business Case. Oracle’s approach enables many of these phases to be run concurrently to reduce the time associated with creating architectures of various scopes. Also, the OADP is meant to be a highly iterative process because architectures are developed and refined with feedback.

• Tasks: Performed in each phase and any prescriptive guidance for performing the task in a practical and most efficient manner that leverages Oracle's EA Repository (of reusable architecture artifacts).

• Artifacts Created in Each Phase: Individual models and diagrams; the simplified documentation approach provides just enough detail without requiring excessive overhead associated with documentation.

• Deliverables Created in Each Phase: Generally one or two documents that summarize the results of each task and references all artifacts produced in each phase.

From the base OADP process, Oracle creates tailored OADP processes that target a specific segment,

domain, and/or solution architecture such as Application Portfolio Rationalization and IT Optimization.

These tailored OADP processes use the basic structure and phases of the base OADP process; however,

they are further streamlined by emphasizing the critical path for a given architecture engagement, and by

providing prescriptive guidance, case studies, sample artifacts, applicable reference models, etc. for

executing these critical tasks and creating key artifacts.


12

4.1 Architecture Vision

The purpose of this phase is to establish an architecture vision

from a business perspective. The steps include developing a

forward thinking business architecture that identifies the

business’s strategy, operating model, core business processes

and capabilities, assessing the current EA maturity gap,

establishing architecture principles for developing future state

architectures, and finally, defining the scope for the current

OADP architecture engagement.

Inputs The inputs to the Architecture Vision Phase are existing discovery maps, customer profile data, prior presales/consulting content that describes the business goals, objectives, organizations, functions and processes within the customer

Tasks The following tasks are performed during the Architecture Vision Phase:

• Create a Future State Business Architecture: o Identify and/or validate what challenges the business is trying to solve (e.g. retail cost

leadership)

o Map the business requirements and driver to operational strategies (e.g. lower inventory

carrying cost by increasing supply chain information visibility)

• Conduct a Maturity Assessment: o Identify & prioritize key organizations and functions (capabilities and processes) that are

going to be impacted by this initiative (e.g. Manufacturing and Distribution)

• Identify Guiding Architecture Principles: o Identify the high-level principles from each LOB stakeholder and the Corporate IT (e.g.

IT: Global Single Instance, Business: Integrate acquisition in 90 days). Put this into the

Architecture Assessment and Vision deliverable.

• Identify Architecture Scope: o Perform a high level EA assessment with the key stakeholders.

o Put the requirements into the Architecture Assessment and Vision deliverable.

• Create an Architecture Development Plan: o Select applied EA process and tool(s) for engagement


13

o Establish review and change management process

o Assign tasks, roles and responsibilities to individuals

Artifacts The following artifacts are developed during the Architecture Vision Phase:

• Operating Model: consists of two dimensions:

o Business Processes Standardization (and related systems means) defining exactly how a

process will be executed regardless of who is performing the process or where it is

completed.

o Integration links the efforts of organizational units through shared data. This sharing of

data can be between processes to enable end-to-end transaction processing, or across

processes to allow a company to present a single face to customer.

• Business Strategy Map: is a visual representation of the strategy of an organization. It illustrates

how the organization plans to achieve its mission and vision by means of a linked chain of

continuous improvements. Strategy Maps describe an organization’s strategies from four

perspectives:

o Financial perspective

o Customer perspective

o Internal (business) process perspective

o Learning and growth perspective

• Drivers, Goals, Objectives, Measurements: provide a cross-organizational reference of an

organization meets its drivers (or strategies) in practical terms through goals, objectives, and

measures. The Drivers, Goals, Objective catalog contains information about the following:

o Organization Unit

o Business drivers

o Goals

o Objectives

o Measure

• Business Model: is like a blueprint for a strategy to be implemented through organizational

structures, processes, and systems. The business model is described through nine basic building

blocks that show the logic of how a company intends to deliver valuable products and or services

to its customers:

o Customer segments

o Value propositions

o Channels

o Customer relationships

o Revenue streams


14

o Key resources

o Key activities

o Key partnerships

o Cost structure

• Business Capability Model: can be used to apply focus to funding decisions, align IT

investments with business goals, and deepen the Business-IT dialogue. The Business Capability

Model provides:

o An approach to deepen the strategic dialogue between business and IT leaders and

increase strategic coherence.

o A translation between business concerns and IT concerns. Tying IT strategies, projects,

and costs to business capabilities offers a view of IT that resonates with business

executives.

• EA Maturity Assessment: defines the stages of architecture maturity, represents the IT

capability being developed, and the strategic business implications of that capability. The four

stages of Architecture Maturity are:

o Business Silos

o Standardized Technology

o Optimized Core

o Business Modularity

• Guiding Architecture Principles: articulate the fundamental rules and guidelines used to define

the Architecture Strategy. These principles ultimately form the basis for making IT decisions

regarding the selection, use, and deployment of all IT resources and assets across the enterprise.

Guiding Architecture Principles should be clearly related back to the business objectives and key

architecture drivers. The Oracle Enterprise Architecture Framework (OEAF) defines Guiding

Architecture Principles for:

o Business Architecture

o Application Architecture

o Information Architecture

o Technology Architecture

o Enterprise Architecture Governance

Discovery Questions A set of “Discovery Questions” have been developed to provide a “starting point” for the interviews with client stakeholders. The intent of these questions is to develop an accurate understanding of the Current-State Business Perspective. These “Discovery Questions” are in the Appendix of this document.


15

Deliverables During the Architecture Vision Phase, the following formal deliverables are developed:

• Architecture Vision: is the architect's "elevator pitch" - the key opportunity to sell the benefits of

the proposed development to the decision-makers within the enterprise. The goal is to articulate

an Architecture Vision that enables the business goals, responds to the strategic drivers,

conforms to the principles, and addresses the stakeholder concerns and objectives. Architecture

projects are often undertaken with a specific purpose in mind - a specific set of business drivers

that represent the return on investment for the stakeholders in the architecture development.

Clarifying that purpose, and demonstrating how it will be achieved by the proposed architecture

development, is the whole point of the Architecture Vision.

• Architecture Development Plan (ADP): The primary objective of the ADP is to describe the

scope and nature of Oracle’s investment in our relationship with the client. The objective of an

ADP is to develop a mutual understanding of the client’s needs and Oracle’s capabilities, and

serves as a plan for execution aligned with Oracle’s Architecture Development Process. The

scope of the engagement may focus on a particular aspect of the OADP (e.g. Architecture

Vision) or may be focused on a particular process or domain area. An ADP document addresses

the following issues:

o OEA Engagement Overview

o Scope, Objectives, and Approach

o Constraints and Assumptions

o Executive Sponsor(s)

o Primary Contact(s)

o Meeting Participants (Key Stakeholders)

o Meeting Location

o Key Tasks

o Deliverables

o Planned Start / End Dates

Phase Exit Criteria An Oracle Architect engagement model is employed and the appropriate Oracle Architect is assigned.


16

4.2 Current State

Using inputs from Architecture Vision, Discovery and other

sources (as available), understand the reasons why the Current

State architecture falls short in meeting the business strategy &

objectives. Use a “just enough” and “just in time” approach to

iteratively capture the current state architecture for the purposes

of identifying misaligned areas and areas requiring change,

performing gap analysis with the future state architecture, and

creating realistic roadmaps from the current state to the future

state

Inputs The inputs to the Current State Phase are well-defined scope for the business problem, organizations involved and a defined team of individuals with specific roles and responsibilities to develop an enterprise architecture.

Tasks The following tasks are performed during the Current State Phase:

• Capture Baseline Architecture: o Setup an EA repository to capture models and artifacts

o Capture the relevant high-level models representing current architecture (just-enough).

These models will be reused for developing the future state blueprint.

• Validate with Stakeholders: o Present and validate the architecture assessment and baseline with the stakeholders. It

is critical to get agreement from those stakeholders since the future state architecture will

be driven by this analysis.

Artifacts The following artifacts are developed during the Current State Phase:

• Business Architecture: o Business Service Catalog

• Application Architecture: o Business Process Flow

o Applications Footprint

o Application-Technology Footprint


17

o Application Integration

o Application Portfolio Catalog

• Information Architecture: o Information Asset Catalog,

o Information Architecture Capabilities Matrix

o Information Architecture-Application Matrix

o Information Architecture-Role Matrix

o Data Dissemination Diagram

• Technology Architecture: o Technology Services Portfolio

o Technology Standards Catalog

o Functional Diagrams

o Systems Diagrams

o Physical Components–Services Matrix

Discovery Questions A set of “Discovery Questions” have been developed to provide a “starting point” for the interviews with client stakeholders. The intent of these questions is to develop an accurate understanding of the Current-State Information Technology Perspective. These “Discovery Questions” are in the Appendix of this document.

Deliverables The Current State Architecture Baseline and Assessment deliverable addresses the following areas:

• Business

• Application

• Information

• Technology

• EA Governance

• People, Process & Tools

• EA Repository

Phase Exit Criteria Captured customer’s Current State and validated the vision for a Future State Architecture


18

4.3 Future State

Working with the customer, use the Architecture Vision as input

to define a Future State Architecture that aligns with the

Business, and adheres to the customer’s architecture principles.

Iteratively develop a Future State Architecture and use as a

foundation to evolve the enterprise. Develop architecture views

across the OEAF layers in-line with EA and solution architecture

activities, providing the “as needed” detail for current efforts.

Establish reference models and leverage OEA assets from the

EA Repository for faster turnaround and a high-quality

deliverable. Identify and analyze gaps from Current State

Architecture and explore implementation options.

Inputs The inputs to the Future State Phase are the Current State architecture (captured, to the level needed), and a vision and blueprint exists to guide what the Future State architecture looks like.

Tasks The following tasks are performed during the Future State Phase:

• Select Reference Models: o Select the relevant reference industry blueprints, architectures, capabilities, applications

footprint, business processes, data model and technology standards

• Refine, Elaborate, and Apply Architecture Principles: o Adhere to architecture principles established in Architecture Vision phase

o Refine, elaborate, decompose, and add architecture principles for completeness across

the BAIT layers.

o Detail implications for using these principles and identify possible incompatibilities

between principles and how to resolve.

• Develop Future State Architecture Models and Artifacts: o With the customer, draw a rough blueprint of a proposed future state architecture (OEAF

BAIT views) based on the business requirements, architecture principles and standards,

industry and technical reference models, and the current state architecture baseline.

o Extend the architectural blueprint to develop artifacts and sections in the arch definition

relevant to describe the future state.

o Analyze and select architectural options to realize vision.


19

o Leverage existing reference architectures and models

• Identify Gaps and Architecture Change: o Compare and contrast the current state models with the future state and identify the delta.

o List the key architectural changes needed to realize the target state (e.g. Need a master

data management solution for all customer records)

• Identify Benefits and Risks of each Change: o Identify the benefits, risks (e.g. cost, compliance, security, etc), and dependencies on the

rest of the enterprise.

o Include proof points to mitigate risks

• Validate with Stakeholders: o Present the target state architecture and the proposed architectural changes to the

stakeholders and get buy-in.

Artifacts The following artifacts are developed during the Future State Phase:

• Business Architecture: o Business Benefits Conceptual Diagram

• Application Architecture: o Updated Current State Artifacts

o Redundancy & Gap Reports

o Applications Footprint Diagram

o Applications-Technology Diagram

o Applications Integration Diagram

o Updated Guiding Architecture Principles

• Information Architecture: o Updated Current State Artifacts


• Technology Architecture: o Updated Current State Artifacts


o Technology Architecture Guidance

Deliverables The Future State Architecture deliverable addresses the following areas:

• Architecture Blueprint (Including Reference Models)

• Future State Value Proposition

• Proposed Future State Architecture


20

• Gap Analysis

• Benefit and Risk Assessment

Phase Exit Criteria A Future State architecture has been created and validated for the defined scope.

4.4 Strategic Roadmap

The purpose of the Strategic Roadmap phase is to create a

progressive plan to evolve towards the future state

architecture that maximizes the value from each phase of the

roadmap while minimizing risk and cost for proposed EA

initiatives and solution implementations, and considers

technology dependencies across phases while providing the

flexibility to adapt to new business priorities and to changing

technology over time.

Inputs The input to the Strategic Roadmap Phase is the target Future State architecture has been created and validated with the customer.

Tasks The following tasks are performed during the Strategic Roadmap Phase:

• Prioritize Current to Future State Architecture Gaps: o Prioritize architecture gaps (between current & future states) based on business value &

alignment, technical/architectural dependencies, cost/risk considerations, EA maturity

objectives, and stakeholder inputs

• Create an Architecture Roadmap: o Create a phased approach that advances the EA, segment, domain or solution

architectures from the current state, through transitional states to the future state

architecture based on priorities (above)

• Create an Implementation Plan: o Convert architecture roadmap into implementable projects (at the solution architecture/IT

initiative level) and create a high level implementation plan

o Define the dependencies and timelines for implementations


21

o Estimate costs of each project based on labor and software license costs

o If practical, assign risk to these projects using simple measures (e.g. “high risk”)

• Validate with Stakeholders: o Get validation from the relevant stakeholders and the oversight board that the strategic

roadmap aligns with the business expectations.

• Plan Transition to Implementation: o Identify potential implementation teams who can execute on the recommendations

approved by the customer and develop a transition plan

Artifacts The following artifacts are developed during the Strategic Roadmap Phase:

• Prioritization Analysis

• Architecture Roadmap

• Roadmap Implementation Plan

• Transition to Implementation Plan

Deliverables The Architecture Roadmap deliverable is developed during the Strategic Roadmap Phase.

Phase Exit Criteria An architecture roadmap, implementation and transition plans have been created to realize the future

state enterprise architecture.

4.5 EA Governance Enterprise Architecture Governance provides the structure

and processes for implementing an organization’s

businesses strategy and objectives through an Enterprise

Architecture

EA Governance primarily revolves around strategic decisions

that are taken that will influence the future design of the IT

environment. EA Governance sets in place design related

Policies, Standards, Guidelines and Procedures that must be

complied with. EA Governance is concerned with ensuring


22

design integrity of the business as a whole and will govern decisions that are outside of the domain of IT.

Inputs The inputs to the EA Governance Phase are existing roles and rules in the organization, corporate governance structure, existing governance KPIs, corporate culture, business organizational model, effective, project management infrastructure, existing accountability structures.

Tasks The following tasks are performed during the EA Governance State Phase:

• Identify existing Architecture Governance: o Collect existing governance structure, roles, rules and responsibilities.

• Assess Governance Effectiveness: o Observe existing corporate culture, business organizational model, effective

communication methods, project management style(s) and existing accountability

structures.

o Assess existing EA Governance Maturity

• Recommend Changes to EA Governance Model (if needed): o Guide EA Governance board structure, policies and procedures.

o Guide EA Governance policies, metrics, compliance monitoring procedures and

communication plan.

o Guide EA lifecycle, EA project lifecycle and EA asset lifecycle processes.

o Define the key measures and objectives of each project used to track the implementation

quality in an on-going basis.

o Identify funding process, ROI monitoring procedures and auditing procedures.

o Implement supporting tools (Enterprise Repository, etc.)

o Integrate into IT Governance and IT Project Lifecycle

• Validate

o Stakeholder signoff

Artifacts The following artifacts are developed during the EA Governance Phase:

• EA Governance Focus Points

• EA Governance Policies

• EA Governance Metrics

• EA Governance Roles and Responsibilities Matrix


23

Deliverables The deliverable developed during the EA Governance Phase is a formal set of recommendations that will

facilitate organizational change.

The EA Governance deliverable addresses the following areas:

• People Elements

• Process Elements

• Technology Elements

• Financial Elements

• Policy Elements

Phase Exit Criteria The EA Governance recommendations and implementation plan are validated and accepted by the

Executive sponsor.

4.6 Business Case Create a Business Case that validates that the defined

Future State Architecture and proposed Roadmap

Implementations will achieve the desired Business and IT

objectives.

Inputs The inputs to the Business Case Phase are the developed implementation/transition plan for realizing the Future State architecture with high-level estimates for each project.

Tasks The following tasks are performed during the Business Case Phase:

• Collect Current State Costs/Risks: o During the current state architecture phase, the business and IT analysts should be able

to provide information regarding their current operational costs and risks

• Assess against Benchmarks & Targets:


24

o The customer might be able to provide certain target benchmarks that they expect to

achieve with the future state architecture. Also, consider using third-party industry

benchmarks to define the targets.

• Define Projected Future State Costs/Risks: o Estimate the cost, benefits and risks of the future state architecture change

recommendations. This is an iterative task that can provide feedback to the architecture

development process to find better and more affordable options for change.

• Estimate EA Roadmap Investments: o Estimate the cost, benefits and risks of the IT projects that have been defined as part of

the strategic roadmap. This is also expected to be an iterative cycle that drives the

project roadmap to be less risky, more affordable and yield higher returns quicker.

• Create Cost/Benefit Analysis: o Summarize the costs and benefits to produce simple ROI estimates if practical

Artifacts The following artifacts are developed during the Business Case Phase:

• Value Proposition Hypothesis: provides a focus for discovery as you begin your business case

assessment

• Business Sponsorship Matrix: assists with targeting and aligning sponsorship with business

issues

• Quadrant Analysis: tests and validates each hypothesis pillar within the logical flow of your

business case findings

• Benefit Triangulation: leverages multiple vantage points to set a range of benefit targets

• Benefit Classification: documents and segments benefits into a logical business structure to

improve communication and presentation of benefit estimates

• Business Value Discovery Matrix: prioritizes, based on business value, which initiatives should

be done in the first transition

• Risk Analysis: is the planning process where you identify the types, probability and severity of

the risks that might happen on a project

• Risk Mitigation: is the plan for what to do about the risks identified by Risk Analysis

Discovery Questions A set of “Discovery Questions” have been developed to provide a “starting point” for the interviews with client stakeholders. The intent of these questions is to develop an accurate understanding of the Business Case Perspective. These “Discovery Questions” are in the Appendix of this document.


25

Deliverables The Business Case deliverable is a formal document that addresses the following areas:

• Executive Summary

o Key Business and IT Issues

• Current Business State

• Proposed Course of Action

• Options Evaluation

o Tactical

o Strategic

o Status-quo (“do nothing”)

• Financial Analysis

• Management Practices

o Project Management

o Risk Mitigation

o Governance

• Appendices

o Additional data that supports the main sections of the Business Case document

Phase Exit Criteria An informal review of the business solution has been validated by customer and is ready to be reviewed

by LOB executives and chief sponsor.


26

4.7 OADP Relationship to TOGAF

OADP is complementary to other EA processes, with clear mappings to TOGAF, such that customers can

use the EA process of their choice.

TOGAF Architecture Development Method Oracle Architecture Development Process

Preliminary A. Architecture Vision B. Business Architecture

Architecture Vision

C. Information System Architecture D. Technology Architecture Current State Architecture

C. Information System Architecture D. Technology Architecture E. Opportunities & Solutions

Future State Architecture

E. Opportunities & Solutions F. Migration Planning Strategic Roadmap

G. Implementation Governance H. Architecture Change Management EA Governance

Business Case

Requirements Management EA Repository The intent of building the OADP was to leverage the strengths of the different EA processes.


27

5 OADP and OEAF OADP provides an architectural development process that can be used for developing architectures of

various scopes. Although the OADP can be used at a project or solution level, the OADP achieves its

greatest value when complementing an Enterprise Architectural Framework. These frameworks provide a

unified and consistent structure for realizing an Enterprise Architecture in an organization.

OADP achieves its greatest value when combined with the Oracle Enterprise Architecture Framework

(OEAF). The OEAF provides a streamlined framework that helps Oracle collaboratively work with

customers to develop strategic

roadmaps and architecture

solutions that enable business and

IT alignment. Oracle emphasizes a

“just enough” and “just in time”

practical approach to Enterprise

Architecture, which may be used

standalone or as a complement to

a customer’s selected EA

methodology.

The OEAF shares the same core

guiding principles as the OADP

providing a practical, agile, and complete solution for EA. In addition, by leveraging Oracle’s Reference

Architectures and industry-specific best practices, the time and risk associated with developing an EA are

substantially reduced.

By focusing on business results and leveraging Oracle’s unique EA assets and reference architectures,

the OEAF can be employed to efficiently create a strategic roadmap with sound technology solutions

backed by a business case for business and IT alignment.


28

6 Oracle Architecture Development Process Applied to IT Problems The Oracle Architecture Development Process is a base architecture development approach that can be

applied to a variety of scenarios and problem types that most enterprises are experiencing in today’s

environment. OADP is structured in a manner that lets us tailor its tasks, in each phase, so that we can

have focused processes around very specific architecture problem sets. The OADP portfolio current

offers the following of applied processes:

• Application Portfolio Rationalization: A specialized version of the OADP process that

prescribes a practical and open approach to rationalizing costly redundant Business Applications

(for example enterprise resource planning (ERP) systems, custom, and legacy business

applications) that an enterprise can end up with after one or more merger and acquisition actions.

The specialized Application Portfolio Rationalization process leverages the overall structure of the

OADP phases, but focuses the tasks on application rationalization. For example, it takes the

OADP task around collecting Current State artifacts and prescribes the specific and “just-enough”

set of models and artifacts that are required to perform an effective application rationalization

exercise.

• IT Infrastructure Optimization: A similar process to the Application Portfolio Rationalization,

however, focused primarily on technology and infrastructure components of the enterprise.

Instead of rationalizing the ERP applications themselves, the IT Optimization focuses on

rationalizing and optimizing the usage of the components that support the applications and other

enterprise IT systems. For instance, IT Optimization can be used to rationalize data center

infrastructure around grid computing, virtualization, security, enterprise management, and other

infrastructure that end-user businesses rely upon. This applied process is a very complementary

process to Application Portfolio Rationalization, since the two exercises are chasing the same

business objective of lowering overall cost and risk of running in the IT without sacrificing

innovation and agility in the business. These exercises can be sequenced in parallel or in serial

as long as the architect has an understanding of the dependencies between the two areas in the

EA.

• Information Rationalization: An applied process that focuses on rationalizing the enterprise

from the perspectives of information storage, management, ownership, exchange, and

consumption. This process provides specific guidance and prescriptions on how to create a single

unified enterprise data model that aligns with the operating model and the data governance

structures in the organization. It provides a set of best practices around architecture artifacts and

templates that can be applied to capture and assess the current state of a customer’s enterprise

information architecture. It also provides a set of reference information architectures and patterns

that can be adopted to develop the future state.


29

The portfolio of applied OADP processes will continue to grow as we keep applying the base OADP

process to different types of architecture problems that seem to correlate quick closely to external

circumstances, such as economic climates and other social and environmental factors in the IT industry.


30

7 Conclusion The Oracle Enterprise Architecture Framework (OEAF) and Oracle Architecture Development Process

(OADP) helps Oracle work collaboratively with customers in developing strategic roadmaps and

architecture solutions that enable business and IT alignment.

OEAF and OADP were developed to enable and support Oracle’s role as a trusted, enterprise solutions

provider. The intent was to make solutions to Customer requirements more prescriptive by including

Oracle’s Intellectual Property (e.g. reference architectures, capability-product service mappings, best

practices, etc.)

By focusing on business results and leveraging Oracle’s unique EA assets and reference architectures,

OEAF and OADP can be employed to efficiently create architecture roadmaps for implementing business-

driven enterprise solutions.

The anticipated benefits to Oracle’s Customers include:

• Strategic analysis and recommendations driven by Business and IT Alignment

• Speak to both Business & IT stakeholders

• Give context to Oracle proposed solutions

o Working with customer’s existing IT environment

o As part of customer’s guiding architecture principles

o As part of a customer’s IT transformation initiatives

• Provides proven reference architectures and prescriptive guidance for moving forward

• Provides a disciplined approach & uses industry EA language that Chief Architects understand

The Oracle Enterprise Framework and Oracle Architecture Development Processes are vendor neutral,

yet take an efficient, practical approach that matches Oracle’s sales and delivery style. The content

(reference architectures, prescriptive guidance, etc.) are not vendor neutral. Oracle emphasizes a “just

enough” and “just in time” practical approach to Enterprise Architecture, which may be used standalone

or as a complement a customer’s selected EA methodology.


31

8 Appendix • Discovery Questions

Oracle Architecture Development Process User Guide ____________________________________________________________________________________________________________________

32

8.1 Discovery Questions

Architecture Vision

Element Area Discovery Question Client AnswerWhat are the Business Goals and Objectives?What are the Business Drivers?

What is within the Scope of the Architecture Vision?What is outside the Scope of the Architecture Vision?

Are there Enterprise-wide constraints?Are there Project-specific constraints? (e.g. Time, Schedule, Money, Resources, …)

How does the business (or government entity) deliver valuable products and or services to its customers?What are the Supply ”building blocks”? (e.g. Key Partners, Key Segments , Key Resources, Cost Structure, …) What are the Demand ”building blocks”?(e.g. Value Proposition, Customer Relationships, Channels, Customer Segments, Revenue Streams, …)

What are the business priorities that are important to business leaders?How are these business priorities aligned with business and IT initiatives?

Business Capability Model

Business Model

Business Goals and Drivers

Architecture Scope

Constraints


33

Element Area Discovery Question Client AnswerDoes the organization have defined Guiding Architecture Principles?What are their Business Architecture Principles?

What are their Application Architecture Principles?What are their Information Architecture Principles?What are their Technology Architecture Principles?

EA GovernanceWho are the key stakeholders for the Architecture Vision?What are their objectives and concerns?What is their level of accountability, participation and sponsorship?

Business CaseWho are the key stakeholders for the Business Case?Who needs to approve and sign-off on the Business Case?At what financial threshold will approval be required by the CFO? CEO? Board of Directors?

Key Performance Indicators

What are the performance metrics that need to be built into the enterprise architecture to meet the business needs?(e.g. Time, Financial, Business Capabilities, Risk, …)

Procurement Requirements

Are there specific procurement requirements for hardware, software and services?

Stakeholders

Guiding Architecture Principles

Stakeholders


34

Current State

Element Area Discovery Question Client AnswerWhat are the business processes that are within the scope of the Architecture Vision?Are any of these business processes performed external to the enterprise?Who are the owners of these business processes? (e.g. LoB, Corporate, IT, …)

What are the applications that are within the Scope of the Architecture Vision?Are there other applications that use or interface with these applications?Are any of these applications operated external to the enterprise?Who are the owners of these applications? (e.g. LoB, Corporate, IT, …)Are there significant “pain points” for these applications?Are there application platform “standards”?

What are the data stores that are within the Scope of the Architecture Vision?Are there other applications that use or interface with these data stores?Are there other data stores that use or interface with these data stores?Are any of these data stores operated external to the enterprise?Who are the owners of these data stores? (e.g. LoB, Corporate, IT, …)Are there significant “pain points” for these data stores?Are there information platform “standards”?

Business

Applications

Information


35

Element Area Discovery Question Client AnswerAre there technology platform “standards”? (e.g. Server, Storage, Network, Operating Systems, Systems Management, …)Are any of these technology platforms outsourced to an organization external to the enterprise?

Are any of these technology platforms operated external to the enterprise?Are there significant “pain points” for these technology platforms?

EA GovernanceOrganizationalBodies

Who approves the Enterprise Architecture?Who is responsible for making sure the Enterprise Architecture is in alignment with the Business and IT strategy of the organization? What are the roles and responsibilities of each stakeholder?

Audit Committee Who is responsible for auditing the implementation of the Enterprise Architecture?

Steering Committee(s)

Who provides subject matter guidance from the business and technology stakeholders into the Enterprise Architecture?

Working Group(s) Who is responsible for working on specific subjects associated with the Enterprise Architecture?

Enterprise Architecture Governance Board

Technology


36

Element Area Discovery Question Client AnswerEA GovernancePolicies

What is the scope of the Enterprise Architecture in the organization? How does the Enterprise Architecture align with the Business and IT strategy of the organization?

EA Standards What standards are to be used in creating and maintaining the enterprise architecture?

EA Strategy What is the strategy for implementing an Enterprise Architecture?

EA Requirements What is required to successfully define and implement an Enterprise Architecture?

Governance Policies

What are the guiding principles for Governance in the Enterprise Architecture?

EA GovernanceProcesses

What are the metrics that will be used to asses the successes of the Enterprise Architecture?How will these metrics be evaluated? How is compliance with the Enterprise Architecture evaluated and enforced?How are IT projects evaluated against the Enterprise Architecture?

Communication Plan

How is the Enterprise Architecture documented and communicated to the rest of the organization?

Strategic Alignment What process monitors the continued alignment of the Enterprise Architecture with the Business Strategy?

EA Scope

EA Value Metrics

Compliance Monitoring Procedures


37

Element Area Discovery Question Client AnswerEA GovernanceTechnology

Portfolio Management

How are projects in the enterprise managed against the Enterprise Architecture?

Workflow How are approvals managed within the Enterprise Architecture?

Compliance Reporting

How is compliance with the Enterprise Architecture’s KPIs reported?

EA GovernanceFinance

Funding Model How is the Enterprise Architecture Funded?ROI Monitoring How is the Return on Investment (ROI) for the

Enterprise Architecture monitored?Financial Auditing How are the finances associated with an

Enterprise Architecture audited?

Business CaseUnderstand the existing Business Case culture

What level of Quantitative model “proof” is expected in the Business Case document?

What are the performance metrics that need to be built into the enterprise architecture to meet the business needs?- Goals / Drivers- Priority measures used- Metrics used- Financials- Time to realize benefits

Enterprise Repository

How are the artifacts of the Enterprise Architecture managed?


38

Business Case

Element Area Discovery Question Client AnswerValue Proposition What is the value proposition for key stakeholders

?(e.g. Corporate, LoB, IT, …)

EA GovernanceFinance

What are the potential risks associated with the Future State and Strategic Roadmap?What is the risk mitigation strategy for each risk?


39

The Oracle Architecture Development Process User Guide March 2011 Author: Steven Gorenbergh Contributing Authors: Gail Wright, Paul Silverstein, Hamza Jahangir Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com

Copyright © 2011, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

0311

Documents

Oadp User Guide(031611)