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?