It was about SOA all along! Chapter 7

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

Chapter 7 is about the “typical” barriers to implementing SOA throughout an organization. The authors added this chapter in the 2nd edition following a suggestion by Avrami Tzur (VP of SOA at HP). I will start by saying that I was a bit disappointed with this chapter: it does literally focus on the specific resistance to SOA without considering the probable more generic reasons for this resistance. But maybe it’s me again expecting cultural issues to be mentioned everywhere! At least, this chapter has the merit of existing. I am sure Avrami was far from being the only one noticing the need for addressing this topic after reading the 1st edition of the book.

This chapter deals with the fears and needs of technologists - used to a “develop and control” centralized infrastructure – that are being asked to adapt to SOA and the flexibility, openness and informality that comes with it. These fears and needs would typically raise questions such as:

• How do I know what services are available for me to use?
• How do I know exactly what each service does?
• What happens when a service I am using is changed or upgraded?
• What happens when I have to debug an application based on services?
• How does the new world of services fit and interoperate with existing IT systems? Etc,…

Five rules are then proposed to encourage adoption of SOA:

• Use visibility to reduce fear, build trust
• Put it in writing
• Extend existing management processes to SOA
• Support new pattern of collaboration
• Provide incentives for SOA adoption
  

The authors do introduce these rules as enablers of communication and knowledge sharing. I agree. However, if your organisation has a command and control culture where knowledge sharing is not the norm (I take you back to my 16 traits of such a culture) following these 5 SOA adoption rules won’t be enough. But maybe it could be argued that a “command and control” organisation would not initiate a SOA in the first place (now that could be a topic for a lively debate).

The authors do explain that the << adoption of SOA do reflects an evolution in the skills and systems of a company >> ( I would like to add that it reflects an evolution in the organisational culture as well). This evolution is made of 3 stages: Integration, Architecture and finally Operations. I finally noted that successful SOA adoption will rely on 3 groups of people: the Enterprise Architects or designers, the Providers or builders of services, and the Consumers of these services.