The Future Of EA

A client recently requested a presentation on the future of enterprise architecture. I always enjoy these types of topics, partly because they give me some latitude to think creatively but also because they make me think about things that don’t come up that often in my day-to-day problem set. In the presentation I covered a lot ground about the current state of EA, trends affecting EA’s future, and what EAs should focus on to ensure future success. Business architecture played heavily in my view. But the bottom line can be summarized in five scenarios. Here are the five scenarios I came up with and my take on each.

Scenario 1: EA disappears as a unique function. I think this scenario is inevitable in the long run (but here I am talking about 20 to 30 years) as we move to purchased applications (“there’s an app for that”) and Moore’s law continues to drive down the cost of hardware to the point where  performance/capacity/reliability/etc. issues all but disappear. But in the near term (let’s call it 10 years) I think this is a highly unlikely outcome. Because, even though EAs struggle to demonstrate value, the promise of EA value among CIOs remains strong.

Scenario 2: As EA becomes more business and enterprise in focus, it moves “in total” to the business.This seems to me to be the least likely of all the possible outcomes for EA. Business architecture (BA) might move to the business (see scenario 5) but I can’t imagine the technology side of EA moving into the business as long as there is an IT organization. First of all no sane CIO would support the move. But more importantly, who in the business would have a better perspective of what (technology based) EA needs to be than the CIO? Some architects seem to believe that putting EA in the business would give them magical powers of influence - but it won’t. Business goals and incentives are the main drivers and they will remain the same.

Scenario 3: EA remains in IT, largely focused on technology architecture.This seems to be the most likely outcome for small to medium sized IT organizations. In this option business architecture will be developed primarily as input into the technical architecture. The key to success here will be for EAs to evolve from technology planners to true IT strategists.

Scenario 4: EA remains in IT but becomes more business focused.This model will be prevalent in medium to large IT organizations where IT has developed a strong partnership with the business. Here, EAs will be welcome at the business planning table and will be well regarded by business and IT for their ability to match business needs with IT capabilities. The business architecture focus here will be business-IT alignment. EA’s resources will be about evenly split between BA and technology initiatives. Successful architects will be very business savvy but keep their technology roots.

Scenario 5: EA splits into multiple groups.This is the most likely 10-year outlook for most large IT organizations. EA will split into three distinct and separate groups: infrastructure, applications and information, and business. Here’s why. Infrastructure is rapidly closing in on the utility model. The cloud movement will force existing I&O managers to create a more “cloud-like” approach. Instant and configurable provisioning will become the norm. Application developers will no longer need to be concerned with the infrastructure architecture. It just works. Infrastructure EAs will move into I&O and become even more technologically focused.

As business architecture gains momentum, business leaders will take notice and seek to move or replicate the BA function in the business. Many BAs will jump at the chance to move and encourage this model – with or without the CIO’s blessing. Look for business schools to add business architecture to their curriculums. When that happens, business architecture’s move into the business will accelerate rapidly.

Being squeezed from the top and bottom, traditional EAs will focus more on applications and information. As SaaS and purchased applications become the dominant solutions delivery model, EAs' focus on information will increase.

Have a different scenario? Let’s hear it!

Comments

The Future Of EA

Scenario 4: EA remains in IT but becomes more business focused.... This is the likely scenario that will prevail for the next 3-5 years. If EA groups don't move up to this value chain, they will become extinct.

EA has always been a business side discipline

Jeff, some good insights here, and I think your scenarios are valid ones.

It is a shame though, because EA is historically a business side discipline. In the last decade IT has co-opted the term, and in doing so has undermined "true EA".

True EA addresses the enterprise as a system, and has little to do with IT except when IT is a strategic component of the enterprise.

As for IT-centric EA, which is what your five scenarios refer to, I think that the greatest challenge is that IT continues to undermine "true EA" by confusing executives about what EA is (and should be). IT-based EAs have shown themselves as a group to not be up to the task of moving up to true EA, because of so much focus on frameworks and technical concerns that are not that valuable for understanding real business issues, which tend to be more about managing change with respect to people.

There are some organizations that are attempting to define business architecture, and perhaps this is the path for IT-based architects to move into true EA.

Where is the "Business Value"?

I think EA, like other domains within IT, will need to take on more of business focus - so I see Scenario 4 as the likely one to emerge.

We are constantly being challenged to prove the business value of EA - through finite metrics and measures - and to report on these elements on a regular basis. This is, quite frankly, a struggle. Can I track reduction in defects that are tagged as "architecture-related"? Do I want to report on a reduction in hours in re-work due to poor designs?

The IT domains that can clearly show value to the overall company will be the ones that thrive and the others will be squeezed out and given fewer and fewer resources with which to work.

