Enterprise architecture (EA) is critical in the federated information technology space by providing a structured framework and methodology for aligning an organization's IT capabilities with its business goals and objectives. Enterprise architecture becomes even more essential in a federated IT environment where different departments or business units within an organization may have a degree of autonomy over their IT systems and resources. Here's how EA contributes to the success of a federated IT landscape: 

In an era where digital transformation is not just a buzzword but a central tenet to organizational longevity, the enterprise architect (EA) has transitioned from being a back-office role to a critical advisor to leadership. Their relevance in steering the company's strategic trajectory is paramount. Here's my perspective:

As professionals, we understand and appreciate the need for continual professional development (CPD). Associations, training organizations, etc. exist to help facilitate this need. However, one of the most important aspects of a well-balanced approach to CPD is having access to a diversity of thought.

I have been working in the area of Enterprise Architecture for 40 years and people have been telling me (and are still telling me) the reasons why they think it is impossible to do Enterprise Architecture. I think I have distilled these reasons down to five basic objections. Let me enumerate their objections before I explain why these objections exist and why they are completely unfounded. 

To return to the basic point ... the kind of descriptive representations (models) you need for engineering are different from the descriptive representations (models) you need for manufacturing.

OThe Framework is the Ontology

I have no idea where people get the idea that the Zachman Framework requires any documentation at all. The Zachman Framework is an ontology – the theory of the existence of essential components of an enterprise (actually, of anything) that warrant description in order to successfully create it, operate it or change it. Whether any or all of those components are described (documented, made explicit) is a function of a methodology and the choice of the Enterprise… not a requirement of the Framework.

I was asked by a PhD student to fill out a survey for research he was doing about the Enterprise Architecture Frameworks. This is a typical question I get, and it is no wonder because of the confusion about the word "Framework." Just because Enterprise Architect Frameworks have the word "Framework" in their titles, it doesn't mean you can compare the Zachman Framework with them. The Zachman Framework is the ontology. The other frameworks are METHODOLOGICAL frameworks, and the artifacts you create by following those methodologies potentially can be mapped back onto the Zachman Framework Ontology. 

After 30 years of talking about this, I am still shocked at the predominant misconception that the Rows of Zachman Framework define "level of detail," or "waterfall," or "decomposition." This is just not true. The Rows of the Zachman Framework define TRANSFORMATION, NOT decomposition. Level of detail is defined in the HEIGHT of each cell (or Row), NOT the height of the Framework itself. While I originally I called the Rows "Perspectives," the underlying theory that defines the Rows is the philosophical concept of Reification. 

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day. 

The common perception (or more appropriately, mis-perception) of Enterprise Architecture in the general marketplace today is that it is one of an Information Technology (IT), model-building exercise. There is validity to that perception because, in order to engineer the Enterprise, the engineering design artifacts (the descriptive representations of the Enterprise) have to be created as they are the "raw material" for doing engineering work and the IT community seems to have the skills to produce those engineering design artifacts. 

 The advent of the commercial employment of computers in the 1950's ushered in an era of dramatic productivity improvements in both the private and public sectors. Clearly, using a computer to perform the processes of the business rather than people performing the processes is better because computers do things the same way every time whereas people make mistakes, computers perform in electrical (or electronic) cycle times and people in human cycle times and computers (in most cases) are cheaper than labor.

I recently ran across some notes I took from a presentation at an IBM SHARE Conference, August 1991 that may shed some light on the idea of Professionalism. 

Peter Drucker points out that that this is not the first Information Revolution, this is "The NEXT Information Revolution,"(1) the fourth Information Revolution.

Architecture Is Not a New IdeaThe ideas about Architecture have been around for a long time. In the old days we used to call this kind of thing "Enterprise Analysis." The whole concept of Enterprise Analysis was, or is, you try to understand the Enterprise first, before you try to overlay infrastructure kinds of things against it. 

We've been having a great GovEA Conference this year- no shortage of good speakers, exhibits and vendors.

I had the distinct pleasure of introducing my long-time friend and colleague, Scott Bernard who has been the U.S. Federal Chief Enterprise Architect for the last several years.

There presently appears to be a gross misunderstanding about Enterprise Architecture among management... but also among the information community as well. Enterprise Architecture is NOT an Information Technology issue... it is a Management issue. It is likely perceived to be an Information Technology issue as opposed to a Management issue for two reasons:  

So, why is it that an Enterprise needs Information Technology people in their Enterprise in the Information Age?

When I happen to be talking to some IT folks and I raise the question, "Why does the Enterprise need Information Technology people in their Enterprise in the Information Age?" I usually warn them at this point that I haven't had an hour and a half or so to soften them up and I am going to make a radical comment... so don't fall of their chairs when I say this but...

The Enterprises of today (2015) have never been engineered. They happen... incrementally... over the life of the Enterprise as it grows and requires formalisms... "systems", manual and/or automated.  

Here are some samples of seminal works that constitute the origins of Enterprise Architecture:

The Information AgeHere is a little context around the Information Age. In the interest of time and space, I will try to be brief but there is a key point I have to make. Having made this observation, I will limit my comments about the Information Age to some well-known works by Alvin Toffler, and I will probably break this blog into three separate parts based on the following, so look for those shortly: