oracle's approach to eda · successful eda adoption requires a holistic approach using proven,...

An Oracle White Paper June 2011

IT Strategies from Oracle Oracle’s approach to EDA

IT Strategies from Oracle – Oracle’s approach to EDA

Introduction ....................................................................................... 2 EDA Adoption .................................................................................... 4

Capabilities .................................................................................... 5 Domains ........................................................................................ 5 Maturity ......................................................................................... 6 Adoption ........................................................................................ 7 Measuring Progress ...................................................................... 7

EDA Infrastructure ............................................................................. 9 EDA Reference Architecture ........................................................ 10

Engineering in an EDA environment ................................................ 12 EDA Governance ............................................................................ 14 Conclusion ...................................................................................... 16


2

Introduction

The business landscape in today's environment is very dynamic and demanding. Businesses can no longer be operating in reactive mode. To gain and maintain competitive advantage, they must become agile and proactive. Business events must be sensed and processed in real-time thereby supporting timely business decisions.

Utilizing traditional passive "pull" based technologies are not best suited to handle this need. Traditional technologies need to be complemented with interactive "push" based technologies that add event detection and processing capabilities. Event Driven Architecture (EDA) complements existing enterprise technologies by providing the infrastructure needed to support the event-driven solutions.

Another important driver for EDA is the need to analyze complex relationships between events to identify business opportunities, threats, and anomalies. Business users need timely insight to improve the quality of the decisions they make, in turn helping the enterprise to stay nimble.

As IT systems continue to proliferate, the volume of events to be processed also grows exponentially. These events possess complex inter-relationships that are not easily deciphered by human examination. The challenge for many organizations is identifying or deriving the notable events that are important to the business. EDA solves this challenge of handling high volume of events that possess complex inter-relationships.

Although basic EDA has been around for a while, the recent trends in business technology (e.g. geospatial applications, algorithmic trading, smart grid, etc.) have generated renewed interest. Several new products and technologies around EDA have evolved in recent years and some of these are driven by the growth in other related technologies like Service-Oriented Architecture (SOA) and Business Process Management (BPM).

Many consider Event Driven Architecture (EDA) as a pure technology play. Some equate EDA to messaging. However, EDA is one of the key technology enablers of agile enterprises that strive to become Real-Time Enterprises. Along with technology strategies such as SOA and BPM, EDA provides the ability for organizations to deliver business information to the business users in real-time and allows them to respond in a timely fashion. This effectively reduces the insight-to-action gap and helps companies to run more competitively than their peers.


3

With any new technology, it is important to get the concepts right before diving deeply into the architecture. This is especially true for emerging technologies that are still in the early stages of adoption. The processes and methods of adopting EDA in general have not matured and some companies may consider it too risky to adopt. Enterprises are excited by the potential benefits of EDA but are often unsure of how to adopt EDA to take advantage of the opportunities that EDA can offer.

Key to the success of EDA is the definition and execution of an EDA roadmap. An EDA roadmap provides the guidance to successfully adopt an event-driven approach to IT solution development. EDA is typically not applied in isolation, but rather, it is used in concert with other technologies such as SOA, BPM, and BI. The objective of EDA is to enable free flow of information in real-time, allowing the business to gain real-time insight and respond rapidly. The EDA roadmap should align with the Real-Time Enterprise (RTE) initiatives of the organization.

IT Strategies from Oracle (ITSO) is the body of knowledge that includes the Oracle Reference Architecture (ORA). ORA is a product-agnostic reference architecture based on architecture principles and best practices that are widely applicable and that can be implemented using a wide variety of products and technologies. ORA addresses the building of a modern, consistent IT architecture while minimizing the risk of product incompatibilities and obsolescence.ORA includes an EDA perspective that describes the EDA reference architecture and presents architectural concepts. It highlights the specific details of EDA as an elaboration of the ORA core concepts with respect to this technological approach.

The ORA EDA perspective is comprised of the EDA Foundation and the EDA Infrastructure documents. The EDA Foundation document is primarily a reference architecture for EDA and includes architecture principles, standards, definitions, and concepts. The EDA Infrastructure document relates the EDA capabilities, as defined by the conceptual and logical architecture views, to the Oracle infrastructure and provides physical and deployment views to help architects and developers define and implement EDA solutions.

Successful EDA adoption requires a holistic approach using proven, pragmatic techniques tailored to the organization’s current capabilities and existing business drivers. There are five essential focus areas which must be addressed to succeed at EDA:

• Define real-time business goals and roadmap • Define EDA roadmap and alignment to the business goals


4

• Execute EDA program level activities • Deliver projects that leverage the program level activities • Ongoing alignment, guidance, and governance

The relationships of these essential areas are illustrated in Figure 1.

Figure 1 - Oracle's Approach to EDA

