Written by David Henderson on Monday 5 August 2013
Last weekend, as we finished lunch, conversation turned to birthday present ideas for our daughter. I thought it was slightly early for this discussion, as it’s still over 6 months until she turns 2, but we continued anyway. My wife’s idea was a play shop stall; at the moment the sofas are pulled out from the walls and the kids stand on chairs behind them ‘selling goods’. She handed me her phone and said “something like this” – open on the screen was Pinterest with a collection of images of children’s shops stalls. The research and scoping of this project had clearly started some time ago. Next came “can you make one?” Up to this point I had been assuming we would simply buy one but now there was another option. As any bloke with a man cave would, I replied “I’ll have a go” and off to the shed I went.
In the world of financial services, we constantly see clients pondering the build or buy decision. For some situations the choice is simple, if you need word processing or spreadsheets you buy Microsoft Office. I have heard of an IT department taking it upon themselves to develop project management software rather than buy MS Project, but normally off the shelf software will proved more cost effective and fully functional for this level of requirement. However as the system requirements grow and start to be shaped by the organisation’s propositions, the decision gets somewhat harder. Major systems charges are rarely dreamt up on a whim over lunch; much like a child’s 2nd birthday you know for quite some time that it is coming. You also know why the changes need to take place, maybe the current system will struggle to scale to the predicted new business volumes, system support is coming to an end or it’s becoming prohibitively expensive or restrictive to maintain. Whatever the reason for the change a full understanding of the business that it will support is essential to inform requirements but a look outside the organisation may also be sensible to see what others are doing – much like the collection of images my wife showed me.
Back in the man cave I assessed the materials I had available. The usual old bits of wood wouldn’t do as I don’t have the carpentry skills for the little details that would tie it all together and make it work. However, the now defunct and disassembled flat pack furniture looked promising; the standardised styling and connection options could make this look like it was meant to be. I picked up a few different pieces and started to fit them together into a variety of shapes, gradually moving towards a representation of the play shops I’d been shown. Proud of what I had done so far, we held a little review session to discuss the required height of the shop and I was informed that it would be nice to have an arch or canopy for the shop keeper to serve through; the early review had successfully elicited additional requirements.
Large bespoke software developments are tricky, time consuming and expensive, in the same way as I have limited carpentry skills, most financial services companies have constraints that challenge their ability to make complex systems work. But rarely in financial service is an organisation in an established market doing something so radically different that no one else is doing it; whatever the reasons for the change (regulation, consumer demand, history, etc) it could be an opportunity to look at packaged solutions to see if they can fulfil or even shape the organisation’s requirements. Given the complexity involved this is unlikely to be just one piece of software from a single vendor (whatever their marketing blurb says); much more likely is that a combination of components will be needed. Those components will need to work together and this is where standards are required to make that integration simple and reliable; much like the Altus Transfer Gateway using SWIFT, ISO20022 and the UKFMPG Market Practice to send transfer messages, or the wooded and metal dowel positions of my flat pack furniture pieces.
Using existing components, rather than bespoke development should reduce the burden on the organisation. Many little decisions have already been made and utility functions built, allowing the effort to be focused on fitting components together and configuring them to the organisation needs. SMEs can then be used sparingly to attend review sessions, provide early feedback and identify any additional requirements, allowing them to get on with their day jobs of keeping the organisation running, rather than being the reluctant clients of a software development project.
As the shop stall reaches the conclusion of the structural build and awaits its soft furnishing and decoration, my build vs. buy decision has resulted in a decent integrated solution despite the limited parts available. For financial services organisations facing their own construction challenge, the range of technology components available is now broad enough to make similar intergation a viable option – something to consider the next time you hear “we’re going to build a new xyz system”.
Sitting back to admire my construction, I have visions of the kids selling homemade lemonade from it, like in that HSBC TV advert. I wonder if my neighbours will mind if I divert some of the hundreds of coach parties that visit Bath each year into our Square?