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.

Managing Requirements

I just posted these thoughts on managing requirements on G+: https://plus.google.com/u/0/103322217256114006757/posts/5ZBmgU1umq7

Sailesh wrote an interesting post on requirements here: https://plus.google.com/u/0/115629371379295233882/posts/7sTEwaUA6Cj.

I agree with him that management of requirements is so important, but a challenging thing to do and not helped by the tools we have at our disposal. Nevertheless, manage them we must and I organise the requirements I come across into Business strategy, Functional requirements and Deficiencies.

Strategy/Vision is perhaps not strictly speaking a set of requirements. However, as change can arise directly from strategic initiatives I capture them as requirements, although I might equally create functional requirements derived from strategy elements.

Functional requirements are things that we would like to, but are currently unable to do. This might be launching a new product or reducing travel through the use of video conferencing. Deficiencies capture requirements that address things that aren't quite right in the way the business operates or in the applications, data or systems we use.

I intend (but don't always succeed because the model isn't complete) to trace all functional requirements and deficiencies back to a source: either business drivers (captured as strategy requirements) or business process or technology.

I am using Sparx EA to model requirements along with the conceptual model I have been building of the business process and application landscape. As Sailesh points out, the tools available aren't great, but manage requirements we must... so a man's gotta do... I'd love to know how others have tackled this challenge.