Is your system an island?
Brian Robert
HR & Payroll | Project Manager | Business Analyst | Change Leader | Accomplished Plate Spinner | Known to ask the question 'When did it last snow in June'?
In an ideal world you would have one system that could do everything but a bit like world peace that is often an unattainable goal.
There can be many justifiable reasons as to why an organisation decides to invest in separate systems but if you do it is imperative that part of the selection criteria has to be how you are then going to integrate all these disparate systems.
If you don't then you could end up with an island with no way of getting off it or the likelihood that it will cost you far more than you originally budgeted for the initial solution.
It will almost certainly delay the implementation of the new system and it may well cause you a lot of pain in having to implement manual processes because it really is like trying to fit 'a square peg into a round hole'.
What seemed like a 'no brainer' in terms of return on investment doesn't seem quite so good when you factor in the integration costs and had that been done at the beginning you would have at least known what the real cost of the new system and the timescale to deliver was going to be or maybe you would have made a totally different decision altogether!
Quite often forgetting about integration occurs when the business decide they have a need and look for a solution to meet it without involving the IT department, because they have been told by the supplier that interfacing data is not a problem and they have an API.
If a supplier has not interfaced to or from the system you want to integrate to then that reassurance is worth nothing and they are often saying that without knowing your specific requirements and as for API's they are not a silver bullet!
You still need to know what it is you want to send between systems and when. You might think you want a 'real-time' interface but in actual fact that may not be possible as it could be that the licencing on one of your systems doesn't allow for a 'real-time' interface and that the licence cost to achieve this is prohibitive.
It might be that an API doesn't achieve the integration you want without a change to a business process or even a change to another system and these costs need to be factored in. It could be that the existing API does only part of what you want and so the API needs to be enhanced. All this adds to the cost and you might find that two or more suppliers are involved to achieve integration and as well as their costs you need to factor in the cost of testing which will become more complicated.
If you do buy the system knowing that integration is needed then it is imperative in the design stage that you involve people who know each of the systems, as well as someone from the business who knows what needs to be achieved. It sounds simple but you would be amazed how often this doesn't happen and how much pain it can cause in terms of requiring manual workarounds or fixes, perhaps resulting in a re-design of the integration layer.
The other thing to consider is that if you have integration between systems there will be an ongoing cost to maintain it (a bit like a road or a bridge) and these costs need to be considered as well. It may need changing if there is an upgrade to one of the systems or there is a change to a business process or maybe it can no longer handle the volume of traffic.
I think of Anglesey where, before Thomas Telford's suspension bridge was opened in 1826, the only way off the island was by boat or you waited for low tide! Then in 1850 they added the Britannia Bridge, which due to fire was rebuilt in 1970 and they turned into a two tier bridge to facilitate both road and rail traffic. Now they are considering a third bridge to meet 21st Century demand.
If you go for disparate systems you need to think not only of the initial cost of integration but also the ongoing costs and whether it might have been cheaper to have chosen a single solution from one supplier.
It is important that integration is considered as soon as possible in the requirements gathering process as it will prevent a lot of pain further down the line and it will prevent you from discovering that you have bought an island with no way on or off!
#integration#interfaces#businessanalysis#requirementsgathering#businesstransformation#businesschange
Now working for the NHS
5 年Good stuff, Brian.