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:
· 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
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
“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
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):
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]
"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):
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:
Software tiers (figure 4)
A part of Business logic; Presentation logic and Application à “Process & Rule”
A part of Business logic
Services and components
A part of Business logic
Integration architecture / ESB
QoS, security, monitoring, and infrastructure
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]
similar architectural domains
closely align IT with business
use input based on business objectives
require similar strategies and planning activities
application frameworks and enterprise applications
enterprise-level infrastructure including servers, DB, etc.
All integration patterns and when they should be used
infrastructure that supports services, namely the Enterprise Service Bus
Only integration approach based on using services
Table 2 comparison between EA and SOA
In order to avoid potential problems, we can summarize the problems as follows:
With all the focus on SOA, other EA aspects are ignored
reciprocally cooperation between both departments (EA and SOA) for a common architecture on enterprise level
à Technical Cooperation Centre
Inefficiencies as a result of duplicated efforts and missed opportunities to leverage existing architecture artefacts
Optimizing monitoring, cooperation and integration between EA, MW, and also SOA à using: Enterprise Service Bus (ESB) as integration tool
Failure to identify and incorporate SOA-specific needs as part of EA
- Separation between SOA and non-SOA projects
- SOA as the basis for the EA functional architecture domain
Table 3 Architecture-related problems
Overlap between the responsibilities of the SOA lead and the enterprise architect
Build-up the “Technical Cooperation Centre” help to “common decision-making”
Competition between SOA and EA for the same business resources
Sharing the same governance boards for both SOA and EA allowed business resources to address both SOA and EA needs in the same forum.
Potential for making contradicting architectural decisions that affect the whole enterprise
Except specific SOA-related issues, all other architectural decisions were approved by the EA
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”
[i] Dr. Mamdouh Ibrahim, Senior Certified Executive IT Architect and STSM, IBM; Gil Long, Distinguished Engineer, IBM: Service-Oriented Architecture and Enterprise Architecture.
[ii] Bernstein, Philip A. Middleware: An Architecture for Distributed System Services, Cambridge Research Lab, March 1993.
[iii] Oracle Fusion Architecture Eases the Adoption of Service-Oriented Architecture, summit strategies, January 2006
[iv] Oracle Fusion Architecture Eases the Adoption of Service-Oriented Architecture, summit strategies, January 2006
[v] The Open Group, SOA, http://opengroup.org/projects/soa/doc.tpl?gdid=10632
[vi] Ali Arsanjani, Ph.D., Chief Architect, IBM; Liang-Jie Zhang, Research Staff Member, IBM; Michael Ellis, Solution Architect, IBM; Abdul Allam, Certified IT Architect, IBM; Kishore Channabasavaiah, Executive Architect, IBM: Design an SOA solution using a reference architecture.