Scenario 6 or 7 Are Most Likely to Occur

From an Enterprise Architecture perspective, either scenario 6 or 7 are most likely to occur.

Scenario 6:
From Jeanne W. Ross. . .

"Let me propose the following hypothesis: Although EA was initially a function within the IT organization, we will soon find IT to be a function within EA. This is actually not a wild theory; it's a trend."
- Jeanne W. Ross, Foreword, The SIM Guide to Enterprise Architecture, CRC Press, 2010, p. xli.

Scenario 7:
EA as a Profession (not IT profession)

Responsible governance, advocacy and advisory services will guide the EA Profession to
a self-governed status of maturity by 2015 - moving from organized, to
qualified, to self-governed by 2020; which includes a measured level of
maturity in three very distinct broad areas:
- Standards of practice
- Professional learning
- Industry governance

This will lead to support of professional autonomy and sustainability of EA as Profession by:
- Clarifying in the public eye as to what a professional Enterprise Architect contributes
- Ensuring the public's trust in EA as a profession
- Assuring the public they're dealing with competent EA professionals

We have been in continuous conversation with business leaders and owners, consultants, academics and others who recognize that both time and an erratic economy are transforming industries. There are new competitors, products, technologies, customer expectations and business models. The aptitude, skills and knowledge of many current leaders are out-matched by the new challenges, and too many businesses have yet to address their transformation. More owners, boards and CEOs are questioning their organization structure and whether they have the leaders they need. (They believe for the most part they have good people. Their question is, quite appropriately, do they have the right people).

Something's Happening Here. What It Is Ain't Exactly Clear.
-- Buffalo Springfield, 1966 ;-)

P.S. Next time we should explore terminology usage. Sometimes we use these interchangeably which distorts the entire concept. And one last note, some people ask, my Enterprise Architects are extremely valuable, no question there…then why does my EA function as a whole have a difficult time expressing its value proposition? What is the difference between the person and the function?
- Enterprise Architecture as an organisational entity
- Enterprise Architect as a role
- Enterprise Architecture as a formalized business capability
- Enterprise Architecture as a way to model an organization

Take care and have fun!

Inflated Names and Broken Models

Following up on Mark's comment --

This emerging discipline and profession has a number of bad habits that those of us who "know better" need to counter at every opportunity.

The first is using the general rubric EA to mean what is really enterprise IT architecture (EITA). The second is the false dichotomy that the enterprise comprises IT and "the business". These two IT-centric perspectives play a major role in people who call themselves EAs not getting the respect they think they deserve.

That said, it's not clear to me which of EA and EITA Jeff's scenarios are meant to apply to.

Maturity models are all the rage these days, and the unspoken assumption implicit in the name "maturity model" is that more maturity is better. I often wonder if assigning a metric of maturity to a continuum of options is like concluding that blue is a "better" color than red because it is further up the spectrum. The proper role of EA in an enterprise shouldn't be determined by some "maturity" model but by what that specific enterprise needs EA to do for it. The principle of natural selection suggests that enterprises will find that proper role for EA, or the EA function will fail.

Enough contextual ranting.

So, I think what's actually going to happen is "all of the above", depending on the particular company, and even within a given company, the scenario that actually plays out will likely be a hybrid.

I have to disagree with Jeff's first scenario, though, even in the long run; given that it's very IT focused, it presumes that EITA is mostly about "performance/ capacity/ reliability etc." issues. Even if EITA's think this way, commoditization will not eliminate the need to optimize such, it will just move it to a higher level of abstraction. As I have written elsewhere, as commoditization becomes more pervasive, the focus shifts from optimization by design to optimization by configuration management, and the need for configuration management will never disappear, and I very much doubt that its provision can itself be commoditized.

If EA (not EITA) is really about continuously aligning an enterprise's assets and capabilities with its vision, mission and strategy, the need to do so will never disappear, and the responsibility for doing so will never disappear as a function within the organization; otherwise, how will it happen? I have heard some people argue that it will pervade the fabric of the enterprise, and everyone will be responsible for ensuring such alignment. This is like saying everyone is responsible for sales, or everyone is responsible for marketing, or closer to home, everyone is responsible for strategy. It's a nice motivational pitch, but it just doesn't work in practice. Somebody has to take ownership of the responsibility and the expertise.

The Future of EA

Here is my own scenario.

In 10 years or so, as IT becomes a commodity like telephony, I think that EA will become more and more diluted among managers and executives. At the limit, most organization stakeholders will understand how processes and information means support business and how to use them.

Cloud is already bringing data center as a commodity and the future is bright to add more IT domains within this abstraction layer.

EA will then be made by CxOs, those able to mix vision, technology and leadership.

Following Leonard and Mark. I

