Quality attributes of a system are few key metrics used to perform the application portfolio assessment. Quality attributes like maturity, adaptability, flexibility, availability, stability are quite a few frequently used metrics in the application portfolio assessment. All of them are subjective metrics and can not be measured directly. All of these metrics are measured through various other observed parameters. Among the listed quality attributes maturity and stability are predominately used in the assessment.
Let me propose how the maturity and stability of the systems can be measured in the landscape to perform the assessment. The purpose of the application portfolio assessment is to rank the system in various categories (same as the Boston consulting methodology). In simpler words, the list of applications which are cash cows to the company, list of applications which are dogs, list of applications which are stars and “?” question mark.
The idea is, as an enterprise architect and IT strategist, you want to make sure all the cash cow applications are stable, matured and in general, has very low risk. Measuring the stability and maturity are very subjective and often it is difficult to present the realistic picture in the exercise.
Stability represents the availability of the system. If a system is stable means that it is running in a solid platform provides a better high availability. The availability of the system can be measured by collecting the number of outages occurred, number of preventive measures (emergency change controls), number of special care taken (like special jobs, running jobs manually which are planned to run as per the schedule), number of upgrades and technology architecture. All these factors come together to derive the probability of the system failure in a given time. The probability translates to the stability of the system. If the probability of failure is negligible, then the system is very stable and if the probability of failure is very high and then the system is very unstable.
Maturity represents the obsolescences of the system. Technology and functional obsolescences are two parameters represents how much of the functionality of the systems are continued to be used by the end users, and how technology obsolescences presents the number of legacy technologies being used in the system. If the technologies used in the systems are kept up to date and fully supported by the software providers, then the technology obsolescence is considered very low. The functional obsolescence can be calculated by counting the number of functional points in the system and total number of functional points that are being used. More the number of functional points not being used by the end user the more the functional obsolescence is. More functional obsolescence is less the system maturity is.
Stability and maturity of the system can be used by the above proposed approach.