Both I and IT Business Edge contributor Mike Vizard last month wrote about the problem of overly complex IT application portfolios. I spoke to Honorio Padron, the Hackett Group's Global IT Advisory Practice leader, who told me l<strong>ack of governance is one of the key causes of overextended application portfolios.</strong> Too often, he said, companies focus narrowly on budget and specifications during IT projects and neglect to shutter applications that may no longer be needed once new technology rolls out.
Padron suggested companies need a more holistic analysis of their entire application portfolio, one of the key tenets of project portfolio management. But The Hackett Group finds only about half of companies consistently use such an approach.
Vizard cited results of a Forrester Consulting study done on behalf of HP, which found business units resist shuttering applications and IT departments too busy creating new applications to deal with the older ones. Forty-four percent of respondents cited business users' over-attachment to applications as the biggest hurdle to retiring applications, followed by busy IT departments (43 percent), inadequate budgeting for data migration and storage costs (40 percent) and leaving apps in inquiry mode for data access and/or compliance reasons (40 percent).
With this fresh in my mind, I was interested to see a post on the Inside Architecture blog posing the question: Does app portfolio simplification solve the wrong problem? In it, Nick Malik noted that a common way to pare application portfolios is to locate two similar business units using applications with functionality overlap, then tweak business processes of one unit and features of one application so the units can then share the modified application.
But as you might expect, this process doesn't always go smoothly. You're asking both business units to make changes, and change isn't something most business users welcome. (See results of Forrester Consulting study above.)
Malik suggested a preferred approach might be to simply merge the two business functions. I agree with Malik that this approach would reduce overall business complexity rather than application complexity. So in the end, it might be worth it.
But as some of the comments following Malik's post make clear, it sure as heck won't be easier to merge two business units. (In fact, I snickered as I wrote "simply" in my first sentence in the above paragraph.) Wrote Kevin Brennan:
Nick, are you actually suggesting that it's EASIER to convince people to restructure the organization? I mean, if you merge the departments you still have to go through all the headaches of changing the business processes and the application (to deal with any unique circumstances) plus the organizational headaches of rationalizing different groups with different job titles, functions, etc. I definitely agree that there are cases where this is the right solution to this kind of problem and in general that IT systems should be looked in the context of the business that they support. I just don't think it's simpler, at least not in the short term. (It could be simpler in the longer term, I suppose -- with one business function it will be easier to ensure that the process stays consistent over time).
Malik's response? He wrote:
Changing IT is changing the business. If a business unit decides to create their own "accounts payable" team, rather than use the corporate "accounts payable" department, they may be able to do that. But if you simply go above that manager's head and point out the value of a couple of key changes... one of them being "use the corporate AR department for all AR activities," you may find that the powerful CFO signs right up. If you look for natural allies, you may find that it is easier to solve business complexity problems by pointing at business complexity, rather than trying to fix those problems through software.
I encourage you to read Malik's original post and the entire thought-provoking string of comments that follow it. However, I think the short dialogue between Malik and Kevin Brennan sums up what I find most intriguing about the discussion. This kind of initiative is what the business often asks IT to provide. But in reality, do business executives really welcome it? And is it even possible in most organizations today, given the still often tenuous relationship between IT and the business?