When I started to write this item I was tempted to use the title “Daddy, Mommy won’t let me play with SOA” however I held back because it is too serious a subject for a one-liner. The topic of whether IT is holding back particular innovations which business wants or vice versa is hardly new. Many will claim that the PC revolution in the enterprise was slowed down in some organizations by IT departments keen to stay in control – until the demands of business departments and their unilateral actions forced the issue.
Is the same blocking happening with SOA? ZapThink certainly seem to the think so with the claim :

“What ZapThink is finding is that the primary barriers to SOA adoption do not come from business management, which by and large realize the benefits of an agile, reusable, and loosely coupled architecture (even if they don’t call it that), but rather from within the IT organization that resists the movement to SOA for a wide range of reasons”

And Ron certainly makes some good observations on why IT departments can struggle with adopting SOA – everything from the challenge of making the required organizational change to general fear of the new to believing SOA could threaten their jobs.

While it is obvious as Joe McKendrick points out that "few analysts, commentators or pundits seem to argue the point that SOA is facing resistence", I think it is too simplistic to say business gets it and IT doesn’t or doesn’t want to. First of all, lets be realistic: Of course SOA is facing “resistance” – any major shift, as SOA is, takes time to be adopted and some organizations will go slow, others will jump ahead. Frankly - either decision can be right depending on individual circumstance.

Secondly, because SOA promises benefits that no sane business person would turn down does not mean that every business person will drive it though the organization (“the business sell” as David Linthicum puts it). What I suspect ZapThink is picking up from some SOA proponents is a “soft yes” to SOA from business, based on the benefits and frustration when IT management can’t convert this to a “hard yes” with budget. The reasons for this difficulty have been widely discussed and relate to the generality of the benefits which can be SOA’s worst enemy as my colleague Steve Craggs puts it:

the platitudes surrounding SOA have been used for 20 years on business execs, so they can be forgiven for having grown rather cautious, and desirous of looking for incremental investment where payback can be validated at each stage.

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

I was forwarded an excellent article written by Kevin Kelly, now of Kemar Solutions, from a new book called Secrets of SOA. Kevin worked for the Irish national airline in the 1960s on a project that with hindsight he believes was Service Oriented. In the extract, Kevin describes the cultural and attitudinal changes required by SOA (The first chapter is free to download from the site and includes this piece as well as others).

Kevin makes some excellent observations on the 1960s project and its relevance to any SOA project today. In particular, he stresses the idea that if the culture of an organizational is truly service oriented, developers will begin to naturally reuse:

“SOA is as much a state of mind as it is a technology. It’s as much about behavior and orientation as it is about programming per se. When I came to IPARS at Aer Lingus [The project he worked on], the overall orientation was a fait accompli; we were introduced to it as the way the system worked. It never occurred to us to vary from that orientation.”

He also stresses that to reuse is not the behavior previously encouraged in developers – in fact it is quite the opposite as developers are normally rewarded for innovation. Therefore, as I said last time, organizations need to make it clear that they reward reuse. As Kevin puts it:

“The decision to reuse is usually a good decision for the enterprise but often a painful decision for the solution builder accustomed to being rewarded for innovation and technical know-how… If we preach reuse while rewarding developers who pay no attention to it, we should not be surprised when the majority of developers perceive reuse as unimportant.”

And finally, Kevin stresses that SOA is about culture change as much as technology change:

Because of this existing critical mass [in the Aer Lingus project], it was easy to follow the example of our predecessors and continue in the service-oriented vein. It’s not so easy when you start trying to introduce SOA to an organization with no experience. It’s necessary to have a holistic approach, one which includes organizational, behavioral and attitudinal perspectives. Having a sound technology base will certainly help, but you need more, and it’s a slow haul.

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

Joe McKendrick’s summary at the end of August of opinions about whether reuse is achievable with SOA or even if it is the real benefit of SOA seems to have ignited an increasingly widespread debate. Reuse is now being discussed in CIO blogs such as here , slammed by Miko Matsumura in “Die SOA Reuse Die”, and defended in my own Illuminatus Research blog among other places, with Joe stirring the fires again at his own blog .

So why the big debate? First off, it is not surprising that at this stage in the SOA adoption curve, failures (or at least lack of success) will be trumpeted more loudly than success. However, there have been successes with SOA reuse for instance at Wachovia as I previously commented on.

Even if we accept these set-backs, I do not believe that we should simply abandon reuse as a goal – frankly without reuse, aren’t we giving up on the benefit of SOA which is most tangible? And while it is tempting to move away from the tangible and adopt the higher level abstract goals of “business agility” or “better infrastructure”, they are hard to measure without being tied back to reuse and hence hard to justify a business case with. As my Illuminatus Research colleague, Steve Craggs puts it:

