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.

Who is accountable for application sprawl?

In my last post I mentioned application sprawl. In many organisation, like self replicating nano-bots, the list of applications that enables the business to function increases uncontrollably. The IT organisation tries to bring some order to this chaos with limited success.

We try demand management techniques, which may be designed to help people to stop and think but are largely seen as barriers to change,dampeners on the springs of agility. We enforce standards, erect governing bodies and create IS Strategies (aligned with business strategies, of course). Despite all this effort there are still the exceptions justified by "my case is special"; and let's not open the can of worms that is self-built solutions - those excel spreadsheets, access databases and (heaven forbid) the unauthorised use of free services on the web.

This is application sprawl, and it exists to some degree or another in every organisation large enough to have an IT department (and probably many that don't as well).

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.