Build a Product Line
You will rarely get a requirement that covers a wide gamut of your particular problem domain. Instead, you will get requirements for reusable assets in bits and pieces. It is in your team’s best interest to look not just at the immediate need. Look for domain relevant reusable assets that are related to your immediate requirement. Notice that I am not advocating building things that are nice to have! When you take time to understand domain relevant assets you will be surprised how effective you will get with incremental development. You will do work that is aligned with your business vision and throw away less code.
Take an example where the requirement is to provide a credit card authorization service for a customer. You can just build that one service of course and that would be fine for your project. But if you step back and consider the domain, maybe you identify that the credit card authorization is just one kind of funding. There could be debit card, traveler’s checks, or even electronic fund transfer capabilities that are required for the future.
Now, should you be building a credit card authorization service or an authorization service with credit card being one of the mechanisms?
You can enhance the authorization service by adding new capabilities over time. By creating modular interfaces new authorization types can be gracefully added. The service could interact with different authorization providers based on customer characteristics or traffic on the service or meeting specific service levels. Or it could use a set of business rules based on type of product being purchased or place of transaction etc. The bottom line – the capability will be able to encapsulate a myriad other domain-relevant functions offering opportunities for reuse in many places.
Have a plan for every reusable asset. At a minimum the plan needs to address:
The scope of the asset’s functionality for your immediate deliverable
The asset’s place in within your product line
The impact to your existing design and overall architecture
Tentative road-map for evolving the reusable asset over several iterations or releases
You don’t have to get answers for all these areas right away! The point is to think about them so you can make decisions on scope and effort. In the midst of an iteration there will be several questions about whether or not to invest time in refactoring or developing a feature. You can use this tiny list as a guide to help you make decisions on what to refactor or build and whether or not it is in line with your overall strategy.
Think Capability Not Technology
There is a reason why your team builds software – most likely, you are either building a product for external customers or supporting technology solutions for internal stakeholders within the organization. Systematic reuse cannot be achieved if we focus exclusively on technologies. Focus on capabilities, more specifically, business capabilities instead.
This is a simple but significantly useful perspective to adopt. Capabilities are tangible units of functionality – regardless of implementation technologies used or systems that they are part of. When capabilities are identified, you can make more informed decisions about whether or not it is a reuse candidate. This is also handy every time there is a discussion on which part of a functionality should reside in a server component or a presentation component etc. Capabilities, when aligned with business needs, gives you the right level of abstraction when considering refactoring efforts. Are we refactoring the right capabilities from a legacy codebase? is this a capability that is useful as-is or is it only relevant within the context of a specific business process? is the current implementation assuming (aka coupling) too much about a business capability?
These are extremely relevant questions – and notice how we haven’t talked about technology implementation decisions. That is on purpose – if we are not careful, impatient technology choices could adversely constrain business capabilities. Once you are clear on the capabilities – technology decisions and need for variability, agility, and other quality attributes can be made appropriately.
Last updated
