An enterprise architecture (EA) is a series of conceptual blueprints that defines the structure and operation of an organization to enable strategic progress.
Enterprise Architecture (EA) explicitly describes an organization through a set of independent, non-redundant artifacts, defines how these artifacts relate with each other, and develops a set of prioritized, aligned initiatives and roadmaps to understand the organization, communicate this understanding to stakeholders, and moves the organization forward to its desired state.
Now, let’s dissect this definition, because it contains a number of items that are quite important. The first thing we have to recognize is that your organization has an Enterprise Architecture, whether it’s explicit or not. Of course, if it’s not explicit, it’s implicit, and you’re making guesses about it. So, one of the important things to recognize is that Enterprise Architecture is about making the implicit explicit.
“Through a set of independent, non-redundant artifacts.” What is that saying? We must use science and technology to determine the minimum set of things that will allow us to understand the enterprise in its future state and in its present state. “Independent and non-redundant”. Another way to say that is mutually exclusive and as collectively exhaustive as practical.
The second set of representations we need are what we refer to as relationships between those artifacts. As examples, what are the relationships between a goal and a process? What are the relationships between a process and a material (sometimes referred to as data)? In addition, there are a number of other relationships that are key to understand the enterprise. These all are commonly referred to as implementation models, because what these representations are, essentially, is how you take the architectural elements that you understand in your enterprise, and combine them together for a specific solution – an implementation.
These representations will drive a set of prioritized, aligned initiatives and roadmaps to execute those initiatives. A series of models is woefully inadequate to understand the enterprise – the models are a means to an end, not the end in and of itself. What Enterprise Architecture is actually doing is deriving and defining the initiatives needed to move the enterprise to its desired state. Another name for initiatives could be capabilities, focus areas, projects, or programs. Many different phrases are used to describe the results of a true Enterprise Architecture.
One of the most important things in the resulting Enterprise Architecture is the communication to stakeholders. We suggest that the representations in Enterprise Architecture need to be human-consumable. Human-consumable, not “computer compiler consumable.” Given current realities, this communication should be done in less than 90 seconds to the stakeholders. That doesn’t mean that the stakeholder/consumer can understand how these items were built, but they need to understand how to read them and use them, in less than 90 seconds. It is just the way life is in the 21st century. Education and training in the concepts and best practices is essential for stakeholder effectiveness.
Finally, Enterprise Architecture provides a roadmap to guide the organization from its “as-is” state to its desired state.
Figure 1: Basic Enterprise Architecture Definition – Process Steps
Enterprise Architecture is not to be confused with EITA, Enterprise Information Technology Architecture. This is something that people are recognizing, that Enterprise ITA – which is what is commonly practiced – is very different from a true Enterprise Architecture.
Enterprise Architecture Participants
Who actually makes a good Enterprise Architect and who makes a good Enterprise Architect team member?
Enterprise Architecture participants may find the effort at times, fascinating, enlightening, frustrating, fun, tedious, inspiring, hectic, confusing, informative, rewarding, and sometimes politically challenging, as well as politically rewarding. When an Enterprise Architecture (EA) transitional roadmap begins to take shape, each person participating in the EA program will have increased their knowledge of the enterprise. The value they can provide to the enterprise, the ability to understand where the enterprise is, and where it can and needs to go, will make the Enterprise Architecture participants trusted advisors, not just “order takers” for information systems.
Certain levels of industry and relevant market experience, organizational position, business acumen, and influences are part of the successful Enterprise Architect and Enterprise Architecture team member candidate resumes. In addition to having achieved certain levels of position and knowledge within the enterprise, each person in the Enterprise Architecture team will need to delegate or transfer their daily responsibilities to focus on the EA effort, if their focus is not full-time in Enterprise Architecture. Enterprise Architecture cannot deliver solid results when individuals spend an hour or so a day on this effort.
There are a variety of skills and personal traits that contribute to the success of an Enterprise Architecture practitioner, or an Enterprise Architecture team participant. While not all of these will be found as strengths in a single person, many of these skills and traits enhance a person’s ability to contribute positively.
Enterprise Architects and EA participants need to be bright. They need to see and seek the big picture answers beyond their immediate scope, yet recognize there really is no such thing as a “high level of detail.” The devil is always in the detail.
EA’s need to be dedicated, willing to take on new tasks, and possibly, stretch their skills. Enterprise Architects and team participants need to be people that understand that their role is to build a path and bridge from the as-is state of the enterprise to the desired state of the enterprise. Enterprise Architects need to be someone who understands the undercurrent that change represents to many of their peers. Yet, the EA works to lead the change as a positive, invigorating challenge to everyone.
Participants in Enterprise Architecture activities will find that their Enterprise Architecture representations and presentations will be met with three possible receptions. The first possible result is passive, which is not good. The next alternative could be confrontational, which is not good either. The third and desired result is engaged learning reactions – fantastic, great, exceptional! Therefore, the effective Enterprise Architect must be able to overcome passivity and confrontation from their audiences, and be able to engage their stakeholders with presentations and representations that inform and encourage participation.
EA’s need to be good listeners. Enterprise Architects need to be articulate. They need to be voracious readers. A good Enterprise Architect is a good interviewer and skilled in documenting requirements. Most importantly, Enterprise Architects need to be people who like people. Enterprise Architects are communicating with people, not computer compilers.
Enterprise architects need to be very organized. They need to be project managers. They need to have skills in librarian activities, such as digging into the core meaning and definition of things and organizing these for others, and for reference. EA’s need grammatical precision because words have specific meaning.
Finally, Enterprise Architects must recognize that the recipients of their efforts are customers and not users. There is very big difference between “customers” and “users.”
Conclusion
When Enterprise Architecture delivers “human consumable” deliverables, rather than the typical EITA deliverable seen in some practices today, business personnel and executives will quickly understand the value of Enterprise Architecture. Practicing proper Enterprise Architecture processes with the right team members will yield a valuable Enterprise Architecture. Enterprise Architecture will help to develop and implement an efficient and flexible enterprise that enables the defined enterprise strategy. That is really what Enterprise Architecture is about – enabling enterprise strategy.