EDA Adoption

To successfully adopt and execute EDA, a company must create a plan that addresses the full extent of the changes required for EDA. Oracle has created an EDA Maturity Model that can be used to measure the progress of an EDA initiative and, more importantly, can identify specific capabilities that are lacking or lagging and are therefore inhibiting the EDA adoption. A remediation approach for each of the identified inhibitors can be determined from industry best practices and prior experiences. These remedies can then be prioritized and used to create a plan, called the EDA Roadmap, to put the EDA initiative on track.


5

Having an EDA Roadmap based on a comprehensive EDA Maturity Model that is constructed using a proven approach and is based on years of collected experience and best practices accelerates the EDA adoption and enables the transformation of the organization to a Real-Time Enterprise.

Capabilities

The EDA Maturity Model includes over seventy capabilities that capture the best practices that Oracle has collected over many years working with a wide variety of companies. The EDA Maturity Model remains technology, standards, and product agnostic while still capturing the major tenants of a complete EDA strategy.

Additional capabilities are added as more best practices emerge. Thus, the details of the EDA Maturity Model will continue to evolve as more experience with EDA is gained. This allows the specifics to morph and improve as industry and Oracle’s knowledge of EDA advances.

For each capability included in the model, a description for each level of maturity and each level of adoption is provided. Although there is always some level of subjectivity when measuring capability, these descriptions minimize the subjectivity injected, and thereby provide, as best as possible, an objective measure of both maturity and adoption.

Domains

The EDA Maturity Model uses the concept of domains to classify and organize the related capabilities. As depicted in Figure 2, there are eight domains in the maturity model:


6

Figure 2 - EDA Capability Domains

These eight domains, although interrelated, are sufficiently distinct. To succeed at EDA adoption, an organization must make adequate progress in all of these domains. Inevitably an organization will be more advanced in some domains (and further in some of the capabilities within a domain) than others. Therefore, it is important to be able to measure the relative maturity within each domain (and capabilities therein) and across domains to identify areas that are lagging. Once the lagging areas have been identified it is possible to formulate remedies and thereby improve the success of the overall EDA initiative.

Maturity

Within the software industry, maturity is frequently related to the Capability Maturity Model (CMM) and the CMM successor, the Capability Maturity Model Integration (CMMI). The EDA Maturity Model parallels this understanding and measures EDA capability against defined maturity levels.

The maturity levels progress from 'None' up to 'Optimized.' These levels define the path an organization usually takes moving toward EDA maturity. EDA by its very nature requires coordination, cooperation, and a common vision to be successful; therefore, it is necessary to


7

define the strategy before it is possible to be truly successful at repeating it and then ultimately optimizing it.

Adoption

Adoption measures how widely EDA is being accepted, embraced, and applied within the enterprise. For smaller organizations within a single line-of-business, maturity and adoption are usually tightly related since there is a single approach to EDA being followed by the entire organization.

However, within large companies with multiple divisions or lines-of-business this is not usually the case. It is common to have one or more divisions that are relatively mature in EDA while other divisions are not even attempting EDA. The EDA Maturity Model handles these situations by providing a separate measure for adoption level. This allows a single division to be effectively evaluated for EDA maturity while still capturing the lack of widespread adoption as a separate measure.

For small organizations, it may be desirable to ignore the adoption dimension altogether and simply measure maturity. Conversely, for very large organizations with a goal of achieving enterprise-wide EDA adoption, it may be desirable to measure the maturity for each division or line-of-business separately and then provide a single measure of adoption across the enterprise. It should be noted, however, that for the realization of many of the key EDA benefits, a level of adoption across the organization is critical. For example, it is possible to have two divisions with mature but incompatible capabilities in which case the adoption is lower (division-wide) and that will inhibit an enterprise-wide EDA initiative.

Thus, to properly measure the overall progress of EDA initiative in a large organization, the maturity of the individual capabilities and the degree of adoption of such capabilities across the organization is vital.

Measuring Progress

In order to properly measure the overall progress of an EDA initiative in a large organization, the maturity of the individual capabilities and the degree of adoption of such capabilities across the organization is vital. Maturity and adoption levels for some or all of the capabilities or for the domains can be plotted as shown in Figure 3.


8

Figure 3 - EDA Maturity Model - Measures both maturity and adoption levels

Generally, the most effective planning horizon for an EDA Roadmap is 1-3 years. This could be longer or shorter depending on the planning cycles for each organization. The initial phases (e.g. first six months) of the roadmap will contain much greater detail than the later phases. This is appropriate and by design. The EDA Roadmap should be regularly reviewed and updated. The business never stays static, so do not expect the EDA Roadmap to remain static either.

It is important to keep the end goal in mind when applying this roadmap creation process and especially when executing against the roadmap. The end goal is achieving the goal of the EDA initiative. It is NOT to attain a particular score on the EDA Maturity Model.

For more details, please refer to the Oracle Practitioner Guide: Creating an EDA Roadmap.


9

EDA Infrastructure

The focus of an EDA infrastructure project is to build a common shared EDA platform using EDA infrastructure products, rather than developing new business functionality, or providing for other business driven needs. It allows enterprises to jumpstart their EDA efforts by providing most of the EDA capabilities needed to build and deploy event-driven solutions.

EDA infrastructure should not be a simple installation of products, rather it should be the "realization" of the reference architecture which is aligned with the IT and business strategies. It is recommended to develop a functional driven EDA reference architecture and a multi-year EDA infrastructure roadmap and develop the infrastructure gradually. This prudent approach to building infrastructure not only ensures that the IT investment is expended with due diligence but also reduces the risks associated with rolling out EDA in the enterprise.

Some of the challenges and risks that can arise if an EDA reference architecture is not utilized are:

• Accidental Architectures: When business requirements are captured and implemented locally by individual project teams, over time they evolve into an architecture that is less than efficient. Since an EDA reference architecture is enterprise scoped, it ensures that such accidental architectures are avoided and silos are eliminated.

• Myopic Solutions: When project teams don’t think strategically, they build myopic solutions that may not be future-proof. This means that the solutions will need to change often, as the business or other parameters change.

• Quality Issues: Without a reference architecture, core principles and best practices may not be followed. This may lead to software quality issues that are costly to fix.

• Compliance Violations: An EDA reference architecture ensures that any requirements related to architecture compliance are captured and the architecture components to satisfy those requirements are clearly identified.

• Incompatibility: A reference architecture ensures that various solution components can be integrated among themselves and to the external solution components using standards based interfaces.

• Technology Obsolescence: Systems may get obsolete faster than one thinks. It is important to ensure that the enterprise is running on the latest and greatest EDA technologies to give the business the competitive edge that it requires. If technology


10

trends are not taken into account when architecting solutions, it may lead to brittle architecture that may break in the near future.

• Redundancy: Redundant efforts lead to duplication and inconsistency and cost time and money to the enterprise. If the learning and experiences from the project teams are not documented and distributed appropriately, this will result in reinventing of the wheel as each project is going to duplicate efforts and try to solve the same problems individually.

• Inconsistent Terminology: Terminology inconsistency may lead to larger issues from a communications problem to major architectural flaws that will hinder integration of applications and systems.

• Event Sprawls: Sprawls that may result from duplication of efforts and lack of communication. For example, the same event may be defined (often differently) and implemented by different teams.

• Product Misuse: EDA infrastructure products may be misused or not fully leveraged.

EDA Reference Architecture

The EDA reference architecture defines the target architecture and the principles to be used by architects to make architecture and design decisions on their projects.

An EDA reference architecture is not just a diagram but rather contains:

• Multiple architecture views (conceptual, logical, deployment, product mapping etc) • Principles and guidelines • Definitions to aide communication and consistency • Event classifications • Related standards • Best practices and patterns

It is important that the EDA reference architecture documents the architecture from multiple views. Each view might include multiple models to illustrate the concepts, capabilities, etc. important for that view. The particular choice of views depends on what material is being covered and which views best convey the information. Example views include conceptual, logical, product mapping, and deployment views. See Figure 4 for an example high-level conceptual view that shows the key capabilities of the EDA infrastructure.


11

Figure 4 - EDA Reference Architecture - Conceptual View

Figure 5 illustrates the EDA logical view. This view provides 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. The EDA logical view is product agnostic so as to describe the solution architecture without being dependent on any specific products. The EDA product mapping view provides the mapping of Oracle products to the logical components.


12

Figure 5 - EDA Reference Architecture - Logical View

The EDA reference architecture must be seen as a “living” document whereby incremental releases of the reference architecture will be produced at regular intervals during the execution of the EDA Roadmap.

Refer to the Oracle Reference Architecture – EDA Infrastructure Document.

Engineering in an EDA environment

Software Engineering in an EDA environment is not radically different from the traditional engineering process but some changes may be needed to ensure that the organization takes advantage of EDA. These changes are summarized in the list below:

• A change in the overall thinking to consider events as a central element of the architecture.

http://www.oracle.com/goto/itstrategies�


13

• A paradigm shift towards Asset-Centric Engineering is a useful change that will accelerate the adoption of EDA. The Oracle Reference Architecture Engineering document goes over Asset-Centric Engineering in great detail.

• The existing Software Development Life Cycle (SDLC) may also need additional check points to ensure adherence to the EDA reference architecture.

• Coordination and hand-off between the project scope and program scope activities.

An enterprise class engineering for EDA assists with delivering projects within an EDA environment by adding key activities at the project level and also adding key activities at the program level.