Following Leonard and Mark.

I think EA is a bad solution to a deeper problem.

Recently, I have come to believe that EA doesn’t introduce anything new to “modern business management”. However, such an approach to management seems to be rare compared to "classic business management". Consequenetly, I feel that EA is a bad solution to a deeper problem : "classic business management". Classic management is based on a tacit assumption that organizations can be compared to machines. Consequently, divide-and-conquer strategies are promoted both in organizational design as well as task responsibility/accountability distribution. This is to be expected because most “classic” management principles date from the industrial revolution. The consequence of all of this is that “classic” management doesn’t take a systemic approach to management (I’m using the term systemic from the perspective of Senge, Demings, etc.). In addition, as stated by Peter Drucker, classic management is about doing things right, it isn’t about doing the right things… that’s leadership.

If I go off into fantasy land for a moment :o) If organizations were managed using a systemic approach, there probably won’t be a need for an EA team. The EA team would be replaced by a strategic leadership/management committee with representatives from across all units (IT would be one). These representatives would work in collaboration in order to insure systemic optimisation and organizational learning.

Now back to reality… because of classic management, these units often do not work in collaboration because, driven by a culture of silos, they fight for limited resource in order to do what they believe is “locally” right instead of working together in order to do what is “globally right”. This is also sustained by a tacit assumption that accountability cannot be giving to a group but only to a single person.

Now if a talk about IT and EA. EA is probably often in IT because IT is always “stuck” in the middle of all the other units fighting for limited resources. Consequently, for IT to function efficiently, it has to compensate for the silo culture… hence the need for an EA team. Often, business management doesn’t understand EA because understanding it would put into question there ways on managing/thinking.

EA is a good path to the solution

James - great comments. You are exactly right that in your "fantasy land" EA would be unnecessary. But in the real world we all have to live in we have to play the hand we are dealt. Yes, business leaders should manage with a more systemic or what I typically think of as a strategic approach. (As an aside, during the last six years of my management carrier I was able to do this with amazing organizational results.) But they don't. So while EA - or more specifically business architecture - may not be the ultimate solution, it is a good one. Now back to fantasy land for a moment. If architects really do a good job, maybe, just maybe, business leaders will start to see the value in a more systemic approach - so look at BA not as the solution but as a good path to the solution.

BusArch as a discipline

I think scenario five is likely.
I don't have a technology background, but I am doing a research paper on Business Architecture. It happens to be for my last part of my MBA. And even though it has been difficult to explain to the other MBA students (without a tech background), they are all extremely interested in it.

I do see it as part of the MBA curriculum in the near future.
I don't see it as the domain of the business savvy IT crowd.
(Competition for domain ownership and all. Business schools are quite viciously political.)

A different scenario

Traditional IT Departments become IT-supply organisations and are divested from most organisations into larger vendor/supplier organisations as both applications and infrastructure are commoditised and virtualised. The division between "IT" and "The Business" goes away - with the IT Department.

The traditional EA function slims down and becomes a technology-procurement agency interpreteting strategic business needs/requirements into information technology acquistions and divestments strategy - fitting the technology to the evolving business architecture.

Jeff, my wife is telling me

Jeff,

my wife is telling me that, according to her understanding, the 'EA' of a company can only be its very CEO (or some representative, for that matter). She is right, I think.
Therfore, forget about all those ridiculous scenarios. Return to reality - as quick as possible.

Peter

I know, I know. MY wife is always right too!

Ok. I know how hard it is to convince my wife she is wrong. But you know, sometimes you just have to try. :-)
If CEOs are accountable for their company’s architecture then they are doing a lousy job of it. In the real world, CEOs are not their company’s architect or strategist for that matter. CEOs spend almost all their time on WHAT the organization should do and very little on HOW they should do it. That’s what COOs, CFOs, CIOs, and HR Directors are for. CEOs set direction through aspirational and inspirational statements, goal setting, and defining high level approaches. They expect their lieutenants to figure out the details and this is where architects and strategists come in. They don’t define the business strategy or create the organizational architecture. The strategist and architect’s role is to illuminate and augment what the CEO (and other executives) want to accomplish in ways that help the organization create a common understanding of the direction and operate in a cohesive, synergistic mode.

You stick still to this

You stick still to this routine-blind definition of company/enterprise-architecture, which captures only part of the issue, in fact, the more trivial part, referring to material and functional settings.

What we have in mind and are speaking about, is referring to people. I admit that a good deal of that is accountable to 'HR-Directors'. However, the mis-alignment between IT and Business, which is at the heart of the issue, is referring to 'HRM in the large', so to speak, rather than to that operational part of HRM.

