[Continuation of my commented reading of Andy Mulholland’s book: “Mashup Corporations. The End of Business as Usual”].
Chapter 6 is about “Internal IT” or the effect the SOA transformation can/should have on the internal IT department/functions. With the help of a meeting with all the managers of the fictitious company Vorpal’s IT department, it explains that a SOA does not only support the informal edges of the organisation but also the formal transactional hub. What unifies it all are “the processes that flow through the business” and link “the informal processes at the edge” with “the more formal controlled processes at the hub”. It is therefore important (in order to successfully become a service-oriented organization) to adapt the company’s functional structure. The functions must mirror the key business processes that SOA has formalized.
The authors then suggest a new structure for Vorpal’s IT department. Below are the original (standard) structure followed by a new service-oriented structure:
Old:
End-user support
Development
Infrastructure (CTO)
ERP
Engineering
New:
· Composition (about defining the common services)
· Services Creation (about development of the services)
· Disruptive Innovators (about the creation of new services)
· Consolidation (about the link with the core systems)
· Services Repository (about keeping track of all the services available)
The authors do make it clear that this is only a suggested structure and that each organization would adapt it to suit their needs.
And then reorganizing the IT department around SOA is only a start. The whole organization structure should be reviewed. For example, I can see new cross-functions between sales, marketing and public relations departments: Services to a specific customer group could benefit from having a function (an individual or a team even) pulling resources from these 3 departments to better satisfy these customers no-less specific needs.
09 January 2008
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.
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.
19 December 2007
It was about SOA all along! Chapter 4
[Continuation of my commented reading of Andy Mulholland’s book: “Mashup Corporations. The End of Business as Usual”].
Chapter 4 is about how SOA can transform the relationships with your suppliers. I will quote from the book how a Vorpal supplier defines these SOA-driven relationships it has built with it’s customers (p.57). He is responding to one of Vorpal’s manager who noted that the collaborative meeting they just had was unusual in style:
“Yes, we’ve noticed [this change] as soon as we created our new services and started doing mass customization for our customers, the relationship changed pretty quickly from a Darwinian struggle to a win-win situation – from conflict to collaboration, if you will – because we’re both going to make a lot of money that way. I like to think of it as negotiation jujitsu – it’s now my job to use your strength to create new business for us instead of just holding the line on price while you pummel me.”
With an SOA, suppliers and customers work hand-in-hand to generate value. They help each other out. Another useful quote on the next page is:
“[…] don’t just define your suppliers as services – define your own operations as services to them”.
You could say that you are helping your suppliers to serve you better. It is then in fact suggested that we should think of our partners and suppliers as members of ‘our’ dynamic ecosystem, where each member contributes directly or indirectly to the growth of all the others. Another good concept given is to see your suppliers as a channel. Your supplier’s customers are potentially new customers for you.
17 December 2007
It was about SOA all along! Chapters 2 & 3
[cont. from previous post about my commented reading of Andy Mulholland’s book: “Mashup Corporations. The End of Business as Usual”].
After reading chapters 2 & 3, I realised that I should clarify something important. When I state that my writings on this blog were about SOA all along, I mean that SOA is probably the best value-adding, customer-facing, tangible web-based implementation (that I know) of a knowledge leveraging strategy. What I do not mean is that SOA is the only way to leverage organizational knowledge, nor do I mean that a company-wide change process to establish a knowledge sharing culture must incorporate some degree of SOA in order to be beneficial. Also, SOA is primarily concerned with online services on the Web but of course, not all transactions are online! Having said that, if the technological aspect of SOA might probably not apply in a meaningful sense to all businesses; its associated cultural implications should be relevant to all.
SOA first advantage [over most other knowledge leveraging initiatives] is to be directly concerned with increasing/generating sales and this should help catching the attention of CxOs.
In chapter 2, a fundamental principle of a SOA is explained: extending IT to the edges of the company. This does not only mean involving the customer-facing collaborators in the creation/evolution of the services to the customers, it means to involve outsiders as well. That is collaborators outside the firewall (to use a technical view) and not on the payroll (well, they could get paid but not with a salary). So, do get this straight: the suggestion is to enable outsiders to “add their own services that create new revenue stream”. The cultural change required to support this is to have your whole company at the service of the people at the edge: the front-line/client-facing collaborators and any trustworthy outsiders with an interest to grow your business (see my knowledge-driven and customer focused organization diagram )
From chapter 3, I will retain in particular the advantages of services (Web 2.0) over traditional Enterprise Applications, with the guiding principle of releasing control to communities of users. The importance of a legal framework also must be noted, in order to secure a service-enabled commercial environment that heavily involve outsiders.
13 December 2007
It was about SOA all along! (Chapter 1)
[cont. from previous post about my commented reading of Andy Mulholland’s book: “Mashup Corporations. The End of Business as Usual”].
Here are my thoughts after reading chapter 1 of the book “Mashup Corporations. The End of Business as Usual”.
This book illustrates its arguments with the help of a tale of a fictitious company Vorpal going through the process of implementing SOA. The authors do stress that it is a rather idealistic scenario, but I couldn’t help thinking that the way in which the realization of the need for a more flexible infrastructure came about, was unrealistic for most organizations today. You have this young clever marketing manager who explains to the CEO how he uncovered a new unsuspected source of income. In order for Vorpal to benefit from it, it had to find ways to allow online ordering flexibility.
The thing is, if you currently work in a (relatively large) organization where a n-2 manager can simply request for a meeting with the CEO to talk about an exciting personal experience that may be of interest to the company, already consider yourself lucky. Then if you are among the lucky ones, if the CEO does listen to your entire story in details, then calls in on the spot the CIO or any other senior directors to listen to it too and give their opinion, consider yourself to be privileged to work with an exciting CEO with a modern management style. Now, if your story is likely to end up initiating a formal project in which you will have a leading role, please tell me the name of your company to add it to my shortlist of preferred employers!
Anyway, the authors’ intentions were not initially to consider all the likely resistance to SOA adoption. Instead, the Vorpal scenario helps us understand typical reasons for needing SOA and a typical implementation process with its cultural, organizational and technical impacts. In this second edition of their book, the authors have added chapter 7 “Overcoming barriers”, after realising how important the challenge to convince decision-makers of the need for SOA was in many companies. So, I’ll come back to this issue after reading this chapter.
The key concept I will retain from this first chapter is the difference between “Hub IT” and “Edge IT” and that “SOA flourishes at the edges”, just inside the firewall or literally outside of it.
I will quote a very useful definition of Web Services: “[they] are standard approaches to exposing the capabilities of a company’s web site or internal systems to other web sites or systems by bypassing the user interface and connecting directly to the underlying technology”.
To be continued…
Here are my thoughts after reading chapter 1 of the book “Mashup Corporations. The End of Business as Usual”.
This book illustrates its arguments with the help of a tale of a fictitious company Vorpal going through the process of implementing SOA. The authors do stress that it is a rather idealistic scenario, but I couldn’t help thinking that the way in which the realization of the need for a more flexible infrastructure came about, was unrealistic for most organizations today. You have this young clever marketing manager who explains to the CEO how he uncovered a new unsuspected source of income. In order for Vorpal to benefit from it, it had to find ways to allow online ordering flexibility.
The thing is, if you currently work in a (relatively large) organization where a n-2 manager can simply request for a meeting with the CEO to talk about an exciting personal experience that may be of interest to the company, already consider yourself lucky. Then if you are among the lucky ones, if the CEO does listen to your entire story in details, then calls in on the spot the CIO or any other senior directors to listen to it too and give their opinion, consider yourself to be privileged to work with an exciting CEO with a modern management style. Now, if your story is likely to end up initiating a formal project in which you will have a leading role, please tell me the name of your company to add it to my shortlist of preferred employers!
Anyway, the authors’ intentions were not initially to consider all the likely resistance to SOA adoption. Instead, the Vorpal scenario helps us understand typical reasons for needing SOA and a typical implementation process with its cultural, organizational and technical impacts. In this second edition of their book, the authors have added chapter 7 “Overcoming barriers”, after realising how important the challenge to convince decision-makers of the need for SOA was in many companies. So, I’ll come back to this issue after reading this chapter.
The key concept I will retain from this first chapter is the difference between “Hub IT” and “Edge IT” and that “SOA flourishes at the edges”, just inside the firewall or literally outside of it.
I will quote a very useful definition of Web Services: “[they] are standard approaches to exposing the capabilities of a company’s web site or internal systems to other web sites or systems by bypassing the user interface and connecting directly to the underlying technology”.
To be continued…
Subscribe to:
Posts (Atom)