Tip #9 Create reusable scripts to achieve continuous integration
You can create reusable scripts for compiling, executing, and reporting all your unit and regression tests. This is applicable whether you are building components or services or even business process flows within the context of a SOA architecture. The next logical thing to do would be to integrate these scripts with a continuous integration suite. Below is a presentation on achieving continuous integration using a reusable set of scripts. Although this presentation is for a Service Oriented Architecture (SOA) platform based on the Tibco suite the reusable scripts can be leveraged for many other projects.
Tip #9 Create reusable scripts to achieve continuous integration
You approach a developer with an idea for a reusable software component or service. What do you typically hear as an answer? I typically hear variations of the same answers. What do you when you hear these? Do you accept and give up? or attempt to persuade? if you are like me you want to persuade the developer. Here is a brief presentation on doing just that:
Instead of looking at systematic reuse a separate analysis, design, and implementation effort that requires lots of time and resources view it as being part of what you do. Practice a few techniques with every project, every single day. When your development activities are aligned with a systematic reuse roadmap your activities are aligned towards delivering today’s needs and positioning you for the future. Think of this as your team’s practice routine before the game. You won’t win if you don’t practice, would you?
Here are some ideas for aligning reuse efforts as part of your everyday development:
- When you review user stories look for patterns and similarities with stories from the past. Or stories from other applications in your team or within your shop
- When doing design always look to existing legacy assets for ideas and refactoring. I wrote earlier about wrapping legacy assets – you will be surprised how much code you already have that is worth reusing when you change the assumptions and decouple it from the existing code
- Be on the look out for opportunities to help other teams with what you own. Got a great algorithm, user interface widget, data service, process flow, content fragment that is reusable? spread the word – establish partnerships with your peers, colleagues, and keep sharing. The good karma is bound to help your team and your organization as a whole by increasing consistency and reducing development time.
- Keep overlapping requirements, functionality, and feature variations in mind while you design, implement, and refactor code. If you get ideas for a reusable component add it to your list of refactorings or to-dos. Come back and finish it when there is a real need.
- Get your team to review existing code. All the code all the time. Code reviews are just about the most effective way to get the most out of reuse – your codebase will continually get leaner and better. Prepare code review check lists for targeted assets (services, features, user interface widgets, classes, etc.) and make sure you use them over and over.
Although you probably build services for an initiative or a project ensure that there are no hidden or explicit couplings with a distribution channel. You should remove identifiers, user tokens, authentication tokens, and other data attributes specific to a distribution channel so your service can be truly reusable. Often in a rush to make dates you might implement an interface that is tightly coupled to a specific channel like a call center. Now, your service isn’t reusable for the branch channel or an online self-service channel or an interactive voice response channel. If you are unsure of how to decouple channel specific attributes you can always encapsulate a separate interface with those attributes (in case of a web service interface you can encapsulate these as a separate XML Schema). As you expose your service with other channels you can either expand or replace the channel data structure at run-time.
Tip #8 Get requirements from production support for your reusable asset
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.
I am introducing two new sections to the blog:
- Systematic Software Reuse Podcast Series – a 5-7 minute periodic audio segment offering tips, design techniques, and ideas on systematic reuse
- Resources – section for offering useful resources – initially will contain PDF documents that address specific areas related to systematic reuse. This will be periodically expanded with additional material as well.
In order to maximize the reuse potential of your assets offer multiple interfaces to the same functionality aimed at targeted audiences. For example, may be you need to expose a service that finds products based on some input criteria. Typically, you might create a findProduct capability that will be generic and reusable and this capability might take input parameters such as product name, identifier, and product family etc. In addition to this basic capability expose additional interface based on line of business – findProduct (name, line of business), findAllProducts (name, line of business) or one based on the relevance criteria – findProduct (name, full-text-match or starts-with-match or fuzzy match) or a combination of these.
This doesn’t mean you run out and build interfaces! More interfaces mean more maintenance so there is a careful balance between flexibility and the number variations that you can effectively manage. On the flip side, if there are multiple interfaces offered your consumers will find it easier to integrate and invoke your reusable assets. To realize this idea, map the variations into a standard set of parameters and the rest of your processing can proceed oblivious of the consumer input. Defaults and standard values can be provided for missing inputs when doing this.
how do you identify these additional interfaces? As with everything else, these interfaces need to be identified based on demand and priority. If your business sponsor needs to offer a capability for a particular geographical region (e.g. offer for the Americas first, followed by Europe, and Asia-Pacific) or for a particular product family then that is what you should consider for development.
Working alongside some very interesting and high performance teams I have come to believe that success with reuse is more than technical brilliance or elegant design. Great teams produce high quality work, understand each other, their strengths, their limitations, and most importantly harness conflict as a medium for healthy constructive dialogue, creativity, and innovation.
Peter Senge in his landmark book The Fifth Discipline says: “Almost all of us, in one time or another, have been part of a group of people working together in a extraordinary way. ..ever been part of a group who worked together in a extraordinary way, who were really exceptional in their effectiveness, in what they were able to achieve, and created a kind of environment that was really exciting to be part of.”
Why is teamwork relevant to systematic reuse?
Because, producing something reusable under severe deadlines and delivery pressures, integrating with legacy systems and processes, working with a myriad teams spread across several organizational departments, geographies, and still delivering high quality products is incredibly hard. It is the kind of challenge that motivates technology leaders and professionals go to work and make a difference.
The fundamental technical concepts for systematic reuse are well understood and what differentiates the winners from the rest of the pack is their ability to execute the reuse vision within their business domains with the help of productive teams on the ground. Every single component, service, asset matters.
Extraordinary teams talk to each other often, exchange ideas and collaborate more effectively, and most of all identify and mitigate risks to ensure the team as a whole is best positioned for success. If this sounds a lot like the agile manifesto it is not coincidental! Building reusable services requires creative brainstorming, conflict resolution, design synthesis, and arriving at a logical point that will be used to deliver your iteration. This isn’t an event – its iterative, continuous, and execution focused. If your team blends creativity and continuous delivery systematic reuse will be a natural byproduct.
Tip #7 Design XML Schemas using the any data type for building reusable services
Leverage the XML Schema any data type to build extensible schema contracts for your reusable services. The any element provides a convenient mechanism to construct modular schemas, separate framework/plumbing related processing from use case specific functionality, and allows graceful mechanisms to support new elements and types without impacting your existing consumers. Any also allows the provider to have containers to hold external schemas (with specific namespaces) that can be used to perform additional tasks.