“a lot of these are grand, strategic benefits can be somewhat difficult to measure, and this is a problem to those people trying to build business cases to justify SOA investment. I think this brings us back to reuse as being a major pragmatic driver of SOA - that is, a driver that actually drives real SOA investment.”

Which brings me to my own three step solution for driving up reuse levels (yes – it is high level and simplified but anyway):

1. Get the technology right – make sure your service definitions are designed with reuse in mind (Gary So of Webmethods has recently covered this subject . Get the technology back-up in place to ensure that services are easy to reuse from registries to repositories to governance to wikis.

2. Get the organization right – SOA isn’t just about technology and in particular it is clear that relying on the technology alone won’t deliver reuse. Some commentators seem to throw the towel in and say that conservative organizations won’t be able to make the change, I am not sure so. The primary change I would recommend is to identify clearly service owners. This was the approach taken in Wachovia and other places that have had SOA reuse success. It is also an approach which is inline with even conservative management theory: clear responsibility, clear measurement.

3. Pay up: Incent with bonuses both the service owner and the service consumers to meet reuse targets. If you incent both ends of the transaction, things start to happen. Yes, there are risks of abuse that must be policed against but the rewards are greater than those risks. I have written a free-to-download piece on this and the second step on at the new Illuminatus Research site http://www.illuminatusresearch.com/.

Unfortunately, as technologists we are comfortable with item 1, willing to discuss item 2 primarily in the context of the IT department (SOA competency centres and service librarians are good ideas, simply not sufficient) and seem shy to address 3 at all!

Posted by rbradley in SOA Organization Issues • 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)

There has been a lot of commentary on organizational changes required by SOA, but I have not seen much about how SOA will redefine existing roles and create new ones within the changed organization. Instead what seems to be assumed is that much of the responsibility for making SOA work is put at the door of the enterprise architect. As Daryl Plumber of Gartner puts it:

The first thing they have to do is make sure that they have proper architects.

Which sounds a little threatening – how many existing enterprise architects will pass this new ‘properness’ test?

Daryl’s comment comes from an excellent and wide-ranging interview around the organizational impact of SOA. He follows this line with some comments which probably reflect the consensus view on the subject but made me stop and think (http://mediaproducts.gartner.com/gc/webletter/progress_sonic121606/issue2/gartner1.html) There has been a lot of commentary on organizational changes required by SOA, but I have not seen as much about how SOA will redefine existing roles and create new ones within the changed organization. Instead what seems to be assumed is that much of the responsibility for making SOA work is put at the door of the enterprise architect. As Daryl Plumber of Gartner puts it:

The first thing they have to do is make sure that they have proper architects.

Which sounds a little threatening – how many existing enterprise architects will pass this new ‘properness’ test?

This comment comes from an excellent and wide-ranging interview with Daryl around the organizational impact of SOA. He follows this line with some comments which probably reflect the consensus view on the subject but made me stop and think . In essence, he sees architects having a role which is a tricky combination of coordinator and influencer:

If an enterprise makes the architect the center of that organization, then the roles of the other people around them, the developers, and the administrators and so forth, begin to change.

An architect is going to be looking at principles and guidelines, but a developer now has to recognize that not only are they building code for a system, they are building a set of components, modules, or services, as in service-oriented architecture.

What made we stop and think is two-fold:

Firstly, in Daryl’s world the architect becomes the interface point with business and even the center of the organization. While most enterprise architects are very capable of speaking with the business, SOA can and should change the goal-posts radically: In a successful SOA, there should be a high level of alignment between IT and business and therefore more and deeper communication. If enterprise architects are meant to be deeply involved in this interaction across the entire business, this is a potentially huge increase of the scope of the role.

The second part of the suggested role definition removes the architect from any sense of ownership of the services themselves (which is right as this would certainly be the wrong job and too big a job). However, this definition risks placing the architecture role in that classic no-win position of all the responsibility and none of the control and pushes a primarily technical role into what should be a strongly business focused environment of a business-aligned SOA.

The second issue that made me stop and think that struck me from Daryl’s interview relates to who owns the services: The key artefacts within a SOA are of course the service definitions (and their related data models). The benefits of reduced cost and increased flexibility rely on these being maintained, evolved and most importantly used as often as possible. So what is the role of the owner and what does he/she own? To my mind ‘owning’ in a business-aligned SOA environment should be in the sense of being responsible for making sure the services are used and used in the way to give most benefit to their business. This person can’t be our super-SOA architect who has all those other jobs!

The solution to me seems quite obvious – if a SOA is business aligned, the business must be more involved in SOA. this suggests that the owners of the service need to be directly aligned to the business owners of the associated business services. How this is done in practise will depend on the organization and its structures and goals. What will be true in every case is that the focus of this role should shift towards business skills and away from technical skills. The service owner can always go ask the architect for help and the architect can then focus again on ensuring that principles and guidelines are followed!

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