Share This:
On Enterprise Architecture

By Samuel Holcman, The Enterprise Architecture Center Of Excellence (EACOE)

People interested in Enterprise Architecture are in a difficult spot;  it is our belief it has become more difficult than ever to separate Enterprise Architecture facts from beliefs, experiences from opinions, and sound practices from declarations.  This situation has risen as consultants, practitioners, academics, and publications present Enterprise Architecture in a disarrayed voice of multiple approaches, multiple meanings, and multiple sets of expectations – some based on experience, some based on conjecture, and some based on opinion.  With blogs, forums, dozens of enterprise architecture organizations of various types, and the internet itself, how do you sort things out?

One principle criteria is

“Does this make sense?”

We look at “physical analogies” and relate them to what we hear about Enterprise Architecture, and if it does not make sense in the physical world, it probably is not true in the Enterprise or Enterprise Architecture world.

That is, we suggest we favor logic over “what I want to believe.”

Another criterion is

“Is this just a statement?”

Unfortunately, saying something one thousand times does not make it so.

A third criterion is

“Who is saying this, and what is their background?”

Have they verifiably actually ever done Enterprise Architecture (whatever their definition)?

There are many more criteria we are sure we can all think of!

An excerpt from one enterprise architecture forum is enlightening;  the suggestion from a respondent on where to get Enterprise Architecture information:

“Do a Google search; there is plenty of information available about Enterprise Architecture. Wikipedia has a concise description of it.”

The response from one of the readers of this forum:

“This is good advice.  Every neurosurgeon, before operating, should quickly do a few Google searches, consult Wikipedia, or pop out and canvas ten or so passers-by in the street to get a “grassroots” feel about thoughts on the latest developments in his/her field!”

We have nothing against Google or Wikipedia (or any other sources of this kind), but point well taken!

What follows is a compilation of the most common questions from attendees at the Enterprise Architecture Center Of Excellence (EACOE) Certification Workshops, and our responses.  Our hope is that the reader will find the responses to these questions logical, fact based, and sound practices and principles-based.  We can assure you these responses are definitively based on decades practice experiences.  Hopefully our credentials are known to you.

What is Enterprise Architecture?

Enterprise Architecture Defined from an information and technology perspective

Enterprise Architecture is explicitly describing an organization through a set of independent, non-redundant artifacts, defining how these artifacts interrelate with each other, and developing a set of prioritized, aligned initiatives and roadmaps to understand the organization, communicate this understanding to stakeholders, and move the organization forward to its desired state.

Enterprise Architecture Defined from a business perspective

Enterprise Architecture illuminates how an organization and all of its members can achieve its objectives, through the creation of a series of engineered models and project initiatives, that can be easily understood by all of the people associated with the organization.

