SW Architecture feeding into Enterprise Archiecture

(prompted by work with Lattix)

SW Architecture analysis compliments Enterprise Architecture
Lattix is an excellent fit with other offerings e.g. those targeted at software design and development, and those oriented at the business architecture and strategy and its relationship to systems. Lattix should assist people reduce the costs of maintaining and extending their systems, whilst also improving the agility and reducing the fragility of these systems.

SW Architecture analysis compliments OO design modelling
RHE was a very earlier adopter of OO analysis and design techniques and introduced UML to many clients in the mid 1990s so I think we have fairly good to top to bottom view of this domain. While UML is very useful in analysing the exact characteristics and behaviour of a relatively small number of critical objects (to be constructed) it is fairly clear that UML does not provide a good way of managing large SW architectures (ie. set of objects have have been constructed and/or elements that do not involve engineering objects).

SW Architecture analysis and EA touch points
There is quite a natural point of interface between an EA systems and SW architecture analysis tools. A EA knowledge base brings together information held in many different discrete silos e.g. business goals, strategies, plans, initiatives etc. (often held in Office docs); business services, processes, rules, information, etc. (often held in discrete models and/or Office docs); extant systems (technology platforms, applications, datastores etc. - held in a range of places e.g. CMDBs); programmes and projects; etc.

Assuming an application is held in an EA repository - and it has also been analyzed by a SW architecture tool - it should be possible to augment the EA's knowledge of the application with information about its structure (e.g. modules) that is known and accessible from the SW architecture tool. This level of detail may be useful when changes or adaptations are being considered. It would also give EA's a more detailed understanding of the applications portfolio - which may provide more insight into the duplication of functionality across the portfolio of applications (supporting rationalisation, refactoring of the set etc.), common services interaction points (for SOAs) etc.

OTS applications
Obviously if one looks at an application portfolio in a large organisation many of the applications are OTS or constructed by third parties (and no insight into their internal structure is often provided). Though no doubt if the organisation developed a habit of recording the major modules within applications it may be that progressive vendors could provide the level of information necessary.

Zachman as a reference point

Using Zachman as a context - Lattix sees its positioning as at designer/logical and physical/builder levels. I also see Lattix operating at the Detailed representations/Out of context/sub-contractor level (i.e. completely outside the bounds of EA per se). In the following diagram I don't see the connection to services at the conceptual level correct (I think it is an attempt to overcome limitations in Zachman's suitability for SOA).




How lattix represents logical and implementation information
Having established a relatively positioning for the information Lattix collects and analyses we can examine how this information is represented.