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

Phase 1-Ad-hoc - In this initial phase there is little or no awareness of reusable assets, and there is very little customer integration expertise. Consumers have low awareness of what assets are available. Systematic reuse efforts not considered and there is a lack of alignment between project deliverables, reuse strategy, and business objectives. Applications within the same domain do not share assets i.e. there is a lot of duplicate code.

View Reuse Roadmap

Phase 2-Aware - In the second phase, legacy capabilities and processes are mined for building assets. Agile practices are minimally aligned to the reuse strategy. Consumers seek reusable assets for applications in the domain and rudimentary product lines take shape. Communication about reusable assets have improved and awareness is increasing.

Phase 3-Ready – In this phase, asset inventory expands task, entity, and utility capabilities. User stories are analyzed within a product line context and additional assets are built iteratively. Agile practices specifically code reviews, refactoring, iteration planning, and pair programming used to identify and refine assets in a continuous fashion. Consumers increasingly use reusable assets to build applications and start to co-create assets. Additionally, assets are used across multiple applications in the domain. A few business process flows start to leverage reusable assets.

Phase 4-Systematic – This is when your systematic reuse program starts to really reap rewards. Asset inventory expands to include additional capabilities in your domain. Assets are used to automate many more business processes and they provide variability mechanisms to meet business needs. User stories and iteration planning are well aligned with reuse strategy which facilitate iterative reusable asset development. Additionally, several assets built by refactoring legacy capabilities and communication about reusable assets are available. Finally, consumers are actively engaged in asset co-creation, retrieval, and consumption and supported by a mature integration function.

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

• If your team is building reusable assets for multiple applications (as part of a product line) within your control you could use a library approach (a JAR or DLL). How you package and deploy the asset is dependent on the development platform. Similarly, if your team is building reusable assets for external applications outside your control, it is better to with a service oriented approach.
• Deploying reusable assets can be tricky! Spend some time thinking about how this asset will work within your environment. Is it going go be centrally deployed for all consumers? Or will each consumer have a copy of the asset in their application? If there are multiple copies, how will you track usage metrics?
• Make sure you have covered security requirements. Your shop might have special information/privacy standards and even legal ones to comply with. Ask around.
• Large shops might have enterprise standards that you might be forced to comply with. Work with the appropriate folks to avoid roadblocks when you deploy!
• A good rule of thumb is to seek input from your production support team (or your own team if you play that role) for understanding their needs. Think of production support input as part of your refactoring effort. Sure you can get away not doing this but why waste a precious opportunity to build a higher quality product while strengthening the partnership.

Don’t wait till the end of your iteration to consider these issues. You will have higher success with systematic reuse if you work these details out as well.

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

Episode Highlights:
Most development environments provide tools for generating WSDL contracts using annotations or platform-specific tools. Existing classes can be easily exposed as service endpoints. Method signatures become web service operations and method parameters become service parameters. This saves time and effort for the immediate term.

From a service-orientation standpoint however, this approach has significant disadvantages:

1. tools that enable contract generation out of the box often have the risk of introducing platform-specific attributes, service implementation semantics that inhibit interoperability and consequently the reuse potential.
2. The implementation contract could also have identifiers (database primary key field for instance) or implementation specific attributes (connection parameter to a proprietary system) that will needlessly couple consumers with a specific implementation.
3. This approach also challenges the provider’s ability to honor SLA policy requirements such as authentication/encryption etc.
4. Service capabilities also run the risk of not reuse entity definitions – business data model entities that will effectively decouple the service contract with the implementation
5. Adding to above is the risk of exposing inconsistent error handling, error messaging, error reporting that will be apparent to your consumers. Not to mention it makes it harder for the provider to support several different overlapping implementations!

The next episode will cover the rationale and advantages for pursuing a contract first approach. Enjoy!

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

Loosely coupled service capabilities help achieve agility in business processes and technology solutions. Why? Because, they make fewer assumptions about the implementation technologies and consumption characteristics.  Designing contracts or interfaces is a critical activity when building service capabilities. The interface needs to avoid specifying technology specific, implementation environment specific constructs. This includes operation system variables, vendor-specific variables, database layout/structure etc. The idea is to not tie yourself too closely with a particular implementation. Ask yourself – what is the impact to the service capability if the underlying database is moved to a different vendor? what if we skip the database completely and load data from a file cache? You shouldn’t have to move mountains to accommodate such changes if the interface is not tied to a single implementation. This concept must sound familiar Indeed it is the same idea that has been espoused with object oriented design. Separate interface from implementation. A service capability may utilize a legacy provider, packaged application, an externally hosted solution (a cloud maybe). It is essential that the service capability is carefully designed when integrating with these dependencies. If there are attributes internal to a legacy system ensure that they are not specified on the service contract.

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

You are doing right if…

• Your refactoring tasks are prioritized with the rest of your tasks for the iteration (maybe your coach or tech lead can help you with this).
• You identified the legacy asset changes, implemented them, and reviewed them iteratively. Getting the changes right with a legacy asset the first time isn’t realistic for most teams.
• Is there a single place to find all reusable assets? Is it accessible by all team members? If you have a geographically distributed team can they get to this?
• Do you have a plan for how this asset is going go be packaged, deployed, and consumed?
• Everyone in the team is aware of the new reusable asset and they know how to use it
• Every reusable legacy asset is either refactored fully or wrapped and consumed

Warning Signs
Here are some warning signs to watch out for while building reusable assets from legacy systems:

• More time is spent documenting what is wrong with a legacy asset rather than coming up with the refactorings needed.
• It takes weeks for you to identify what the legacy asset does or what it is coupled with (hint:  ask your team for help. You could be surprised how much undocumented knowledge is locked up!).
• The refactoring tasks are completely irrelevant to what your team is working on for the iteration (hint: the refactoring is either a waste of your time or your team isn’t communicating).
• The legacy asset changes are made without creating automated tests.
• The newly crested reusable asset has no documentation. No one knows what it really does.

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

: : : : :

1. Save time developing, integrating, and testing core domain components that get reused across projects. You did separate them from project-specific code, didn’t you?
2. Reuse service capabilities across business processes and when building composite service capabilities
3. Minimize point to point integrations when exchanging data among systems. Pursue event driven publish/subscribe and have interested parties subscribe to a standard set of messages. An ideal place to publish these standardized messages? business process orchestrations.
4. Reuse legacy system capabilities as long as you are leveraging them via a mediation layer.
5. Pursue refactorings and align capabilities towards reuse within the context of user stories. You have to do that work anyways to get the story to be functional. Why not save development time for subsequent iterations?

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

: : : : :