As new IT concepts emerge, we tend to take words from the ‘real world’ and twist and turn them into technology terms. Unfortunately, SOA is currently a particularly bad offender when it comes to creating as much confusion as clarity with the terminology that is being used (even with term SOA itself). And what better examples than orchestration and choreography – is a business process really best described with reference to an orchestra or a dance?

This lack of clarity means that we seem to spend more and more time explaining what we mean by the terminology we use instead of actually communicating. In case you aren’t convinced, a great example of a basic but still unclear bit of terminology is the term Transformation which is used in hugely different ways by different people – all the way from bit-twiddling data fields to complex processing of the information contained (I tend towards the second).

If we look at the definition of the ‘real’ word “transformation”, it comes from the verb: to transform which has meanings such as To change the form of; to change in shape or appearance; to metamorphose, to transmute. It all sounds close enough except when one comes to actually ask different people what they think is technically involved in transformation and discover that some think it is a simple reordering while others regard it as fundamentally complex and more about semantics than anything else.

Unfortunately I don’t see much alternative to current situation until SOA matures and all of this terminology settles down. In the meantime, we will have to show patience and accept that one man’s transformation is another man’s translation is another man’s something else. (And these thoughts were inspired by yet another discussion I was caught up in which was more about terminology than substance)

Posted by rbradley in SOA concepts | Permalink | Comments (0) | TrackBacks (0)

With all the stories appearing around the level of reuse actually being achieved and even the level of reuse we should reasonably expect, what has caught my attention recently has been how the challenge of reuse plugs into the need for organizational change as part of a SOA program.

I covered this in passing in my previous blog posting on how the architect role seems to be greatly expanded by SOA and how business needs to be involved particularly in the area of service ownership. Richard Akerman, a technology architect with NRC CISTI, expanded this in his own blog saying:

“One of the things we found useful was separating the business-level service description, from the IT-level service implementation. What we're currently thinking is that the business should own the business-level service ideas, but the IT-level implementation should have an IT owner. This is important, because I think you can get a bit carried away in the "business drives technology" or "business-driven SOA" enthusiasm. Yes, the business is in charge of generating and validating the business ideas, but they shouldn't be deep within your IT organization making technology decisions.”

I agree with Richard’s point – we need to remember what we are trying to achieve with service ownership: it is not to make business people into enterprise architects or enterprise architects into business people (although there are some who are already both). It should be all about achieving the goals of SOA which in the case of service ownership is primarily about driving the rate of reuse up. The technical goals around perfecting the service definition, interacting with registries, repositories and governance etc. should all support this goal of reuse being achieved in a resource efficient, controlled and ‘safe’ way.

Similarly, we need to figure out in a given organization how to use business ownership in a way that increases reuse. The way this works will depend on the service in question and the structure of the business. In the case of some services (say a booking service for the logistics function), the service maps pretty well onto a business line and the purpose of the service is easy to communicate to a business owner. With others, the purpose of the service is less easy to map as they are inherently more technical – say querying a logging system about failed messages. It is still a valid service but ownership fits better within the IT organization – all be it with an owner who looks at his/her costs and sees how the service will reduce them. I will return to this topic again!

To change track a little, Jeff Schneider of MomentumSI looks at service ownership from another perspective in “Lessons from Planet Sabre”: He points out that some services will be built by units which are primarily in the business of providing services to others, while others will be built by a unit for its own use. Both are still valid and need to be handled with equal care. As Jeff puts it:

“The shared services group had a great process for managing the deployment and operational processes around services that THEY built. But what about ours? Doh!”

and

“Lesson: New services will be found on projects and in some cases they will be 'non-shared'. Understand who will build them, who will maintain them and how they will be supported in a production environment.”

However, he saves his best lesson for last:

“Lesson: SOA takes time to figure out. Once you do, you'll never, ever, ever go back. If you're SOA effort has already been deemed a failure it only means that your organization didn't have the leadership to 'do something hard'. Replace them.”

Posted by rbradley in SOA Organization Issues • SOA concepts | Permalink | Comments (0) | TrackBacks (0)

SOA addresses such a broad problem domain that it is obvious that there must be significantly different architectural patterns or styles within SOA – each best suited to address different types of integration problem and within any organization it is likely that multiple styles will need to coexist. Understanding these distinctions in the context of your organization is clearly crucial to evaluating which products (or custom coded alternatives) should be used for a specific project. Equally, ensuring that the products selected for different SOA products work well together will be essential to ensuring SOA works across the organization.

Oracle published a white paper over the summer which described at a high level some of what I would call styles and they call “Value Patterns” emerging among their customers adopting SOA. These styles are:

• SOA based integration
• Modern, composite application development
• Modernising mainframe and legacy applications

The first two styles were also well described by Brenda Michelson back when she was with Patricia Seybold before launching out as Elemental Links Inc, in “Service Oriented World: Cheat Sheet” (Brenada calls SOA based integration “flow” style integration):

“The two primary styles of SOA used in business solution development are composite application development and flow. In composite applications, the user interaction drives a request for one or many services. Most of the service invocations are synchronous in nature. A composite application typically serves one business domain. Composite applications are often delivered in a portal.

In flow, business process and/or events drive the service invocations. The service invocations are a mix of asynchronous and synchronous; however, the overall flow is usually long running and asynchronous. A flow typically crosscuts business domains and often extends outside of the enterprise. "

(Oracle’s third style I am afraid I simply don’t buy as a different style: mainframes and legacy application modernisation may be the requirement but it isn’t a value pattern in itself. Although it does make sense to make the distinction at product selection as most vendors/products are either very mainframe focused or not at all.)

The style selected of course reflects the type of solution you are trying to create but it is often also influenced by the expertise within the organization which may reflect the problem domain or be an accident of history: if there is a strong background in EAI, flow will tend to be favored; if application servers are the preferred platforms, composite application development may feel more natural.

The three styles also drive very different technical requirements which strongly links back to product selection as products will tend to specialize in one style and provide weak(er) support for the others. This is of course at odds with the normal marketing hype of “Universal SOA platform for all known problems”.

Even in the case of Oracle, IBM et al, while their portfolio may include solutions for each style, it is very unlikely that a single product can address more than one style and the degree of integration between the products is then the issue. This is probably why Oracle stressed the level of integration within their latest releases as I previously commented on and why there is still a need to consider best of breed products unless the big vendor can really prove the strength of each product and their complete portfolio.

Posted by rbradley in Enterprise Service Bus • Market trends • SOA concepts | Permalink | Comments (2) | TrackBacks (0)