Sunday 24 June 2012

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.

In order to manage something you must first quantify that thing. Or, to put it simply in the context of business applications, you need an inventory of the applications you are managing. This may sound simple, even trite; but it is much more difficult to achieve. In part because there are different viewpoints of the landscape, and each would create a different list. Of course, I will contend that the business view is the most important. And, of course, there is the temporal layer – the inventory past, present and future. Add in the complication of solutions created without the centralised oversight – those access databases and excel spreadsheets – and the task resembles the proverbial herding of cats.

I have lost count of the discussions I have been in attempting to answer the question: “What is an application?” You need to sort this out within your organisation, and capture specific meanings that you will attribute to terms like Systems, Subsystems, Components, Applications and Solutions. I will expand on this in a future post on business context; for now we may agree simply that there are many ways to count the components in your application landscape.

So, do you think it is as important as I am suggesting?  How do you go about creating an inventory of applications?

No comments: