< Funktionale Programmierung: SATProblem

Enterprise Architecture (EA) and Middleware

Relationships between Enterprise Architecture (EA) and Middleware

---

Relationships between Enterprise Architecture (EA) and Middleware

It’s important to find out a common approach in an enterprise for all architectural levels. One of the important levels is located in-between Enterprise Architecture as strategic level and Middleware Architecture as tactical level. In this article, I’m going to try to clear the relationships between Enterprise Architecture (EA) and Middleware. If the relationships between strategic and tactical levels are well-defined, then we can create a basis for the discussion and the decision making about assignment of our activities and division of responsibilities/duties in an enterprise.

This article consists of:

·        Objectives

·        EA: strategic decision and planning

·        MW and “reference architecture”

·        “Oracle Fusion Middleware”

·        SOA: both strategic and tactical decision and Planning

·        Relationship between EA and SOA

·        Roadmap for working together

 

 

a.      EA: strategic decision and planning

There’s no particular definition of Enterprise Architecture (EA), Middleware (MW) and Service-oriented architecture (SOA) that has been commonly agreed upon by everyone. That means the different standards for technical terms make understanding between EA & MW even more difficult. In addition, the “definitive and complete delineation of the responsibilities and authority” of MW and other areas are difficult. For example, MW-EA-, MW-SLA-, MW-CM-Relationships etc. Overlap between EA & MW, and also SOA, in the concepts, activities and processes and their corresponding governance is the centre of attention in this memo. Having said these, I’d like to achieve the following objectives:

·        agreement relating to EA- and MW-, and also SOA-Governance

·        common reference architecture and Terminology: An important objective is to provide common vocabulary and conceptual model for common understanding on EA & MW

·        Roadmap for enterprise-wide working cooperatively

 

The EA discipline defines and maintains the architecture models, governance and transition initiatives are needed to effectively move semi-autonomous groups towards common business and/or IT goals[i]. EA domains consist of EA roadmap, EA governance and EA architecture (business & IT). Its main tasks are:

·        Decides the overall architecture strategy: business-, application-, information- and technology-architecture

·        EA incremental development and maintenance

 

b.      Middleware and “reference architecture”

“To help solve heterogeneity and distributed computing problems, vendors are offering distributed system services that have standard programming interfaces and protocols. … These distributed system services are called middleware because they sit ‘‘in the middle,’’ layering above the operating system and networking software and below industry specific applications.”[ii] It includes web servers, application servers that support interoperability in a heterogonous and distributed environment.

 

à It should be noted that there are different definitions of middleware. One sees MW as just “infrastructure”; the other understands it as “glue” between all levels (“Sandwich-Software”, “Fusion” approach). Although I think Bernstein’s definition is technically correct and shares a common perspective with Oracle Fusion Architecture-OFA (see topic: “Oracle Fusion Middleware”), I will use a pragmatic approach in order to avoid a "theoretical Discussion". Hence, depending on the task and its relevant domain, I will use the most suitable definition (domain specific definition).

 

Figure 1 shows the transformation of the MW architecture from a 3 to a 5-tier-architecture.

See: Figure 1 - form 3-tier architecture to 5-tier architecture

c.      Oracle Fusion Middleware

Oracle Fusion Architecture (OFA) was presented at the September 2005 Oracle Open World conference.[iii] It consists of the three “sub” architectures of:

1)      Service-Oriented (SOA) and Event-Driven Architecture (EDA),

2)      Enterprise Information Architecture (EIA) (a renaming of the Oracle Information Architecture) and,

3)      Grid Computing.

See: Figure 2 Oracle Fusion Architecture (OFA)

 

Oracle constructs of basis OFA the Oracle Fusion Middleware, an integrated set of MW-Services that consists of the following components (simplified):

• Oracle Application Server (OAS)
• Business Intelligence (BI)
• Business Process Management (BPM)
• Oracle Data Integration (ODI)
• Business Integration
• OFM for Application
• Identity Management
• Service Delivery Platform
• Collaboration Suite
• Content Management
• Developer Tools

 

OFM is “a portfolio that encompasses both infrastructure software and enterprise applications, which is able to leverage and synchronize both of these software tiers.

