One of the most beloved lines from the movie “The Matrix” was when the Spoon Boy told Neo, “Do not try and bend the spoon. That’s impossible. Instead… only try to realize the truth…There is no spoon.” The same Zen philosophy behind this quote – focus on the fundamental instead of the superficial – can also apply to the planning and execution of data governance integration project that often accompanies a data governance implementation.
The Approach
Choosing a management approach that fits the nature of the project is critical to successful delivery. With the right, modern platform, a data governance implementation rarely requires custom development. On the other hand, data governance integration projects often involve significant custom development. Therefore, the ideal management methodology for the supporting integration can be very different from that for the main data governance project. And strictly adhering to just one approach for all can adversely impact project delivery.
Note that the Agile methodology is well-suited for managing integration custom development projects, especially in support of data governance projects where the scopes tend to be more limited. To help toward overall success, an agile approach should be considered for the integration portion of the project.
The Requirements
Another important factor in ensuring project success is to define the requirements well upfront, both functional and non-functional. Functional requirements, including those for integration, are generally well-defined because those are often related to the motivation for doing the overall project in the first place. However, non-functional requirements, especially for supporting functionality like integration, are often overlooked, and thus, insufficiently defined.
For data governance integration projects, non-functional requirements should always outline:
- Maximum throughput expected (e.g. how many records to be processed in a given time period, and how complex those records are)
- Service level expected for latency (e.g. is synchronous response needed, or upper limit on processing duration?)
These parameters not only will determine hardware specifications, but software architecture as well. And they must be well defined for the implementation to proceed smoothly.
The Resources
For hardware resources, it is important to allocate dedicated and properly-sized servers for the integration applications. As best practice integration processes and data governance platform should run on separate servers to provide better stability and robustness of the overall system.
More critically, the team skillset should match the expertise required, especially if custom development is needed for integration. It is best practice to have an experienced software architect and a dedicated technical lead on the team to ensure the integration solutions are optimally designed and developed to meet the requirements.
Day-to-Day Operational Support
For the core data governance platform after go-live, the day-to-day tasks performed by the end users often cover the bulk of operational support needed. For integration processes though, where interactions are generally machine-to-machine with multiple points of failures, operational support will involve establishing monitoring processes to track log files and notifications as well as procedures to escalate issue to human operators when issue arises to ensure fast resolution and satisfied end users.
In summary, the nature of a data governance integration implementation can be different than that for the overall data governance project. And even though integration may play only a secondary, supporting role, to help drive overall project success, it is best practice to review and understand these differences and then tailor the project management for them.
