Oadp User Guide(031611)

Oracle Architecture Development Process
User Guide

March 2011

Oracle Architecture Development Process User Guide
____________________________________________________________________________________

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.

ii

____________________________________________________________________________________

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

1

____________________________________________________________________________________

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.

2

____________________________________________________________________________________

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.

3

____________________________________________________________________________________

4

____________________________________________________________________________________

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

5

____________________________________________________________________________________

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.

6

____________________________________________________________________________________

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

7

____________________________________________________________________________________

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

8

____________________________________________________________________________________

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.

9

____________________________________________________________________________________

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 OEA Content Meta Model
Meta Model • Business Architecture
• Business Architecture • Information Architecture
• IS Data Architecture • Application Architecture
• IS Application Architecture • Technology Architecture
• Technology Architecture
Part V: Enterprise Continuum: Architecture EA Repository
Repository
Part VI: Reference Models and Technology Technology Architecture
Reference Model (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.

10

____________________________________________________________________________________

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.

11

____________________________________________________________________________________

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

12

____________________________________________________________________________________

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

13

____________________________________________________________________________________

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.

14

____________________________________________________________________________________

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.

15

____________________________________________________________________________________

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

16

____________________________________________________________________________________

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

17

____________________________________________________________________________________

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.

18

____________________________________________________________________________________

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
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:
• Technology Architecture:
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

19

____________________________________________________________________________________

• 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

20

____________________________________________________________________________________

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”)
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

21

____________________________________________________________________________________

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

22

____________________________________________________________________________________

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:

23

____________________________________________________________________________________

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

24

____________________________________________________________________________________

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.

25

____________________________________________________________________________________

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 Architecture Vision
B. Business Architecture
C. Information System Architecture
Current State Architecture
D. Technology Architecture
C. Information System Architecture
D. Technology Architecture Future State Architecture
E. Opportunities & Solutions
E. Opportunities & Solutions
Strategic Roadmap
F. Migration Planning
G. Implementation Governance
EA Governance
H. Architecture Change Management
Business Case
Requirements Management EA Repository

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

26

____________________________________________________________________________________

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.

27

____________________________________________________________________________________

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.

28

____________________________________________________________________________________

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.

29

____________________________________________________________________________________

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.

30

____________________________________________________________________________________

8 Appendix
• Discovery Questions

31

____________________________________________________________________________________________________________________

8.1 Discovery Questions
Architecture Vision

Element Area Discovery Question Client Answer
Business Goals and What are the Business Goals and Objectives?
Drivers What are the Business Drivers?
Architecture Scope What is within the Scope of the Architecture
Vision?
What is outside the Scope of the Architecture
Vision?
Constraints Are there Enterprise-wide constraints?
Are there Project-specific constraints?
(e.g. Time, Schedule, Money, Resources, …)
Business Model 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, …)
Business Capability What are the business priorities that are important
Model to business leaders?
How are these business priorities aligned with
business and IT initiatives?

32

____________________________________________________________________________________________________________________

Guiding Architecture Does the organization have defined Guiding
Principles 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 Governance
Stakeholders Who are the key stakeholders for the Architecture
Vision?
What are their objectives and concerns?
What is their level of accountability, participation
and sponsorship?
Business Case
Stakeholders Who 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 What are the performance metrics that need to be
Indicators built into the enterprise architecture to meet the
business needs?
(e.g. Time, Financial, Business Capabilities, Risk,
…)
Procurement Are there specific procurement requirements for
Requirements hardware, software and services?

33

____________________________________________________________________________________________________________________

Current State

Business What 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, …)
Applications 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?
Are there significant “pain points” for these
applications?
Are there application platform “standards”?
Information 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?
Are there significant “pain points” for these data
stores?
Are there information platform “standards”?

34

____________________________________________________________________________________________________________________

Technology Are 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 Governance
Organizational
Bodies
Enterprise Who approves the Enterprise Architecture?
Architecture Who is responsible for making sure the Enterprise
Governance Board 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 Who provides subject matter guidance from the
Committee(s) business and technology stakeholders into the
Enterprise Architecture?
Working Group(s) Who is responsible for working on specific
subjects associated with the Enterprise
Architecture?

35

____________________________________________________________________________________________________________________

EA Governance
Policies
EA Scope 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
EA Requirements What is required to successfully define and
implement an Enterprise Architecture?
Governance What are the guiding principles for Governance in
Policies the Enterprise Architecture?
EA Governance
Processes
EA Value Metrics What are the metrics that will be used to asses
the successes of the Enterprise Architecture?
How will these metrics be evaluated?
Compliance How is compliance with the Enterprise
Monitoring Architecture evaluated and enforced?
Procedures How are IT projects evaluated against the
Communication How is the Enterprise Architecture documented
Plan and communicated to the rest of the
organization?
Strategic Alignment What process monitors the continued alignment
of the Enterprise Architecture with the Business
Strategy?

36

____________________________________________________________________________________________________________________

EA Governance
Technology
Enterprise How are the artifacts of the Enterprise
Repository Architecture managed?
Portfolio How are projects in the enterprise managed
Management against the Enterprise Architecture?
Workflow How are approvals managed within the Enterprise
Architecture?
Compliance How is compliance with the Enterprise
Reporting Architecture’s KPIs reported?
EA Governance
Finance
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 Case
Understand the What level of Quantitative model “proof” is
existing Business expected in the Business Case document?
Case culture
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

37

____________________________________________________________________________________________________________________

Business Case

Value Proposition What is the value proposition for key stakeholders
?
(e.g. Corporate, LoB, IT, …)
EA Governance What are the potential risks associated with the
Finance Future State and Strategic Roadmap?
What is the risk mitigation strategy for each risk?

38

____________________________________________________________________________________

The Oracle Architecture Development Process
User Guide
March 2011
Author: Steven Gorenbergh
Contributing Authors: Gail Wright, Paul
Silverstein, Hamza Jahangir
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
Oracle Corporation
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
World Headquarters
fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
500 Oracle Parkway
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
Redwood Shores, CA 94065
means, electronic or mechanical, for any purpose, without our prior written permission.
U.S.A.

Worldwide Inquiries: Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective
Phone: +1.650.506.7000 owners.
Fax: +1.650.506.7200
oracle.com 0311

39

Oadp User Guide(031611)

More Related Content

What's hot (17)

Similar to Oadp User Guide(031611) (20)

Oadp User Guide(031611)