Figure 6 - Engineering in an EDA environment

Figure 6 highlights EDA engineering tasks that address the engineering requirements not covered by traditional methodologies.


14

Topics covered at the program scope should include:

• Requirements Management: provides a process for identifying real-time business drivers and requirements that are suitable candidates for event-based implementation.

• Event Identification & Discovery: establishes the procedures around identifying event candidates, as well as discovering candidates for consumption from the existing event catalog. It takes the process from identification and discovery, through the justification processes required to determine if an existing event can be viable for consumption in the proposed manner, or if the proposed event candidate should be realized as a common event component.

• Event Release Planning: provides the groundwork necessary for planning for project and event deliveries within EDA.

Topics covered at the project scope should include:

• Event Definition: takes the identified event candidates and defines the event specification that will be used for both construction and consumption of the event.

• Event Design: provides the best practices and procedures required to design events from the event specification and produce the event interface.

• Event Implementation: provides the guidelines for effectively and efficiently developing event components.

• Event Testing: defines the strategy that should be taken with respect to ensuring the appropriate level of quality for delivered events.

• Event Deployment: defines the guidelines and practices that need to be considered when deploying events into an enterprise environment.

• Event OA&M: covers the operation, administration, and maintenance guidelines required for supporting the EDA's operational environment. OA&M is not simply about keeping the environment operational, but enabling consumption and evolution, in addition to measuring the EDA's adoption and success.

EDA Governance

Like any other technology initiative, EDA initiatives need to be governed to ensure that the benefits envisioned for EDA are realized and maximized. EDA assets need to be governed and controlled to promote architecture consistency, reduce risk, drive the cultural change, and show business value.


15

Oracle has defined a generic unified governance framework that applies to all Enterprise Technology Strategies (ETS). This framework is illustrated in Figure 7.

Figure 7 - Unified Governance Framework

The governance model can be categorized as five inter-related groups as explained below.

• Asset Portfolio Governance: A key area for EDA Governance is in the area of Event Portfolio Management, which manages EDA projects, EDA assets, and associated metadata in a holistic manner and is a key enabler for event discovery and consumption. In addition, Asset Portfolio Management must support dependency tracking, support impact analysis, and measure and communicate compliance.

• Design-Time Governance: Design-Time Governance requires the visibility and traceability of assets throughout the entire lifecycle. The SDLC process must be “tweaked” if necessary to include additional gates and roles to ensure quality and compliance of EDA solution delivery.

• Operational Governance: Once deployed, EDA infrastructure and solutions must be managed and monitored. Policy management and enforcement is required to ensure that constituent components operate as intended, within design parameters. This is critical for visibility into policy compliance and Quality of Service (QoS) metrics.

• Vitality Governance: It is imperative that the EDA investments made by an enterprise are routinely reviewed, and remains current, accurate, and most importantly, relevant.


16

In essence enterprises should view their EDA investments as living assets and execute a continuous improvement feedback loop to maintain their value and relevance.

• Organization Governance: EDA Governance requires the establishment of a viable and pragmatic organizational and change management model. It may require updates or creation of new governance structures to define/monitor and enforce policies surrounding the enablement of the EDA initiative. EDA generally does not require radical changes to the organization structure but rather just requires minor adjustments. Tools must be utilized to ease and automate as many processes and policies as possible.

EDA Governance Continuous Improvement Loop enables enterprises the ability to define and deploy their own focused and customized EDA Governance model. This is illustrated in Figure 8.

Figure 8 - EDA Governance Continuous Improvement Loop

Conclusion

EDA is a key strategy for real-time enablement of modern enterprises. The competitive nature of business environment has required businesses to be agile and establish differentiation using


17

a combination of value and customer experience. Enterprises are constantly under pressure to place the right information at the right time at the hands of both customers and employees alike. Events happening across the enterprise need to be analyzed and correlated to identify business critical patterns. Applying EDA to accomplish these requires a systematic, widespread, holistic, and proficient application of EDA best practices.

Oracle’s approach to EDA addresses the full adoption lifecycle by covering the program and project scopes as well as the governance needs. In addition, it can be customized and applied against an enterprise’s existing software engineering process. Oracle’s approach is based on a systematic maturity assessment that paves the way for a strategic roadmap plan to accelerate the maturity and adoption of EDA in your enterprise. Oracle has defined the EDA Reference Architecture that guides the build out of the EDA infrastructure and Oracle’s EDA and SOA products provide the capabilities required to implement a scalable and reliable EDA infrastructure to support the real-time needs of the business.

Oracle’s approach to SOA June 2011 Author: Anbu Krishnaswamy Anbarasu

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.

Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200

oracle.com

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

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open Company, Ltd. 1010

oracle's approach to eda · successful eda adoption requires a holistic approach using proven,...

Documents