Master data management and SOA

Joe McKendrick has an interesting post “SOA’s role in master data management explained”

Pfizer first launched an SOA effort in 2001, but had to retrench its efforts when it didn’t provide access to stovepiped systems. “One of the things we learned is you can’t do SOA without data, and you can’t do it within silos,” Brodbeck said. “It’s more about farming than fishing.”

MDM and SOA have another thing in common — both require enterprise governance to succeed. Pfizer’s MDM governance structure strongly resembles one assembled for SOA, led by a business sponsor. “Master data management is much more about governance than it is about technology,” Brodbeck said.

While that works for enterprises like Pfizer, that have financial muscle and the ability to “govern” all of the IT assets, its impractical to expect at some level because getting consensus on what the “one-true” customer is can be a lot more expensive than having two systems integrate with each other. More importantly, IMHO, if the SOA is not able to bring together processes so as to alleviate the need for a formal MDM, then the business processes need to be re-engineered.

For an MDM implementation effort to succeed, it should be an outcome of business process (re)engineering. It needs to be grown organically while discovering needs to integrate business functions using SOA. After all, its better to engineer your business for efficiency than your data!

Contract-First or Code-First service design; does anybody care?

The advantages of going with contract-first is certainly evident when it comes to interoperability. I remember reading an interesting article about the Contract-first vs Code-first debate a while ago. At the time it was published, I remember thinking to myself that both sides seem to have very valid points, but, Ted Neward, whom I have great regard for, an evangelist for interoperability, was dissing the idea of contract first. Why?

Now, After a couple of years effort in spearheading the contract-first approach to SOA, it behooves me to wonder about the practicality of such an endeavor, for a couple of reasons

1. Change management is more intuitive for a code-first approach; and this may very well be just the tooling support around managing changes across schemas and services isn’t as mature.
2. The development processes in most places today don’t know how to slot the task of managing contracts in the schema/wsdl form. Who is the person responsible for rationalizing and implementing the changes. Is there a formal process to do this? Can developers do this on their own, without thinking big picture?

In a homogeneous SOA environment its code-first is easily the more practical of the two (which is not to say it doesnt involve an equal amount of thought and architecting). That said, in my opinion, given a service interoperability scenario, there is no clearer winner than contract first. I say this on the strength of one fact. If one were to design code-first interfaces and have them generate the contracts; who is to say that the way the platform renders these contracts would not change in future versions of the platform. All of a sudden service consumers fail because the contract has changed implicitly!!!

Useful links for designing versionable schema

Not to rehash best practices for schema versioning … I’ve found these links really helpful in designing schemas that are part of service contracts

Designing Extensible, Versionable XML Formats - Dare Obasanjo

Versioning XML Vocabularies - by David Orchard

Principles of Service Design: Service Versioning - MSDN article 

 XML Schema Versioning Use Cases - W3C

Service Versioning

Just as with any service in our day to day lives; e.g. auto repair etc.; services in software also come with contracts and service level agreements between every service provider and consumer. As services evolve and consumers uptake newer technologies and services, it becomes very important to “label”/”certify” every service contract/agreement because this is what enables a service provider to guarantee support for a “certified” service and a consumer to depend on a “certification” and hold the provider accountable for honoring the same. Versioning is a mechanism for “labeling” service contracts in a machine readable form.

Every service oriented application lives in a service ecosystem. The size of a service ecosystem could be from a single application to multiple applications that use services as a means to scale. At the other end of the spectrum it goes all the way upto a set of composable services in the cloud e.g. Amazon’s Mechanical Turk Service or Microsoft’s Biztalk Service. The greater the exposure of the service to consumers the more fragile it becomes in terms of changes in service interfaces. Small changes in “primitive” services have the potential to cause ripple effect of changes that affect dependent services and ultimately the consuming applications. One way to define primitive services is that they are the smallest unit  of reuse in a service ecosystem. Breaking changes to these services need to be carefully planned to minimize these ripple effects. In the next couple of weeks we’ll look concrete examples on how to version and manage the evolution of services in an SOA ecosystem.

Next time : Service Versioning – Contracts

How SOA?

Service oriented architecture (SOA) has been around for a long time. Only it used to be called by different names. Its NOT a new technology, its only a way of thinking about the various pieces in an enterprise application landscape and how they interact with each other; an example of a technology is web services and it can be used to achieve service orientation, but the vice-versa is not always the best solution neither is it the only choice.

Service oriented applications are only as good as the business analysis that goes into defining the various business entities and processes. Its a way to discover business and process inefficiencies and articulate them in a manner thats a “living document” of the current processes. With globalization and the consolidation of business, a.k.a. mergers and acquisitions, its inevitable that business processes and rules associated with them constantly change over time. To keep up with the change is crucial to the success of organizations. SOA is a way to provide business agility, one of the key measures of a successful SOA effort.

Nick Malik has a great post titled “Beware of SOA in a box” where he talks about vendors tools for SOA and how it MUST align with business

“So when you decide to move to SOA, you will inevitably have to pick some tools and products to empower your implementation. In that process, look to insure that the vendor can tell you how to get from where YOU are to where THEY want you to be. Is that destination where your organization wants to go? Can you get in for a low cost? Can you measure value? If your choice doesn’t let you answer these questions… why pick it?

* Buying a tool that you don’t use… that’s bad.
* Buying a tool that forces you to make expensive changes to your process before you see value… that’s worse.”

He is right-on about the questions companies must ask themselves before investing in tools. Just as object oriented analysis provides encapsulation, modularization and reusability in software development; the principals of SOA provide to business processes. Technologies that enable service orientation are only a means to an end and need to adapt to businesses not the other way around.