General « Art of Software Reuse

Role of Systematic Reuse in Enterprise Integration

January 7, 2012

Systematic reuse in the context of enterprise integration provides several benefits:

allows the team to evolve consistent set of data interfaces across integration efforts – if multiple systems need to integrate with yours, can you define a generic data model for your domain-specific concepts? This could be file layout(s), service interface schemas, or platform specific APIs
enables common interfaces for domain specific services and business processes
integration points often need cross-cutting concerns such as logging, transaction management, exception handling, etc. that can be reused
reusable utilities can help with support and testing tools – for instance, reply failed messages, drain message queues/topics, generate high volume test data, etc.

Question is – are your teams taking advantage of integration points? or is each integration point implementing identical or similar functionality in an inconsistent fashion?

Leave a Comment » | General, Reuse | Tagged: EAI, integration, integration points, software reuse, systematic software reuse | Permalink
Posted by vijaynarayanan

Track Service Reuse Metrics

December 24, 2011

Service driven systematic reuse takes conscious design decisions, governance, and disciplined execution – project after project. In order to sustain long running efforts such as service orientation, it is critical to track, report, and get buy-in from senior management in the organization. So what metrics are useful? Here are a few:

Total number of service operations reused in a time period
Total effort saved due to systematic reuse in a time period
Number of new service consumers in a time period
Number of new consumer integrations in a time period (this includes integrations from both new and existing consumer
Service integrations across transports/interface points (for instance, the service operation could be accessed SOAP over HTTP, or as SOAP over JMS, or REST, etc.)

What metrics do your teams track?

Leave a Comment » | General, Reuse, SOA | Tagged: metrics, service metrics, service orientation, service reuse, SOA, systematic reuse | Permalink
Posted by vijaynarayanan

9 Quick Tips to Reducing Technical Debt

April 13, 2011

Wrote earlier about the importance of refactoring and continuous alignment within the context of systematic reuse effectiveness. Reducing technical debt is an integral aspect of refactoring. This post provides tips for reducing technical debt in your software assets:

Minimize redundant definitions of key domain objects (i.e. competing, conflicting definitions of the same domain object across related applications)
Minimize similar solutions for slightly varying business processes and instead create common process flows
Loosen tightly coupled integration/transport logic with business logic
Provide consistent strategies for implementing cross cutting concerns
Replace tactical implementation for a problem that has a better open-source alternative
Eliminate redundant approaches for managing configuration information
Harmonize multiple, incompatible interfaces and make them more domain relevant
Minimize excessive coupling with a particular technology/implementation stack
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?

Leave a Comment » | agile, General, Reuse | Tagged: agile, configuration, domain driven design, loose coupling, refactoring, software reuse, systematic software reuse, technical debt | Permalink
Posted by vijaynarayanan

Creating RSS feeds using Freemarker

September 8, 2010

As a follow up to the earlier post on using freemarker, here is an example of creating RSS 2.0 feeds using a freemarker template. This FTL will work assuming there is an input javabean that has a collection accessible via getItems() and returns a list of Item objects. Each Item would have a title, description, link, and last modified date properties as shown below:

<rss version="2.0">
<channel>
<#list items as myitem>
<item>
 <title>${myitem.title?html}</title>
 <description>${myitem.description?html}</description>
 <link>${myitem.link}</link>
 <pubDate>${myitem.lastmodifiedDate?datetime}</pubDate>
 </item>
</#list>
</channel>
</rss>

Leave a Comment » | General, open source | Tagged: freemarker, software reuse, templates | Permalink
Posted by vijaynarayanan

Think Capabilities Not Technologies

August 14, 2010

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.

Leave a Comment » | General, Planning, Reuse | Tagged: business capability, implementation, software reuse, technology strategy | Permalink
Posted by vijaynarayanan

Getting Mindshare for Reusable Assets

August 1, 2010

Success with systematic reuse is part-technology, part-process, and part-communication. In fact, a LOT of communication. A critical factor influencing reuse effectiveness is the mindshare that you enjoy with the developer community. That community might be your immediate team or a department, or even the organization. Regardless of the scope, the following are relevant issues to think and plan for:

Awareness: are developers aware what reusable assets can and cannot do? Can they understand the overall strategy behind the reuse effort? are they aware of specific assets, role for reuse in the development process, and the benefits?

Client experiences: think about the good and bad experiences. Every interaction matters, so does every medium – whether through mailing lists, bug reports, or phone calls to the reuse team.

Asset Quality: is the asset behaving the way it is supposed to? is it robust? does it allow for variability? Is it architecturally consistent with other assets? How does the potential consumer know about the quality?

Reputation: how strong are reusable assets referred to during design and implementation tasks? can clients trust the reuse team’s deliverables?

Documentation: are assets well documented? Is the document written with the reader in mind? Does it make sense – e.g. is it logically organized for a developer to follow and leverage?

Team member Behaviors: do they care about client projects like their own? Are they approachable by developers from various external teams? Ensure there is genuine empathy for business aligned projects – just like in the outside world – if you care enough and deliver, more reusable assets will be utilized in the future.

Emotional Connection: do reusable assets enhance learning and provide a sense of accomplishment for the developer/tech lead? Co-create assets whenever feasible.

Ease of use: how are assets set up? are they easily configurable? are bootstrap code generated for developers? Take care to highlight ease of integration and the multiple variability mechanisms to your audience.

This isn’t an exhaustive list but the intent was to provide some pointers when thinking about the overall reuse strategy and how that strategy needs to translate in the day to day actions that you pursue.

Leave a Comment » | General, Planning, Reuse | Tagged: asset quality, awareness, client experiences, documentation, ease of use, software reuse, systematic software reuse | Permalink
Posted by vijaynarayanan

Why Systematic Reuse instead of Cut and Paste?

July 31, 2010

Cut and paste reuse is simple and easy – so why pursue systematic reuse? For all the seeming benefits it has significant disadvantages. For instance:

It increases codebase size. There is nothing eliminating duplication – so the codebase starts to contain multiple instances of similar logic. Systematic reuse aims to cut down the amount of incremental code that needs to be written to address new requirements.
Lose the benefits of enhancements and bugfixes: everytime you “fix” a problem with cut and paste code – that has to be propagated across the codebase. This isn’t trivial – every where the cut and paste code was originally placed, would now be coupled with various other classes.
Doesn’t promote consistency in behavior – cut and paste from one part of the codebase to another might save time in the short term but will quickly lead to different behaviors for achieving a capability. Over time, this increases the size and complexity of your solutions.
Makes it hard to refactor – related to the earlier point – when you refactor, there is extra care needed to make sure that new defects aren’t introduced and existing code is identified carefully. That being said, refactoring will help you reduce the amount of duplicate code and move towards a more reusable, more modular design.

Leave a Comment » | General, Reuse | Tagged: cut and paste, modular, software reuse, systematic reuse | Permalink
Posted by vijaynarayanan

Systematic Reuse & The Art of Less

July 10, 2010

I came across these 8 key lessons on the Art of Less from the Japanese Ink and Wash painting technique Sumi-e. When I read them, I couldn’t help but think about their applicaton to reusable software. Here are some initial thoughts (Sumi-e lessons in bold):

1. More can be expressed with less- One effective way to add value with reusable assets is to enable developers to be more productive. With less code, can they implement business functionality faster? can they reuse their knowledge of one asset when using another?
2. Never use more (color) when less will do: only support known variations. Needless flexibility not only increases development time, it also adds complexity and results in speculative design.
3. Omit useless details to expose the essence: what are the key interfaces that developers need to know about? If there are obscure configuration options or edge use-cases that most developers don’t care about – do they have to be communicated in an all-or-nothing fashion? When in doubt enable developers to peel away at your asset on a need-to basis.
4. Careful use of light-dark is important for creating clarity and contrast: There is a reason why your API was created and why it abstracts away certain details while exposing others. It is important to communicate the intent behind your design keeping in mind the developer’s need to get productive quickly.
5. Use color with a clear purpose and informed intention. Reusable assets should be part of a whole. Think constantly about how one asset relates to another and how a combination of them can make it easier for new automation opportunities. The key concept is to break it down into domain-relevant concepts that are part of a larger story. The colors do paint a picture, don’t they?
6. Clear contrast, visual suggestion, and subtlety can exist harmoniously in one composition. You don’t want every reusable asset to support completely different idioms – can you make it impossible for errors? can you provide warnings with actionable, informational messages for the developer? Think about suggesting good practices to the developer while they are inside a development environment.

7. In all things: balance, clarity, harmony, simplicity. As far as possible, reusable assets should be simple to setup and use. Strive for providing flexibility but follow the 80/20 rule – what do most developers want from an asset? Support those objectives and make it very obvious to achieve.

8. What looks easy is hard (but worth it). Reusable assets should make hard things possible – making it easy should be a goal to aspire to as always without taking the route of hiding too much information. Goal is to avoid repetitive code and configuration across multiple projects. It is extremely hard but well worth it!

What do you think? Do these principles resonate with you as a software professional?

1 Comment | Design, General, Reuse | Tagged: art of less, Reuse, simplicity, software reuse, sumi-e, systematic software reuse | Permalink
Posted by vijaynarayanan

Execute A Systematic Software Reuse Pilot

April 16, 2010

Before you go organization-wide with the systematic reuse strategy it is surely worthwhile to get a pilot project (or multiple pilots even) going. The objective of the pilot is to test how well your reuse strategy can be applied to a real-world application. In a nutshell, here is what a pilot could be:

Get engaged with 1 or 2 projects early in their lifecycle and identify reusable business and technical components based on their business needs. The key is identification – not necessarily implementation/realization. With the agile software reuse approach, we can refactor existing code to reuse or plan known assets as part of iterations on a as-needed basis.
Identify folks from the pilot projects who are receptive to reuse and work with them closely. You want reuse evangelists, like-minded developers and technical leads who share the possibilities of reuse. It helps if they are also aware of the pitfalls and challenges with reuse.
Collaborate with the project team to design new reusable components and integrate existing ones. Identify components that are : unique to an application, unique to a product line, unique to a domain, and relevant across multiple domains
Prioritize assets from above list based on project constraints as well as business need. Implement a subset of these assets and examine how the integration works with multiple assets being utilized by a business process, service capability, or an application.
Establish a environment for testing these reusable libraries outside the main application in order to facilitate reuse on subsequent projects. This is key for sustaining your future efforts – provide automated tests and an environment (a sandbox server to begin with will suffice) that allows developers to prototype using reusable assets.

Most likely, with a pilot you will learn a lot – a lot about how developers actually use reusable assets, what challenges come in the way in terms of project deadlines, lack of documentation, and unclear assumptions that the asset makes about the domain and even the operating environment. This exercise would also make it painfully obvious the technical debt various reusable assets are carrying – fixes, refactorings, and enhancements that are needed for reuse to be successful. This would be valuable feedback to use – work with your teams to flush out these issues and get to a working mode that allows for iterative and incremental delivery. Remember – your reusable asset doesn’t have to be perfect only constantly aligned to business needs.

Leave a Comment » | agile, General, Planning, Reuse | Tagged: agile, developers, domain specific, iterative, software reuse, technical debt, testing | Permalink
Posted by vijaynarayanan

12 Practices to Consider When Pursuing Systematic Software Reuse

April 15, 2010

Systematic reuse is hard because it isn’t a problem that technology alone can solve. It requires a various practices that have to be executed in a coordinated manner across teams and projects. Here is a starter list of practices to consider for success with systematic reuse:

allocating resources including changes to budgeting practices for funding shared capabilities
setting up appropriate incentives for developers, technical leads, and management staff
creating a roadmap for increasing organizational agility – reduced time to market, increased flexibility, increased quality – across multiple processes and applications.
recognizing failure signs and course-correcting – not only for large initiatives but for individual asset development as well. Don’t forget the need to involve your consumers in addressing delivery and integration challenges.
utilizing product line management techniques for identifying, managing, capturing, and realizing variability in business capabilities.
explore reuse opportunities not only business functionality but also with IT processes such as bug tracking, problem management, incident management etc.
align reuse efforts closely with other initiatives such as service oriented architecture, business process management, master data management etc.
Provide training to developers, technical leads, and development managers on what is available, what is being planned, and how the resuable asset inventory is managed/evolved. Make your teams buy-into the effort.
Look for reuse opportunities throughout the entire development cycle- not just during implementation! You can reuse requirements, analysis patterns, domain models, business processes, as well as documentation.
Aligning reusable assets with business goals/objectives. Remember: the rationale for reuse is to reduce costs and increase revenue for your firm.
Communicate reusable assets within your immediate team, then your department, before taking it organization-wide. Without a support and maintenance strategy in place, your reuse efforts cannot be sustained.
Address Non Functional Requirements (scalability, reliability, etc.) when creating resuable assets.