What Is The Key To Effective Enterprise Architecture?

What is the key to effective enterprise architecture? In a word: influence. I rarely see an EA team that can’t build a reasonably good architecture, but I also rarely see an EA team that can successfully drive support for even the best of architectures. The most elegant architectures are worthless unless they are widely adopted and utilized. We don’t need more elegant architecture models; we need more eloquent architects. 

Over the past few years I have asked hundreds of architects two simple questions. First: “What is more difficult - building architecture or implementing architecture?” Every single architect without exception tells me architecture is much harder to implement than to build. My second question is more telling: “Where do you spend the majority of your time?” Their answer: “Building architecture and my architectural skills.” Even though EAs clearly understand the problem, they don’t address it. Why is that? I think it is because deep down inside, they don’t want to.

Building organizational influence is long and difficult work. It requires an entirely different skill set than architecting. The focus is on people and relationships rather than technologies and concepts. Most architects don’t feel comfortable here. Instead of acknowledging reality and dealing with it, often architects try to avoid it by putting the problem on someone else’s back. “EA can’t succeed without executive sponsorship.” “Someone needs to give us more authority and control.” The fact is, very, very few EA teams actually get anything close to this. The majority don’t even get significant support from their CIO. And yet, somehow, many succeed. How? By building personal and organizational influence. The bottom line to EA success is organizational impact. How much are you having?

This comment was originally posted at eBizQ (http://www.ebizq.net/blogs/ebizq_forum/2010/07/what-is-the-key-to-effective-enterprise-architecture.php).


Scott, it is not clear to me

Scott, it is not clear to me what do you mean by "implement" and "build".
The terms are used interchangeably, as I know.
I surmise that by build you mean model, design ... and by implementation, well implementation (or should I say build/transform the Enterprise using the model?).

Do most EA architects avoid "implementation"?
They probably do because of the maze of conflicts of interests stirred by the great change the EA threatens with. Some organizations avoid change at all costs, no matter how "influencing" an EA architect is.

But do EA architects alone have to take the brunt of the Enterprise politics because the EA raises all these cross-organizational Enterprise level issues? They might like heroic poses but they don't have any managerial authority, typically, to achieve anything, unless business management really believes in EA. In that case, a top level business sponsor should be assigned to take leadership, responsibility and pave the way for EA, provided he is properly convinced the EA returns business benefits. That is a job of the EA.
But there is not much to capture the attention of or impress the executive sponsorship if the EA is so focused on IT and has no clear definition, scope, purpose or business case, as it often happens.

Well there is the alternate opinion that the EA architect should be the CEO or in any case a CXO. I wish.

So, in short, I disagree.

The challenge is still influence

Adrian - First I would say that EAs do have to take the brunt of the enterprise politics and that dealing with cross organizational political issues is just as much their job as dealing with cross organizational technical issues. But even if I accept your argument that they need a "top level business sponsor" then I would have to ask, "how do they get that?" EAs still have the accountability to convince (influence) management that they should take on that role. So, whether it is an IT project manager, a business manager, or a senior executive; the solution is still influence.

EA architect influencing

Scott, the "influencing" skill typically characterises a role that is not endowed with the authority to make things happen. And an EA architect has such a role, usually. True. Then the architect's only avenue is to attempt to influence all other stakeholders. Agreed so far.
The questions that come to mind then: should the architect do the influencing and why? What are the chances of success anyway?
Most stakeholders would refute change, unless told otherwise; the influencing would soon meet the politics coming with such large scale change.
Implementing EA through influencing is not what you really want in an Enterprise; and it does not really happen in practice as you discovered for obvious reasons: things are falling in between silos of responsibilities (as they should do with EA), the culture of hierarchical organizations may not help. And the work of influencing is hard not properly rewarded by the job.

A reason the architect has no authority is that EA does not deliver much value, today.
But assuming that one believes in EA and trusts the architect why would the company risk its future by letting key decision making at the vagaries of influencing?

If the role is truly believed to be benefic to the Enterprise, then the EA architect should occupy a position high enough to make decisions not influence.
This is what common sense governance principles would dictate. Or at least provide an able business sponsor.

Best vs. best marketing

you provide a very wishful view on the thing.
Normally an enterprise should concentrate on its business, but most companies EAs work for do not have the core business Enterprise Architecture.
That means that the EA already have to convince senior stakeholders that a good architecture is good for the business, that means influencing without authority.
Also, if it would be a natural law that the "best" wins, why are there so many products and standards market leading that are not the best from a technological point of view ?
Very often the soft criteria like "I like it" and emotions determine the success. So having a good marketing strategy would be a good investment with regards to market acceptance.
For me the same principles apply in the area of EA.
The benefits of a good architecture are not obvious, we need to sell it and relate it to business value.

Driving the Architecture Program

This is one of those "you get it when you see it" kinds of a thing.

We have a few folks who are excellent at the technical considerations of architecture, but manage to alienate somebody in every conversation they have. We may call them architects, but in my book fail on a basic level to meet my definition. They can build, but they cannot implement.

I always tell my architect-candidates, if you are counting on authority to be successful, you're not cut out for the job. You implement architecture by winning the trust of your constituents. If you ever make the CIO choose between you and a business team - you deserve to lose.

Phrased another way - being right is insufficient.

EA and the art of persuasion

I agree with Eric's comments that you should never make a CxO choose between the "EA" way or the "Team" way. As an enterprise architect, you need to realise that you are as much a part of constructing the bridge over architectural gaps as you were in identifying them.

Bringing about change is a gradual thing and understanding that fact is crucial. Different enterprises will adopt change at different rates but the EA should always remember to factor corporate culture into their plans.

When faced with a situation where a proposed initiative isn't receiving the priority that one would wish, circle back around and attempt to decompose it to smaller, more manageable projects. This might present the business with a more acceptable choice whilst still moving the enterprise in the desired direction.

A small step is better than no step at all.

An enterprise architect should always work to understand the cultural fabric of their company with a goal of using the knowledge to better present ideas for consideration in situations where the EA department lacks the authority to crack the whip themselves.

Superb blog subject. Thanks, Jeff!

Even a little progress is progress

Could not agree more Ray, and at the risk of abusing the etiquette of the bog-o-sphere, I made this the topic of a recent posting -> http://enterprise-it-architecture.blogspot.com/2010/06/how-much-progress...

I especially liked your comments on factoring culture into your expectations.

influence is a must

I agree 100%.

The reasoning I personally use is as follows. An architecture that does not get implemented is waste of effort. Therefore you should evaluate what degree of influence you have either through your own authority (if any) or the authority of those who will trust in your work.

Then when you predict that the authority will not be enough and you have no way to farther increase it (by influencing others), you should stop the architecture work or limit it to the perimiter where the authority combined with trust are sufficient for implementation.


The challenge of bringing 2 opposing forces

Nice article. Here are some thoughts on the Role of the Enterprise Architects.
Enterprise Architects have the challenge of bringing 2 opposing forces Strategic & Operational to make value be seen in the work we do for the Enterprise. The workforces that support these "opposing forces" have diametrically opposite perspectives as well. To build the blueprint for the Enterprise - the Architects have to work diligently in bringing these "opposing forces" and show alignment. So we Architects belong neither to Earth or Sky - hang in there in mid-air!