So, your project has kicked off. It’s big. It’s strategic. A career maker. Your task? To design and implement a new strategic messaging platform to replace the existing legacy system. This constitutes a myriad of SQL scripts, staging tables, tactical data stores and trade flows feeding several Core Applications. How hard can it be? Just rip the scripts and tables out and replace them right? A bit of data mapping and the job’s done yea?
Well, before you get carried away with the moment, take pause first. The following may well make the difference between a project that’s constantly playing catch up and one that delivers that Strategic platform, positions your firm ready for the future and makes your career as well.
It’s all too easy to see the end product in projects like this. To rush quickly into build, agile stand-ups and backlogs, iterative code releases and test driven development sprints. However, before you do any of this, you need to understand the here and now – the “As Is”. Without understanding that in detail, you cannot hope to succeed in replacing it.
How do you go about achieving this? How can you be sure you understand exactly what is happening within the current trade flow? There are a number of tools and techniques that you can employ to get to the bottom of the functionality. I’ll run through some of them here.
Tell me all about it – get the Business guys to talk about what it does and how it does it. Not just the 80% of the stuff that it does, get into the nitty gritty of the complex and strange stuff. If the system uses allocation rules – are all trades expected to match against them? You’d be surprised how many times you’ll hear an explicit “yes” answer, only to discover later on that a significant subset of trades never match against them and are just ignored by the current processes as later flow events superceed them. That may be fine for the “As Is”, but can your pristine messaging trade flow system cater for that without generating thousands of breaks?
The IT guys – without the involvement and buy-in of the current IT support team, it’s going to be incredibly difficult to understand the “As Is”. It’s not too bad if you are that current team, but it’s a challenge if you’re coming in from outside. Meet with them regularly, get them onboard. Try to have someone from that team assigned to you, either directly or via the matrix.
You’re so “As Was” – If your project is in flight for any significant length of time, it’s more than likely that the current system will not stand still whilst you work. The business will still want to drive forward, taking on new client requests; bringing new products to market; offering more visibility through in depth client reporting – it will never stop. Make sure there is a process in place that feeds changes, business developments and new project initiatives into your project and “As Is” model.
What goes in must come out – Do you know all the input and outputs involved in the current system? You may think you do but you need to consider not just the exterior boundary of the domain. There will be numerous internal boundaries between messaging and Core Applications as well as static and reference data that is required to support the processing. List them; categorise them; get samples and understand what the data means and how its meaning may change during the flow.
Timing is everything – you need to understand the sequencing of events in the current system in great detail. Which scripts run? When do they run? What data is available when they run? What data changes after they run? A mis-understanding here will cost you dearly further down the line.
If this; then do that – typically the business rules in the current system will have evolved over a number of years. They will have been scattered far and wide across the plethora of scripts employed in the system. You need to find them and understand them and to do this you will need to revisit the work you did with the business guys regularly. At this point you’ll start to unearth business rules that have been long forgotten by the current business community – these rules will have been implemented years ago by people who no longer work for the firm.
Once you’ve fought your way through the above processes, you’ll have enough information to produce the most valuable asset you will ever have – a working model of the “As Is”. If you produce this, you will reap the benefits time and time again. It will support your design process for the new system – which should produce it’s own model of the “To Be” domain model. It will allow you to validate your data mapping analysis steps. It will support your system testing steps and will also provide invaluable assistance it UAT/Parallel testing and issue resolution. It will allow you to compare “As Is” vs “To Be” states in discussions with the business, especially when the 20% edge case rule rears its head. In short, you’ll use this project artifact throughout the entire project lifecycle and it will reinforce your sanity time and time again.
So, if your BA’s aren’t talking about “As Is” and “To Be” domain models; if they are focussed exclusively on data mapping exercises; if they can’t describe the business use cases in the system inputs and they aren’t asking those probing questions around the edge cases and sequencing, all the things that feed into the production of the “As Is” domain model – then you need to take a long hard look at the project. Ask yourself the question – how can we possibly get to where we want to get to if we don’t know where we’re setting off from?
Embrace the here and now and Don’t dis the “As Is”.