30 December 2007

It was about SOA all along! Chapter 5

[Continuation of my commented reading of Andy Mulholland’s book: “Mashup Corporations. The End of Business as Usual”].

With the family reunion of the Christmas break, I have only managed to complete Chapter 5. In my defence, it is probably the most important chapter of the book judging from the powerful messages it conveys. The following chapters seem to be only about some of the consequences of taking on the challenge defined in this chapter: “Creating a Program of Service Enablement”. The authors describe such a program in terms of three levels or steps:

1. Designing a Single Service.
2. Designing Systems of Services.
3. Service-Enabling your Enterprise Applications.

According to the authors, no company has yet (at the time of writing) reached level 3! This is probably still true but I wonder if a company like Google that seems to have been implementing step 2 for years now, is not already well into service-enabling its core applications (and maybe they were designed as such from the beginning). In any case, what is implied here is that the first companies to successfully reach (and complete) step 3 are likely to be the success stories in the coming years.

The chapter starts with a wonderful email sent by the CEO of the fictitious company Vorpal. She writes to all the staff to involve them in building a new service-focused culture. The goal is to foster technological innovation throughout the company and “take shadow IT out of the shadows”. Once again, I’m not aware of many CxOs (let alone CEOs) with such an open-mind on new technologies and the courage to initiate and lead the drastic cultural change that a SOA demands. Such forward-looking leadership is indeed a must for a successful SOA implementation.

Chapter 5 describes 5 rules for successful SOA implementation. I want to comment only on the first two:

This chapter’s first rule is about promoting Shadow IT. The authors are quick to note that it is not a new phenomenon. Probably since IT was provided to people to do their work, most of them would work out their own “tools, procedures and workarounds” to increase efficiency at doing their job. Most importantly, this personal or team innovation is done without the IT department (official) involvement and in most cases even without it’s knowledge. This unofficial but productive IT is what the authors define as Shadow IT. I will quote their conclusion on this topic: “Failure to embrace and support Shadow IT in the long run means wasted resources, and inability to maximize the value of your company’s collective candlepower, and lost opportunities”.

The second rule is “Institute a Service Culture”. This is for me the cornerstone of an SOA implementation. The author only give this rule half a page but a lot more is implied. Service-enabling an Organization means adapting its internal culture. “Creating a lifecycle process in which services are made, reported, judged, and finally supported by IT, is essential to maximizing the potential of your homegrown and ecosystem-developed services.” I would add that all this creativity and innovation resulting in productive services must be formally recognized and rewarded. New pay, rewards and even promotion mechanisms will be needed to foster Shadow IT.

Going back to the second level of a Service Enablement Program introduced above, the authors give a brief but useful explanation of how to build a good set of services. In a nutshell, [each service must be] “sufficiently granular to allow for easy reuse; good design is decomposing process steps into a suite of services that can be orchestrated to solve the business need in question, while allowing for recombination.” This implies a potentially large number of services that will then need to be cleverly referenced, tracked and maintained.

The last comment I will make on this chapter refers to its last section (before a set of real life examples) titled “Rethinking Your Architecture”. SOA implementation will eventually (when reaching the level 3) mean a completely new organisational physical structure, and not just limited to IT but hierarchies and departments as well. When embarking seriously on the SOA adventure, you must be ready for significant no-turning-back – sometimes painful - changes that will transform your Organization.


At 4:09 PM, Blogger Loraine said...

I wonder if some of what they call "Shadow IT" would fall under a new trend, which Forrester calls "business technology." This is where business units are dealing directly with vendors and buying actual technology solutions - as opposed to the small, unofficial projects typically meant by the term "Shadow IT."

I talked with a Forrester analyst about how this trend could impact SOA. Here's the Q&A link, if you're curious.

- Loraine
IT Business Edge

At 6:54 PM, Blogger Peter-Anthony Glick said...

Hello Loraine
I read your interview of Bobby Cameron with interest. I feel uneasy about the term "business technology". It seems to assume "traditional technology" not to be for the benefit of the business. As if IT was doing its stuff in its own world regardless of what the business needs and wants!
But to answer your question, yes I think what Cameron talks about and what Mulholland describes as Shadow IT are the same I think.
I actually much prefer to call it "Shadow IT" because it better relates to the fact that it is not done by the official IT dept, without implying (like "business technology" does) that what the IT dept does is not business focused.
The key for this new trend to become a true competitive advantage is education/training of the non-IT people by the IT dept, in order to do it safely and efficiently.


Post a Comment

Links to this post:

Create a Link

<< Home