What do you mean by

" Do you have a complete service-, semantic-, and process-level understanding of your enterprise?"

?

Nothing personal Dave, but this article is indicative of the current poor state of the practice of Architecture within IT. VERY FEW people do their homework including the Executives that hire and fire us and the many Sr. Developers out there claiming to be "Enterprise Architects."

I agree with the excerpt "the person that is needed to understand and implement the value of SOA is sometimes not the current enterprise architect in charge", but why is this? Could it be that it's so difficult getting management to give up responsibilities deemed now the Enterprise Architect's because Executive management won't fully support them?

The two issues speak of risk and mentions "Another issue is that it's easier to stay high level, than do actual work." I think we understand you here. Prototyping/proof-of-concepts/demonstations where there is high risk absolutely helps in reducing risk and is normally expected from most Architecture groups (although a developer current on implementing the technology might actually build it - quite arguable).

A few thoughts on the questions:

Question 3 assumes that there are only three (models?) needed to understand an organization. Recommend checking out IEEE-1471-2000, Zachman, and SEI's research among others.

Question 4 says that every organization should have a common abstract model. ALL models are an abstraction. So what LEVELS of abstraction are necessary? Again, I would refer to Zachman as a good "Best Practice" letting the Enterprise Architect choose what models will be most effective in communicating the architectural design to each stakeholder group.

Question 5, what does "well integrated and real-time" mean? That's quite open...a great catch-all when you want to fire that new Enterprise Architect for not agreeing with the solution that was made by management without her input.

Question 6, isn't an architecture supposed to anticipate changes to the business so that it isn't required to be changed everytime the business changes?

And finally I whole-heartedly agree with your excerpt "you fail you're fired approach, versus a let's try new things and seek improvement." What happened to good old-fashioned leadership? Do we fire someone for not meeting assumed and ill-defined (if not even defined) expectations or do we actually do our homework, define them, communicate them to employees/contractors PRIOR to hiring them, determine if they're actually a good fit, stay in touch with their work on at least a weekly basis, and then mentor them when they need it? Nah, let's just fire them and move onto another company!

How many organizations have architects with this amount of influence? I don't know of any. You seem to be talking about the CIO.

And what is an Enterprise anyway besides the ship on Star Trek?

"A huge chasm between the traditional enterprise architecture crowd, and those looking at the value of SOA"

From my feeling, and what I can observe in our French situation, enterprise architects, or IS city planners, belongs now to established professions. In some cases, they forget the objective of their job, and want to protect their position. Fortunately, this profession is still in evolution, intellectual curiosity has not died, and the top management wants short term results.

"The core issue is an add-not-change approach to architecture."

On this point, there is an actual synergy between IS city planning, and SOA. IS city planning highlights the work of enterprise architects with the project teams, to find a best way to preserve existing applications, when driving an evolution to a best target. The add-not-change issue is for us a basic of “urbanization�. This way, SOA is very fine and facilitate this pragmatic goal. And Club Urba-EA activity model does not impose a top-down approach. I observe that Enterprise Architecture guidance is much strict, and marketed as THE solution. See the Gartner white papers, or TOGAF.

"Another issue is that it's easier to stay high level, than do actual work"

It should not be easy to stay high level. We need enterprise architects which link technology, existing applications, processes, and business strategy. Methodologies can help. They can also hide the stakes. Models can be useful, but too much models create complexity, much more complexity than necessary.
The problem is that, at high level, you do not see the actual “gain and pain�. The sanctions or benefits exist, but arrive later.

"Do you have a complete service-, semantic-, and process-level understanding of your enterprise?"
"Do you have a common abstract model for key elements, such as customers, sales, inventory, transactions, etc?"

If we had the answers to theses questions! In many case, there is a long way to achieve such goal. I have proposed some answers in my book (in French…�De la strategy business aux systèmes d’information� “From business strategy to Information Systems�). I think that all those models must be aligned to a fundamental grid layout, based on the different cycles of transformation realised by the enterprise, and the different value chains. It is far from technology, but many examples prove that a common abstract model is underlying processes and IS. Theses questions are not technical but conceptual. And they can be simplified if we do not drill down in detail: the macro-structures are simple.

"Are systems well integrated and communicate in real time where needed?"

If we do not have the value chain vision, it is difficult to judge opportunity of synchronism, of asynchronous, or batch implementation: which business service has to be delivered and in which manner? In some cases perfect synchronism is a wrong solution, and time must elapse between the different phases of the business process. In some cases, the same “service� has to be invocated in a random mode, for instance for simulation, or in a batch mode, for instance to execute the real calculation. We have to understand the fundamental logics of the transformations realised by processes and services. And we have to design flexibility where needed: for instance, is there a short term evolution, and a stable trend?

"Can you change your architecture to accommodate business changes at the speed required by management and the marketplace?"

In many cases, the existing legacy applications are constraints. Anyway, if we build “from scratch� a new IS city, it will never be perfectly flexible. It will be theoretically flexible! Of course it will be more flexible than the old buildings (legacy, ERP, internal regulation), designed with the old technologies. But new constraints will emerge. The point is to find the stable foundations of the business evolution. Actually this does not relate to strategy (the strategy plays a game in defined limits), nor to technology. Strategic alignment is not the solution (when an evolution is needed for a strategic requirement, it is often too late to create the flexible architecture). We should design the buildings with regard to the business stable elements (value chain, cycle of events), which are common to all the strategies, and then we could have more durable buildings (I mean high level IS architecture), which resist to business evolutions.