In the last two weeks, we’ve covered the ideal criteria for scoring against business fit, and technical fit. In the last of this series on estimating the attributes of applications as part of a portfolio effort, we’ll be talking about risk and the components that make it up. So what risk factors are we facing for our applications?
1. Vendor risk
Many software packages will come from vendors – some may even be managed by them. So our first factor in scoring application risk is: How dependent are we on vendors to deliver this system, and how stable are those vendors?
2. Inherent complexity
Some applications are more complex in their architecture, configuration or operation than others – and greater complexity increases the chance of errors. So the second factor to ask is - how complex is the application? Is it inherently difficult to understand?
3. Infrastructure
Many applications are quite liberal in the platform that they require… but some are not. The more specific the application’s requirements for specific infrastructure components, the more vulnerable it is to changes. So - does the application require any specific infrastructure? And if so, what risks are associated with the infrastructure components involved?
4. Required upgrades
How soon will the production version of the application require an upgrade? Is the current production version facing de-committal of support in the immediate future?
5. Expansion capability
Business changes, and sometimes an application will need to supply more capacity than initially (or currently) implemented. So - will there be any issues as and when the application needs to expand capacity?
6. Ongoing security vulnerabilities
I think I’m on safe ground when I say that security is an aspect of application risk. Applications have vulnerabilities; it’s a fact of life. The question is, are there any known security vulnerabilities associated with the application – and do they have fixes or workarounds available?
7. Cost estimation
If we don’t understand the components of the application’s cost, then we can’t monitor and estimate them. So another factor in application risk is going to be - do we have a clear understanding of all of the costs involved in managing and maintaining this application?
8. Skill dependencies
Managing and maintaining an application will naturally require skillsets – system administration skillsets, programming skillsets, configuration skillsets. Do we have access to the skillsets necessary to maintain and extend the application? Are any particular skillsets that are needed rare and/or expensive to source?
9. Governance issues
Risks can occur when responsibility is shared between different parties – it can cause issues with fault resolution and expansion. So - who owns the application? Is the application owned by the business – either partially or wholly?
10. Business integration
Using any application requires some degree of accommodation from those using it. Does the business have the necessary capabilities to use the application effectively? If not, have they shown willingness to acquire the necessary capabilities – or resistance?
11. Disaster Recovery
Last of all, an element of the risk for any application will come from disaster recovery. Specifically, what disaster recovery is in place for the application? Is the current disaster recovery regime appropriate given the business criticality of the application?
Final Word
Measuring your applications against these business fit, technical fit and risk criteria is a simple but sure way to optimise your application portfolio and in the end, reduce cost. Of course, visualizing these criteria in a way that allows you to make decisions is another problem. That's where application scoring dashboards come in, a necessary feature of any application scoring exercise!