Today’s EA Methods Can’t Handle Continuous, Pervasive Business Change

Enterprise architects I talk with are struggling with the pace of change in their business.

We all know the pace of change in business, and in the technology which shapes and supports our business, is accelerating. Customers are expecting more ethics from companies and also more personalized services but do not want to share private information. Technology is leveling the playing field between established firms and new competitors. The economic, social, and regulatory environment is becoming more complex.

What this means for enterprise architects is that the founding assumptions of EA — a stable, unified business strategy, a structured process for planning through execution, and a compelling rationale for EA’s target states and standards — don’t apply anymore. Some of the comments I hear:

“We’re struggling with getting new business initiatives to follow the road maps we’ve developed.”

“By the time we go through our architecture development method, things have changed and our deliverables aren’t relevant anymore.”

“We are dealing with so many changes which are not synchronized that we are forced to delay some of the most strategic initiatives and associated opportunities.”

The bottom line is that the EA methods available today don’t handle the continuous, pervasive, disruption-driven business change that is increasingly the norm in the digital business era. Our businesses need agility — our methods aren’t agile enough to keep up.

Forrester has released version one of a new EA method — Business-Centered Enterprise Architecture (BCEA). We’ve taken models and techniques from business architecture, portfolio management, and information technology infrastructure library (ITIL), combined and extended them into a streamlined set of methods that enables continuous change from initial planning through design, implementation, and operational enhancement. It supports agile governance, which delivers desired business outcomes even when disruptive opportunities change everyone’s priorities. It doesn’t replace EA’s stock-in-trade of standards, reference models, and target states, but rather builds on and reshapes them to address the need for agility throughout the business change cycle.

I encourage you to read Forrester’s EA Method Playbook and tell us what you think. In our initial release, we’ve described core elements which we’ll be revising and expanding on — for example, over the next few months we’ll be publishing on performance management of EA, and how this changes the roles and skills of a firm’s EA practice.

Are you using some of the techniques already? Have you developed your own techniques dealing with some of these issues? Do you see ways we can make BCEA better, easier to use, or more effective? We want to hear your ideas in a partnership to develop new EA methods to address the new reality of continuous, pervasive, disruption-driven business change to address the digital business era.


Data Architecture Agility


You are 100% correct! As long as data architectures are based upon islands of disparate data, business agility is not possible. The islands of disparate data result from flawed data modeling methods where databases are designed to be disparate. Data integration is simply not a database design consideration.

I have enhanced these antiquated database design methods to provide for data integration between databases. Check it out @


Centralisation is not the solution for sustainable agility

Thank you Robert for your insight. If I read you correctly you are promoting to recentralize the data islands. Trying to simplify what is complex today is a practice that EAs are using for years. They are doing that through standardization for example. But that strategy of "one size fits all" is failing now that companies are becoming global while they should comply with different business requirements in different geographic territories.
So the centralization (of data but we could extend that) has now some limitations to comply for example to local regulations, growth rates, markets paces, etc. Within BCEA we are promoting "architecting in zones" that Forrester introduced few years ago. Zoning is defining what can be seen as common whle still defining other zones which can have a different approach. A zone defines for example standards, principles, governance to comply with business needs which are different. "Zoning" is trying to find commonalities where previously we were unable to bring "the one size fits all".
Is "zoning" a concept you also have in your "data reintegration" method?

Don’t Centralize, Harmonize!

Thank you for your response. Let me explain the data integration by design methods by analogy. If we look at the technical architectures of the 1970’s, computers were characterized as “stand alone” computers. Most often “floppy diskettes” were passed from user to user as a means of sharing data between computers. Before that, we used magnetic tapes, paper tapes and punch cards all of which are now obsolete because of computer networks. The computer networks that became popular in the late 1980’s allowed any computer to share its resources with other computers that are also on the network. One would not consider the technical architecture of the 1970’s agile.

Today’s disparate databases are much like the “stand alone” computers of the past. Disparate databases are not designed to share their data with other disparate databases. The Extract, Transformation, and Load (ETL) approach is like the passing of floppy diskettes. The disparate data architecture, which is based upon disparate databases, is not agile and it never will be!

The data integration by design methods are used to develop “integrated” databases or to convert disparate databases into integrated databases. Integrated databases provide designed and reliable data access paths between integrated databases. Much the way that computer networks support sharing computer resources, integrated databases share their data with other integrated databases without the need for ETL software. The integrated data architecture, which is based upon integrated databases, is far more agile, efficient, and effective than disparate data architectures.

Data integration by design is not centralization of databases. If we begin with 10 disparate databases, we finish with 10 integrated databases. Integrated databases, while distributed, function in harmony like a single “virtual” database. For more information about the integrated data architecture visit:

Proactive, agile, business centered EA approach

As an EA in a very large company that has gone through multiple business acquisitions and internal re-alignments to increase their competiveness, I can attest to your point that EAs must be agile, or they shouldn't bother at all. When these kind of changes occur, EAs need to re-energize and quickly get plugged into all the strategic discussions regarding go forward plans, system rationalization, investment priorities, etc. and be able to reflect updated, high level target state guidance and roadmap implications quickly - else they will simply get left behind, unable to shape strategic decisions BEFORE they are made. Many of these strategic discussions are difficult to even get invited to, as they are intended for small audiences across the business and IT. But a good EA will find a way to get hooked in. Once in the loop, EAs should quickly begin absorbing the business changes and drawing out system implications in the appropriate business context. Analysis speed & thoroughness, communication of architectural guidance in a clear / concise manner and building new relationships across IT and the business in an open, collaborative manner are the success factors I pursue after acquisitions / re-orgs.

There is new practices in BCEA to support M&A

Dear Daymond thank you for your comment of how Mergers and Acquisitions require architecture agility.
You are absolutely right and "Merger and Acquisition" where you can need the two types of agilities : range and time.
You can find the definitions here :
Time agility if the M&A are huge, nearly unpredictable and happening once
Range agility if the mergers are smaller and happening several time a year and thus more predictable.
I know this is not the best explanation and if you want a better ones I have that with slides I will be happy to share with you. Please let your email address and I will send you a presentation about agility.
You seem to talk about the "range agility" and I agree with you connecting earlier with the business is one best practice we described in this document :
But in addition to due diligence check lists, Business capability maps and so on we think BCEA provides another step in the agility direction particularly in the planning phase by tolerating multiple strategies, helping to discriminate the winning set of strategies, using broader business outcomes to take into account HR and regulations issues for examples. BCEA is described here :
I am sure there are other benefits in BCEA to support Mergers and Acquisitions activities and get the sustainable business agility. Let us know if you would see any interest in your own case.

The only constant factor is change!

EA practitioners need to be more agile than ever to keep up with the business. A philosophical shift may also help them adapt: rather than thinking about Enterprise IT Architecture, IT practitioners should think about architecting the enterprise. For example, in this model, a group of business representatives including IT defined how the business will transform, and then the IT Chief Architect is responsible for meshing the business blueprint on the IT landscape to evolve IT with the business. Tim Westbrock from EA Directions has written about this philosophy at we’d be interested to hear your thoughts.