The key is to go back to the basics of good design: identify what varies and encapsulate it.

The myth that you can somehow create this masterpiece that is infinitely reusable and should never be touched is just that – it is a myth and is divorced from reality. Reusable doesn’t imply:

• that you invest a lot in big up front design effort
• you account for everything that will vary in the design – the critical factor is to understand the domain – well enough, deep enough, so you can identify the sub-set of variability that truly matters

In the same vein, reusablility strives for separating concerns that should be kept distinct. Ask repeatedly:

• Are there multiple integration points accessing the core domain logic?
• Is there a requirement to support more than one client and if so, how will multiple clients use the same interface?
• What interfaces do your consumers need? is there a need to support more than one?
• What are the common input parameters and what are those that vary across the consumer base?

These are the key questions that will lead the designer to anticipate the appropriate places where reuse is likely to happen.  Finally, it is important that we don’t build for unknown needs in the future – so the asset is likely to solve a particular problem, solve it well, solve it for more than one or two consumers, and finally has potential to be used beyond the original intent. At each step there are design decisions made, discarded, continuous refactoring, refinements to the domain model – if not re-definition altogether.

Don’t set out trying to get to the end state or you will run the risk of adding needless complexity and significant schedule risk.

1. Minimize redundant definitions of key domain objects (i.e. competing, conflicting definitions of the same domain object across related applications)
2. Minimize similar solutions for slightly varying business processes and instead create common process flows
3. Loosen tightly coupled integration/transport logic with business logic
4. Provide consistent strategies for implementing cross cutting concerns
5. Replace tactical implementation for a problem that has a better open-source alternative
6. Eliminate redundant approaches for managing configuration information
7. Harmonize multiple, incompatible interfaces and make them more domain relevant
8. Minimize excessive coupling with a particular technology/implementation stack
9. last but not the least – create a comprehensive suite of automated tests

Are there similar themes in your development efforts? What steps are you taking to ensure technical debt is addressed?

• Building reusable assets from existing applications
• Designing new reusable components and services
• Design patterns, product line practices, and more!

1. Account for domain analysis and modeling in your iteration planning. Domain analysis is necessary to understand the nuances and variation points that an application/service/process needs to realize. Discovering the right variations requires time and interactions with business stakeholders and subject matter experts.
2. Aspire for a core set of business object definitions that can be shared across business processes and service interfaces. Without appropriate data governance, domain knowledge will either be inaccurate/incomplete or worse duplicated in an inconsistent fashion. As the number of customer interfaces increase for your services, the domain inconsistencies will lead to greater point-to-point integrations and complexity.
3. Align overall architecture with domain variations. Your domain is rich and complex but probably varies in a known set of ways. Additionally, what varies isn’t uniform and the rate of change across these variations aren’t identical. This is significant because the variations in the domain need to be captured in your overall architecture. Products/applications in the domain need to share a common architecture – only then can components integrate and inter-operate and systematic reuse will take hold. Constantly evaluate the need for a new version of a core business entity and associated classes to manage the entity.
4. Refactor constantly to get to intention revealing design and code. As Eric Evans illustrates in Domain Driven Design, intention revealing code is easier to understand and evolve.  It also makes it easier to address new business requirements – as the design/implementation are closely aligned with the business domain, the quality of communication (referred to as ubiquitous language) and the ability to change it both increase significantly.

This isn’t an exhaustive list – instead, it is meant to highlight the need for placing the domain in the middle of every design, architecture, and implementation decision your teams make.

Here are a few scenarios where refactoring opportunities can be utilized:

Horizontal logic mixed with app-specific logic: This is typically manifested in two flavors – cross-cutting functionality that is horizontal across several applications or domain-specific functionality that is applicable to a product line. Cross cutting functionality such as authentication, logging, error handling etc. can be refactored from app-specific to distinct components.

Redundant definition of business objects: maybe two or more of your projects are redefining a core concept from your problem domain and refactoring can help align them to a common definition. Once a common definition is used, add tasks into your iteration plans.

Manage application configuration: If several applications use ad-hoc set of practices to manage runtime configurations (e.g. xml configurations, property files etc.), refactoring them to use a consistent strategy would certainly make sense. This refactoring can be done one component at a time if time constraints make it harder to transform an entire suite of components in the app.

Freemarker is a templating engine that can be leveraged to perform object to text transformations – with freemarker it is easy to generate RSS feeds or delimited text or plain old XML very easily. Below are some code fragments that illustrate freemarker usage:

Below is a code fragment for setting up the template configuration:

try {
	// Initialize configuration;
	cfg = new Configuration();
	cfg.setDirectoryForTemplateLoading(new File(templatesLocation));
	cfg.setTemplateUpdateDelay(0);
	cfg.setTemplateExceptionHandler(TemplateExceptionHandler.HTML_DEBUG_HANDLER);
	//Use beans wrapper (recommmended for most applications)
	cfg.setObjectWrapper(ObjectWrapper.BEANS_WRAPPER);
	cfg.setDefaultEncoding("ISO-8859-1");
	//charset of the output
	cfg.setOutputEncoding("UTF-8");
	//default locale
	cfg.setLocale(Locale.US);

} catch (Exception e) {
	//handle the exception
}

