Many IT organizations are overloaded, but under-budgeted, their significant portion of resources have been used to keep the light on, and maintain the current application portfolio, In a time when IT departments are being asked to do more and more when budgets are not increasing, where does the money come from for innovation? Wouldn't it be useful to know where there are unused licenses? Wouldn't it be useful to know where you have multiple applications doing the same thing in different areas of the business? And wouldn't it be useful to profile your users based on what they use and need and then provide them with only those applications? To put simply, what are the barriers to managing a balanced IT portfolio, how to run IT more effectively, and do more with innovation?
It tends to be an organizational issue. If you have a large, enterprise organization with shadow IT or business power users that have the budget - the spread of applications can quickly get out of control. Every user tends to believe that their particular application is "business critical" and it can be difficult to convince otherwise. On top of that, true software asset management is hard to implement - it is a transformational project if done right, and those projects are almost always complicated and take a long time to complete. But often applications that once added significant value to the business remain in the portfolio, being supported and licenses being renewed, when they have been superseded by a 'better' alternative. To keep supporting more and more applications for fear of political issues that traditionally IT stays out of is unsustainable. Unused or under -utilized applications that consume a disproportionate amount of resource when compared to their value, need to be addressed. It’s an organizational issue. An application has associated with it, a lot of business infrastructure and even a profit or revenue stream and customer relationships.
IT has been unable to demonstrate the value in application portfolio management. It does well at a gross level but when it comes down to individual applications, it doesn’t do that well; largely because IT focuses on overcoming technology challenges, not solving business problems. IT managers have never highlighted the fact that the business suffers from multiple applications, not IT. IT is one of the outputs of the issue, not the cause. From an organizational standpoint, for APM to work, the users have to want to move. So the question IT management should be asking is ... how do we motivate the business users to want to move to a common application. In addition, many companies are driving down a dark road with no headlights or instruments. They don't know if there is a problem brewing or if there is an opportunity to increase their performance. Good business sense suggests that knowing an application's utilization and resource consumption (both admin and infrastructure) are necessary to make good architecture decisions. On the other side of the equation, one must also understand the value an application brings in revenue, compliance, risk and business strategy. Making business decisions with any of the key parts obscured only raises risks in an environment where there is an increasingly little margin for error.
Understand real usage of applications and tie that information back to the end-user. The burden of APM is not solely IT. If you can make it clear where the true cost is, IT can get success. If you can motivate the users that the grass is greener, you can get success. But if you take the burden on as an IT project, you will struggle. Moreover, empower the user. Get them to choose the ideal solution for their work; from this IT can build up a profile of a user or group of users and understand their work-style. This alone provides a fact base for strategic decisions about rationalizing unneeded applications and provides the basis for innovation, in more complex cases, it can be the foundation for further investigation.
Application Portfolio Management (APM) is challenging for IT because of its political ramifications. No end user wants to give up his/her application because (a) they don't need it, or (b) there's another application that is less expensive. They will be especially reluctant to give up their application if they perceive it is the IT department that is mandating it. The 'do more with less' mantra applies every bit as much to functional management as to IT. The people running business units or departments would rather spend their time worrying about their mission than whether they should pay the price of the dislocation required to help the enterprise achieve some cost savings by migrating to an application used by some other department with a parallel function. "What's in it for me?" is a legitimate question under these circumstances.
The service concept can be effective when tied to projects. Part of the problem is that a single application may not be the best concept to build portfolio management around. Consider "Six Blind Men & the Elephant"—how are you going to find the applications to be managed vs. the applications that for whatever reason need/should/have to remain in the house (assuming their edges can be determined)? Many companies simply do not have an accurate inventory of what's running on their infrastructure and who's using it. Companies without an effective project portfolio management may also be missing important contextual information. Not having the big picture creates a vulnerability to be second-guessed and stonewalled by anyone that might be forced through a transition. A better alternative might be the technology agnostic concept of a "service" that has specific technology resource types mapped to it. The services concept is even more effective when tied to projects. If one combines the service portfolio with discovery tools and other forms of volume or usage measurement, figures out how to map volumes to the actual points of consumption within the organizational hierarchy and then wraps processes such as the financial and demand management of IT Services around it, then one does have the information required to properly govern IT.
A charge-back process will go a long way towards creating the "understanding" that is required to make a change. Whether it is an allocation or direct charge, once the end users understand how much it costs to keep their favorite application on hand and running, it brings about a rapid change in thinking. What is the company's position on chargeback? If IT assets or services are not accurately charged to the business units that use them, it creates disincentives to change. Many IT organizations divided up the IT costs on a pro-rate basis, based on the number of staffs or on revenue. These schemes may not create a disincentive, but a perverse incentive to create waste.
SAAS model creates the new angle to review IT portfolio. More and more new applications, or new versions of existing applications will be delivered on SaaS models, ease of management and capacity elasticity will provide significant incentives to migrating in that direction. In the long run, this will create opportunities to address consolidation of redundant COTS applications. Custom applications are another story. So the direction that must be taken is to (a) collect the information needed to really identify opportunities to simplify and save, (b) evaluate the chargeback schemes in place to determine whether they create disincentives, (c) CapEx vs. OpEx analytics. (d) prioritize opportunities based on RISK-ADJUSTED returns and (e) partition the benefits of achieving savings to reward the people that bear the brunt of the work.
The key is executive leadership, from all parts of the business, not just IT. Traversing the political APM minefield requires a strong IT leader who understands business and sits at the executive table and engages the senior executives. Without executive backing APM will take on a life of its own, the battles will be long and bitter and, in the end, costly and non-productive. And a transformation team whose responsibility is to educate the organization about the costs of application ownership should be established. This team should engage the end users, let them make the decisions regarding what [application] standards they wish to establish, and have the responsibility for executing a strategy to streamline the application portfolio, standardize processes, increase productivity and reduce costs.