An often ignored aspect of systematic software reuse is the need for integration maturity – both with respect to existing and new consumers of shared reusable assets. With all the excitement about the benefits of sharing software assets across projects, it is easy to forget the ramifications of reuse. Remember:
- Thoroughly and carefully evaluate changes to interface contracts before changing them. Will the interface change break existing consumers? will they need to regression test or perform code changes? If the answer to any of these questions is “no” – then you need to co-ordinate the changes across your consumers. Depending on the complexity of the change, consider formal governance processes as well.
- Do not refactor reusable assets without a comprehensive suite of automated tests. When you are both the provider and consumer of an asset – you can fix bugs and broken builds without anyone else outside your team becoming aware of them. Even in this case, you absolutely must create automated tests – i am not suggesting you don’t need tests if you don’t reuse :-). Automated tests become an imperative when you bring in multiple consumers in the mix – do you want completely independently managed applications, processes, and services to break/buggy because of your “minor” refactoring? Of course not – this will not only generate bad press for your team but also make it more expensive to fix, test, and verify multiple consumers.
- Ensure you make design assumptions and known issues explicit. When your consumer integrates with a reusable asset and walk away thinking “this thing can solve all my problems” – that is a sure warning sign. As a provider, make your assumptions and limitations explicit. Get a wiki or at the very least maintain a document that you can provide. If you limit the number of concurrent requests/connections or have restrictions based on distinct IP-addresses making calls to your service – communicate that to your consumer. This is especially important for critical revenue-generating business processes in your firm. Can you afford to adversely impact order processing, account opening, or other critical processes?
These are integration related challenges that are super-critical to your success with reuse. Additionally, there is the need for robust documentation, useful/consistent error handling semantics, and the need to be scalable with increased volume.