Technology is an important, essential, and necessary ingredient for systematic reuse. However, it isn’t sufficient to achieve widespread reuse. Hyperbole? No – widespread reuse is being touted from the days of mainframe routines, functions, object oriented design, and component based development to service oriented architecture and domain specific languages. Yes, the level of abstraction is inching closer to the business domain and the tools have certainly gotten richer and more reuse-friendly (for instance, refactoring support in IDEs).

So why hasn’t systematic reuse happened? There are equally relevant considerations with systematic reuse (ones that often get ignored):

• Process - are your teams performing design and code reviews? how much thought is given to architecture – not only at a system level but when systems interact and exchange data? are requirements reused across projects? if not, are overlapping/similar requirements resulting in duplicate functionality?
• Training- how can a new developer who joins the organization come to know about reusable assets? how do we reduce the learning curve and demonstrate utility of existing assets? how do we align architecture efforts to better leverage reusable assets?
• Infrastructure - how are reusable assets identified, developed, managed, and retired? what if a team needs to contribute a patch to an existing asset? are there continuous/daily builds and automated tests for reusable assets? who ensures the quality of reusable assets? who “owns” these assets and how do they get supported?
• Culture- do your teams collaborate and cross-pollinate ideas? is there a not-invented-here syndrome prevalent when it comes to leveraging existing solutions? how do technical leads and developers come to know about reusable assets?
• Resource - how are resources allocated when they are meant to be useful for multiple applications? are there incentives for developing and leveraging reusable assets? are there resources allocated for horizontal components that are non-functional in nature – but extremely useful for several apps?

This is only scratching the surface and is meant to illustrate that technology alone isn’t a silver bullet to achieving systematic reuse. No single product or technology can guarantee reuse to happen organization-wide overnight. You can make it easier with the right set of technology tools/libraries/products but time, sustained effort, and calibrated strategy (one that takes into account your organization’s challenges and constraints) are essential for enduring success.

The Software Product Line (SPL) practices from Software Engineering Institute pursues a comprehensive set of practices that address the above considerations. It takes a holistic view of reuse covering multiple perspectives including people, process, technology, and places a common architecture at the heart of achieving widespread reuse. It isn’t promising a panacea and is a much better approach than buying a technology that is being touted to hand you reuse success.

1. Rule driven Exception Handler: Integrate exception handling with business rules engine. The rules could  determine how to resolve, mitigate, and handle errors. It will also specify routing instructions for errors requiring human intervention.
2. Internationalization Support: Status messages driven by a resource bundle as opposed to a single locale. Additional locale-specific resource bundles can be added as required for your business needs.
3. Seamless Cross Channel Movement: Enable a business process to start in one sales channel and get completed in another. Idea is to support business processes that start, pause, and get reactivated via an alternate channel. For example, a user can start ordering a book online and request a customer service rep to finish the process. The idea is to have the user’s in-progress process instance data get placed in appropriate work queues in a new business process or in a new state on the original one .
4. Business Process Completion API: Ability to determine % complete for any business process based on the state of the process instance . This API can provide the ability to get current status, estimate completion time (e.g. based on historical data), and what steps are remaining for the process instance to finish.
5. Business Activity Hold & Retry API: Facilitate pause, resume, and delegation of any business activity based on business rules. This interface would put processing on hold as well for one or more process instances.
6. Authentication: Enabling integration with a LDAP store, or providing digital certificate based security for interfaces that instantiate the business process are examples here.
7. Entitlements  API: Enable fine grained authorizations for business activities and business processes. Role based entitlements for events – i.e. if a particular user role cannot initiate a business process or execute a particular activity, the software  infrastructure should prevent those actions.
8. Content Management integration: Integrate with content management system to serve targeted content based on state of business process or to augment data in a process instance.
9. Event Integration API: Capture or derive events and handle them using one or more business processes. This could also impact existing process instances that are in-flight.
10. Indexed Search Integration API: Ability to execute full-text search as well as categorized search using an indexed search engine against completed and in-progress business process instances. E.g. search all process instances from a particular division or with a particular customer code, or category etc.
11. Process Dashboarding: Provide key business process metrics – report real time status of availability, performance, usage statistics, escalations, etc. Also provide ability to override/adjust in-flight process instances based on business scenarios.
12. Business Process Preferences API: Manage a set of process-level preferences. E.g. default logging level for all tasks could be set to high or all notifications get delivered to additional recipients, or data fixes will get audited a different way etc.
13. Document Integration: Attach documents using information in a process instance and attach/route content as part of the business process orchestration.
14. SLA Adherence API: Manage service level agreement specifications associated with end to end business process as well as key business activities. Ability to define/handle, and proactively prevent SLA violations.
15. KPI Definition and Monitoring API: Monitor business processes to capture key process indicators based on business process. E.g. number of accounts opened today, number of accounts opened after multiple validation errors etc.

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

Code reviews are one of the most effective ways to ensure that your reusable assets are being utilized appropriately. Often times in a rush to get the product out the door, developers might put in code not realizing functionality that already exists elsewhere. Because it takes time and discipline to review code it is a good idea to do this in small chunks. The key is consistency not so much quantity of code. You would want a quick way to refer to what reusable assets exist and marry that with changes to your code. I often find myself discovering ideas for new reusable assets while doing code reviews also. Over time you will start to see patterns and duplication across code fragments and application functionality which will help you achieve synergies.

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

: : : : :

There is one thing you should do before placing your reusable asset into production and that is talk to your production support staff. Get their input, share your design, and get their feedback early and often. This will not only make your asset supportable (imagine a reusable asset without logging or instrumentation or ability to report on key metrics) it will also get you a valuable partner. Production support will soon learn to trust your assets, your services, and will demand that multiple projects leverage the capability. It is one thing for you to sell reuse but another thing for your partners to voice support.

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

: : : : :