Signs That Systematic Reuse Efforts Are Succeeding

August 30, 2009

I’ve written previously about systematic reuse being hard, the rationale for taking an agile approach, and the need for pursuing it within the context of business objectives. How do you know you are succeeding and that your efforts are having a positive impact? Here are a few signs to look for:

  • Developers and team leads think about functional capabilities first and implementations next. Teams also start to recognize reusable functionality across applications and projects.
  • Teams have constructive conversations about reusable assets.
  • Development/maintenance costs are distributed across reusable and application specific assets
  • Legacy system capabilities are reused by wrapping native APIs with external/target interfaces
  • Reusable assets are identified and evolved at varying levels of granularity i.e. assets could be simple utilities, components, services, business workflows, etc. and reuse is integrated with other initiatives such as business process management (BPM) and service oriented architecture (SOA).
  • Applications iteratively get transformed from being mostly consisting of application specific code to a mix of application specific and reusable assets. Over time, reusable assets become more sophisticated and start to provide a variety of technical and domain-specific capabilities.
  • Reusable assets are built not for perfection. User stories are continuously aligned with evolving reusable capabilities.
  • Reusable assets are organized in a easily accessible location and designers utilize these assets during design and not only when writing code.

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

add to Digg it : post to facebook: Stumble It! : :

Software Reuse Quick Tip #17

August 25, 2009

Tip #17 – Return informative and actionable exceptions from reusable assets

Reusable assets such as service capabilities need to return both technical and business (or domain relevant) exceptions. If a service or component returns a business exception often times it is useful to provide additional information to resolve the exception as well. Similarly, if a business exception needs a human user to resolve (e.g. fixing incorrect data, overriding a business rule, escalating to a manager based on business rules) you will want to return this information. It signals to the consumer that repeatedly invoking the call won’t resolve the problem.

Exceptions must follow a standard format that provides information for two audiences – internal support team and your external consumer. They should include warnings, statuses, remedial steps, retry procedure in addition to the core exception (if applicable). From a reusable asset standpoint, consistent exceptions signal robustness. It is critical for your consumers to know that the asset returns high quality exceptions and handles them gracefully. For your internal support staff, you should add additional diagnostic information such as stack trace, location of exception, state of key variables, as well as possible resolutions to the problem. For reusable services, this could make the difference between successfully recovering due to a failure and missing a key consumer’s SLA requirements. In other words, your exceptions need to be as informative and actionable as possible.

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

add to Digg it : post to facebook: Stumble It! : :

10 Design Assumptions That Hurt Your SOA Efforts

August 24, 2009

Building service capabilities that are strategic for your enterprise is a key aspect of SOA and lays the foundation for agile business processes in your organization. Many teams are engaged in building service capabilities both as part of SOA initiatives and bottom-up ones motivated by technology teams pursuing the benefits of service orientation.

How do you ensure that the service capabilities are in line with business objectives?
Are th
ere assumptions that hurt your SOA? I believe so! Here are 10 design assumptions that you need to watch out for:

  1. Service capabilities are always Web Services
  2. Services need to support only one data format i.e. SOAP
  3. Services are implemented first and then contracts are extracted (aka code-first approach)warningsign
  4. Service contracts don’t have to be reviewed or governed
  5. Service capabilities from vendor solutions can be consumed out of the box without mediation
  6. Services handle exceptions in an ad-hoc manner
  7. Services implement consumer specific logic
  8. Service interfaces are always non-validating
  9. Service capabilities are always accessed in a on-demand fashion. No need to support event driven interactions.
  10. Service consumers will all migrate to new versions simultaneously. No need to support multiple versions.

Please add to this list any additional assumptions that inhibit the effectiveness of SOA efforts!

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

add to Digg it : post to facebook: Stumble It! : :

Agile Software Reuse – Key Ingredients

August 20, 2009

Pursuing systematic software reuse is fraught with risks – hence the motivation to take a pragmatic, agile approach. What exactly does that entail? This post will introduce four key ingredients when pursuing agile software reuse:

4 pillars of agile software reuse

Reuse Roadmap
You can keep building one-off components and services and hope they all fit together nicely. But, that would be wishing for something that is extremely unlikely. Hence the need for a roadmap. The reuse roadmap is your guiding compass that provides business vision/objectives, a set of phases that transform the way you build software, and planned high-level milestones. Why is this roadmap important? Because you need to make sure that your reuse objectives are aligned with tangible business goals. Reuse pursued as a technology-focused objective will yield only minimal benefits. This shouldn’t be vaporware or slideware but based on ground realities in your organization. My recommendation: start small and keep things simple by pursuing reuse within a pilot project or two, get traction, and build on it. Start firmwide and your chances of success will dwindle very rapidly.

Continuous Alignment
You need to ensure that every iteration is aligned with your reuse roadmap. Your iteration has tangible features that are being implemented. They become much more effective if they are aligned with your overall vision. This isn’t meant to make every feature reusable or every iteration produce reusable assets. Just the opposite. Continuous alignment accepts that building reusable software is hard, takes time, and is iterative.  You can fight that and stand firm on producing perfect assets. That will not only add needless complexity but increase schedule risk for your iterations. Instead the idea here is to align assets towards reuse. This could be refactoring existing code, wrapping legacy service capabilities, or building a sub-set of a new asset’s features. Make your best efforts to align project backlog and refactorings with reuse objectives. This won’t always be possible and that is okay. Agile practices advocate exploration and alignment rather than prediction and certainty. Continuous alignment simply extends these ideas towards systematic reuse.

Iterative Design
Agile practices espouse simple design and avoiding big design upfront (BDUF). Iterative design is to build a reusable asset in successive iterations. Too many systematic reuse initiatives have failed in pursuit of the perfectly reusable software component or service. Business requirements, motivations, and goals change continuously and trying to implement the perfect asset only makes design risky. Iterative design also is about building for your immediate requirement and nothing more. Have a very cool idea to extend an asset? Add it to your project lists of tasks or refactorings and align them with iterations as appropriate. Just design what you must. There are times when you know future requirements and you can build towards that but those are still predictions. When in doubt, go back to the basics: understand your domain, clarify existing domain models/relationships, refactor the design, and build towards reuse. Never hesitate to delay commitment.

Systematic reuse isn’t about technology or software techniques alone. It is a rich-interaction activity that involves every member of your team. Teamwork is key and foundational in achieving reuse objectives. Your daily standup meetings, iteration retrospectives, and code reviews are all opportunities for your team to examine work in light of your reuse roadmap. Collective code ownership, continuous refactoring, and integration are practices that require your team’s contribution. Simply put – without constructive dialogue, reuse-friendly conversations, and passion, reuse will remain a dream. Your team is practicing iterative design, pursuing continuous alignment when planning iterations, and ensuring your codebase is in the accordance with the systematic reuse roadmap. No teamwork, no reuse!

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

add to Digg it : post to facebook: Stumble It! : :

Model View Controller Pattern and Reuse – Podcast Episode

August 16, 2009

Want to listen using iTunes?

Using iTunes?

podcast Just posted a new episode on the software reuse podcast series about the Model View Controller (MVC) pattern and how it helps with software reuse.


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

add to Digg it : post to facebook: Stumble It! : :

Loosening up legacy systems

August 15, 2009

Reusable capabilities are available in legacy systems but first you have to loosen them up.

SOA-based Systematic Reuse – Key Considerations

August 13, 2009

Here is a presentation on the key considerations when pursuing a SOA-based systematic reuse approach.

Are there others you think should be included in this topic?

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

add to Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

%d bloggers like this: