EA for SOA (CBDIForum)

(prompted by EA for SOA?)

This raises some issues - but doesn't answers for a number of them.

1. Current Architecture Death March - Automated collections [ETL] from the plethora of silos makes these significantly easier, as does role based Web portals to the information i.e. that allow the changes to be recored as part of day to day business.
2. Technical Reference Model (TRM) Stagnation – The biggest issue with TRMs is that different taxonomoies are suited for different purposes e.g. Asset management (which tends to be around products that can be bought), Standards management (which is oriented around more abstract concepts - i.e. not around products), Organisational divisions of responsibility (i.e. that organise technologies in large organisations around the organisations that will support them e.g. you will find all OSes looked after by what is really Server oriented systems group) Technology architecture (which lies between Asset and Standards). There are several solutions - one is use different TRMs for different purposes (modern EA repositories allow things to be classified using many taxonoies)

3. EA Compliance Becomes a Barrier - The difficulty in measuring the value of EA is
well known (e.g. I think it relates to counterfactual reasoning - see http://ea-in-anz.blogspot.com/2007/08/justifying-architecture-and-strategy.html).
Town planning is a good parallel. Town planning compliance is a barrier to laissez-faire property develop - as it should be. One can also see there is nothing wrong with a "critical business initiative" overridding the "planning authority's" existing plans - provided it is done openly, for well discussed reasons and by exception. Major programme of capital works involve overriding existing town planning regulations, and local planning guidelines on a regular basis.

4. Why so much effort was being put into hoovering up information about existing systems - because you are starting at wrong place i.e. the systems (which are a technology legacy that reflects a combindation of what the business wanted to do once, and how it once considered best to implement this). The right place to start is at the top (in the business) or as near the top as possible. Process models are also too detailed a place to start (this Webinar discusses some of the issues -http://www.troux.com/company/events/webinars/20060511caston/)

SOA and EA - issues with EA can apply to SOA. The difference is that the failure of SOA will be more obvious and damaging to the business (you can't bury you SOA mistakes as easily as you can your EA mistakes). see: http://ea-in-anz.blogspot.com/2007/08/soa-must-be-underpinned-by-better.html

A canonical data model - You can't like processes to them because in practice they seldom exist (I have never seen one that is anywhere near complete). See http://ea-in-anz.blogspot.com/2007/09/enterprise-data-management.html

I agree that SOA is a core enterprise level strategy. But the SPP needs to be built from the top down (using Zachman as a reference for top and bottom).