Business Ecology Initiative & Service-Oriented Solution

It is autumn in London and, as you properly guess, it rains all the day. You do not have much to do in this weather but surf the Web. This is what I did and found an excellent article published by Nick Malik in Microsoft's Inside Architecture BLOG almost a year ago. The interesting part of this post was that he responded to my BLOG where I analysed IEEE 1471 standard from the perspective of Subject of Architecture. Here is what Nick said and what I'd like to comment on:
>>Michael's conclusion is "the viewpoints and views, so loved by the IEEE 1471 standard, do DESCRIBE but NOT DEFINE the architecture and the Enterprise Architecture, in particular."
With all due respect, I believe that Michael missed the point. IEEE-1471 does not define the concrete enterprise architecture, nor the abstract enterprise architectural metamodel. It defines the concept of architecture itself. There are a few steps in the middle that need to be understood in order to bring all of these concepts together. Saying that IEEE-1471 does not define EA is like saying "the concept of a Mammal does not define my cat Fluffy."<<

This comment is followed by really outstanding explanations in line of "IEEE-1471: a conceptual model for any architecture" and, especially, Microsoft take on it. I do appreciate this information presented in such laconic way. Nevertheless, it seems that Nick my point, unfortunately.

One of the five principles of the IEEE 1471 (according to standard itself) is: "an architecture and an architecture description are not the same thing" and the IEEE 1471 stands for "IEEE Recommended Practice for Architectural Description for Software-Intensive Systems" (even by title), doesn't it? In my post I just tried to explain where architecture subject deviates from the architecture description. I never meant to talk about "concrete enterprise architecture, nor the abstract enterprise architectural metamodel" as an argument against the standard because it didn't and doesn't make sense, I agree with Nick in this.

The essence of my original post and what I am still standing for now is:

a) a definition of the thing is vague, incomplete or even ay be wrong if it is based on external views only. Such views cannot get into the core of the thing but can easily mix subjective motivations and pre-set opinions with reality;
b) basing definition of Enterprise Architecture (EA), i.e. design the EA, on the fully subjective concerns of stakeholders is the direct way (though it may be a golden way) to the hell. Every stakeholder has to be able to see the EA in his or her individual way but this does not mean that the EA must change to please each of stakeholder every time. There is and will be a gap between the individual wishes and the corporate strategy; this is the nature of life. Thus, the stakeholder's views have to be addressed with the inside-out information and not the other way around;
c) there is a difference between what the EA is and what the Enterprise Architects do, i.e. what is the EA subject and discipline. The latter includes an element of targeted satisfaction of the stakeholder interests.

My points are relatively simple; at least, they are simpler than IEEE 1471 standard (I hope). So, let me rephrase Nick and say:
"My advice is this: don't define the conceptual Enterprise Architecture as a set of views, but do" DESCRIBE "the concrete EA model as a set of views on an ideal metamodel... because those views have a purpose. Know the purpose: to meet the concerns of EA stakeholders."