Think Products, Not Applications
We are often used to thinking about changes, bug fixes, and enhancements to an application or system. To be more effective with software reuse start thinking like a product manager responsible for a set of related products. Think mass customization. This perspective offers several advantages specifically related to systematic software reuse:
Products have vendors who have a charge back model to recover the cost of installation, setup/configuration, leasing, maintenance etc. Your reusable assets are no different.
Products typically come in multiple flavors or offerings. Think basic, intermediate, and complete flavors that all share a set of identical features and offer unique flavor specific features. See managing variations.
Products have clients or real customers. You need a mechanism to track feature usage, common patterns across the domain, frequently encountered errors/exceptions, etc. You need metrics for all of this and it ideally should be captured, managed, and reported on via some administrative interface. Without these metrics you cannot effectively understand and govern reusable assets.
Products require support for multiple concurrent versions. Sometimes you have to offer migration paths from one version to another. Other times you have to plan for a customer to upgrade to a newer version gracefully. Data migration scripts have to be thought through and need to be very robust to ensure there are no losses in translation when upgrading to a newer version. This applies whether the asset is a library or a service.
Products require training – better the documentation better the chances of effective usage. If your documentation is engaging, interactive, and works well for a targeted audience you have a winner in your hands. No documentation means no reuse – it is that simple.
Products have a lifecycle – at some point you introduce them, convince customers to adopt them, they get mature, and eventually get retired. Features get added, become simpler, and mature over time. Things are typically done iteratively. Understand this and your reusable assets can be introduced and evolved within the context of business requirements and priorities.
Products need better logging, trouble shooting, customer support, and maintenance cycles. They need a team that cares about the quality of what goes out the door. Poor quality products don’t sell -period.
Products need some flavor of marketing – whether it is informal word of mouth or formal presentations, events, and educational materials for customers your product needs to be front and center of your audience. One of the key reasons systematic reuse efforts fail is due to lack of awareness. No marketing means no awareness. Your reusable assets don’t have a voice and entropy sets in.
If you manage your applications as a set of products you will notice commonalities, manage variations better, market them, plan for migrations and upgrades, and top notch after-sales customer service and education. In short, you will set yourself up for success with your systematic reuse efforts.As always, you don’t have to do this as a firm wide thing.Start within your team – these practices will help your team build higher quality reusable software that ultimately help your ability to serve your business stakeholders.
Last updated