How do you view the term 'Enterprise' within this definition?
A definition of “Enterprise” in this context is any collection of “organizations/people” and related things, that has a common set of goals/principles, and/or single bottom line. In that sense, an Enterprise can be a whole corporation, a division of a corporation, a government organization, a single department, or a network of geographically distant organizations linked together by common objectives, a project, a team, etc. The “wider” the definition of the term “enterprise”, the more opportunity there is for “integration”. A “narrow” definition of enterprise leads to more “interfacing”.
How do you view the term “Architecture” within this definition?
Architecture is the art and science of “building (construction)” representations, and the manner in which components and artifacts are organized, related, and integrated.
Is Enterprise Architecture about information technology (IT) or is it about the entire enterprise?
The answer for Enterprise Architecture is, it is not “or”. It is about both the enterprise (business understanding), and the technology enablement (IT) of the enterprise. This follows from the definition of Enterprise Architecture above. As a note, “technology” can include paper and pencil. Within this question is an underlying question – “what does the Enterprise Architect do”? The Enterprise Architect does not do everything in the field of Enterprise Architecture – this is a fundamental confusion. Doctors do not do everything in the medical profession; electrical engineers do not do everything in the engineering profession, etc. The EACOE defined twelve Architecture Modeling Roles, which are mutually exclusive – providing clear role responsibility, and complete – no loose ends or unassigned gray areas to be overlooked, or to be a source of concern, in Enterprise Architecture. These roles are: Enterprise Architect, Business Architect, Process Architect, Data Architect, Policy / Rule Architect, Role Architect, Logistic Architect, Event / Sequence Architect, Rule Assertion Architect, Workflow Architect, Technology Architect, and Event State Architect. Of course, this requires a “frame of reference”.
I guess I do enterprise information technology architecture – that is good, isn’t it?
We are not really sure what is meant by the phrase enterprise information technology architecture. If it means the current layout and inventory of technology assets, then it should be called technology assets and logistics layout. If it means the connectivity of various technology assets, it can be called the technology blueprint. Architecture and implementation are different. You may be able to “architect” the current assets of information technology, but without the “enterprise architecture” desired state, architecting the desired state technology architecture has little value (we did not say it has no value.). Questions need to be asked. What are you architecting against? How do you know if the technology has anything to do with the business and its future intent? Going back to the definition of Enterprise Architecture, Enterprise Architecture is about understanding the business intent, and the technology to achieve the business intent. Setting up an enterprise information technology architecture out of context from the enterprise architecture is not desirable, and may be one root of the belief that Enterprise Architecture is about information technology only.
I can use any framework – there are many out there - correct?
A framework is a structure that organizes a set of related artifacts. The framework shows the relationships of the artifacts of the chosen subject area and brings a totality perspective to otherwise individual ideas. A framework, therefore, makes the unorganized organized and coherent, and is fundamental to any profession or discipline – engineering, chemistry, physics, language, music, etc. Framework elements must be mutually exclusive and collectively exhaustive. A framework that is in constant update and versioning is troubling. It means that it is/was not complete. If we used version 4 of the framework, and we now have version 9, what does that say about the work we did with version 4? Can you imagine the English alphabet starting off with 15 letters (version 1), the going to 21 letters (version 2), and then going to 26 letters (version 3), and someone suggesting xy letters (version g)? How useful would that be? Can you imagine the periodic table of elements in chemistry having multiple versions? Chemistry would be alchemy. Can you imagine the notes in music to be in continuous versioning? It would really fun playing in an orchestra. A framework is fundamental to Enterprise Architecture. The Enterprise Framework TM, and the framework defined by John Zachman, meets the criteria for an Enterprise Architecture framework.
And a methodology?
A framework is not a methodology, and a methodology is not a framework. A framework can possibly accommodate many methodologies, but we have not seen a methodology work across multiple frameworks (not in the physical world, so we cannot believe it will be different in the enterprise architecture world). A methodology has practices and procedures applied to a specific branch of knowledge. A methodology has proven processes followed in planning, defining, analyzing, designing, building, testing, and implementing the area under consideration. An outstanding methodology guides the process, simplifies the process, standardizes the process, can be customized to meet specific standards and practices of the using organization, is correct, is up to date, is complete, is concise, defines deliverables, has methods, has techniques, has standards, has practices, has roles and responsibilities, has suggested timings, has suggested sequences and dependencies, and has associated education. Guidelines are not methodologies. Saying you can do this, or that, or that and this – are guidelines. Providing suggestions on deliverables are guidelines. Methodologies should provide a path, or provide predefined paths. You should be able to do something “Monday morning” with a methodology – not start trying to figure out how to take a guideline and turn it into a path to follow. The Pinnacle Business Group, Inc. Quick Start Methodology meets the criteria for an Enterprise Architecture Methodology.
I need my Enterprise Architecture to fit on one page – after all, it only has to be at a high level.
We are not sure what you are actually trying to do in one page, but it is not an Enterprise Architecture. If you have had the privilege, or frustration of ever building a house, you know you get a “scroll” of diagrams (blueprints) with the house. If something as simple as a house needs a scroll of drawings, an Enterprise Architecture will, at a minimum, require a scroll of drawings. There is also a hint we can get from this analogy. There is no one “picture” that solves all constituents or stakeholders needs in building a house. There is, therefore, no one drawing that will solve all needs for Enterprise Architecture stakeholders – complexity is much greater. We suggest there are thirty possible Architectural model representations that may be of interest to various enterprise stakeholders, and 684 possible Implementation model representations that may be of interest to various enterprise stakeholders. We can calculate this census of models because we have a frame of reference. We have not said that we have to develop all of these representations today. However, anything that is not made explicit does not mean it does not exist – it is just implicit, and we are making a value judgment to not have that specific representation made explicit. We are sure glad we can understand what we know and are making explicit, and also know what we are making assumptions about (what remains implicit). This is due to the frame of reference – the Framework.

Our primary criteria for business-facing models is

Are they “human consumable”?

Our primary criteria for technology and implementation facing models is

Are they transformable into solutions?

Different audiences require different criteria.

Enterprises are different and don’t need the level of specificity of buildings, or airplanes, or ocean liners, or other physical items – correct?
In two words – why not? What is the basis of this belief? We truly wish this was correct. We believe that enterprises are much more complex than any of these physical items. If you are building a rowboat, you probably do not need much architecture. If you are building an ocean liner, you need extensive architecture, at great detail. If you are building a model airplane, you probably do not need much architecture. If you are building a Boeing 747, that flies over water, at night (with us in it!), you need extensive architecture, at great detail. If you are building a log cabin, you probably do not need much architecture. If you are building a 100 story building, you need extensive architecture. Ask the people that recently completed the Trump International Hotel and Tower in Chicago how much time they spent on architecture and how much time they spent on implementation. You may be surprised. We do not think you will be surprised at the level of detail for the hotel and tower. So therefore, if you have an enterprise that is the corner store, you probably do not need much enterprise architecture. If you are building an enterprise, around the world, with thousands of employees, undergoing constant change, you need extensive architecture. Architecture is the baseline for managing complexity and change. If it is not, what will be used to address complexity and change, and what are you going to do to avoid unintended (no details in your architecture) consequences? Architecture is about planning, analyzing, designing, and constructing, and hopefully we can stop using a different, presently more common lifecycle – constructing, maintaining, maintaining, maintaining. What is your approach to managing complexity and change, if is not Enterprise Architecture? This does not mean we have to do everything at once. Enterprise Architecture is a continuous process, with greater granularity of its artifacts over time as the enterprise changes, and more of the enterprise is “mechanized” or “automated”. Architecture occurs prior to making a change. Documentation occurs after the change is made. This is the only logical and practical way to do this in a cost effective manner. Our objective is to continually reduce the risk of unintended consequences, and “inappropriate” changes.
What abilities are required for Enterprise Architecture?
The abilities and skills change for the twelve Roles defined for Enterprise Architecture. The skills mix changes as you move from the “top” of the Enterprise Framework to other Roles in the Enterprise Framework. Generally, more soft skills (facilitation, meeting dynamics, communications, etc.) are required at the business layer roles than at the other layers. More hard skills (modeling, technology transformations, etc.) are required at the technology transformation layers of the Enterprise Framework. We would suggest that both hard and soft abilities and skills, to different degrees, are required for all Architect Roles in an Enterprise Architecture.
An analogy you often use is Engineering and Manufacturing – can you elaborate?
First, it is an analogy. We do not really know if, eventually, we will be able to engineer and/or manufacture an enterprise. We have seen the continual movement from “hand crafting” things to “manufacturing” things in almost every discipline that we can think of. Let’s see what the future holds for enterprises. The study of enterprises is only about sixty years old. More importantly, the analogy is to suggest two separate but linked disciplines exist in the physical world, and Enterprises need to take notice of this. These disciplines are Engineering (Architecture), and Manufacturing (Implementation). In the beginning of each new discipline, we tend to begin in manufacturing (Implementation). Think hand crafting automobiles 150 years ago. Once there is a body of knowledge about a discipline that is codified (engineering), this codified knowledge is used to produce better engineered products (better implementations). So the sequence is manufacturing to engineering to better manufactured products. This analogy fits perfectly in Enterprises today. Most of what is done in Enterprises can be considered to be Implementations (manufacturing). We are now codifying this enterprise understanding (Architecture), and eventually we will be able to produce better enterprise Implementations. So the sequence in Enterprises will be implementations to architecture to better implemented solutions and products.

Article Name
On Enterprise Architecture
People interested in Enterprise Architecture are in a difficult spot; it is our belief it has become more difficult than ever to separate Enterprise Architecture facts from beliefs, experiences from opinions, and sound practices from declarations.
Publisher Name
Enterprise Architecture Center of Excellance
Publisher Logo

Share This: