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.