Enterprise architecture at Infosys works at the intersection of business and technology to deliver tangible business outcomes and value in a timely manner by leveraging architecture and technology innovatively, extensively, and at optimal costs. Stay up-to-date on the latest trends and discussions in architecture, business capabilities, digital, cloud, application programming interfaces (APIs), innovations, and more.

« Legacy Modernization: A Recommended Approach for de-risking it | Main | Should Architects Make House Calls? »

The Death of the Enterprise Architecture Framework?

By Avinash Nicklas Malik, Senior Principal Strategic Architect, Infosys

Is it time to kill the EA framework?  Perhaps.

As the field of EA has matured, one thing has become clear.  Only a small percentage of the Enterprise Architecture framework concept is actually being used in the field.  This is not for lack of investment.

Over the course of the past decade, substantial investments have been made in time and expertise to create this "thing" we refer to as an Enterprise Architecture Framework.  It's curious because no other field of practice in any business setting has a "framework."  For some reason, Enterprise Architects have felt, for decades, that we need one.  I'd like to challenge that notion by making a comparison to chronic medical care.

What?  Chronic medical care?  Not city planning?  Not enterprise strategy management? 

Here is where the first mistake is often made.  Frameworks foster the notion of either project engagement (TOGAF) or big strategic planning engagements (Zachman and FEAF, etc).  The most effective enterprise architects that I have met, and that is a long list, understand that enterprise architecture is an ongoing activity that doesn't fit either category very well.  There are some big efforts, like discovering and naming the core underlying issues that are driving decisions in an organization, and setting principles to help guide them.  But most of the time, Enterprise Architecture is a day to day activity: work with teams to guide the decisions that go into socio-technical systems.

In that way, an Enterprise Architect is less like a strategic planner and more like an endocrinologist.  (An endocrinologist is a physician who specializes in diagnosis and treatment of hormones and endocrine system issues, including diabetes).  Once an organization understands that they need an enterprise architect, it is similar to the realization that a person needs to be seeing an doctor for their diabetes.  Instead of big diagnoses, an endocrinologist will see a diabetes patient relatively frequently (four or more times per year) to run tests and focus on the decisions that the patient is making: are you taking medication regularly, is your blood sugar controlled, are you exercising and losing weight.  Day to day decisions that, over time, produce a healthier patient.

An Enterprise Architect is effective when they are guiding the gradual development of the health of the ecosystem.  It is often repeated that an organization with a good enterprise architect is "fit for purpose."  I'd like to see the EA profession focus more on the concept of "fitness" and less on the concept of "ideal state".  We aren't really in the ideal state business.  We are in the fitness business. 

That is where our frameworks fail us.  The frameworks describes processes.  With TOGAF, the most widely adopted framework, there is an overarching technology process that starts with business alignment and cycles through requirements gathering, solution design, implementation and ongoing maintenance.  But the act of the patient "getting fit" doesn't require the physician to follow a process.  It requires the physician to follow a set of practices.

As I have studied the frameworks around the world, I have seen a sturdy emphasis on processes that an architect needs to use.  Sometimes there is an overarching process (as there is in TOGAF) and sometimes there are a series of related processes, but let there be no doubt that frameworks are all about process.  (See note on the Zachman ontology below). 

That "process focus" is why the framework concept should be killed

We do not need an overarching process.  Here is what we do need.

  • We need a core understanding of terminology (what is a capability, what is a system, what is a program, what is a business rule).  That is clear.  It is difficult to communicate without core terminology.  Every physician knows what a pancreas is and what conditions lead to ketoacidosis. Every enterprise architect should have a shared understanding of what a capability is, what a system is, and what a strategy is.  We cannot develop forward without these core understandings.

  • We need objectives to meet that are well understood and relevant to our organization.  There is no "one size fits all" Enterprise Architecture practice but there is a core concept of what EA is and does.  This has existed for many years, starting with nascent efforts in the frameworks themselves, up through the FEAPO perspectives paper, and now in commonly cited textbooks. 

  • We need a well understood set of deliverables and activities, along with the value that each provides. This can leverage the "design pattern" concept in that each activity or deliverable will have a set of conditions that drive the organization to undertake the efforts involved.  Just as Christopher Alexander described the concept of a pattern language, as as the Gang of Four translated that into technical patterns in object oriented design, Enterprise Architects need to develop an EA Pattern Language that describes not only what to do, but when to do it, without reference to some overlying technology process.

  • We need a set of best practices for producing the deliverables and/or performing the activities.  These practices can certainly evolve over time as the tools evolve, and as we grow in our understanding of usefulness. 

That's it.  We do not need to tie ourselves to software development lifecycles any more than physicians tie their efforts specifically to the age of the patient.  Certainly, software lifecycles matter (just as there are differences in treating diabetes for a 14 year old or a 41 year old).  But the practice of endocrinology is not based on following a rote process with every patient for every visit.  And the practice of Enterprise Architecture, day to day, does not involve following a rote process for every client or every client project.  

At the end of the day, most organizations already realize this.  That is why it is often difficult to "adopt" TOGAF.  Not that a staff team cannot be trained on TOGAF... but because TOGAF refers to a process that does not mirror either the real experience of system development nor does it produce the correct outcomes for an effective EA team. 

a note on the Zachman ontology -- John Zachman originally used the term Framework to refer to his concepts.  Over the years, he realized as I have that the word "framework" is heavily loaded with connotations of business processes and practices.  John has (wisely) resisted the temptation to be descriptive about processes, preferring to stick to the value in the core concepts.  Sometime around 2005, he renamed his landmark deliverable the "Zachman Ontology," a naming change that I heartily support.  Nothing in this article should be taken to mean that I disagree with his ontology (although I think it describes things in a way that is both accurate and not particularly useful... that is the topic for a separate article). 


Need extension of EA framework to include new enterprise activity / challenges. New Enterprise services /solution -virtual Infrastructure , virtual desktop , Containerization and Continous Integration/Delivery . Extension of EA framework should add more features in Model driven architecture and micro service based integration.

Good thinking Nick. And if this model was followed, it would allow architecture to be... (gasp) AGILE. Adjusting to the business as it evolves and grows. Informing leaders when more analysis, investment, or resources are needed and what the handicap of not having them is.
Taking your analogy one step further, leads me to the "promised land" of medicine and what perhaps SHOULD BE the promised land of Enterprise Architecture: Evidence-Based Practice. A defined and understood "standard of care" that addresses the basics with a praxis that has been honed and refined using the combined knowledge of the EA Community and it's practitioners (like us).

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.