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 #15

July 24, 2009

Tip #15 – Separate Business Process Context from Core Data

Service contracts that automate business processes should not mix contextual data with core entity data.  The following are examples of contextual business process data Рinitiator info (the user who started the business process, their role(s)), current user info (the user who is executing a particular activity in the business process, their role(s), the set of actions that are valid based on the state of the business process, as well as routing/delegation attributes. Authentication tokens, channel specific information (e.g. call center processes will have specific attributes).  This type of information should be decoupled (or not mixed with) data entities such as Product specific or Customer specific information. You want to keep them separate so they are candidates for future reuse. If they are coupled together, both the process contract and the data attributes become specific to the project or application.

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 #14

July 1, 2009

Tip #14 – High Cohesion and Low Coupling Applies to Reusable Services

Good object oriented design has always stressed the importance of high cohesion and low coupling. This applies to services as well! You want cohesive service capabilities be organized and offered as a service. Cohesive service capabilities make it easier for your consumers to find and comprehend your offerings. Additionally, high cohesion means less need for you to move capabilities across services. Most importantly, striving to be cohesive forces you to put related capabilities together and not end up with a kitchen sink of unrelated functionality. Likewise, each capability needs to be loosely coupled to the implementation language, technology vendor, and physical data characteristics in your SOA environment.

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! : :


Being consistent is more important than following a standard

May 13, 2009

When building software components and services for reuse across applications it is more important to strive for consistency rather than to comply with a standard. Why do I say that? Because you can always switch your implementation to be standards compliant. If a bulk of your applications use a particular reusable component you can always treat the existing interface as an adapter that in turns invokes a industry standard API behind the scenes. Note however I am not advocating blindly creating wrappers for components for which mature standards already exist (e.g. If you are trying to use a logging API for java you should evaluate Log4j instead of building a new logging implementation).

This is specifically related to horizontal business capabilities that you want to reuse. For instance, say you need the ability to process credit card payments from several applications and there wasn’t an industry standard at the time you needed this functionality. It is important to have a payment API that your apps utilize rather than wait for a standard to magically appear. Day two, if and when a standard appears you can change the existing implementation without any impact to your existing applications. Okay I am oversimplifying – you might need minor code changes and regression testing. But the bottom line is that you will be in a significantly better position rather than having to change code across your codebase.

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! : :


Building Reusable Services – SOA Magazine Article Published

May 1, 2009

article1 I wrote an article in collaboration with the editorial team at SOA Magazine for building reusable services.

Here is the link:
http://www.soamag.com/I28/0430-1.asp

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! : :


Building services for Reuse – Top 10 Practices for your SOA

May 1, 2009

You want to build services that are reusable across projects and initiatives. That is the aspiration at least. How do you make sure that your services are reusable? Here is my top 10 list to achieve this goal:

  1. Make sure your services are interoperable across platforms. What do i mean by this? you don’t want platform specific data structures, parameters, header values, etc. in your service contract. You also want to use a tool like WSDL Analyzer to ensure that your interfaces are compliant with Web Services Interoperability guidelines.
  2. Minimize (if possible avoid) building services specific to a target consumer -whether it is a process, human, or an external application. When you build point solutions you are not building reusable ones!
  3. Decouple transport logic from services logic. You don’t want your service to be only available via HTTP. Most enterprises that need guaranteed delivery, scalability, and asynchronous processing will want your service to be accessible via a reliable messaging transport such as JMS. So don’t make your service tightly coupled with a transport
  4. Avoid naming schema elements after particular systems or technologies. Your element names and complex data types should be domain relevant¬† and be descriptive. e.g. don’t use names such as MyEntity or customer001!
  5. Separate authentication from core services logic – you want to decouple the core services logic from how you authenticate the service request. This will give you the flexibility to support multiple authentication mechanisms (e.g. for a real time invocation the authentication might be a userid/encrypted password vs. a messaging invocation could be based on authentication set on a particular queue) or switch technologies altogether (e.g. change authentication from using LDAP tokens to X509 certificates).
  6. Encapsulate data object so they can use a separate schema: You don’t want to mix web method or service interface level elements with data object related elements. If you keep these separate, it will facilitate reuse of data objects across services (e.g. getCustomer and updateCustomer could both use a Customer data schema definition).
  7. Reuse data types across schema contracts – You should always be consistent with types within your domain and your organization across conracts. A customer name or gender cannot have one set of definitions in one schema and a different one in another schema. Reuse of complex data types will be tricky and you might be forced to use a custom definition on each instance but you can at least adopt this practice for simple data types.
  8. Design services to support multiple access patterns – This practice is essential for services that need to be accessed in both real-time and an event driven fashion. For instance, you have a getCustomer service capability that can be accessed on-demand as well as for publishing updates to customer data for a set of interested parties.
  9. Keep your service capabilities stateless – Avoid complex web of calls to manage state and keep your interface stateless. Sure it will make the interface bulkier but it is far easier to reuse a stateless service than a stateful one!
  10. Publish standard events from your business processes – Don’t build point to point integrations with downstream systems that need notifications from your business processes. Instead for each business process support a standard list of events you will publish. Any interested party can subscribe to the standard events and act accordingly to consume.

If you have additional practices and design techniques please contribute!

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 #9

April 30, 2009

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.

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: