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:
Post a Comment