In some cases an organisation has been utilising various IT systems over the past 30 years. As business problems evolve the IT systems will change and in some cases new ones will be added. Over these sorts of period of time a fairly chaotic environment can eventuate creating complexity and subsequently an inefficient architecture.
This complexity usually manifests itself in preventing or slowing down the businesses ability to respond to change in the market. Back in the day the business would be talking to the Chief Architect telling him they had to be able to sell on the internet. The problem was that their system wouldn’t be architected to support the volumes the internet would provide and most likely the thick client wasn’t suited to the internet. Sound familiar.
You find that an organisation will often produce a reference architecture that is designed to provide some guidance on how future solutions should be developed to reduce the complexity. Think along the lines of a council implementing various building regulations.
Reference Architectures take various forms but as a starting point try and break the functions delivered by technology into some logical categories. Here I have taken part of the Microsoft Reference Architecture for Banking.
The fun starts when you take a reference architecture like this and overlay the systems in use over the top of this. You often find that a function is duplicated across multiple systems and that a system is performing multiple functions which limit the ability to reuse.
So all the good coding practices that we learn as developers get violated when we look at the architecture of the enterprise. So in a sort of way we need to do a little refactoring.
So starts the journey of many transition states to get to our target state……..