Enterprise architecture, somewhat axiomatically derives its name from the planning and design of construction projects. Yet oftentimes the analogy is leaned on too heavily and the differences are sometimes overlooked.
Construction architectures have tangible and physical manifestations, as opposed to the ethereal and less concrete arenas of software, process, capabilities and data. The comparison is most apt in the sense that EA is to information what building architecture is to space. Put another way, it involves looking to maximize the effectiveness of information, much like a construction project intends to harness the use of space.
The focus on information underpins the notion of enterprise architecture as a knowledge management discipline, but this isn’t always recognized by practitioners or stakeholders. It’s not uncommon for practitioners to emphasize information technology, only to spend far too long focusing on the latter part of the equation. Moreover, there is the ubiquitous stakeholder perception that EA is a synonym for IT!
When coaching and mentoring businesses, one of the big eureka moments is coming to understand enterprise architecture as a knowledge management discipline. It enables organizations to change the way they view and reuse artifacts. A knock-on effect, of course, is that the appropriate tooling becomes increasingly important, providing the glue for bringing together diagrams and documents that would otherwise be hidden in Microsoft Word, Excel, PowerPoint, or Visio. At the same time, collaboration between the EA team and stakeholders become ever more vital. These two capabilities are right at the core of effective knowledge management.
Information, Processes and Outcomes
Interpreting EA as a knowledge management discipline requires information about architectures, applications and processes. So, when identifying the strategy or business drivers and requirements, it’s important to ask information gathering questions: 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?
Outcomes are important, especially when delivering the architecture vision, and so are the processes that get you there. Fair process is a cornerstone of good knowledge management practices as stakeholders want to know they have been listened to and that architects have heard their ideas. The method of gathering information about architecture and its requirements sends out signals about the decision making process. Contrast this with decisions being made behind closed doors in a secretive and isolationist fashion and it's immediately obvious how the initiatives will be received. Making the decision process open and communicating regularly and clearly, shows a willingness to trust people, to seek their ideas, and to get their input and feedback on proposed changes.
Ultimately, when decision making is closed it is almost set up to fail. When open, it builds trust, unlocks ideas, encourages genuine architectural-level debate, and develops the commitment critical to successful enterprise transformation. Ultimately, if the rationale behind architectural decisions is made explicit, it becomes so much easier to get buy-in, sponsorship, and ongoing support for architectural change.
Guidelines for Running a Knowledge Management Discipline
So how do you make enterprise architecture a knowledge management discipline that improves decision making processes? Key guidelines to adhere to include:
- 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.
- Explain why each decision was made. This builds trust and shows that each person’s views have been considered and fairly evaluated and that decisions, priorities and trade-offs were in the overall interests of the enterprise.
- Let the entire organization know how the enterprise architecture decision-making process works. This builds trust by ensuring that everyone knows their responsibilities and what is expected, and who else is involved and how.
The initial point of contention in the building architecture analogy was that it focused on things that are tangible, whereas enterprise architecture deals with more adaptable and, at times, abstract concepts. By unpicking this further, we see the significance of difference: Successful enterprise architecture is not so much about the what, but rather how the decision making process is carried out. It is on this point that your EA initiative will live or die.