SOA agility continued: Leveraging Data Services and provide agility in enterprise

 

The promise of SOA is flexibility and agility.  SOA people give the definition of agility as the ability to adapt to change at the speed of business.  In today’s global economy which has been fuelled by collaboration and Internet technologies, businesses change at a much faster rate than ever before.  So how does SOA help companies become agile?  In previous post i have consider my case of agility concerning the developing and architecting of SOA enabled applications, after facing some real world bottlenecks and difficulties.

Continuing with the notion of developing and expanding it to the agility of the enterprise (yours or mainly yours customer as an asset to provide to), the main issue should be to abstract the necessary data services that the other layers of the architecture use. The trick here is the ‘magic’ logical (or conceptual) representation of an entity (in this example and in many real world cases, the customer), not the physical implementation. From the point that in software we can deal with symbolic transformations, the option of abstracting the semantics into simpler (but yet transformable back) entities, is the magic. (Although, here i don’t refer to semantics, keep in mind, that in some legacy SOA platforms of biggest vendors, the semantics is on main focus as a next step for tools to by – they mention it as the heart of orchestration, organizing and identifying the correct services in the SOA-ws sea – which is the next step of my consideration here).

Firstly, let’s look at a logical view of a typical SOA.

You can see in this diagram how each layer of the architecture has been abstracted and is mutually exclusive or “loosely coupled” from the other layers of the architecture.  Why is this important?  The answer is simple…..ease of change!  Here are some advantages of this approach.

• Share services, components, rules, etc. across the enterprise (reuse)
• Isolate changes and reduce dependencies (speed to market)
• Minimize impact of business changes (speed to market)
• Easier to maintain (maintainability)

Finalizing here, to give a clear applicable explanation of the above, let me give an example of how this approach helps companies become agile.

Use Case: New customer data from a new client

Let’s say your company provides a service for customers in the retail industry.  You have a website that offers online services for consumers and your white label solution is tailored to look like it is hosted by the individual retailers.  The problem is that each retailer has their own customer database.  In the past you would have to write a ton of code for each retailer that you signed up to use your services.  With SOA, now it is a simple data mapping exercise.  By abstracting data services, the other layers of the architecture use the logical representation of customer, not the physical implementation.  Behind the scenes, the data services layer is translating the request for customer data from logical view to physical implementation.  So when you bring on new clients, you simply use a tool in the data services layer to map the new clients customer data to the standard logical definition as defined by the architecture.

You can see from this example that all three retailers have an entirely different implementation of their customer database including different naming conventions and even different attributes. In the data services layer, you can map all of these physical implementations to one standard customer definition. You can also see how the business processes all use the logical view of customer. This allows us to add and change customer definitions on the back end without changing code on the front end. If two more retailers were to sign up tomorrow, we can map their definitions to the logical customer view and be done. No Code!!! That is agile!

If you would like help establishing a data services strategy, give me a shout!

The above schematics and context (reason) for writing this post are from Mike Kavis . Also I would like to thank him for the definition of the Use Case above and the schemes usage.