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 del.icio.us: 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 del.icio.us: 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 del.icio.us: 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.

Teamwork
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 del.icio.us: 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 del.icio.us: 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 del.icio.us: Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

Refactoring To Reuse #1

August 9, 2009

#1 Decouple connectivity from business logic

Often times you have a class that has a mixture of logic that is core or central to it and extraneous ones. A classic case is when you have a class that does calculations and also connects to a file or database. This isn’t bad per se because it probably works. But it inhibits reuse of both the calculation logic and the connectivity logic. One way to refactor the original class is to split it into 3 classes: a controller class, a connectivity class, and a calculation class. The controller is lightweight and co-ordinates the work across the other two classes. The connectivity class encapsulates file or database connectivity, and the calculation class executes a specific algorithm.

Here is an example – say you have a class named DiscountCalculator that accesses customer data from a database, and finds the ones that qualify for a particular promotional discount. You introduce a class named DBUtility that gets/closes a database connection, executes queries etc. I would advise against building such a class since good ones already exist. For example, if you use java, a better idea would be use Spring’s JDBCSupport and JDBCTemplate classes to achieve this. Now you can create a simple object (e.g. a plain old java object – POJO) that is returned from the database queries. The DiscountCalculator class can encapsulate the business logic within it or if you need to support multiple types of discountss you can consider introducing the Strategy design pattern. Whatever you decide, you can remove the database related logic from DiscountCalculator and keep it flexible for new types of discount calculations. In the same vein, the POJO is reusable as well for additional classes.

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

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Software Reuse Quick Tip #16

August 4, 2009

Tip #16 – Work with multiple stakeholders not just development

Systematic software reuse is a complex and challenging journey. Many of us in technology think of reuse from a developer standpoint. This is only part of the story. The success of reuse efforts often hinge on more than developers and development practices. You need to recognize the other stakeholders in this journey – they include system analysts, production support staff, information modelers, technical leads, and most importantly executives and development managers. Unless you have management support it will be tough influencing many projects in your organization. In the same vein, unless your reusable assets are supported in a production environment you cannot garner the required credibility of consumers and partners within your organization. Before you rush to buy the latest greatest silver technology silver bullet that will take you to the promised land of systematic reuse recognize that there isn’t one. It is a collaborative, incremental, and iterative effort requiring technical excellence, diplomacy and negotiation skills, and continuous communication. All these ideas apply whether your reusable asset is a library, framework, or service capabilities in a SOA context.

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

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Decouple App Specific and App Agnostic Logic

August 1, 2009

Your application typically consists of a variety of functionality – user interface components, business logic components including domain assets, business rules, and services, backend assets such as legacy components, packaged systems etc. If you tie your assets too specific to an application it will severely inhibit reuse.  Application agnostic logic should be built as reusable assets. If they aren’t, plan to refactor so they are reusable.

Business tier assets could be a combination of objects and services. Your SOA efforts need to be brought into the picture here so you can leverage existing services for fulfilling application functionality. Enterprise data can be decoupled from your application either via a data access layer or a data services layer or a combination of both. Business rules can be encapsulated using Classes via the Strategy pattern or via a declarative rules engine. Either way you should ensure that most of your rules are standalone units of logic that taken a bunch of inputs and return a result. That way they are not specific to a single application. External system integrations should be encapsulated as well including connectivity, data transformations, target specific data values, and error handling. Equally important is handling exceptions in a consistent way across your application.

The idea is to reduce coupling between application specific logic and application agnostic ones. This will help you reuse technology assets in new and unexpected ways! This in fact is a foundational idea of Software Product Lines.

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

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


%d bloggers like this: