Does app portfolio simplification solve the wrong problem?

As you may know, I agree with Roger Sessions that one of the value propositions of Enterprise Architecture, as it relates to IT,  is to simplify the IT application portfolio.  I believe that every application has a “cost to own” and adds to complexity.  By reducing the complexity and size of the portfolio, we can free up resources that are so desperately needed for innovation.

One of the primary patterns for application portfolio simplification is to find two similar business units that use two overlapping applications, and change the processes in one unit, and change the features of one application, so that both units can use the same application.

 

There are two changes here.  You have to change the business processes of at least one of the teams (probably both teams), and you have to change the features of one of the applications, which usually means bring together the data sets as well.  That’s a lot of change.

But as an enterprise architect, I get to look beyond the bounds of IT.  So, let’s take that viewpoint.  Now, we don’t have an IT problem.  We have a business complexity problem.

As an Enterprise Architect, wouldn’t it be simpler to simplify the business itself?  Not always possible, but it can be done.  In those cases, there can be less overall change if you simply merge the business functions. 

People get very attached to their applications, and it is tough to convince an executive to take on the cost of making all of the changes to merge applications.  In some cases, application portfolio simplification can be done best through “business function portfolio” simplification.  In other words, the case is more compelling to merge the business functions instead.

What say you, gentle reader?  Have you ever worked to merge business functions?  What was your experience?

Comments

• Anonymous
  March 25, 2010
  The comment has been removed

• Anonymous
  March 25, 2010
  I agree. Whenever you have a pattern as suggested in your post then look beyond applications. But after that it would be a reverse exercise in that you would first address the business part, start redefining the process, decouple the application slowly and then phase one, or even both out. It turns out the best way to leverage some technologies like BPMS, BRE, and SOA. Just one point here though that too many applications wouldn't be a reason enough to force a business function level change. You've got to find enough reasons on business value level to force any changes, and what you and I are  suggesting could be too costly for them to even blink if not for a better business value than just applications rationalization.

• Anonymous
  March 25, 2010
  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).

• Anonymous
  March 25, 2010
  The comment has been removed

• Anonymous
  March 26, 2010
  The comment has been removed

• Anonymous
  March 26, 2010
  Hi, Nick. Interesting post, as always. Looking beyond IT when trying to solve this kind of problem definitely sounds like a worthwhile exercise. I'll be sure to bring it up next time we have these kinds of discussions. Unfortunately our industry (finance) is heavily regulated and I'm not sure it's a realistic option. But one well worth discussing. So far, every time we've tried to simplify our application portfolio we've run into the problem of dependencies: applications that depend on the application we want to remove. Sometimes dependencies are easy to identify and sometimes not (think publish/subscribe) and in those cases it's always a bit scary to take an application down. It usually ends in either a large IT effort to re-write code and re-route data or that we decide that it's not worth it. That's my experience any way. /Johan

• Anonymous
  March 26, 2010
  Simplification of the application portfolio is primarily an IT 'goal' or focus if you will. If IT can achieve integration between the applications and maintain them at a low cost, the Business will still be able to thrive. The common (IT and Business) goal is to lower cost of application maintenance in its broadest perspective to increase profit. But that 'common' goal is often left out of the equation because of the Demand - Supply roles. Business asks for something, IT delivers. And with that justifies its existence. There is no real common understanding of the overall Business problem, and the best way to solve it taking both Business and IT road maps into account. My background is in the implementation of off the shelf CRM applications, whereby the best balance is achieved by a balance between customizing the application to fit the business requirements and changing the Business process to make best use of the application with lower costs (in longer terms). This should be the real discussion, sponsored by higher management, between Business and IT. And that requires a common understanding.

• Anonymous
  March 26, 2010
  I think there is a risk in EAs telling business how to do its job better, as there is in telling IT how to do its job better. EA is not about business or IT, but about the intersection between the two. Having said that, it is my experience that when business and IT come together to drive simplicity into the IT/business relationship, that simplicity seeps out into both the IT AND the business. So I agree that EA can influence business to simplify through consolidation, but only indirectly.

• Anonymous
  March 26, 2010
  One other point I would like to make... We tend to assume (from our IT training) that duplication of functionality makes things more complex. Often this is not the case. Often we make thing more complex when we try to generalize them in preparation for consolidation. Processes should be consolidated only when the net complexity is reduced by consolidation. This sounds obvious, but in my experience, most consolidations do more harm than good.

• Anonymous
  March 27, 2010
  Nick, this is a great post. This methodology you've outlined is one that is used by Intel. I'm aware of at least one MBA program requires the student to study Intel's method of technology innovation and delivery. You have touched on the following Intel metholdologies.

1. Innovation by Reapplication - This is where existing solutions are examined for extensibility and applied to new or existing domains to simplify the portfolio.
2. Innovation is managed by  six parallel vectors. (1) Vision, (2) prototype (3) Business case (4) business process change (5) Organizational change (6) Customer or societal change The business and those who are charged with visioning must agree that vectors 5 and 6 are an accepted part of the solution delivery. For whatever reason it seems IT and business miscommunicate on how a particular solution will change the organization or a particular customer. Perhaps this is due to the lack of evidentiary ROI analysis against the current seperate solutions and the envisioned reapplication solution. For more information check out Managing IT Innovation for Business Value. Actually this ROI formula provided in this book compliments your premise around running IT as a non-profit and government.

• Anonymous
  March 28, 2010
  The comment has been removed

• Anonymous
  April 08, 2010
  Hi Nick,  I've done something similiar to what you are talking about several times.  The real pain is always in the last 5%.  In my opinion it comes down to project management plans never having robust enough clean up phases.  The clean up always ends up getting passed to Operations to clean up in BAU, which in turn results in the detritus you find in any technical environment that has been running for a long time.  Most of the Architects I know have a story about when they had the server that nobody knew what it did turned off.  With some form of disastourous consequences. :-)   On a different note, from a Government perspective.  Functions of government don't tend to change, whereas government agencies do, so descrete applications for each function can be a blessing, not a curse.  The higher cost tend to be in having to take over (or change) a function that was not descrete in the agency you took it over from.

• Anonymous
  May 10, 2010
  The comment has been removed