Enterprise Architects Versus The World

Scott Mark and James Tarbell wrote very interesting pieces on the difficulties the discipline of enterprise architecture faces, and I'll add my amplification and two cents to the discussion.

The underlying theme behind the anti-EA, and moreover, the "Web 2.0-Saves-Humanity-As-We-Know-It" crusade is this: you, the user, can have it better, cheaper, and faster if you [ fill-in-the-programming language-or-kewl-technology blank here]. Most of us who have been around the information technology business for a substantial length of time know that, eventually, this mode of thinking reinforces a number of serious and detrimental issues, particularly in the complex corporate and government environments where most of us ply our trade.

As a result, when we raise numerous issues along those lines, we are universally branded by those in the diametric situation as cynics, 'Astronauts,' or just, "not getting it." What these pundits generally don't realize is, yes, we do get it, and while it's unfortunate that you don't like our answers, let's look at reality one more time, shall we?

One of the issues that drives these perception problems is that of scope. A typical enterprise architect's scope is much more broad then that of a development team or end-user organization. The development team is concerned about their project, and perhaps projects and systems they may interface directly with - and usually nothing more. End-user organizations are interested in projects that assist and benefit their specific business mission and goals, and usually nothing else unless it directly affects their paychecks. These are almost perfect situations to exploit technology du jour-style thinking and approaches, because there are needs that potentially can be addressed in the ideal: quick and cheap. Astute technology bandwagon-jumpers seize upon these seducing attributes to justify their actions regardless of the end results.

We work in environments where IT budgets are in the tens of millions, and in a number of cases, hundreds of millions of dollars. While there will always be some wasted money and failures financed by budgets in that range, part of our role is to insure that the systems designed and deployed with those monies provide value and cost control to the organization beyond the scope of any individual system or project. As JT notes, "Every architect and customer must understand the REAL business problem and functionality we are solving for." Not only is that true, but I would add that a message like this must be clearly communicated to executive management, both line and IT. If you do not have the complete support of your CIO, for starters, you're working with a minimum of one hand tied behind your back.

So...the real problem we're solving for, as JT noted, isn't necessarily better, faster, cheaper. In the large corporate and governmental areas, I'd argue that the real aggregate problems we're solving for are, as examples: cost-effective front and back-end, compliant, auditable, available (pick your nines), extendable/maintainable, interoperable, and secure.

Unfortunately for people like us, here is where it gets worse: our constituencies and stakeholders are routinely pitched by vendors and pundits that they can have it all - today. Our development teams are repeatedly advised that the latest and greatest tool, language, framework, etc. will help them solve all problems easier and faster. We're all constantly exposed to silver-bullet thinking and approaches, and it's not a new technique or tactic. Just the same old hype on a different day.

Where I would start to address the problems created here goes back to my belief that enterprise architecture is properly practiced as a holistic discipline that delivers tangible results to the business - both the operating entities and IT. We must do a better job of selling our scope and vision to our constituencies - and not in the fashion of vendors and pundits, but as key empathetic players in our organizations. For example, I have always found that "...here is how I help you (and the business)" to be far more effective in communicating architecture than "...this is what you will (or must) do per standard 232.2756." While this is a bit of an over-simplification, it's obvious that we send the latter style of message far too often, with the predictable reactions and responses.

Finally, I'd like to pose a question to my colleagues in the blogosphere: as architects, are we more effective within our organizations as advisors, or as authorities? If it's a combination of both, what constitutes a generally workable balance between the two? The reason I'm posing this question is if we're too often viewed simply as advisors, we don't get taken seriously and are accused of being in the ivory tower, and if we're too authoritative, we're viewed as rigid dinosaurs who can't and don't realize that the latest buzzword or phrase-driven 'sea change' is upon us.

I'm very interested in hearing your stories and commentary on this as well as the overall topic.

Comments

[JT]

Bob,
Your question: "are we more effective within our organizations as advisors, or as authorities?"
I think the real answer is neither and both. Neither because we need to be participants and partners in the problem solving with automation that is right sized to the business priorities. Both, because as architects we wear multiple hats. One of them is advisor as to the impact analysis of the scope of business automation be required. The other is authority over the technical aspects of our IT portfolio. Developers and customers need to ask questions we have answers for (or at least know how to get them).

[Joe]

I think the word "enterprise" is completely meaningless. And I fail to see what difference working on a project that has hundreds of millions of dollars available.

What I've seen people call "enterprise applications" are generally overly-complex, slow, and really hard to modify.

[Scott Mark]

I think the scope comment is very applicable - I happen to appreciate a lot of the disruptive influence that things like Ruby and many Web 2.0 concepts have; they challenge me to re-think my open positions and assumptions. But as far as rushing ahead with them, I point out that moving a large enterprise towards them is like re-tooling a factory line. I think a lot of people who pull out the productivity arguments are thinking about re-tooling craftsmen rather than factories. Not to say it can't be done, or shouldn't be considered, but it's a bigger task than meets the eye.

There is a definite balance on authority vs. advisor, but I still tip the balance in favor of advisor, and tried to get to that point here- http://scottmark.blogspot.com/2006/02/setting-values-versus-enforcing.html. There are places for authority, but that posture runs the risk of not hearing feedback, and I think that's a big concern. You should earn your foothold with the content of your counsel, not the position of bullhorn.

[Carl Trachte]

"One of the issues that drives these perception problems is that of scope. A typical enterprise architect's scope is much more broad then that of a development team or end-user organization. The development team is concerned about their project, and perhaps projects and systems they may interface directly with - and usually nothing more."

Something to keep in mind is that the projects and systems these folks work with are, more often than not, components of their companies' core business, which directly impact the bottom line. Whether the core business is service-based or production-based, their job is to make the business successful today. A bad performance over a month or a quarter in today's market can significantly damage or destroy a company's prospects for the future. So why wait 36 months for enterprisey software when there are ways of getting what you need in 2 months or less? IT is a fraction of the production costs - now is better.

I agree with very little of what you've written. Nonetheless, I appreciate the effort you've made to communicate things from your perspective. The cynical view is that you guys (architect types) are just trying to wrap yourselves in a lot of buzzwords and rake in a lot of cash over a prolonged implementation period. If I may make a suggestion, try communicating to people in the companies you work for in terms of their products and their companies' cash flows rather than the buzzword jargon they (we) often hear.

Examples of buzzwords: "A new way of doing business", "innovative solutions", "enterprise resources", etc.

Example of tangible idea: "Your hard work and ideas used in producing successful product X will be lost and unrecognized without this system of managing information and communication within your big corporation."

or

"If you don't allow us to protect your information with this system, much of your efforts in making the company successful will have been in vain. Controlling information is, to the success of the company, as important as safety and legal compliance. Help us out."

Lastly, if you are making obscene amounts of money for your services, please don't flaunt it. People will hate you and your ideas even before you start imposing them.

Thanks for taking this input into consideration.