I suppose I must thank you all...

Sorry for a bit of self gratification but I had to tell you about this.

I have been approached recently by Colleen Carmean, a PhD candidate at Capella University, researching new tools and practices in informal, just-in-time, self-regulated learning that contributes to organizational knowledge and effective business practices.

Colleen asked if I was interested in contributing to her research. I accepted with pleasure but what I really had to mention here on my blog is the fact that her research started with a selective analysis of Knowledge & Learning related sites (http://cmcarmean.googlepages.com/tappingknowledgeintheblogosphere ).

Colleen explains on her site:

“The study tapped into the Blogosphere's version of both popularity and peer review to determine trusted "experts" who are writing about:

• organizational knowledge
• organizational learning
• just in time learning
• informal learning
• emergent learning. “

Starting with 885 sites, Colleen ended up with a list of the 24 most trusted sites and guess what? This site you are reading now is among them!

So I must thank you all, regular readers of my blog, for your encouraging support.

Colleen then writes to define her objective:

“it is the intention of this study to gather knowledge on effective design and support of environments for shared knowledge via collective inquiry by community-identified and connected experts. How we can best design and support emergent learning in the creation of organizational and shared knowledge?”

I wish Colleen success for her PhD and no doubt I will write again about it.

Peter-Anthony Glick

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.

It was about SOA all along! Chapter 6

[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.