In 1987, John Zachman published an article in the IBM Systems Journal called A Framework for Information Systems Architecture which laid the formalized foundation of Enterprise Architecture. In the 1990s, John Zachman further develop the idea to classify, organize and understand an organization by creating The Zachman Framework™. The Zachman Framework™ talks about understanding an organization in terms of:
Today, the field of Enterprise Architecture (EA) also draws from the fields of Engineering, Computer Science, Business Administration, Operations Research, Psychology, Sociology, Political Science, Public Administration, and Management. Due to the advancements and inclusion of various fields, the definition of what EA is continues to evolve depending upon if you are a practitioner, academic, vendor or government but the basic premise of Enterprise Architecture is to holistically understand the entire organization to make management decisions.
In addition to The Zachman Framework™, there are many other EA frameworks that have emerged over the years to help an organization understanding where they are (current state or as-is), where they want to be (future state or to-be) and what steps (transitions) they should take to get to the future. Some of these EA frameworks include:
- The Open Group Architecture Framework (TOGAF)
- Federal Enterprise Architecture Framework (FEAF)
- Department of Defense Enterprise Architecture Framework (DoDAF)
To be clear, EA is not only about frameworks but its also about the EA methodology, tools, artifacts, and best practices. As you develop EA within your organization, you will realize that not all frameworks and tools would fit perfectly but it is a continuous improvement over time. Regardless of the size of the organization, EA can help create a holistic thinking mentality, optimize business processes and improve decision-making.
By now you might be thinking that of course, EA is the answer to your woes. But hold on! Before you jump into EA, it is critical to know: 1) The term EA and its jargon can confuse people, 2) EA is about the entire enterprise (aka organization) and not about just certain functions of the organization, 3) People working under the EA function should have a complete grasp of Business operations and IT capabilities, 4) EA is not an IT activity and 5) EA’s purpose is to communicate what is happening and what could happen.
For organizations, EA is like an overarching umbrella which when used effectively can have a profound impact but if used incorrectly can turn into a burden to carry. Keeping these things in mind, let’s ask the following questions:
Who is demanding the need for EA and who is creating it?
|Who should be demanding a need for EA and who should be creating it?|
|What if EA fails?||What should happen when EA fails?|
|Where EA is helping in decision-making?||Where EA should help in decision-making?|
|When EA artifacts are being collected?||When should EA artifacts be collected?|
|Why EA is being used?||
Why EA should be used?
As we can see, whoever sees a need for EA matters, EA champions within various organizational functions matters, EA execution matters, EA measurement matters and EA best practices for organizational-wide improvement matters. It should be noted that all organizations do EA in some way (unformalized, semi-formalized or fully formalized).