I’ve been a fan of business capability reference models (BCRM) for a while now. These are a great tool for looking at existing IT landscapes and new projects to understand the degree to which functionality is duplicated from a business perspective. A BCRM is a hierarchical breakdown of the capabilities, or functions, an organisation needs. For example a financial services organisation may include Policy Administration and Investment Administration as top-level capabilities. In turn these will break-down to lower level capabilities, e.g. Policy Administration will need to provide quotations, new business processing and claims handling. There is no limit to the number of levels but in financial services four to five seems typical.
With the BCRM it is possible to look at each piece of software and list which capabilities it implements and then to establish where there is duplication.
So what to do when duplication is discovered? Surely an organisation only needs one piece of software supporting a given capability? Well maybe; I’ve previously described some reasons why an organisation might want to retain two systems serving similar capabilities. I would also observe that aiming for one system per capability is the correct answer if the organisation is going to remain static and has no prospects of internal or external change in the medium term. However, in a changing world, and organisations, you are quite likely to find: an older system in declining use, the current (‘strategic’) choice, and maybe something new and experimental. Perhaps tolerating around three is a reasonable position from an EA perspective.