You are on page 1of 32

IT Strategies from Oracle

An Overview
Release 3.0
E18336-03

September 2010

ITSO Overview, Release 3.0


E18336-03
Copyright 2010, Oracle and/or its affiliates. All rights reserved.
Primary Author: Bob Hensle
Contributing Author: Cliff Booth, Dave Pearson, Dave Chappelle, Jeff McDaniels, Mark Wilkins, Steve
Bennett
Warranty Disclaimer
THIS DOCUMENT AND ALL INFORMATION PROVIDED HEREIN (THE "INFORMATION") IS
PROVIDED ON AN "AS IS" BASIS AND FOR GENERAL INFORMATION PURPOSES ONLY. ORACLE
EXPRESSLY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. ORACLE MAKES NO WARRANTY THAT
THE INFORMATION IS ERROR-FREE, ACCURATE OR RELIABLE. ORACLE RESERVES THE RIGHT TO
MAKE CHANGES OR UPDATES AT ANY TIME WITHOUT NOTICE.
As individual requirements are dependent upon a number of factors and may vary significantly, you should
perform your own tests and evaluations when making technology infrastructure decisions. This document
is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle
Corporation or its affiliates. If you find any errors, please report them to us in writing.
Third Party Content, Products, and Services Disclaimer
This document may provide information on content, products, and services from third parties. Oracle is not
responsible for and expressly disclaim all warranties of any kind with respect to third-party content,
products, and services. Oracle will not be responsible for any loss, costs, or damages incurred due to your
access to or use of third-party content, products, or services.
Limitation of Liability
IN NO EVENT SHALL ORACLE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR
CONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOSS OF PROFITS, REVENUE, DATA OR USE,
INCURRED BY YOU OR ANY THIRD PARTY, WHETHER IN AN ACTION IN CONTRACT OR TORT,
ARISING FROM YOUR ACCESS TO, OR USE OF, THIS DOCUMENT OR THE INFORMATION.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.

Contents
Send Us Your Comments ....................................................................................................................... vii
1 Introduction
2 Oracle Reference Architecture
2.1
ORA Layers..................................................................................................................................
2.1.1
Horizontal Layers ................................................................................................................
2.1.1.1
Shared Infrastructure ...................................................................................................
2.1.1.2
Information Management ...........................................................................................
2.1.1.3
Information Assets .......................................................................................................
2.1.1.4
Application Infrastructure ..........................................................................................
2.1.1.5
Business Services ..........................................................................................................
2.1.1.6
Business Processes........................................................................................................
2.1.1.7
Interaction......................................................................................................................
2.1.2
Vertical Layers......................................................................................................................
2.1.2.1
Enterprise Development..............................................................................................
2.1.2.2
Enterprise Security .......................................................................................................
2.1.2.3
Enterprise Management ..............................................................................................
2.2
Perspectives .................................................................................................................................
2.2.1
Technology Perspectives ....................................................................................................
2.2.2
Industry Perspectives..........................................................................................................
2.3
Key Concepts ...............................................................................................................................
2.3.1
Vendor Neutral and Product Agnostic.............................................................................
2.3.2
Views .....................................................................................................................................
2.3.3
Principles...............................................................................................................................
2.3.4
Guidelines .............................................................................................................................

2-2
2-2
2-2
2-2
2-2
2-2
2-2
2-3
2-3
2-3
2-3
2-3
2-3
2-3
2-3
2-4
2-4
2-4
2-4
2-4
2-5

3 Enterprise Technology Strategy


3.1
3.2
3.3
3.3.1
3.3.2
3.3.3

ORA Technology Perspective ...................................................................................................


Practitioner Guides .....................................................................................................................
Maturity Model ...........................................................................................................................
Domains ................................................................................................................................
Maturity Levels ....................................................................................................................
Adoption Levels...................................................................................................................

3-1
3-2
3-2
3-2
3-3
3-3

iii

4 Enterprise Solution Design


4.1
4.2
4.3
4.4

Industry Reference Architectures .............................................................................................


Industry Solutions.......................................................................................................................
Technology Patterns ...................................................................................................................
Enterprise Software Framework...............................................................................................

4-1
4-2
4-2
4-2

5 Intended Use of ITSO Material


5.1
5.2

Oracle Enterprise Architecture Framework............................................................................ 5-1


Oracle Unified Method .............................................................................................................. 5-1

