EA (enterprise architecture) is not TA (technical architecture).
Although the two share the noun "architecture" they are different things. EA attends to the architecture of a business that uses technology; TA attends to the architecture of the software-intensive systems that support the business. Each domain - that of the business and that of the system - have fundamentally different stakeholders with different perspectives and different viewpoints. The fact that the both share some aspects of terminology and concerns and even notation is good, but can be confusing in the dialog between those two worlds..
Indeed, speaking of two worlds, in the dialog between science and religion, there's also this notion of two worlds: science has some things of which it may speak with authority and faith has some things of which it may speak with authority, but when science tries to answer questions of faith (why is the world the way it is) or vice versa (is there or is there not a randomness in the laws of the universe) then conflict arises. Not to diminish the complex texture of the dance between science and religion - if you want to go there, then the Templeton Foundation is one place to start, although Richard Dawkings has some things to say about that too - but IMHO EA and TA are similarly of two worlds. Most contemporary economically-meaningful enterprises use software-intensive systems to carry out their mission, and so there is and should be this jiggling between the architecture of the business (as it uses technology) and the architecture of the software-intensive system (as it serves and leads the business).
If you accept my premise that this collision of worlds exists between EA and TA, then I want to be clear that both worlds must co-exist and both must interoperate. SOA actually has some interesting traction here, because on the one hand, architecting a business around the services it provides and architecting a software-intensive system that makes manifest those services are shared goals of the enterprise and the technology.
And yet - and here's where I'm likely to inflame some folks - IMHO it's a mistake to try and extend EA frameworks and notations and processes to attend to the architecture of the software-intensive systems it uses, just as it is a mistake to try and extend SA frameworks and notations and processes to attend to the architecture of the business. There might be some overlap in view and basic modeling elements and processes at a high enough level of abstraction, but when you get to the details, it becomes too much, and you lose the perspective of what each is trying to do. EA is not a desert topping and a floor wax and neither is TA.
I'm currently working with Tilak Mitra, a colleague at IBM, on surveying the 20 or so EA frameworks that appear to have some traction in the world. There are far fewer TA frameworks - most are some variation of Kruchten's 4+1 model view - and the fact that there are so many EA frameworks out there speaks to the vibrancy of that market, but my experience tells me that there are too many chasing the same problem, and eventually the market will make its choice; I view this as a healthy sign, but a sign that EA is still in its adolescence. In contrast, the fact that there are fewer TA frameworks is a sign to me of the greater maturity of that domain, not to say that it's any less vibrant (look for the next edition of Documenting Software Architectures, but the market appears to have made its choices.
Quote of the day:
Read more at Grady’s Handbook blog