Towards an Enterprise Architecture of Knowledge

A customary way of modelling an enterprise is as a collection of purposeful behaviours - functions or processes or capabilities or whatever. Each function or process or capability encapsulates some knowledge or know-how. Sometimes this knowledge will be fairly static, so the behaviour will be stable and unchanging. And sometimes the underlying knowledge will change, so the behaviour will need to be adjusted to accommodate the most up-to-date and relevant knowledge. In some areas, such as product development and marketing, there may be a strategic imperative to find and assimilate new knowledge and ideas (about market trends, technology trends, competitor trends, and so on), to build new collaborative partnerships, and to experiment with new behaviours. These areas will rely on business intelligence - not just BI tools but all the practices associated with collecting and making sense of complex information.

The overall architecture of the enterprise can then be understood in terms of how these functions or processes or capabilities interoperate to produce a viable system-of-systems. The enterprise architect must understand which of these functions are relatively stable, which of them are strategically volatile, and create appropriate mechanisms for coordinating between them. These mechanisms are essentially behavioural ones - information flows, event triggers, process flows and so on.

But if we look at the enterprise through a knowledge management lens, we will see a different kind of structure. There is a series of overlapping knowledge domains - marketing, accounting, regulatory compliance, health and safety, employment, technology - each with its own specialist terminology and ways of thinking. So there is an architectural question about how these knowledge domains (we might also call them agendas or discourses) interoperate.

In a traditional organization, these knowledge domains only come together at board level, with one or more directors speaking for each significant domain. Thus the CTO speaks for the technology domain, the HR director speaks for the employment domain, and so on. Of course all the directors will try to influence the agenda of their peers - so everyone else might be citing random snippets of evidence of technology trends, or challenging the CTO's decisions and interpretations, pushing the CTO to explain or change direction. In a well-functioning organization, this will be all done in the spirit of healthy and vigorous debate.

In a hierarchical organization, some pieces of this debate can of course be delegated - either to internal departments or to external consultants - but the directors remain responsible for putting the pieces together.  

Thus the coherence and intelligence of a traditional organization depends heavily on the collective intelligence and effective functioning of the board of directors. But there are several evident problems with this approach. Firstly, we can observe many organizations that lack coherence and intelligence, so this approach is manifestly not working well enough for these organizations. Secondly, we may assume that the board of directors has a finite reasoning capacity - however clever they are as individuals, and however well-bonded they are as a team - and that they will not always be able to keep up with the increasing complexity and volatility of the business environment. And thirdly, we can see a lack of joined-up intelligence at the lower levels of the organization.

Some people think there is a different way of integrating an enterprise. If we can identify a single universal knowledge domain, then we can use this knowledge domain to join up everything else. For example, in a financially driven organization, management accounting acts as a unifying language across all functions. Conversely, many enterprise architects regard their favourite EA framework as providing such a unifying language. Although there have certainly been very large organizations that have been managed according to a single unifying principle (such as GEC under Lord Weinstock), the fact that there are several specialisms each wanting to be top dog helps to explain why this doesn't work very often.

A third idea would be a bottom-up Enterprise 2.0 swarm intelligence, in which a satisfactory resolution to all difficult issues emerges from uncontrolled debate and "sharing" across the organization. To read some of the material on the internet, it's tempting to believe that this is how some of the really cool organizations in Silicon Valley are organized. But even if this were true, there is still a need for some kind of architecture and governance, for example, providing suitable platforms and pathways for constructive and reasonably efficient problem-solving. Kevin Kelly, whose book Out of Control introduced me and many other people to the huge potential of bottom-up intelligence, is careful to warn that the bottom is not enough.

Which brings me to the fourth idea - regarding the coherence and intelligence of the knowledge-bearing organization as a real architectural issue. Not the kind of structure that enterprise architects are accustomed to modelling or managing perhaps, but this structure may have a significant effect on the business outcomes of the organization. Isn't this something enterprise architects should be interested in?

Intelligent Knowledge Management

@snowded has started a series of blogposts about knowledge sharing across silos (part one, part two). He starts by identifying a number of different types of knowledge that (some people think) it might be valuable to share.

• Data - avoiding duplication between data stores - for example consolidating all health records in a single database
  

