Which System?

As a follow on from my post on reference architecture you can start to look at what system(s) deliver these functions. Most often there are multiple systems that deliver a certain function within an organisation. There are multiple historical reasons that cause this to happen, one of the most common ones is organisation structures that drive two areas of the business to implement their own systems to solve a similar problem. There are many more, the key is that that would have made sense at the time.

As the organisation looks at the business and such things of the cost of running the organisation and the ability to respond to change duplication is detrimental to this. If you have 2 or more systems broadly delivering the same function you firstly have duplicated costs across these systems. Also if you need to make a change to a function across the organisation then you will need to change all systems that perform this function, reducing your ability to respond quickly i.e. time to market.

In the diagram above you will note that the non-strategic systems can often be categorised in some way. The spreadsheet system is red or bad, as in get of it as soon as you can. The orange coloured systems are not strategic systems but staying on them is less detrimental to the organisation than the spreadsheet solution. How organisations deal with these classifications are many and varied.

The enterprise will often look at these functions and set a direction or target state for this function. E.g. we will move to a Strategic system that meets the requirements of the enterprise as a whole. You end up with a system that is deemed strategic. If a project is impacting this function from an architecture perspective the project should remove the function from the non-strategic (Legacy) system and implement it in the strategic system.

The big problem here is that a small project may be planning to implement a 100k solution but the cost to move to the strategic system may blow the cost out to many millions of dollars. Here we have to deal with trade-offs, architecturally we should be going in one direction but project pressures (cost) mean we may need to actually do some development in the nonstrategic system.

This now goes into the realm of architecture governance which I may skip at this point.

So as a solution architect you have a target state for in this case “Loan Origination” being the Strategic Lending System. You need to weigh up your projects ability to say move part or all of the origination function out of the Retail Lending System. This becomes a transition state and with all journeys you may need to back track a little to actually get to your destination or invest in a non-strategic system.

It is up to you to sell this to your stakeholders.

Reference Architecture

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……..