6 Summary
A Further Reading

iv

List of Figures
11
21
31

vi

IT Strategies from Oracle ........................................................................................................... 1-1


Oracle Reference Architecture .................................................................................................. 2-1
Maturity Model Domains .......................................................................................................... 3-3

Send Us Your Comments


ITSO Overview, Release 3.0
E18336-03

Oracle welcomes your comments and suggestions on the quality and usefulness of this
publication. Your input is an important part of the information used for revision.

Did you find any errors?

Is the information clearly presented?

Do you need more information? If so, where?

Are the examples correct? Do you need more examples?

What features did you like most about this document?

If you find any errors or have any other suggestions for improvement, please indicate
the title and part number of the documentation and the chapter, section, and page
number (if available). You can send comments to us at its_feedback_ww@oracle.com.

vii

viii

Preface
For many years, Oracle has provided industry-leading documentation for product
functionality. With the IT Strategies from Oracle (ITSO) series, Oracle is augmenting
this documentation with guidance on how to deliver business solutions using
information technology. This document provides an overview of the ITSO materials.

Audience
The primary audience for the IT Strategies from Oracle series of documents is
Enterprise Architects and Solution Architects chartered with the technical evaluation
and implementation of business solutions based on information technologies within
their organization. The material may also be of interest to the larger IT solutions
community including designers, developers, business owners, etc.

How to Use This Document


This document is an overview to the series of documents. It describes the types of
materials that are available under the IT Strategies from Oracle banner and describes
the structure used to organize the materials. It is expected that a reader of this
document will then select and readother documents of interest from the ITSO series.
The ITSO materials are available on the ITSO web site.

Document Structure
This document is organized in sections that describe the contents and structure of the
ITSO materials. Specifically,

Chapter 1 provides a description of ITSO and the types of materials under the
ITSO banner.

Chapter 2 provides a description of the Oracle Reference Architecture.

Chapter 3 describes the Enterprise Technology Strategies.

Chapter 4 describes the Enterprise Solution Designs.

Chapter 5 provides guidance on how the ITSO material is intended to be used.

Chapter 6 is a brief summary of the document.

Chapter A provides a list of additional resources that the reader may find
informative and beneficial.

ix

Conventions
The following typeface conventions are used in this document:

Convention

Meaning

boldface text

Boldface type in text indicates a term defined in the text, the ORA
Master Glossary, or in both locations.

italic text

Italics type in text indicates the name of a document or external


reference.

underline text

Underline text indicates a hypertext link.

1
IT Strategies from Oracle

IT Strategies from Oracle (ITSO) is a series of documentation and supporting


collateral designed to enable organizations to develop an architecture-centric approach
to implementing enterprise-class IT initiatives. ITSO presents successful technology
strategies and solution designs by defining widely adopted architecture concepts,
views, principles, guidelines, standards, and patterns.
Figure 11 IT Strategies from Oracle

ITSO is made up of three primary elements.

Oracle Reference Architecture (ORA) defines a detailed and consistent reference


architecture for developing and integrating solutions based on current
technologies from Oracle and other vendors. The reference architecture offers
architecture views, principles, and guidance based on recommendations from
technical experts across Oracle. It covers a broad spectrum of concerns pertaining
to technology architecture, including middleware, database, hardware, processes,
and services.
Enterprise Technology Strategies (ETS) offer valuable guidance on the adoption
of horizontal technologies for the enterprise. Each ETS extends the Oracle
Reference Architecture by adding the unique capabilities and components
provided by that particular technology i.e. a horizontal, technology-based
perspective of ORA. In addition, each ETS explains how to successfully execute
on a strategy by addressing concerns pertaining to architecture, technology,
engineering, strategy, and governance. An organization can use this material to
measure their maturity, develop their strategy, and achieve greater levels of
adoption and success.

IT Strategies from Oracle

1-1

Enterprise Solution Designs (ESD) are industry specific solution perspectives


based on ORA. They define the high level business processes, business functions,
and software capabilities in an underlying technology infrastructure that are
required to build enterprise-wide industry solutions. ESDs also map the relevant
application and technology products against solutions to illustrate how
capabilities in Oracle's complete integrated stack can best meet the business,
technical, and quality of service requirements within a particular industry.

