Art of Software Reuse » communication

12 Practices to Consider When Pursuing Systematic Software Reuse

vijaynarayanan — Thu, 15 Apr 2010 13:06:20 +0000

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.

Does this resonate with your experience? what is missing in this list?

Tagged: agile, communication, product lines, requirements, services, SOA, software reuse, systematic reuse, warning signs

The AssetMap – Useful Resource

vijaynarayanan — Sat, 12 Sep 2009 20:22:11 +0000

Often times, developers and technical leads don’t know what reusable assets are already available. In the same vein, they may not be aware of what is already being planned – either refactorings on an existing asset or an entirely new one in keeping with your overall vision. Recognition is much easier than recall and one tool that I have successfully used in the past is the AssetMap. It is a concise artifact that is made up of two pages – one page with technical assets and another with business ones.

Where do you use this artifact? Fill it up and customize per your team’s needs and distribute it to your teams. Make sure every developer, technical lead, and designer has it. Print out and give it to your new hires as well! More importantly, ensure that they are aware the purpose behind the artifact and use it to implement user stories/business requirements. You can also place it as a document on the Intranet with links to individual asset details. The intent is to have the AssetMap as the summary artifact and not contain every bit of detail about every asset.

Here are the typical business assets that you can place in the AssetMap:

Data Assets (core data entities such as customer, account, product, etc. as well as reference data such as currencies/country codes/zip codes etc.)
Business Assets (business orchestration services, task services,
Decision Assets (including rulesets, eligibility criteria, policies)
Legacy Assets (capabilities in legacy systems that are reusable or have reuse potential)
Business Workflows (approval chains, human/system workflow that can be reused in more complex flows)

and some candidate technical assets:

authentication/authorization
localization
legacy integration (e.g. service adapters when invoking CICS modules)
reliable messaging
event processing
testing utilities
data transformation
routing
auditing
monitoring
notification (to send email messages for example)
logging
error handling
data binding

The above list isn’t exhaustive and is meant to be a starting point for your teams. Here is a candidate AssetMap template that I have used in the past – feel free to customize it to suit your needs. For instance, you could add notations to indicate asset type (whether it is a service, library, component, UML diagram etc.) and readiness (deployed, being developed, needs bug fixes, etc.).

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

Tagged: asset summary, communication, components, libraries, refactoring, services, software reuse

Communicating Reusable Software Assets Podcast Episode

vijaynarayanan — Sun, 07 Jun 2009 13:39:23 +0000

Using iTunes?

The newest episode of the software reuse podcast series covers key communication themes/concepts and the communication plan artifact.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

Tagged: communication, podcast, software reuse

Minimize Jargon and Maximize Relevance

vijaynarayanan — Fri, 05 Jun 2009 22:46:25 +0000

How many times have you talked to a technologist who uses a lot of jargon? MDA, SSO, SAAS, BPELWS . As a technologist I am guilty of using jargon as well However, if you want to turn people off specially when you are trying to influence and persuade them there is no better way than to use excessive jargon!

Software reuse is a hard problem mainly because a lot of us get buried in the technical aspects and ignore everything else. If you want to successfully communicate with developers and development leads minimize the jargon and refrain from showing off your technical superiority. Instead, focus on relevance. If you understand the problem and can truly add value by pointing them towards a reuse friendly solution more power to you. Too often I see just the opposite – anxious to force solutions technologists decide on the approach using a favorite technology (they freely sprinkle arcane terms and acronyms to intimidate coworkers) and then wonder why people resist.

When you encounter a problem pause and reflect – strive to understand the bigger picture:

who is asking for the functionality?
is this a one-time requirement or something that is relevant to multiple applications?
have we solved this problem before within the team?
do we have something that could work with some refactoring?

These are the questions that will get you closer to success with reuse. Focus less on the technology and more on the problem and relevance. Watch your developers become more adept at recognizing which functions need to be reusable and which ones aren’t.

I am not for a second saying technology is irrelevant or unimportant. Far from that. Before the how you have to figure out the what and technology is good with the latter. Framing reuse within the problem at hand will make it easier for you to convince folks within and outside your team. Try it and surprise yourself!

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

Tagged: communication, software reuse

Communication Plan – Simple Template

vijaynarayanan — Thu, 28 May 2009 11:54:10 +0000

Here is a simple communication plan template that I use to keep track of communicating reusable software assets. It is very lightweight and can be easily put up on a wiki or a web page and kept upto date.

Feel free to customize it to suit your particular needs. Here is how I use it:
Date - Target date when a particular communication going to be delivered
Channel – Channel of communication (intranet, newsletter, email announcement, formal meetings)
Audience- Audience for the communication (managers, developers, architects)
Purpose – Purpose of communication might be to increase technical design knowledge, metrics/investment rationale, teach/educate, increase awareness, a call for participation/action etc.
Reusable Asset(s) in focus: List of reusable assets (template, pattern, library, component, service, etc) being communicated

Like with everything else it is more important to be disciplined about this exercise rather than anything else.

Like this post? Subscribe to RSS feed or get blog updates via email.

: : : : :

Tagged: communication, software reuse, template