« HIM is the killer app for ... | Main | Why you don't need a BPMS »

This blog has often addressed leading edge techniques for the integration of business processes with an enterprise IT backbone. A particular focus has been "human-driven" business processes - those in which people not only enter data and record decisions in online forms, but where they also collaborate with each other and leverage business intelligence to create and innovate business solutions.

In recent entries I have articulated a top-down business process management methodology which addresses the most pressing needs of the modern enterprise - to acquire the agility necessary for survival in a globalized, wired marketplace, while simultaneously complying with statutory regulations and company policies, all within a safely controlled management hierarchy. Here is the methodology in outline:

1. First draw up a process architecture, to unite business goals with business processes.  This is a sine qua non - unless you start here, you will be building a house on sand. As discussed often in this blog, goals are the true foundation of all business activities.
2. Next apply Human Interaction Management, to make best use of the humans in your organization, at all levels of the organization chart - not in order to downsize your people away, but rather in order to leverage the skills you have on board.  Only via HIM can you gain the dual advantages of structure (for efficiency) and agility (for responsiveness).
3. Use BPM/workflow to improve your performance of mechanistic work - but be aware that there are no magic bullets to remove real-world complexity!  The idea that BPM would make it possible for business people to change mechanistic processes on the fly is a complete myth.  The IT department are going to stay involved for the duration, and when you want a new version of a mechanistic process you will need to ask IT people to draw it up, IT people to ensure it complies with regulations, IT people to test it, and IT people to deploy it.  Agility is for human-driven processes only - it is the province of HIM, not of BPM/workflow.
4. Finally (and only at this point should SOA enter the picture), look at all the processes you have defined - both human-driven and mechanistic - and ask: which of these could make use of services?  Then build the services you need, not those that the IT department suggests may be quite handy.

This methodology goes by the name of Goal-Oriented Organization Design, aka GOOD.

In previous posts I have discussed most techniques required to implement GOOD, and shown how tooling for BPM and SOA is evolving to meet these requirements. However, the area to which so far I have devoted least attention is the final level, which from an IT specialist's perspective is where the rubber meets the road. How should one go about the provision of a service layer in the enterprise?

There are several related aspects to such work. No longer is it appropriate simply to put together a team of designers, coders, testers, and technical authors, add a project manager and start building systems. The world is full of new deployment frameworks, application frameworks, architectural techniques, programming techniques, communication technologies, ...

Anyone that starts out on an SOA programme without grasping the general shape of a modern development infrastructure runs a serious risk. They are likely to find out part-way down the line that they have not only wasted a large amount of their organization's resources by failing to leverage modern best practices for development, but that what they have spent so much time and effort building is not in any way future-proof and hence only ever going to have a limited life.

Of course, a site such as ebizq.net is full of advice on aspects of SOA implementation. There are also fully-fledged SOA methodologies available from various vendors and even analysts, and no end of consultancy and training services on offer to support it all.

However, many people that I speak to are looking for something much simpler: a simple, clear description of the capabilities required to build a service layer, and roughly how these capabilities relate to one another. The SOA marketplace is chock full of arcane buzzwords, which often describe techniques and technologies that do not so much compete as overlap in ways that confuse almost everybody. This serves to disguise the shape of what actually needs to be done by an organization seeking to build a set of services.

TAKE AWAY

Suppose you plan (as most organizations do) to develop code in Java, either in place of or along with code in .NET. How well do you understand the different offerings of such component technologies as SCA, JBI, J2EE, JMX, OSGi, and JPF? What about new proposals such as JSR-277, or vendor-specific technologies such as the SAP Composite Application Framework? Which of all these are Java-specific and which ones can be used to integrate Java with .NET components?

Most people are struggling so hard with the subtle differences between these acronyms that they have no mental space left for getting the perspective required to make strategic decisions.

In this next series of blog posts I will try to un-muddy the waters, and talk at a high level about the kinds of things you need to think about if your organization is planning to implement SOA on any scale. If you have difficult decisions to make about technology implementation for an enterprise backbone, you may find that my articles over the next few weeks help to clarify the issues - and ensure that you do not come unstuck when justifying decisions to the board.

Posted by keithhb in Service-Orientated Architecture |Digg This|Add to del.icio.us

Posted by: James Taylor at March 21, 2007 07:12 PM

Posted by: A. Samarin at April 5, 2007 02:30 AM