Marginalizing Enterprise Architecture

Posted by Mike Rollings

This is my first post as a Gartner employee.  In the spirit of business as usual, here we go.

Business Process Management (BPM) is a discipline for managing business processes explicitly as strategic assets.  Richard Watson states in his Burton Group document “Market Profile: Business Process Management Infrastructure 2009” that the BPM infrastructure market is growing and it  appears immune to recessionary forces.  The BPM market continues to grow.  BPM market growth should be great news for enterprise architecture (EA), but it is not all good news.  

EA includes the pursuit of business architecture -- a representation of the collective understanding of the business model, current strategies, business functions, processes and information.  Because BPM is married to process and information then BPM should mean good things for EA, right?  Surprisingly, no!  The way that BPM is happening in some organizations foreshadows a bigger trend for EA and a bifurcation of what we have long thought EA includes. 

In organizations pursuing BPM, Business Capabilities and Business Architecture should finally take center stage -- successful examples of BPM show that they do even if they do not use these terms explicitly.  The concerning part for EA is that Burton Group’s Contextual Research Study conducted in December 2009 shows that the people responsible for these successful BPM programs do not describe what they are doing as EA.  In fact, some even say that they are still figuring out how to connect with the EA group.  WOW!  One would think that EA teams would be celebrating in these organizations, not disconnected!

The good news is that the business is doing business architecture related activities.  The bad news is that EA is beginning to disappear into the business. Why is this happening? I believe it is because the EA community continues to make EA appear "special".  EA has become just another thing that the business does not understand and therefore feels "Oh, let IT worry about that".  The special language, the pursuit of EA as a profession, and the fact that people still are trying to figure out what EA is, what it does, and what it looks like when it is successful all contribute to the marginalization of EA.

Yet, this can be a good thing for the EA discipline - practitioners just need to come to realize that EA has gone through a fundamental change and EA does not exist solely as an IT competency.

• Embrace this and feel good about it - many already have.
• Learn to describe architecture’s business contribution and value without using EA’s secret language.
• Deliberately avoid a highly theoretical approach to EA in favor of helping produce results.
• Describe what you can do to help versus describing EA.
• Help the broader audience of business and technology professionals use the knowledge of dependencies, implications, and constraints to improve their results.

As I said in my blog post "Is the business result more valuable than 'EA'?", the reason we care at all about the analysis techniques etc. in the EA bucket is because we want to improve business outcomes – not because we care what you call the bucket!  When you focus solely on the bucket it leads to ivory towers, ineffective processes, a lack of participation, and low stakeholder commitment. I would rather focus on the value to the business. The foundations of good architecture are disappearing into the business.  Go with the flow!

#EA #Gartner #BurtonGroup #BPM

Comments

[Jdietzgen]

Nice piece this. I agree that many EA people still seem to be disconnected from impacting the business bottom line. However, don't you think that much of the non-impact of EA stems from the general short-sightedness ("shareholder value" and all) of many businesses?

[Paul Jansen]

The article describes the reality well, but I do not agree with the analyses at all. About the disappearance of EA into BA you say: "I believe it is because the EA community continues to make EA appear 'special'. EA has become just another thing that the business does not understand and therefore feels 'Oh, let IT worry about that'" In fact, EA is 'special' and we apparently have not made this clear enough yet since Gartner c.s. keeps telling 'the business' that EA is an IT discipline. This article may therefore very well describe the success of Gartner c.s. with their persistent marginalization of EA into the IT discipline... It is a self fulfilling prophecy. Means EA community needs to work harder to make clearer even that EA is 'special' and that BE and IT are part of EA instead of the other way around.

[Nick Gall]

@Paul: "Gartner c.s. keeps telling 'the business' that EA is an IT discipline."

Gartner's EA research does NOT say that EA is an IT discipline. Here's our published definition of EA: "Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution." http://bit.ly/91bIeK

So it is NOT Gartner who has been marginalizing EA (at least not Gartner's research on EA). In fact, we've been trying to resist such marginalization for years.

@Mike. First, welcome aboard! Second, Amen. Completely agree with your analysis and recommendations. Stay tuned...

[Mike Rollings]

Paul,
"Special" relates to the notion that only those with the title or credentials for EA should do what is in the EA bucket. If we want the organization to be effective with strategic analysis then we must incorporate this into the organizational DNA. Strategic analysis may be part of the practice of EA, but it is an error to suggest that only those with the EA title (or an EA certification) should conduct strategic analysis. On the contrary, this must become an organizational capability and EA practitioners need to help everyone in the organization improve the capability and the consistency of the result. I would like to see wide-spread consideration of dependencies -- not just see one person or a small team examining them.

This is why I strongly disagree with you --EA is a discipline. This is one of the central problems with pursuing EA, and for that matter SOA and BPM. People do not recognize that they are disciplines.

Organizations adopt disciplines and people adopt approaches. Organizations commit to improving planning, optimization and design by assuring the analysis of dependencies, implications, and constraints. They incorporate the skills to do this into a variety of roles and processes. They focus on improving the discipline and reaping the benefits of it over time. People advance their ability to perform their role by looking for approaches that provide a particular result. These approaches can and should increase in sophistication over time (the proper level to address maturity). Processes, methodologies, and analysis techniques are examples of approaches.

If people do not look at EA, BPM, SOA and other similar "lifestyle changes" as a discipline, then they will never achieve systemic behavior change -- which is a primary goal.

The ultimate goal is to improve business outcomes and to influence better decision-making. You can't do that without thinking organizationally. This is why the EA community needs to realize that their audience is not just the people that identify themselves as an "EA" but also people with titles like CFO, Business Strategist, Marketing VP and others too numerous to list.

I also disagree that thinking about EA as a discipline is equal to marginalizing EA. Developing a cloistered view of EA is much more responsible for marginalization.

Jdietzgen,
I believe that short-sightedness is one symptom that the organization has not adopted the discipline.

[Carlhaggerty]

This is a very interesting post and i agree that EA is more than an IT competency. I believe that it is an organisational competency and that is something that EA practitioners need to support and develop as part of any Business Architecture effort.

The challenge that Business Architecture Programmes have is staying focused on what the business in trying to achieve and offering real value. It is similar to trying to do good project management without people knowing what methodology you are following, you are simply delivering what people articulate, appreciate and want.

I read a lot about how people are trying to make Business Architecture work, but there seems to be a lot of focus on ensuring they stay true to the method as opposed to working iteratively and building trust and respect outside of IT with the key stakeholders

EA's who can deliver EA without forcing the methodology onto others will gain more traction within the business, providing they link all of the components together to archive the desired future state.

[Adrian Grigoriu]

Mike, you are right in saying that BPM is ignored by EA practitioners. I tried a few times, without success, in my blog and discussion threads, to invite opinions on the EA relation to BPM, xSigma, process re-engineering... After all, business processes and their improvement are part of BPM as they are part of EA. The business process teams have been already working at it and have the competency. Strategy is already specified and aligned by existing business teams for a long time now. To succeed, EA has to include, re-use and only eventually, if mature enough, coordinate such efforts rather than ignore them. That proves that EA is IT oriented no matter how much it is claimed otherwise.
EA practitioners have not agreed yet what that is and what is its purpose, if you follow some discussions. Because of that, EA is self marginalizing.
read http://it.toolbox.com/blogs/ea-matters/

[Ahmed Chicktay]

Mike, I cannot agree with you more. There is too much focus on EA rather than the value it provides business.