Simple SOA

Simple SOA is the moto of Udi Dahan's presentation in the 19^th meeting of the SOA Forum of the Israeli Association of Information Processing on February 17^th. .

According to Udi, SOA architectures are sometimes too complex, the term Service is overloaded and may define different kind of entities.
Udi presented step by step a unique SOA model which was discussed by the forum members.

Model Highlights

The following highlights describe Udi's SOA model principles:

• It is a Loosely Coupled model
• Loose Coupling starts with the Business
• Service definitions are Business definitions
• A Service is a very coarse grained entity defining business functionality e.g. Customer Care, Sales, Fulfillment, marketing, Billing.
• Each Service owns its database or files.
• The communication between services is simple one way messaging. No Request-Response and no transactions are part of the model.
• Business Processes are inter Services events
• Events notification is message based using Publish & Subscribe.
• Some of the events are complex events because there interpretation is based upon multiple messages from multiple services e.g Product Price change, definition of a group of customers as strategic and an Order by a customer are a complex event determining the price of a buying transaction. .
• In case of an event each service extracts the data it needs and write it in its database or files in its dedicated format. Each Business function unit data infrastructure is independent on another Business Unit data infrastructure.
• Service Level of a Service is independent on other Services and their availability
• Each service is composed of Components, based on Business definitions.The Components are autonomous. Multiple components may serve the same technical contract e.g. Sale transactions above 10,000 USD Component will be separated from Sales of less than 10,000 USD. The contracts could be different and the message structure may be different. The separation is based upon Business rules distinguishing between the two kinds of transaction.
• SOA transition process is a Top-Down process: Business Services mapping and analysis, architecture building and finally coding.

Benefits of model of this type

According to Udi, this kind of model is aligned with the Business, it is simple and clearly understood by Business people. Other benefits of this model are:

• Services are clearly defined
• Service Level of a Service is independent on other Services
• Service Availability is less dependent on other Services.
• No need for translations between different business models in different departments, e.g Fulfillment is Product Centric while Billing is not.
• Technical Infrastructure decisions are justified by Business Value, e.g. buying a separate server for Strategic Customers sales is justified by high revenues from sales to these customers.

Open issues discussed during the meeting

• Data inconsistencies because each business unit keeps identical data
• Are the entities defined by Udi as Services SOA Services?
• Is Publish& Subscribe a model capable of addressing all SOA interfaces?

My Take

• Services granularity could be too coarse

Is it the return of the old Monolithic applications paradigm with a different integration pattern (Pub&Sub)? No, Components are included in the model.

Is it the return of one of the Component Based Development (CBD) models e.g. Paul Allen's model (Not the ex-Microsoft but CA's and previously Sterling Software's Paul Allen)? Yes, if the Components do not have explicit Business defined boundaries.
How can a Service be reused? Probably it will not be reused at all.

• Service is an overloaded term. Component is not less overloaded term

The model could use the term Component for an entity another SOA model could use the term Service. The term Component could stand for: UML 2.0 Components, ERP Components, CBD Components, CBD2 Components etc.

• The trade off: Simplicity vs. more extensive model

It is difficult to maintain a Complex model and to synchronize it with technical implementations (see previous posts: SOA and BPM: Too much Round Tripping? and SOA & BPM), however, a simple model may not always address properly all requirements. For example, other integration patterns in addition to Publish & Subscribe may be needed for addressing business requirements properly.

• Loose Coupling is not always the right approach

The loose coupling of Business Services is nice and simple model with many advantages. A technological Loose Coupling is a derivative of the Business Loose Coupling. As mentioned by Udi, there is a hierarchy of loose coupling levels.

ZapThink's ZapFlash posted by Ronald Schmelzer on November 28^th 2007 analyzes seven layers of Loose Coupling:

1. Implementation – Loose Coupling between Service provider and Service Consumer

2. Service Contract

3. Service Policy

4. Process

5. Data Schema

6. Infrastructure – independence on certain vendor infrastructure implementation.

7. Semantic Layer – Loose Coupling of Semantic Changes

Never the less, in some circumstances Tight Coupling or less Loose Coupling is more adequate. The 5^th presentation in the SOA forum by Nati Shalom included examples of high intensive computing grids requiring Tight Coupling due to performance requirements.

• Enterprise wide processes are not addressed by the model

Enterprise processes and sometimes processes spanning outside the enterprise are probably required in most large enterprises. As far as I understand, the model does not address such Business Processes. Enterprise Business Processes improvement and innovation is a key SOA implementations benefit.

The atomic unit of a SOA process is a Service. Which entity is the atomic unit of a process in this model? Is it a Coarse Grained Service? If yes, process agility could be limited.

• Data is not necessarily in one centralized database or duplicated many times

In addition to the two cited data models, discussed in the forum meeting, a Federated data model is possible. Each of these three models has strengths and considerations.

• Aligning IT Costs with Business Value is correct but it is not new

The model ties beautifully between Business Value of a Component or a Service and the infrastructure costs for deploying this Component or Service.

However, similar ideas are shaping current Business Service Management (BSM) for the last five or ten years.

For example the priority for fixing a server problem is determined according to the impact on critical business services.

Even some Y2K compliance projects prioritize tasks according to potential business risk and not according to technological dimensions.

In summary, Udi Dahan's simple model is interesting and in my opinion could be applicable and valuable for some enterprises especially SMBs. Unfortunately, other enterprises implementations require more complexity and will have to deploy other models.