Like a horse with blinders
Several years ago we arranged annual customer event for one of our large-scale customer. After the formal agenda, two of our project managers who had led the integration project parts of different ERP projects in that very same customer, sat down together to share experiences. Our project managers are often a combination of designer and project manager so it took only two beers and these two started to compete whose project delivered the most elegant integration solution. It turned out that among other things both projects delivered web services to retrieve and manage customer information. Of course both of the solutions followed principles of service-oriented architecture (SOA). Services itself were reusable, autonomous and granularity of published data was carefully designed to meet requirements efficiently. As the discussion went on into the details, these two project managers noticed that their projects had delivered almost identical services on the very same Customer data – and could have even reuse one of each other’s web services.
Both projects had their own budgets, own requirements and own deliverables. Budget wasn’t exceeded, requirements were fulfilled and deliverables were deployed by both projects. So the projects succeeded, right?
As the development is lead strictly as project organization and each project implement their own integration solutions with blinders on, this kind of waste of money and time is obviously possible, not to mention the increased maintenance costs.
How to solve this organizational issue? I think that the easy answer is to stop implementing the integration inside the projects. Instead, gather the best people and best practices for integration together and let them do design and implementation. This group could then serve all projects or business units corporate wide. The idea is quite old – it is called shared service. Hey, companies managed to do that with HR and IT already. The key is to found a proper Integration Competency Center which ensures – among other things – that interoperable services are really reused/and fully utilized. In the world of ICC, projects create requirements, whereas ICC designs and implements reusable integration solutions as a continuous process.
Wonder what happens when owners of these two projects with several others start to generate business process driven changes to integration. How quantum and pace of changes can be managed? Well - that is topic for another integration war story where ICC is an element of winning team.
Back >