The scope of ITSO is all of Oracle's product families. However, the Oracle technology
real estate is extremely large and evolves as new products are introduced. Thus, the
ITSO material will continue to grow as more ORA documents are created, additional
ETSs are covered, and additional ESDs are created. Please consult the ITSO web site
for a complete listing of ITSO documents.
A common problem facing many IT organizations is how to create consistency and
improve interoperability in an environment consisting of many heterogeneous
best-of-breed systems and custom-built solutions. Though these assets represent
tremendous value to the company in terms of their individual strengths, they often
place a large burden on IT due to basic incompatibilities. IT organizations often
struggle with issues related to system integration, security, monitoring, management,
availability, resource sharing and utilization, data provisioning, etc. Even with a bias
toward popular standards, such as XML and WS*, organizations find that options and
interpretations often lead to inconsistencies that inhibit interoperability and efficiency
thereby increasing costs and complexity.
ITSO provides an architecture blueprint and recommendations that promote best
practices. It describes the key architecture principles and technology-based strategies
to help architects build better solutions and help companies maximize their
information technology investments.

1-2 ITSO Overview

2
Oracle Reference Architecture

The cornerstone of ITSO is the Oracle Reference Architecture (ORA). ORA covers the
broad spectrum of technologies required to realize the next generation enterprise IT
infrastructure.
Figure 21 Oracle Reference Architecture

The purpose of ORA is to provide a reference architecture for designing, building, and
integrating solutions based on modern technology from Oracle and other vendors. The
reference architecture offers architecture principles and guidance based on
recommendations from Oracle product development architects and field experts.
Information provided by ORA gives architects an understanding of how to design
solutions for the Oracle environment and best leverage its capabilities.
The obvious challenge in creating a reference architecture across a wide spectrum of
technology is that technologies must be able to co-exist and complement each other;
however there is too much material to coalesce into a single architecture document.
Additionally, one can't assume which technologies an IT environment will adopt. An
architecture shouldn't require every technology, and technologies shouldn't be
presented as being unnecessarily dependent on one another.
ORA addresses this challenge by presenting a single, unified reference architecture,
that is designed to be modular and extensible. The core ORA documents describe
fundamental concepts such as application infrastructure, integration, security, user
interaction, monitoring and management, engineering (or development) etc., which
are common to practically all industries and technology strategies.
ORA promotes consistency, interoperability, and best practices through the definition
of architecture layers, principles, guidelines, patterns, standards, and technologies.

Oracle Reference Architecture 2-1

ORA Layers

2.1 ORA Layers


In order to promote modularity and encapsulation, an architecture will usually be
divided into layers. Each layer has a specific purpose and leverages technologies,
standards, and products designed specifically to address that purpose. Layers
generally build upon the layers below and provide benefits and capabilities to the
layers above.
The ORA diagram in Figure 21 illustrates the many aspects of enterprise computing
in the form of horizontal and vertical layers. This section provides a brief description
of each of the layers.

2.1.1 Horizontal Layers


The horizontal layers illustrate that upper layers build upon or use the capabilities of
lower layers. Since ORA is concerned with enterprise solutions, each of the layer
names could be prefaced with the term 'Enterprise' (i.e. Enterprise Interaction,
Enterprise Business Services, etc.), but 'Enterprise' has been omitted to increase
legibility of the diagram.

2.1.1.1 Shared Infrastructure


The Shared Infrastructure layer provides the network, storage, and computing power
for the upper layers in the architecture. This layer includes the resource pooling and
on-demand capacity that is commonly used in today's modern IT environments. When
describing a specific industry solution, this layer also contains shared infrastructure
components that are essential to the solution.

2.1.1.2 Information Management


The Information Management layer provides the capabilities necessary to organize,
persist, manage, and retrieve enterprise information. This includes the capabilities to
ensure accuracy, integrity, and consistency of the information as well as data
integration capabilities.

2.1.1.3 Information Assets


The Information Assets layer contains the enterprise data entities. Some examples of
enterprise data entities include customer, product, order, etc. For specific industry
solutions, this layer contains the domain data entities that are part of the solution.

2.1.1.4 Application Infrastructure


The Application Infrastructure layer provides the capabilities for business logic
execution, service enablement, event handling, integration, messaging, routing,
orchestration, etc. This layer allows business logic to be written and hosted without
concern for the specifics of the compute platform, including the infrastructure that
allows business logic to be distributed across multiple compute nodes while still
providing the appearance of a single, unified, resilient system.

2.1.1.5 Business Services


