Carefully exceeding the mandate

It strikes me that many enterprise architecture groups are stuck in IT departments desperate to break free from the shackles of solution architecture and talk to the business yet hampered by a constrained job description, limited by their own leaders' perceptions and invisible to leaders beyond IT walls. So often I hear people talk about their practice of enterprise architecture as though the bonds have been broken. On deeper questioning, however, it becomes clear the mandate under which they are operating remains unchanged. I cannot help feeling that these groups are simply delusional. I wonder too how they continue to deliver on their restrictive mandate as they must be spending a large amount of time doing things for which they have none.


There is no easy answer on to how to draw an enterprise architecture group out of the shadow of IT. I suspect the answer is different for every group and every organisation - as is the nature of cultural change. My suggestion is to ensure you pay attention to deliver the things you are tasked with and be intentional (I mean really develop a plan for it) about nudging those around towards a different view of the your true value. I don't believe this is an enormously difficult task if approached in the right way and with the right set of skills. I believe this because I believe in the value of architecture at the enterprise level.

The need for an application inventory

Application Sprawl is an ever present reality for enterprise architects. Is it the role of EA or the IT organisation to constrain this sprawl? Does such constraint hamper business innovation? Or is the limitation in agility a worthwhile price considered against the long term consequences of an unmanaged, unconstrained application portfolio? Is application rationalisation a reality or is the way we look at platform services creating an illusion that is simply masking sprawl of a different sort?

It is logical that platforms of shared capability or components that are reused will be cheaper to operate and maintain than duplicated capabilities – especially those built on different technologies. Killing two birds with one stone increases return on investment receives little argument. This is as true of technology as any other aspect of the enterprise; or life - the TV in my kitchen doubles as a computer monitor. However, shared platforms simply create another container for more applications. Is a dashboard less of a business application than a web application simply because it is hosted on a BI platform and not an application server? To be absurd you might reduce the whole data centre to one application.

Being abstract about data

Data abstraction as a key tenet of SOA is a given. Linthicum writes about XAware, an open source product, and it certainly looks attractive. However, his support for Open Source is less easy to swallow; citing "typically much less expensive than... proprietary [tools]" as a reason.

I think Linthicum is dangerously simplifying the situation and, despite being a very keen advocate of open source products myself, I would sound a word of caution. The way I govern our technology standards is by creating an abstract architecture. This abstract architecture is a representation of the objects in the real world. I encapsulate and isolate as far as possible to reduce the complexity of the abstract architecture, and to understand the links between components. This abstract architecture is a representation of the capabilities that we have and underpins our service catalogue. It also tells me what skills are required to support, operate and maintain that capability.

I allow things that are not represented on that landscape IF AND ONLY IF they are isolated, black boxed, and totally invisible as an entity in the abstract architecture. If this can be achieved I don't need to know about it to maintain it, I only maintain its container. (This isolation can be achieved by using a service provider to support the product, effectively outsourcing the support, operate and maintain requirement.)

So look very closely at the open source product. What other components is it introducing into your landscape that you will have to support. As a rule open source will not isolate components, it will expect you to be able to support those elements upon which it is built.

Real World SOA | David Linthicum | InfoWorld | When Data Abstraction Meets Open Source | November 5, 2007 10:12 PM | By Dave Linthicum

XAware provides data abstraction tool that allows the architect to create a logical database before linking existing physical data stores to it. Thus, this allows the architect to work from the design to the implementation, and provides complete independence from the physical instances of data.