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?