I have recently been made aware (on ActKm listserve) by Shawn Callahan of one of his blog post dated 03/09/06 and titled “Tree dozen knowledge sharing barriers”. Shawn was commenting on an article written by Andreas Riege (with the same name as the post).
I thought that it could be interesting to compare Andreas’ list of barriers with my list of 16 “not conducive to K sharing” cultural traits.
First, I excluded the technological barriers as these are not directly linked the organizational culture.
From the remaining 29 barriers, I manage to make 15 of them correspond to at least one of 12 of my traits. So they were mutually confirming each other.
One barrier can actually be linked to nearly all of my traits: “Existing corporate culture does not provide sufficient support for sharing practices”.
This left the following 4 cultural traits not addressed by Andreas’ list:
2. Focus on short-term objectives: the “no need to share knowledge since once objectives are met, it wont be needed anymore” syndrome.
11. Job Description framing: The 'No-one's paying us to have a wider vision' syndrome.
13. Only money talks: The 'those so-called stakeholders aren't actually funding anything directly, so they're not real customers' syndrome.
15. Modesty resulting from lack of encouragement: the 'who am I to teach others, of course they know' syndrome.
From the 14 barriers not linked to a cultural trait, I identified only 4 that each warranted a new cultural trait in my list. Here are the 4 new traits with the associated syndromes:
17. Dominance of explicit over tacit knowledge sharing:
The 'we only truly value what is written down and validated' syndrome.
18. Lack of social networks:
The 'only networks supporting business processes are important and encouraged' syndrome.
19. Lack of knowledge management strategy and sharing initiatives into the company’s goals and strategic approach:
The 'Intellectual Property is the only Intellectual Capital that is worth managing strategically' syndrome.
20. High internal competitiveness within business units, functional areas, and subsidiaries:
The 'we only share knowledge within our team since everyone else is potential competition' syndrome.
So that makes now 20 traits of organisational cultures not conducive to knowledge-sharing.
If you identify one missing, please let me know.
22 February 2008
22 January 2008
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
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. “
19 January 2008
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.
09 January 2008
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.
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.
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.
Subscribe to:
Posts (Atom)