This blog provides guidelines for the EA decision-making process, highlighting the importance of recognising EA as a knowledge management discipline.
EA as a Knowledge Management Discipline
It is sometimes useful to see the similarities and differences between Enterprise Architecture and Building Architecture. It was the analogy with buildings which originally suggested that the label “architecture” could be applied to information systems. And the tag was so appropriate that it stuck!
While there are many things that enterprise architects can learn using the analogy with buildings, it is also important to recognize that EA is a very different discipline. The most obvious difference is that the subject matter for building architecture is something that has a tangible and physical manifestation, while EA deals with domains that are more ethereal and less concrete – such as software, processes, capabilities, or data.
I’ve said in the past that EA is to information in the way that building architecture is to space[i]. What I mean by this is that the most basic reason for architecting an enterprise is to make effective use of its information resource (in a similar way that building architects seek to make the best use of the available spaces).
This focus on the information resource means that Enterprise Architecture is very much a knowledge management discipline – but this isn’t always recognized by practitioners or stakeholders. Practitioners that emphasize information technology miss the point that the technology is only there because of the information. Information comes first – technology is second[ii]. And there is an all-too-common stakeholder perception that EA is a synonym for IT!
When I provide coaching and mentoring to EA teams, one of the big Ah Ha! moments is when they recognize that EA is a knowledge management discipline. It changes the way that they view artifacts and their reuse, and they find that software support for EA - such as Orbus Software’s iServer - becomes an ever more vital for managing artifacts. In fact, a tool like iServer is particularly important in this role: it provides the glue for bringing together diagrams and documents that would otherwise be hidden in Microsoft Word, Excel, PowerPoint, or Visio; and it supports collaboration between the EA team and stakeholders. These two capabilities are right at the core of effective knowledge management.
Here is a simple phrase you can adopt to remind you that architecting an enterprise is a knowledge management discipline: “information about...”
This will help you to get information about the architecture and information about business needs.
Here’s another tip: outcomes are important, especially if you are tasked with delivering the architecture vision or target architecture; but the process that produces those outcomes is also important. Fair process is a cornerstone of good knowledge management practice. Stakeholders want to know that they have been listened to, and that we (architects) have heard their ideas. The way that we gather information about the architecture or information about requirements will send out signals about the architectural decision-making process. For example, the EA team at a travel company were sending out signals that architectural decisions were made behind closed doors by a specialized team of architectural geeks – simply because they didn’t involve key stakeholders in the decision-making process or explain how they had reached their recommendations and conclusions. The process was seen as secretive and isolationist. It didn’t take too much effort to change this – by making the decision process open, by communicating and explaining what was wrong with the current architecture, and what could be achieved by changing the architecture. These changes showed a willingness to trust people, to seek their ideas, and to get their input and feedback on proposed changes.
When decision making is closed it is almost set up to fail. When decision making is open it builds trust, unlocks ideas, encourages genuine architectural-level debate, and develops the commitment critical to successful enterprise transformation.
Do not underestimate the value in explaining the rationale behind architectural decisions. When these are made explicit, it is so much easier to get buy-in, sponsorship, and ongoing support for architectural change. Friedrich Hayek, a Nobel laureate economist, said that “practically every individual has some advantage over all others in that he possesses unique information of which beneficial use might be made, but of which use can be made only if the decisions depending on it are left to him or are made with his active cooperation.[iii]”
As a final tip, here are the three critical guidelines for making your EA practice a knowledge management discipline and improving the EA decision-making process:
Building architecture is things that are solid and hard; enterprise architecture deals with things that are adaptable and soft. When it comes to Enterprise Architecture as a Knowledge Management Discipline, it is not what you do but the way that you do the EA Decision-Making Process.
[i] http://it.toolbox.com/blogs/architecting-information/what-is-business-architecture-17605 or http://content.yudu.com/Library/A1nec7/160CharacterChalleng/resources/50.htm
[ii] Hence the title of my book on EA, Information First - http://www.amazon.co.uk/Information-First-Integrating-Knowledge-Architecture/dp/0750658584
[iii] http://www.sjsu.edu/faculty/watkins/hayek.htm - The Price System as a Mechanism for Using Knowledge, by Friedrich A. Hayek