The Business Services layer exposes business data, functionality, and logic as easily
consumable services. The business services may be stand alone services or may be
exposing custom, packaged, or legacy applications as reusable services. When
describing specific industry solutions, the key business services required for the
solution are called out in this layer.

2-2 ITSO Overview

Perspectives

2.1.1.6 Business Processes


The Business Processes layer contains the business processes. Business processes may
be contained within an application or may span multiple applications. Business
processes should be easily modifiable to support increased business agility. When
describing specific industry solutions, the key business processes required for the
solution are called out in this layer.

2.1.1.7 Interaction
The Interaction layer provides the presentation capabilities necessary for users to have
a rich, user-friendly interaction with the solution. This layer also provides the
capabilities to enable users to collaborate across the enterprise. The users can be
individuals either within the enterprise (e.g. employees, contractors) or they may be
external users (e.g. customers, partners). This layer also provides the capabilities
necessary for business-to-business (B2B) interactions.

2.1.2 Vertical Layers


Layers depicted vertically are orthogonal to the horizontal layers and apply across the
entire platform, working in conjunction with horizontal layers to provide a complete
solution.

2.1.2.1 Enterprise Development


The Enterprise Development layer provides the capabilities necessary to design, build,
and package an enterprise solution. This layer includes the analysis and design tools
as well as the registries and repositories used to manage development assets and their
associated metadata.

2.1.2.2 Enterprise Security


The Enterprise Security layer provides the capabilities necessary to secure the solution.
This includes authentication, authorization, and auditing of users as well as the
infrastructure necessary to support confidentiality, integrity, and availability. This
layer also includes the storage and centralized management of security information
including user ids, credentials, permissions, certificates, etc. Data security capabilities
(controlled data access, online and offline data encryption, data masking, etc.) are also
provided by this layer.

2.1.2.3 Enterprise Management


The Enterprise Management layer provides the capabilities to monitor and manage
systems end-to-end. This layer includes the capabilities to manage multiple systems
as one, dynamically allocate resources as needed to support changing loads,
configuration management, and resource provisioning.

2.2 Perspectives
The core ORA material is extended via architecture perspectives. There are two types
of perspectives: Technology and Industry.

2.2.1 Technology Perspectives


Technology perspectives extend the core material by adding the unique capabilities,
components, standards, and approaches that a specific technology strategy offers.
SOA, BPM, EPM/BI, and EDA are examples of perspectives for ORA.

Oracle Reference Architecture 2-3

Key Concepts

2.2.2 Industry Perspectives


Industry perspectives extend the core material by adding the business functions,
business processes, data entities, software capabilities and components that an
industry vertical requires. Retail, Financial, Telco, and Pharma are examples of
industry perspectives for ORA.

2.3 Key Concepts


Key concepts used throughout ORA are defined below.

2.3.1 Vendor Neutral and Product Agnostic


ORA is a logical architectural based on capabilities and principles. ORA defines and
describes the capabilities required for building modern enterprise class solutions
based on widely applicable architecture principles. The capabilities required can be
satisfied by a variety of products from a variety of vendors.
Once the architecture has been established, Oracle products are mapped to the logical
architecture in order to illustrate where they can be used. A similar mapping can be
done for other products from other vendors. ORA does not attempt to present product
architectures, product comparisons, product usage (i.e. how-to...), or product
version information, except in cases where it is necessary in order to explain an
architecture concept.

2.3.2 Views
Architectures are often presented using a number of views, each of which presents
information to satisfy a different set of stakeholder concerns (viewpoint). A common
approach to application architecture is the 4+1 view model. It includes logical,
development, process, and physical views as well as scenarios that illustrate key
interactions.
ORA presents multiple views as appropriate for a reference architecture, including
conceptual, logical, product mapping, and deployment views. Scenarios may be
presented in the form of architecture patterns. Common ORA views include:

Conceptual View - An executive level view that describes the architecture as a set
of layers and capabilities. This view describes what the architecture will provide in
common business terms.
Logical View - A technical representation depicting logical components that
provide the capabilities of the conceptual view. It includes component
relationships as well as applicable technologies and standards.
Product Mapping View - This view illustrates how Oracle products can be
positioned within the architecture to fulfill capabilities of various logical
components.
Physical and Deployment Views - These views help illustrate how products might
be deployed into a common IT environment.