• Information - ensuing all relevant information is available to support critical decisions and actions - see for example my post on Joined-up Healthcare
  

• Transactions - a sense that the citizen or customer has to navigate tortuous pathways through the bureaucracy

• Practice - good practice developed in one area is not appreciated or understood elsewhere
  

• Ideas - innovative combination and variation of issues, ideas, solutions and problems from within different silos

Obviously a mixed bunch of stuff here, and it seems very confusing to lump all of this under the heading of "knowledge management". As Dave points out, some of these look more like information flow. However, suppliers of knowledge management products and services (consultants and tool vendors) typically want to find as many different applications for their stuff as they can. Knowledge is therefore presented as a way of achieving a bunch of different things.

• more efficient information systems and working procedures
• improved decisions
• more effective and convenient customer service
• faster, more efficient and more consistent innovation
• greater cooperation and collaboration
  

Underlying the knowledge management agenda are a number of (usually) unexamined assumptions

• most of the knowledge we need already exists in people's heads - we just have to get it out
• knowledge is additive - the more knowledge we can "capture" or "extract" the better
• explicit knowledge is better than implicit or tacit knowledge - codification is a "good thing"
  

Thus knowledge management becomes a combination of documentation/codification and librarianship, plus whatever persuasion or coercion may be necessary to encourage people to participate in this game. Added to this is a kind of open-ended information retrieval, as exemplified by IBM's Lotus Knows campaign. (See my comments here.)

Undoubtedly there are some situations where this kind of thing can deliver direct value to the organization - for example in pharmaceuticals, where any delays in the assembly of regulatory information for a new drug can cost millions of dollars in lost revenue. But is this really knowledge management, or just a sophisticated form of information management?

An alternative approach to knowledge management is to leave it in people's heads, but then to provide knowledge maps that tell everyone whom to ask. The trouble with this approach is that the genuine experts often keep their heads down, for fear of being swamped with enquiries from around the globe, while attention-seekers use this as an opportunity to promote themselves. Thus questions of motivation and excellence must be addressed, and knowledge management becomes a branch of Human Resources.

---

Meanwhile, I've been reading a couple of older critiques of the 'knowledge management' industry.

• Erik Bergman, When bad things happen to good ideas (CIO, May 2001) via @rotkapchen
  
• T.D. Wilson, The nonsense of 'knowledge management' (Information Research, October 2002) via @oscarberg
  

Although these papers predate the recent explosion of web-based knowledge management tools (including Enterprise 2.0, however that is defined), the issues raised in these two papers largely remain unaddressed. Bergman points out that knowledge management is often regarded as a technological initiative. He mentions a number of very expensive white elephants, which failed largely because they failed to address the real business objectives or the real cultural and working practices of the organization. Wilson raises some more fundamental issues, suggesting that the knowledge management agenda is muddled and self-serving, and that Polyani's original concept of tacit knowledge has been grossly misinterpreted in order to promote an utopian fantasy of the manageability of the human mind.

So what (if anything) can we rescue from this mess?

Well we might start by shifting from "knowledge as a resource" to "knowledge as a process", as Gil Ariely argues in his paper Knowledge Management as a Methodology towards Intellectual Capital (Sept 2003, pdf). See also Interview with George Siemens (Dec 2009). Unfortunately, this phrase was long ago coopted by solution providers - for example in their paper Knowledge Asset Management, (June 2001), Ron Young and Gregoris N. Mentzas describe what they claim to be "one of the world’s first truly holistic and integrated knowledge management solutions". Holistic, huh?

Perhaps knowledge management shouldn't be about grabbing and hoarding stuff but about deploying it intelligently. This points us towards concepts like Evidence-Based Management, where knowledge is collected, analysed and deployed within a management loop. Consultancies promoting this and similar concepts include Pfeffer's and Sutton's Evidence-Based Management, as well as Management Epistemology. and the Knowledge Management Consortium - see for example the KMCI paper Corporate Epistemology (November 2003, pdf).

