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?
Hi Nick, a timely post for me as I’ve been thinking a lot about this recently.
I think that simplification is a good end in itself, but at the same time we need reliable ways of understanding what value the process (or application) delivers before we can work out which one to change (in your example above).
Managing a portfolio of any kind requires understanding what the relative values of the components are as well as their costs.
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.
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).
@Martin
Figuring out what the value of an application really is… now that’s always tough. I have no "magic bullet". Capability analysis will tend to point to both applications equally because they are both "inside" the capability. So you have to look at features, and proximity to principles, and ability to share information, and about a dozen other things. That’s a tough nut.
@Ashish
You are correct: forcing business units to merge just to reduce the number of applications… there may not be enough value there.
I am not suggesting that application portfolio complexity would be sufficient rationale. But it could be a clue to look deeper. Once you do, you may find that the smarter recommendation is to merge business units.
@Kevin
Sometimes, the easy answer is the one staring you in the face. 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.
Not the most common case, I agree. But one worth considering.
Nick,
I agree with what you’re saying, I just wouldn’t call it "simpler". It may be conceptually simpler but it’s probably more complex to execute, at least in the short term and for this example.
That said, I do want to violently agree with you that there are a lot of cases where we build complex IT solutions when we could solve the problem much more cheaply and easily by simplifying the business instead.
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
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.
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.
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.
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.
@Patrick,
You point out a common experience and one of the best reasons, IMHO, for creating an EA program. It is the job of EA to facilitate those conversations.
@Roger,
I agree with your observations, and appreciate your contribution. This is a nuanced role, and nearly all of the actual impact of EA is done through indirect negotiation and influence. I had taken that as an assumption in the post, but you have added clarity by pointing it out. Thank you.
@RHWhite
Thank you for your very interesting pointer to the work being done at Intel. I will check out the book you mentioned. Also, you mention the "Lack of ROI analysis" of a future state model.
This is a fascinating problem. IT does a bad job, traditionally, of presenting business cases for the good things we are asking for. Sometimes we ask for not-so-good things as well, and ROI analysis is impossible (because there is no ROI). On the other hand, sometimes the business pushes through a change with no ROI either.
I think ROI is a hammer used to tell IT to shut up, a hammer that the business simply ignores when they don’t want to use it.
You nailed it when you said that agreement has to be reached… which I read as "agreement on a balanced set of criteria for deciding what to fund, with some value for tactical and some value for strategic, across multiple measurements (not just ROI)."
— Nick
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.
Great post Nick. Definitely points squarely to a long standing observation that "IT Architects are sometimes their own worst enemy". The fact that there is IT architecture does not imply that it lives in vacuum, although more often than not it appears like that.
Isn’t one of the first architecture principles "do the big things first!"? Confirming that business processes (bigger things, which IT functions support) are still correct and at the right level of complexity, before we change IT landscape, seems like an imperative.
As Roger says, EA must address the intersection between business and IT concerns for the organisation to gain full benefits.