2.3.3 Principles
A principle is an unequivocal statement defining the reference architecture. It is a rule
that must be followed in order to remain in compliance. If unique circumstances
warrant a variance to a principle, the variance should be considered by an Architecture

2-4 ITSO Overview

Key Concepts

Review Board after considering the circumstances and possible negative effects such a
variance might pose. Some example principles include:

Standards Based - following open standards where applicable increases


interoperability while reducing risks associated with proprietary technology.
Loose Coupling - loose coupling between components provides greater flexibility
and agility by allowing individual components to be modified or replaced without
impacting other components in the solution.

2.3.4 Guidelines
Guidelines are non-binding suggestions or recommendations. Guidelines describe an
approach with demonstrated success, but there are other approaches that could also be
followed which would likely yield similar results. Thus, a guideline should be
followed unless another equally viable approach is being followed.

Oracle Reference Architecture 2-5

Key Concepts

2-6 ITSO Overview

3
Enterprise Technology Strategy

The evolution of technology, infrastructure, and advancement of standards has led to a


number of new technology strategies. Examples include:

Service-Oriented Architecture (SOA)

Event-Driven Architecture (EDA)

Business Process Management (BPM)

Enterprise Information Management (EIM)

Cloud computing

Enterprise Performance Management / Business Intelligence (EPM/BI)

Social computing (E2.0)

This is just a partial list and it evolves rapidly over time as new strategies emerge.
Some become mainstream and have greater impact on IT organizations than others.
Each tends to introduce new concepts, technologies, standards, components, and
infrastructure. Each addresses some business problem or challenge.
Some technology strategies remain at the margins of business, but the technology
strategies that break through to the mainstream market by delivering real business
value provide substantial opportunities for organizations to use the new technologies
for competitive advantage.
Of course, these technology strategies are all dependent on technology; however, they
require more than an understanding of standards or product functionality to be used
successfully. A reference architecture and pragmatic guidance for using the
technology are essential to success. Enterprise Technology Strategy (ETS) collateral
provides essential and detailed information to achieve and measure success with a
given technology.
There are three primary types of collateral provided for each ETS:

ORA Technology Perspective

Practitioner Guides

Maturity Model

3.1 ORA Technology Perspective


Each technology strategy presents unique requirements to architecture that includes
specific capabilities, principles, components, technologies, standards, etc. Rather than
create another reference architecture for each strategy, ORA was designed to be
extensible to incorporate new computing strategies as they emerge in the industry.

Enterprise Technology Strategy 3-1

Practitioner Guides

In order to present the reference architecture in the most effective manner, each new
technology strategy adds a perspective to ORA. This enables the reference architecture
to evolve holistically. New computing strategies extend the core material, providing
further insight and detail as needed.
A perspective extends the ORA core collateral by providing views, principles,
patterns, and guidelines that are significant to that technology domain yet cohesive
with the overall ORA. The perspective includes:

A foundation document describing the terms, concepts, standards, principles, etc.


that are important to the ETS.
An infrastructure document that defines a reference architecture built using the
technologies pertinent to the ETS.

3.2 Practitioner Guides


A Practitioner Guide explains how to deliver solutions based on that particular
technology strategy in an architecturally consistent fashion. A Practitioner Guide
provides:

Insight and guidance when working with the particular technology and address
the common concerns faced by customers and practitioners.
Guidance on important matters to consider, plan, and understand in order to
maximize benefits of the technology.

Whereas the ORA Technology Perspective describes the what, the Practitioner
Guides provide pragmatic guidance on how.

3.3 Maturity Model


The Maturity Model identifies and describes the capabilities that an organization must
possess to be successful with the ETS. Each capability described in the Maturity Model
is essentially a best practice for successful adoption of the technology required by the
ETS. Thus, the Maturity Model provides the ability to accurately measure the current
state of an organization and helps to create a customize, step-by-step roadmap to
incorporate the technology required by the ETS.

3.3.1 Domains
The capabilities are organized (categorized) into eight domains. The domains are
illustrated in Figure 3:

3-2 ITSO Overview

Maturity Model

Figure 31 Maturity Model Domains

Although the Maturity Model for each ETS will have distinct capabilities, the domains
shown above remain the same for all ETSs. This allows maturity models for ETSs to
be combined to create a composite measurement for an organization that is adopting
more than one ETS concurrently.

3.3.2 Maturity Levels


