Fake it till you make it! A model for integration in banks?

On Bankervision, I read this great post Using people as glue. It is often the case, when you move from a legacy system to a new system that you have to face the struggle of moving your data and user experience from one to the other. As described by James Gardner:

You know that, even if you mandate a new systems approach, you’re always going to have to spend piles of money doing legacy integration, because that’s where the data is. It is data on which the business relies, so it has to be available, and, obviously, the job of moving it all, and the business rules and all the rest, to a new system in one go is far to large and politically charged.
And then, you wake up one morning and realize on top of everything, you have the "die or retire problem". Everyone who knows the guts of legacy is either dead or about to retire.
You have to do something about legacy, so you sigh, and sign up for truck loads of integration anyway. (emphasis added)

Gardner proposal is to use people to do these tasks instead:

What about, for example, using people as glue? Why can’t they look up data in both systems and perform appropriate updates?

and

Now, I’m not suggesting that anyone put people back into systems permanently. But as temporary, good enough, solution while something better is worked out, surely it makes sense to at least consider the option.

Actually, that’s something that startups are sometimes doing and that has been worded by GigaOM writer Liz Gannes as Fake it till you make it in an article on Aardvark.

Aardvark is a social search engine (recently acquired by Google) which can find the best persons willing to answer your questions and send their answers back to you. Ask a question on Photography and someone online who listed photography as a center of interest is proposed your question and can answer it.

What’s interesting about Aardvark is that they started creating their product using people instead of building an automated back end from the beginning. Basically, they “faked” being able to route automatically queries during 6 months by having people do that for them. In the mean time, they were able to attract funds by showing the concept was working and to take the time to build the actual routing engine.

 

aardvarkautomation

From people to automation (people in black / system in blue)

Looking back at Gardner’s proposal, I believe this strategy could be applied to banks when transitioning from one system to another. Instead of spending a lot on integration, fake that you can actually transfer in an automated way from one system to the other until you are fully on the new platform or you built a successful interface if the legacy system has to be kept longer.

 

I included the presentation from Aardvark, as a whole, it’s a very interesting presentation on entrepreneurship, building companies and products. (specific part on automation starts at 12:35)

 


Watch live video from Startup Lessons Learned on Justin.tv

Liked this post? Follow this blog to get more. 

  • Pingback: CU Water Cooler » Blog Archive » CU Water Cooler 5/4()

  • Really? You want to FAKE the customers’ financial data? If you’re talking about systems that contain REAL monetary info, I think this is a recipe for disaster.

    OTOH, if you’re talking about moving from a legacy project management system to a new one, or something like that, that doesn’t handle customer monetary data, then I can see considering this option.

    Is it really cheaper to pay your staff to do the data transfer manually, while you build the conversion (which now has to account for the fact that not ALL of the data should be converted) than to just build the conversion and hold off implementation until it’s done? I’m guessing not, in most cases. But it’s worth considering.

  • Really? You want to FAKE the customers’ financial data? If you’re talking about systems that contain REAL monetary info, I think this is a recipe for disaster.

    OTOH, if you’re talking about moving from a legacy project management system to a new one, or something like that, that doesn’t handle customer monetary data, then I can see considering this option.

    Is it really cheaper to pay your staff to do the data transfer manually, while you build the conversion (which now has to account for the fact that not ALL of the data should be converted) than to just build the conversion and hold off implementation until it’s done? I’m guessing not, in most cases. But it’s worth considering.

  • Really? You want to FAKE the customers’ financial data? If you’re talking about systems that contain REAL monetary info, I think this is a recipe for disaster.

    OTOH, if you’re talking about moving from a legacy project management system to a new one, or something like that, that doesn’t handle customer monetary data, then I can see considering this option.

    Is it really cheaper to pay your staff to do the data transfer manually, while you build the conversion (which now has to account for the fact that not ALL of the data should be converted) than to just build the conversion and hold off implementation until it’s done? I’m guessing not, in most cases. But it’s worth considering.

  • I don’t mean to literally FAKE the customer data but to “fake” that your systems are as automated as possible (a target for most financial institutions) during the limited period of the transition between 2 systems. For example, if you have a system managing trades and positions, having people do some of the legacy transactions manually, while your new transactions are already handled by the new system, instead of going through the hurdle of moving all your positions to the new system through a complex and costly interface. This might not apply to all projects and migrations but it can be worth considering when a limited number of data is creating a major issue in terms of transition (data cleansing issues for example)

  • I don’t mean to literally FAKE the customer data but to “fake” that your systems are as automated as possible (a target for most financial institutions) during the limited period of the transition between 2 systems. For example, if you have a system managing trades and positions, having people do some of the legacy transactions manually, while your new transactions are already handled by the new system, instead of going through the hurdle of moving all your positions to the new system through a complex and costly interface. This might not apply to all projects and migrations but it can be worth considering when a limited number of data is creating a major issue in terms of transition (data cleansing issues for example)

  • mcx tips

    Wonderful post dude.i really appreciate sir. 

  • mcx tips

    Very informative post sir .i just love it.
    for contact please call us on 0731-4295950