This kind of approach shifts the emphasis from knowledge sharing to knowledge embedding - grounding the work in the best available and critically evaluated knowledge, as well as actively seeking well-grounded knowledge to support organizational learning. Obviously collaboration is important here, but there is a distinction between collaborating-in-the-work (for example shared responsibility for decisions) and collaborating-in-the-knowledge (for example, shared responsibility for collecting and interpreting intelligence, connecting the dots). This distinction builds upon the RAEW technique we have long used for analysing organizations. A key question here is the relationship between decision and intelligence - how closely the expertise and authority should be coupled/aligned to the work itself.

What characterizes the intelligent organization is not just having more knowledge than its competitors, or even doing better at sharing the knowledge it has, but how effectively it invests its entire knowledge capital to increase its own viability and survival. This is so not a technology question, or even a best-practice question, but a strategic question. But you already knew that, didn't you?

---

see also When does Communication count as Knowledge Sharing?

Business Design Choices

The SOA Consortium (part of the OMG) has published a Business Architecture Paper, edited by Brenda Michelson. The paper presents the following case for formalized Business Architecture under IT leadership.

1. Business architecture is a critical input to IT planning, technology architecture and business solution delivery.

2. Technology trends and IT capabilities influence business design choices in the realms of capabilities, value chains, processes, and channels.

3. Business architecture provides the mechanism to clearly illuminate how strategy, processes, business structure and staff can best be utilized to deliver reliable and cost effective operations. With this clarity business can enable new functions and services, with the right resources and technology, effectively and efficiently.

4. Business architecture can help organizations analyze key value chains. Organizations can eliminate duplicate operations, processes and technologies across business units and functions. Business architecture provides the methods to analyze and plan how the organization should morph its structure, processes, technology and staff.

5. The most likely origin of a business architecture practice is within IT.

It is difficult to see anything here that wasn't included in the Business Systems Planning and Business Engineering methodologies I first saw in the 1980s - for example, as a front-end to such methodologies as Information Engineering. Nowadays, Michael Porter's value chain concept is taught in high school business studies; so unless business managers are really thick, they are not going to need help from IT folk to "analyse key value chains".


Actually, there are some more advanced business design choices where business architecture has a useful role to play, and where some IT people might have some relevant aptitude, but the SOA Consortium doesn't mention any of these. I see the real challenge for business architecture being to appreciate the economic and social impact of structure. And by structure, I don't just mean the kind of line-and-box diagram or simplistic block diagram that most so-called architects produce, whether in Powerpoint or some cheap modelling tool, but something that reflects the real complexity of the business.



So what are these "business design choices" then? Well, this is a topic I've been talking about for many years, going back to my 2001 book on the Component-Based Business. Here are some critical ones, all of which I've discussed on this blog before, as well as in articles for the CBDI Journal.

1. Coupling. Which "components" of the business need to be closely aligned (tightly coupled) and which "components" should be autonomous (loosely coupled)? How is an enterprise governed as a system-of-systems? How do we reason about the properties of the whole enterprise?


2. Differentiation and Integration. Where does standardization make sense, and where should requisite variety be deployed? This question goes back to the work of Lawrence and Lorsch (see summary here), and has recently been rediscovered (in slightly different terms) in the book Enterprise Architecture and Strategy.

 
Operating Model Quadrants (Adapted by Clive Finkelstein from Figure 2.3 of “Enterprise Architecture as Strategy”) - Source The Enterprise Newsletter #38.

3. Business as a Platform. A business provides a set of services to its customers. There is a strategic choice between a high-volume generalized platform, which takes a small slice of a large amount of activity, and a lower-volume specialized platform, which takes a much larger slice of a relatively smaller amount of activity. So for example, how does a telecoms company create value-adding services on top of the basic calling services (which are getting continually cheaper, thus eroding core revenue) without losing the economics of scale.

4. Edge Organization. What are the structural implications of turning your business upside-down and inside-out to address the dynamics of the demand environment?

5. Viable Business. What structures are required to support the intelligent organization?


So there is a set of really interesting and important issues here, which some of the smarter business people in the more complex industry sectors (aerospace, telecoms) are already trying to tackle. There are some new and emerging techniques for tackling these complex problems, including Asymmetric Design, as well as some older but underused techniques. However, I don't yet see much evidence of enterprise architects stepping up to the real challenges of business architecture.