For each capability, the Maturity Model provides a description of each level of
maturity. The maturity levels, from highest to lowest, are: Optimized, Managed,
Standardized, Opportunistic, Ad Hoc, None.

3.3.3 Adoption Levels


For each capability, the Maturity Model also provides a description of the levels of
adoption. Adoption measures how widely the ETS is being accepted, embraced, and
applied within the enterprise.
For a complete description of the domains, maturity levels, adoption levels, etc. please
see the ITSO Maturity Model document.

Enterprise Technology Strategy 3-3

Maturity Model

3-4 ITSO Overview

4
Enterprise Solution Design

Enterprise Solution Designs (ESD) are based on the Oracle Reference Architecture.
They adhere to its architectural principles and also draw on the best practices and
guidelines provided in ETS collateral. ESD materials address how technology, and
specifically Oracle technology, can best meet the changing business needs and
priorities of a modern enterprise.
There are four types of ESD material:

Industry Reference Architectures

Industry Solutions

Technology Patterns

Enterprise Software Framework

4.1 Industry Reference Architectures


An industry reference architecture is a set of high level architectural representations
which characterize the current state architecture of an enterprise and a desired state, or
architectural vision, based on the ORA. As its name implies, an industry reference
architecture is specific to an industry or industry segment but a reference architecture
can also be customized to represent a single enterprise.
For most enterprises today the current state reflects an IT estate largely made up of
hard-wired monolithic applications which are statically deployed on dedicated
hardware. The desired state architecture is a logical and hence vendor neutral
representation. It specifies the technology capabilities and business processes, business
services, and key information assets which are required to design, build, and deploy
enterprise wide solutions. The technology components also specify the capabilities
required to meet demanding qualities of service.
The current and desired state representations serve as useful artefacts in the initial
phases of an Enterprise Architecture method. The current state architecture can reveal
complexity and inefficiency in how resources are exploited to deliver IT services. It can
also identify constraints and limitations which are preventing the business needs of
the enterprise being fully met. The desired state provides the basis for making
decisions to rationalize existing IT investments, to identify the need for new
investments, and to consolidate resources in order make IT more cost effective, agile,
and responsive to business needs.

Enterprise Solution Design 4-1

Industry Solutions

4.2 Industry Solutions


An industry solution meets a common business need or the needs of a widespread
industry initiative. Examples of a common need include the ability to conduct
electronic trading in capital markets and the ability to deliver smart citizen services
integrated with external agencies in local government. Examples of widespread
industry initiatives are smart metering and smart grid programs in the Utility sector
and digital oil field programs in the Oil & Gas industry.
The scope of an industry solution is enterprise wide, spanning several business
functions and hence multiple business processes. It is a complex solution because
typically it involves integration with one or more legacy applications, is based on
heterogeneous software technologies, and may include external interfaces to partner
and supplier applications.
An industry solution consists of a set of logical and physical solution architecture
representations and an implementation roadmap. The logical representations include
a functional architecture, a level 2 process architecture, and an information model. The
physical architecture representations include a technical architecture with product
mappings and a hardware topology. The product mappings illustrate how the
business, operational, and service level requirements are met by products, product
options, and features in the Oracle stack. The scope and complexity of industry
solutions means that they are normally delivered through a phased program.
Therefore, an implementation roadmap is an important component of any industry
solution.

4.3 Technology Patterns


A technology pattern is a design pattern which addresses a common IT operational or
service delivery challenge. Examples of these challenges include the need to increase
the ROI and reduce TCO of IT infrastructure assets, to meet and maintain the
demanding service levels of applications with highly unpredictable workloads, to
deliver the highest levels of availability for mission critical systems. Every industry
solution includes a technology pattern but patterns can be deployed to improve the
quality of service delivered for existing applications. In addition, technology patterns
can be composed or aggregated into complex solutions that address extensive IT
service offerings. An example of one such solution is a private cloud.
Technology patterns are standardized reusable designs which incorporate the
cumulative knowledge and experience gained by Oracle, its partners, and customers
in addressing IT challenges. A technology pattern consists of a set of logical and
physical solution architecture representations. The logical representations include a
functional and a process architecture. The physical architecture representations include
a technical architecture with product mappings and a hardware topology. These
representations illustrate how the service level requirements are met by products,
product options, and features in the Oracle stack.

4.4 Enterprise Software Framework