Meanwhile, the infrastructure software that supports these modular services must perform a variety of tasks. These include registering and storing the services, routing and transforming them, combining them into composite applications or multi-step business processes, securing them, and a number of other functions. Some vendors offer middleware products that perform specific jobs within this arena while others, including Oracle with its Fusion Middleware, offer full-spectrum software suites that perform all of the core SOA infrastructure functions in a consistent and integrated way.”[iv]

 

That means Oracle recommends a comprehensive and integrated middleware concept. This concept fusions software tiers such as business-, presentation-logic, and (partial even fully) application tier. You can see the entire product range in Figure 3.

See: Figure 3 Oracle Fusion Middleware (OFM)

 

SOA: both strategic and tactical decision and Planning

We can define SOA from business-, architecture-, and implementation-perspectives, but I’d like to emphasize the architecture perspective in this article. It is clear that SOA is more than architecture.

 

The Open Group:

“SOA is an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.”[v]

 

Gartner's definition:

"Service-oriented architecture is a client/server software design approach in which an application consists of software services and software service consumers (also known as clients or service requesters). SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components, and in its use of separately standing interfaces."

 

Interoperability and federation of resources are the two requirements for efficiently use a SOA.

A Significant Step in SOA is the separation between business (Service/business logic/IT) and Process (process and rule logic, End-User). Via the decoupling of implementation from interface in SOA, the implementation (Business) is hidden from End-User (process). Such separation makes the rapid restructuring and reconfiguration of business processes possible. Consequently, SOA have close relationships with various areas. We can classify SOA-relationships as followed (provisional):

• SOA-Business logic: EA, Operations, SW-Dev.
• SOA-Process and Rule: Data Processing (DP), Service Level Agreement (SLA), Change Management (CM), Account Manager
• SOA-Core: Technical Cooperation Centre, “MW-Team”

Technical Cooperation Centre (in some literatures as “Center of Excellence (CoE)”) is my short-term suggestion instead “CoE”, because we can adjust the “CoE”-concept with traditional IT or ICT structures, that they are existing for a long time and change the relationship has less impact of them.

See: 4 SOA: Separation between Business and Process

 

Relationship between EA & SOA

There's a significant common overlapping in the concepts, activities, processes, and outcomes of SOA, EA, and their corresponding governance. For example, both SOA and EA require input based on business objectives and produce outcomes tied to and measured against these objectives. They both aim to address issues on the enterprise level (strategy and planning, reference architecture, and so on), and their governance models are similar. Table 1 shows the mapping SOA and EA architecture domains:

 

 

Table 1 Mapping SOA and EA Architecture Domains

 

The develop SOA approach can be started with Bottom-up architecture, on the contrary EA that use Top-down architecture. EA works toward a long-term design perhaps 5 until 10 years. SOA developing (similar whole developing processes) addresses questions coming out of projects and should be solved quickly. This different between Bottom-up and Top-down approach can improve the ability to quickly make project-level decision that supports the long term vision. It is important that an organisation need both types of architecture to achieve the success. The big challenge is, getting the both approach in a chain.

 

The SOA domains are a subset of the EA domains.

For example, SOA uses the outcome of business architecture as input to identify business services. In the same way, SOA is concerned with the modelling and development of services and the components that realize them while the EA architecture deals not only with SOA-specific artefacts, but also with other components, packages, and systems for the whole enterprise. Another area of overlap is security and service management. In fact, SOA security is a special case of the total security that EA must specify, and SOA Service Management and Monitoring is a subset of Systems Management that EA must deal with.[vi]

 

Table 2 comparison between EA and SOA

In order to avoid potential problems, we can summarize the problems as follows: 

 

Table 3 Architecture-related problems

 

 

Table 4 Governance-related problems

But what is to do? Some suggestions are here:

·        arrive at an agreement relating to EA-MW-SOA-Relationships

·        Variant 1: (SOA is subset of MW) and (MW is subset of EA) and (through “Technical Cooperation Centre” will assume the duties and responsibilities). à my recommendation (see Oracle approach for OFM and “fusion”-strategy)

·        Variant 2: (SOA is not subset of MW) and (MW is subset of EA) and (SOA is subset of EA)

·        Variant 3: new suggestion?

·        Define common/separate scopes/tasks for EA & MW, and also SOA

·        The relationship between “Technical Cooperation Centre” and EA-governance

·        The responsibility and ownership (exclusive or share?) of SOA infrastructure: DB(s), Enterprise Service Bus (ESB) etc. (“who do what?”)

à acceleration of building up “Technical Cooperation Centre”