Service Oriented Enterprise

Wednesday, June 15, 2005

The WSDL is the Offshore Contract  

As more and more organizations move large portions of their I.T. department to offshore facilities they are questioning which activities to keep on-shore and which to push offshore.

For those that have chosen a service oriented path, the decision seems to be clear: "The WSDL is the Offshore Contract". In other words, domestic employees will work on business processes, enterprise architecture, orchestrations (agile controllers) and service design (up to the WSDL). And building the service? You got it - offshore.

It's an interesting line to draw, yet perhaps an obvious one. Using the "software contract" as the "legal contract" invites a clean division of labor and facilitates a simple approach for acceptance testing.

Obviously - the WSDL only defines the external interface leaving other aspects of the service (LIKE THE INTERNALS) to be described by other mechanisms. The algorithms and business logic are described with variations of the Use Case (think 'service case'). The relationship between the server and other elements (the hosting container, other services it calls, etc.) will likely be described by the System Definition Model, or some variation.

The science of describing architectures, interfaces and dependencies has significantly increased in recent years and it appears as though we are entering an era where the adoption level will skyrocket. The ability to describe systems in this fashion is what I've been calling 'precision specifications'. By using digital definition languages like SDM and WSDL, we are able to provide a 'software factory' with clear directions for construction.

Using 'services' as the unit of work appears to be a very manageable approach. Companies that are big into test-driven development will likely find test-driven-services a natural extension. Organizations that have adopted the Agile Manifesto may find this world too rigid. However, the Extreme Programmers may like the ability to lump X number of services into an iteration plan. And project managers will be thrilled to see acceptance tests directly linked back to line items on the Gantt chart.

I.T. organizations must increase their capability to describe systems with precision specifications prior to initiating a 'SOA factory'.

posted by jeff | 9:01 PM

Sunday, June 12, 2005

CIO's Aren't Taking SOA Serious  

I'm going to make a quick prediction:

More CIO's will lose their job over SOA implementations than lost their job over ERP implementations.

I was chatting with a CIO the other day and asked him, "In retrospect, do you think you were involved enough in the early stages of your ERP implementation?"

He answered, "In retrospect - no - I wasn't involved enough. Had I known the size of it I would have definitely gotten more involved."

I followed up with, "Are you aware that an enterprise SOA roll-out will be significantly larger than your ERP implementation?"

He started laughing; he thought I was joking. My face didn't change. He quit laughing. "Jeff, are you serious?"

"Yes, I'm very serious. SOA is a complete overhaul impacting how systems are analyzed, designed, built, integrated and managed. And not just some systems - all systems including packaged applications like ERP."

He responded, "But with ERP, it was an all-or-nothing approach. Doesn't SOA offer an incremental approach - one that can be managed better?"

"Yes and No", I responded - "SOA is first and foremost about a network of services. The value of your service network is directly related to the effort of creating/obtaining services and making them available. All networks require a critical mass of 'valuable services' before they become useful to the consumers. The SOA service network is no exception. What I'm saying is that you can take a slow and steady approach to SOA but be prepared to receive gains that are even slower. Remember - this is really about the 'network effect'.

SOA done properly is a massive undertaking. It requires a rethinking of your infrastructure, development methodology, business impact analysis, budgeting process, organizational design... Don't underestimate the value it provides, the competitive advantage one can assume AND the investment it will take!"

It was clear that I had surprised my friend - perhaps even scared him a bit. And I realized that so many of the people in this space (vendors, analysts, press) are doing a disservice to the CIO by failing to tell the whole story: An Enterprise SOA implementation will be larger than ERP, Y2K and the Web.

Now is the time to get involved.

posted by jeff | 6:06 AM