The Enterprise Software Framework (ESF) a more detailed definition of ORA for each
technology component. It serves as a framework against which products, options and
features in the Oracle stack, as well as 3rd party technologies, can be mapped against
the defined software capabilities.
The ability to produce detailed product mappings against ESF makes it an important
artefact in enterprise architecture methods. It can be used in conjunction with industry
reference architectures to assess how well existing assets are being exploited and to
4-2 ITSO Overview

Enterprise Software Framework

identify duplication and/or gaps in software portfolios. It also plays an important role
in the definition of industry solutions and technology patterns by ensuring that
architectural principles are adhered to and that relevant software capabilities are fully
exploited

Enterprise Solution Design 4-3

Enterprise Software Framework

4-4 ITSO Overview

5
Intended Use of ITSO Material

ITSO covers a broad spectrum of technologies related to IT infrastructure and business


solutions. The architecture principles, views, and perspectives as well as the pragmatic
guidance are intended to be broadly applicable.
Each customer environment is unique. Existing products from a variety of vendors as
well as custom, packaged, and legacy applications must be incorporated into an
architecture providing interoperability and the foundation for continuing deployment
of business solutions.
Since ORA is not designed for a specific customer environment, ORA content must be
customized to fit the unique requirements of each customer situation. ORA provides a
sound, widely applicable foundation from which customers, SIs, ISVs, and Oracle
Consulting can quickly define a vision and reference architecture to meet a customer's
unique requirements. Likewise, the ETS and EDS material is not intended to be
adopted verbatim as a solution for a unique customer environment. Rather, the
material is expected to be used as a foundation to create customer specific reference
architecture and method.

5.1 Oracle Enterprise Architecture Framework


The Oracle Enterprise Architecture Framework (OEAF) and the associated Oracle
Architecture Development Process (OADP) provide the structure and practical
approach for creating a customer's Enterprise Architecture. The ORA materials fit
naturally with OEAF and OADP.
ORA is adaptable to relationships with other technology and industry architectures to
define comprehensive customer reference architectures. The models, patterns, and
guidelines described within ORA provide assets that fit within the OEAF structure
and accelerate the development of customer specific content following the OADP.
Of course ORA is not restricted to OEAF and OADP and can be used in conjunction
with other EA frameworks such as Zachman Enterprise Framework, The Open Group
Architecture Framework (TOGAF), OMB Federal Enterprise Architecture (FEA),
Department of Defence Architecture Framework (DoDAF), etc.

5.2 Oracle Unified Method


The ETS Practitioner Guides provide pragmatic guidance and approaches to
successfully adopting new technology including guidance on solution engineering,
roadmap creation, governance, etc. The Practitioner Guides do not provide a complete
methodology; rather they address specific issues that are new and specific to the ETS.

Intended Use of ITSO Material 5-1

Oracle Unified Method

The Oracle Unified Method (OUM) provides a complete, end-to-end methodology to


deliver enterprise solutions. OUM and the Practitioner Guides are fully compatible
and, where applicable, the approaches described in the Practitioner Guides have been
incorporated into OUM.
The pragmatic approach described within each Practitioner Guide is expected to be
modified and incorporated into the existing methodology used by each customer.
Practitioner Guides can be used with any methodology that the customer chooses. For
customers looking for a complete, end-to-end methodology, Oracle Unified Methods
(OUM) provides exactly that.

5-2 ITSO Overview

6
Summary

The IT Strategies from Oracle series provides thought leadership and guidance for
applying the important technology strategies that deliver real business value and can
provide real competitive advantage.
ITSO provides collateral that enables architects to develop an architecture-centric,
pragmatic approach for enterprise class initiatives that promotes consistency and
interoperability by defining universally adopted architecture principles, guidelines,
standards, patterns, and best practices within their organizations. The technology and
industry perspective materials illustrate how Oracle technology can be best exploited
and their benefits maximized.
The collateral contained in ITSO augments and complements existing material such as
product documentation, Oracle Enterprise Architecture Framework (OEAF), Oracle
Unified Method (OUM), Maximum Availability Architecture (MAA), etc.

Summary

6-1

6-2 ITSO Overview

A
Further Reading

This document is an overview for the IT Strategies from Oracle series of documents.
As such, the entire collection of ITSO material is potentially of interest. Please visit the
ITSO web site for a complete list of available material.

Further Reading A-1

A-2 ITSO Overview

You might also like