by Fiona Hamilton, Vice President, EMEA Operations at Volante Technologies Ltd
In the first article in this three part series we looked at the business and technical drivers behind the business case for implementing a common data integration architecture. In the second part, we examined the process of deciding how to best achieve that end goal by selecting the most appropriate architecture. In this third and final part we look at some of the key points to bear in mind when implementing the chosen integration architecture. For the purposes of this article we are assuming that a decision has been made to implement a vendor-based solution but many of the points would be equally applicable where internal hand coding has been selected.
Project Planning
The success of any project is the sum of many factors. Just because you believe that you have selected a world class and best fit solution it does not guarantee either a smooth running implementation or a satisfactory outcome as measured by the criteria outlined in the previous article. It is not the purpose of this article to advocate the exact methodology employed to execute the project, whether that be PRINCE2®, ITIL®, Scrum or something home grown by picking the best bits of any of the industry standards. What they all contribute is good practice guidance for elements such as management, monitoring and stakeholder engagement which are all entirely necessary. Where, however, many projects fail, is in getting the basics right. These can be grouped into common areas: resourcing, training/consultancy, testing and realism, which in turn impact project budgets and timescales.
Resourcing
By definition, data integration projects are technical projects that aim to deliver business benefit and/or regulatory compliance. A key aspect is that the devil really is in the detail and as such, very often, detailed analysis of the integration end points; i.e. application interfaces, database structures and external message types, has not been undertaken. Therefore the project is much more akin to a development rather than an application implementation and as such it is always beneficial if the appointed project manager has experience in that area. Whilst project management is a generic skill, understanding of the technical aspects will ensure that areas of concern can be adequately communicated to stakeholders in non-technical terms.
An enterprise-wide integration project can involve dozens if not eventually hundreds of end point pairs. How these structures and data items relate to each other is at the core of any integration project and will usually represent the largest amount of activity in the project. The business analysis skills that therefore need to be brought to bear are a key to success. Identifying appropriate resources will generally go beyond the usual request for finding someone that understands payments, equities, OTC, vendor applications, etc., often considered to be the usual remit when trying to resource any project. For each end point pair, either one person that intimately knows both end point structures or two people to work together is required. Given the detailed knowledge required it is unlikely that you will find resources that know more than a few end points and if you have dozens or more, that entails acquiring many business analysts. It is also a fact that many of those skills may not exist within the organization. So a key upfront planning activity is to create a skills matrix laid out as a series of end point pairs. Identify the appropriate internal candidates and at this stage leave their availability to one side. Then work with external systems integrator partners and the vendor, to see if they can fill in the gaps. It is essential at this point that a team effort is stressed. Many external parties will have the skills that are lacking in-house and it is not an admission of any inadequacy that that is so. The key is to leverage the best skills at any given time.
As stated above, at this stage, availability can be addressed as a subsequent activity but try to pick the “A team” first. The reason for this being that each individual end point pair is a discrete and usually fairly short lived activity. In most projects, business analysts are either allocated to or contracted onto a project for its entire lifecycle. For the reasons stated above, this is highly unlikely to be the case here. Creating the mapping specifications will typically take a few days or weeks for a very complicated pair and hence often the challenge is sourcing people for short periods of time which can be easier internally. This task should be completed in a form that directly inputs into the technical implementation via a shared design time environment and not a spreadsheet for reasons of reusability and keeping the specification in line with the eventual deployed solution. A more generic mapping resource can then pick up these specifications and implement them. The analysts then only need to be available for queries during the definition and testing phases.
It is acknowledged that this sounds like a somewhat utopian view, however, the closer you can get to this ideal the less iteration and exceptions will occur not only during implementation but also in production.
Training and Consultancy
Whilst everyone wants to get on with a project and hopefully agrees that they have acquired the best intuitive product for the job, it is rarely the case that internal resources will know the product or how to implement it as well as the vendor or their partners. It is therefore important to schedule sufficient training time for project members at the start of the project, not only so that they understand how to use the product but also so that everyone can share a common vocabulary. It is also equally important that at least for a period following the training, when the product is being used, that a period of mentoring consultancy is requested from the vendor or their partner. Regardless of how good the training was or how good the supporting documentation, the most important thing in the project is finding the answer in the shortest possible timeframe. If experience is on hand early, then the most effective use of the resources can be achieved from the start. This mentoring phase will then typically eventually tail off.
Most integration products will and certainly should be, highly flexible in their architecture and as such, the starting point of the integration project is the design. Just because the product has a world class reputation and will generate reliable solutions, it doesn’t mean that you can’t design a solution that may not perform as efficiently or be as maintainable as desired. Involving the vendor, who will have implemented the product many times before at the architectural design stage, is essential. These will usually be the most experienced resources that the vendor has, so they may not come cheap but they can make a huge difference to the quality of the deployed solution.
Testing
Integration is all about the detail and as such mostly involves unit testing rather than user testing, with subsequent system testing on the end deployment architecture. There are a number of key points to consider:
- Source test data and as much as possible, up front. Don’t wait until you think it will be needed as it always takes longer to source than you think.
- If possible, your chosen product should incorporate a common design time that provides comprehensive testing facilities that the business analyst, mapper and tester can all use thereby facilitating testing without recourse to the target deployment architecture.
- Integration is very often more about the exceptions than the rule and very often the test data will contain content which hasn’t been thought through at specification, so allow plenty of testing time. We all know that this is the first thing that gets cut when there are project budget reviews. It shouldn’t.
Realism
Probably the most important contributor to the success or more often otherwise, of a project and usually the hardest to control is realism. Very often organizations will arbitrarily set a go-live date and a project budget without any recourse to how realistic it is. The deadline doesn’t move even when for example, the systems selection process overruns or additional functionality is added. Integration projects are deeply specific to an organization, so just looking at a competitor and how long it took them doesn’t necessarily mean you will be the same. So a few mantras to consider are:
- If you haven’t done the analysis you can’t possibly have an accurate implementation budget.
- If the deadline is not regulatory, then question it.
- Sacrifice function not quality.
- Don’t forget maintainability.
- Work with the vendor and partners as a team.
- Get the best resources you can for the analysis wherever they come from.
- Don’t scrimp on training, consultancy and testing.
- Never forget that estimates are usually optimistic, so not liking the result and asking for a lower number is nonsensical.
Due to the restrictions on space for this article not all key aspects to a successful integration project can be covered but if you can implement some or all of them then I can guarantee you a much improved outcome and hopefully less stress. Happy integrating!
To know more about financial message and data integration visit www.volantetech.com