The templatesLocation variable is the path to a folder with freemarker templates (referred to as FTL templates). These are similar to templates used with frameworks such as Velocity. For example, below is a template fragment:

<Name>${myBean.firstName?xml} ${myBean.lastName?xml}</Name>

“myBean” is the java object that has first name and last name properties supported by JavaBeans style getXYZ() methods. The ?xml built-in function is used to encode any special XML characters.

Below is the code fragment when trying to invoke a template with a java object:

// loading the template file
Template template = //get template from a map
Writer out = new StringWriter();
template.process(dataObject, out);
String strResponse = out.toString();

The above code fragment essentially takes a java object (dataObject) as input and creates a string as output. Using the template above, the output for example could be:

<Name>John Smith</Name>

Freemarker also supports loops and conditions and offers a rich library of built-in functions as well.

There is always a deadline (or many deadlines) to meet and technical debt to accumulate. Since we are always in a hurry, it helps to be aware of what should be reusable – even if we won’t get to it in this iteration . So here are some ideas that can help you decide whether or not a capability should be developed for reuse:

• is the capability unique to your enterprise? i.e. it captures logic and/or process variations that provide competitive differentiation.
• is the capability making something incredibly hard/defect prone simpler and/or easier?
• is there a desire for customers to have a capability across business channels? i.e. from the web, from a mobile device etc.
• is it specific to your domain and potentially relevant to multiple applications in the domain? this may or may not be obvious – if it isn’t, delay commitment.
• is the capability only available in a particular technical platform but is solving  an often needed problem?
• is it automating boiler plate code generation or preventing defects?
• is there an in-house/external alternative that achieves your functional requirements? if so, seriously consider stopping investment in the asset.

This is a starter list – the idea that we keep coming back to is this – treat a reusable asset like a real investment. Every iteration and release is an opportunity to review and update the investment. When you make a decision, continuously refactor to make the capabilities less app specific and reusable.

• Reviews happen prior to code being placed in production – they give you a chance to extract, build, or integrate reusable assets.
• Code reviews often identify opportunities to refactor – refactoring to reuse. Have you ever had a review where someone said, “you know what, you should talk to Joe, since he is building a similar thing…” or “…we should use the existing service for implementing this story.”
• Reviews help discover reusable assets – you might include classes and interfaces (not necessarily neatly demarcated) – in a component that can really be split up into two or more components. It may be appropriate to slice up the logic to ensure the existing component isn’t too monolithic
• Reviews are very effective in preventing defects – with reusable assets, quality is everything and the act of reviewing them is critical to their stability and production-readiness. These can be extended to unit tests and documentation as well.
• Reviews are a neat opportunity to communicate to at least a sub-set of the team what reusable assets exist and how they can be leveraged. Often times, when assets are mentioned as-is, they may not be that well received. Place them within the context of a real project, a real deliverable, and a tangible need – now the communication is much more effective.

As more developers pitch in and learn from each other, the reviews will become a critical part of how you develop and evolve reusable assets.

This is hard to get right the first time – often, business requirements aren’t clear from the early on making it tricky to identify reusable assets. More importantly, reuse adds project risk – specifically risk to the timeline. Always ask yourself if it is worth making the extra investment – if you aren’t sure delay commitment.

Capture possible enhancements to your codebase via an issue tracking tool and you can always assign those enhancements to future iterations. When you implement a story and you see the opportunity for making something reusable, consciously align classes and interfaces for reuse. Refactor, refactor, and keep refactoring – because only with multiple iterations is your asset going to be increase it’s reuse potential. Remember – very often, the asset would not be used as-is. It will need changes – patches, enhancements, major redesign even – before it can be leveraged across projects.

• Fit within product line: is the asset of relevance to one or more applications in your domain? You want to invest in assets that encapsulate business functionality that can be utilized in multiple business processes and applications. Similarly, if there are assets with business relevance but in a area that your organization intends to divest out of – you will be less inclined to use them.
• Coupling: How tightly or loosely coupled are the pieces within an asset? sometimes the asset itself might be mixed in – tightly coupled – with a lot of extraneous code. Business logic might be mixed with data access, presentation, and even specific calls to external systems. Every one of these aspects introduces coupling that will need to be assessed thoroughly.
• Integration: what is the effort required to integrate the reusable asset with applications? The asset might be very difficult to integrate because of platform specific requirements or because of language needs.
• Business Assumptions: are there assumptions that the asset makes about business rules or business activities? if so, are these assumptions still relevant? will the rules need externalization/refactoring? Often, business assumptions are lost due to lack of alignment between business concepts and abstractions in code.

In a followup post, I will elaborate on robustness, scalability, deployment, documentation & samples. Without thinking through these aspects it is risky to introduce new assets for reuse. You will quickly discover that your consumers are unforgiving when it comes to asset quality. Additionally, a huge learning curve will drive away potential and existing developers and technical leads from evaluating assets for use with new applications.