Enterprise Architecture as a Knowledge Management Discipline: Guidelines for the EA Decision-Making Process


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

  • When you are gathering information about architectures, use this phrase to precede the topic or domain that you are analyzing. So you might need to gather information about applications, or information about processes.
  • When you are identifying the strategic or business drivers and requirements, ask stakeholders: what information do you have about the need for a new website? Or what information do you have about competitors to show that we are losing market share? Do you have any information about anything (in the architecture) that prevents you from doing the things you want to do?

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:

  1. Involve people in the decisions that affect them – ask for their input, and allow them to challenge other ideas and assumptions. This builds trust and shows that their opinion is important.
  2. Explain why each decision was made. This builds trust and shows that each person’s views were considered and fairly evaluated, and that decisions, priorities and trade-offs were in the overall interests of the enterprise.
  3. Let everyone know how the EA decision-making process works. This builds trust by ensuring that everyone knows their responsibilities and what is expected from them, as well as letting them know who else is involved and how.

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.