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.