HRM in the large, is what often is called 'Corporate Culture', even 'Corporate Identity'. Who other than the CEO could be in charge for that? Not, by any rate, those stylized EAs, playing around with their deviant functional models, hand-knitted along the lines of functional programming.

, but to the there remains often is called 'Corporate Identity' or 'Corporate Culture', the manner, how Human Resource Management is basically perceived. , how might be called named could be : . Let me try :

The History of Business Architecture (conjecture)

IT Architecture was created to solve communication problems. If an entire solution wasn't planned, different components might have problems communicating (or people managing the problems like the n*n-1 complexity issue addressed by SOA). This issue was very successfully addressed (a hard system addressed by hard system thinking methods). The next problem addressed by Architecture skills was that of future planning of technology under Enterprise Architecture.

Outside of these hard systems, there was an additional problem that IT faced. It is what people in the IT department think of as the communication issue between IT and 'the Business'. The assumption is that if architecture could solve the previous communication problems, then it could solve this problem too. This is termed Business Architecture.

However, there isn't just a problem of communication between IT and 'the Business', there is no such thing as 'the Business'. There is actually a communication problem between every single department and within every single department. So Business Architecture has moved beyond trying to improve (nail down in precise terms) the understanding of 'the Business' by IT, and it hasn't even yet solved that problem.

Business Architecture is not interested in setting strategy, or deciding what the operations management methodologies should be. As IT architecture is (meant to be) technology agnostic, Business Architecture is agnostic about any specific initiative. The goal of Business Architecture is to better align the different units and departments by using skills and models and frameworks (that may or may not exist). One potential metaphor is that the BusArch function acts as the service layer of SOA, so each department, unit, and function can get on with focussing on their own work without trying to learn the languages of every other department, but can focus with the faith that they are in fact aligned to the other units in a cohesive organisation strategy.

The role of Business Architect does not replace the CEO, or the line managers, or anyone else. It addresses a function that is claimed to be the domain of everyone (project managers, project sponsors, business analysts, line managers, HR, C-Suite, etc) and that no one is effectively doing. By explicitly identifying the issues and problems, and hopefully a skill set and intellectual foundation, Business Architecture may exist as a function. But this cycle has happened many times so far without effect (a decent example is 'The Great Transition' about Enterprise Engineering written in 1995). Business Architecture seems to have an impressive magnetism about it, but it remains to be seen if it attracts the right people that can give it the spark of life. I have read many books and journal articles about Business Architecture, and no one has yet planted the seed to my satisfaction.

It is why I hang out it places like this, looking for ideas. (Thanks everyone so far. I especially liked the 'Novelist' metaphor from a previous post.)

Peter, please do continue this discussion. There is much that needs discussing. Other people, please join in for a substantive thread.

@Adam and Peter, great posts

@Adam and Peter, great posts !
@Adam, any thoughts about my previous post ?

Four-year-old thinking

There is no way I can use this metaphor without it being an insult (to the managers to which it applies), but it is just meant to be an observation. James, your comment about managers not being able to accept EA methods because it runs contrary to their thinking reminded me of it.

My 4yr old daughter wrote her sister's name on a drawing. She wrote it in near perfect mirror image (which was impressive). I politely mentioned that writing usually goes from left to right, and she just as politely informed me that was the way she intended to write it as she had the freedom and discretion to do as she pleased.

The way she said it reminded me of some managers using some operational systems. They were using them in violation of several simple norms, and these norms existed for a reason. They were correct that they could do things backwards and that they were still recognisable if I were to just pay attention, but they missed out on many of the benefits that result from the developed standards.

Manager thinking and the resulting silo mentality that you pointed out may be the biggest challenge to Business Architecture (EA, EBA, etc). Even if one creates the prettiest and most perfect drawing of how an organisation could exist, overcoming (aligning, harmonising, etc) management inertia of thought and self interest is nigh on impossible.

And my biggest issue with your 'fantasy world' ever coming to fruition is the issue of time. People at the top have to deal with things once and be done. Executing an architecture means that issues will have to be chewed on for a long time. So even if it is their responsibility and desire, time prevents that world from ever becoming real. The only question left (after 'Is Business Architecture possible?') is 'Is the value enough to justify Business Architecture's existence?

/And as Leonard pointed out that the Business/IT dichotomy is an IT centric creation and is false, I would also like to point out that the Leader/Manager dichotomy never does the issue justice. I use such thinking (did Leonard call it lazy?) to make my points, but that dichotomy is one of my pet peeves. There are hundreds of issues and dimensions under the Leader/Manager banner that neither name even begins to contain the topic.
But yeah, good post. Good issue.

Oh - Your blog has no Preview

Oh - Your blog has no Preview function or equivalent! So, sorry for my un-authorized 'appendix'.