Every Project Is An Opportunity

May 26, 2012

Succeed with systematic reuse by pursuing opportunities across every project. Every single project. Explore synergies across projects to not only identify new reusable components but also update existing ones. Here are a few common areas that yield reusable components:

  • Data access and updates – is there a single suite of APIs for managing core data? are there redundant implementations, overlapping calls, across projects?
  • Domain rules – are domain rules organized in a clear and well maintainable manner? or are they split across layers and implemented using multiple technologies/strategies?
  • Processing templates – are there a common set of steps of relevance in your domain? are these steps always executed in a consistent manner? is there an opportunity to Templatize the steps?
  • Config management – how are applications managing configuration properties? how do they enable properties for a particular environment? how does an application get only properties that it is entitled to?

The above isn’t exhaustive but gives you a flavor for the kinds of questions that will drive opportunities for systematic reuse


Detect Service Availability Issues Before Your Clients Do

January 17, 2012

When service capabilities get reused across applications and processes, high availability becomes imperative – key question: do you detect availability issues before your clients do? This is important for several reasons:

  • Unlike stand alone applications/processes, shared services impact several consumers. Not every consumer might be okay with your service being unavailable for an extended period of time. The same service might be in the critical path for some and not so much for others
  • For some service capabilities, running them in a partial mode might be acceptable – e.g.  operating out of a cached copy of data rather than fetching it from a live database, or servicing only read only operations during an unexpected outage, etc.
  • Some consumers might have regulatory processes that are dependent on services being available – a service being unavailable might cause SLA breaches

Finally, consumer trust is key for systematic reuse – if they perceive service availability as a limiting factor, it will be harder to convince them to use services – including current and upcoming integrations


Role of Systematic Reuse in Enterprise Integration

January 7, 2012

Systematic reuse in the context of enterprise integration provides several benefits:

  • allows the team to evolve consistent set of data interfaces across integration efforts – if multiple systems need to integrate with yours, can you define a generic data model for your domain-specific concepts? This could be file layout(s), service interface schemas, or platform specific APIs
  • enables common interfaces for domain specific services and business processes
  • integration points often need cross-cutting concerns such as logging, transaction management, exception handling, etc. that can be reused
  • reusable utilities can help with support and testing tools – for instance,  reply failed messages, drain message queues/topics, generate high volume test data, etc.

Question is – are your teams taking advantage of integration points? or is each integration point implementing identical or similar functionality in an inconsistent fashion?


Systematic Reuse Mythbuster #1 – Reusable Doesn’t Mean Perfection

December 26, 2011

One common criticism against systematic software reuse is the myth that it implies perfection – creating a reusable asset automatically conjures up visions of a perfect design, something that is done once and done right.  Many developers and managers confuse reusability with design purity. However, reusability is a quality attribute like maintainability, scalability, or availability in a software solution. It isn’t necessary or advisable to pursue a generic design approach or what one believes is highly reusable without the right context.

The key is to go back to the basics of good design: identify what varies and encapsulate it.

The myth that you can somehow create this masterpiece that is infinitely reusable and should never be touched is just that – it is a myth and is divorced from reality. Reusable doesn’t imply:

  • that you invest a lot in big up front design effort
  • you account for everything that will vary in the design – the critical factor is to understand the domain – well enough, deep enough, so you can identify the sub-set of variability that truly matters

In the same vein, reusablility strives for separating concerns that should be kept distinct. Ask repeatedly:

  • Are there multiple integration points accessing the core domain logic?
  • Is there a requirement to support more than one client and if so, how will multiple clients use the same interface?
  • What interfaces do your consumers need? is there a need to support more than one?
  • What are the common input parameters and what are those that vary across the consumer base?

These are the key questions that will lead the designer to anticipate the appropriate places where reuse is likely to happen.  Finally, it is important that we don’t build for unknown needs in the future – so the asset is likely to solve a particular problem, solve it well, solve it for more than one or two consumers, and finally has potential to be used beyond the original intent. At each step there are design decisions made, discarded, continuous refactoring, refinements to the domain model – if not re-definition altogether.

Don’t set out trying to get to the end state or you will run the risk of adding needless complexity and significant schedule risk.


5 Service Governance Practices for Effective Reuse

December 24, 2011

Pursuing service based systematic reuse or business process development? Then, these five practices will help your teams achieve increased level of service reuse.

  1. Manage a common set of domain objects that are leveraged across service capabilities. This could be a library of objects (e.g. Plain Old Java Objects) or XML Schema definitions or both. Depending on the number of service consumers and the complexity in the domain, there will be need for supporting multiple concurrent versions of these objects.
  2. Provide common utilities for not only service development but WSDL generation, integration and performance testing, and ensure interoperability issues are addressed
  3. Appropriate functional experts are driving the service’s requirements and common capabilities across business processes are identified early in the software development lifecycle
  4. Governance model guidelines are clearly documented and communicated  – for example, there are a class of changes that can be made to a public interface such as a WSDL that don’t impact existing service clients and there are some that do.
  5. Performance testing needs to be done not only during development but during service provisioning – i.e. integrating a new service consumer. If your teams aren’t careful, one heavy volume consumer, can overwhelm a service impacting both new and existing consumers. Execute performance testing in an automated fashion – every time you integrate with a new client to reduce risks of breaching required SLAs

What additional practices do your teams follow?


9 Quick Tips to Reducing Technical Debt

April 13, 2011

Wrote earlier about the importance of refactoring and continuous alignment within the context of systematic reuse effectiveness. Reducing technical debt is an integral aspect of refactoring. This post provides tips for reducing technical debt in your software assets:

  1. Minimize redundant definitions of key domain objects (i.e. competing, conflicting definitions of the same domain object across related applications)
  2. Minimize similar solutions for slightly varying business processes and instead create common process flows
  3. Loosen tightly coupled integration/transport logic with business logic
  4. Provide consistent strategies for implementing cross cutting concerns
  5. Replace tactical implementation for a problem that has a better open-source alternative
  6. Eliminate redundant approaches for managing configuration information
  7. Harmonize multiple, incompatible interfaces and make them more domain relevant
  8. Minimize excessive coupling with a particular technology/implementation stack
  9. last but not the least – create a comprehensive suite of automated tests

Are there similar themes in your development efforts? What steps are you taking to ensure technical debt is addressed?


Benefits of Decoupled Service Contracts

March 13, 2011

The Decoupled Contract pattern separates the service contract or interface from the physical implementation. The service interface is independent of implementation yet aligned with other services in the domain or enterprise service inventory.This is a follow up to the podcast episode on building contract-first services

Distributed development technologies such as .NET and Java allow easy creation of service contracts from existing or newly created components. Although this is relatively easy to accomplish the service contract tends to get expressed using the underlying technology platform – one of the many anti-patterns to avoid. This inhibits interoperability and increases integration effort for service consumers. Additionally, service consumers get forced to a specific implementation thereby considerably increasing technology coupling. Finally, this is problematic for the provider as well. If there is a need to upgrade/replace/change the service implementation, there is high probability that existing consumers will need to change their code.

The Decoupled Contract pattern solves above problems by decoupling the service contract from the implementation. Instead of auto-generating service contract specifications via a WSDL document, this pattern advocates the creation of contracts without taking implementation environment/technology into consideration. This contract will be free of physical data models instantiated in a backend data store and proprietary tokens or attributes specific to a technology platform. Consequently, the service consumers are bound to the decoupled contract and not a particular implementation.

The service and the consumers will still be coupled with any limitations associated with a service implementation (for instance, an implementation may not be able to realize all features of the contract or guarantee policy requirements etc.). It is also possible for a particular implementation technology to impose deficiencies across the service inventory in its entirety. But even given these impacts, the contract-first approach that this pattern facilitates is significant and foundational to service-orientation.

This pattern is beneficial to several design techniques that use Web Services or benefit from a decoupled service contract. Contract Centralization and Service Refactoring patterns are greatly enhanced by this pattern. Service Façade is often applied alongside this pattern as well to realize Concurrent Contracts.


Using Spring & Java Annotations to Inject Reusable Capabilities

January 19, 2011

Want to inject reusable functionality but don’t want your consumers to go through complex set of steps to implement? Using annotations, a reusable capability can be injected at runtime – your clients can take advantage of common, reusable capabilities while avoiding the need to implement boiler plate code. Consumers can also be allowed to declaratively specify/alter the reusable asset’s behavior using this approach.

Here is an example using Java and Spring framework to print a test message before invoking the target method.

Declare an annotation – a simple annotation with a boolean flag:

package example.annotation;

import java.lang.annotation.*;

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface Loggable {
	 boolean log() default true;
}

Create a dynamic proxy – all this does is examines the boolean log method from the annotation and prints a test message:

package example.proxy;

import java.lang.reflect.*;
import example.annotation.Loggable;

public class ExampleDynamicProxy implements InvocationHandler {

	private Loggable loggable = null;
	private final Object targetObject;

	public ExampleDynamicProxy(Object target, Loggable loggable) {
		targetObject = target;
		this.loggable = loggable;
	}

	public Object invoke(Object target, Method method, Object[] arguments) throws Throwable {

		Object result = null;
		try {
			if (loggable.log()) {
			  System.out.println("message before invoking method...");
			}
			result = method.invoke(targetObject, arguments);
		} catch (InvocationTargetException ite) {
			throw ite.getTargetException();
		}
		return result;
	}
}

Create a spring bean post-processor – checks for annotation and creates a proxied version of bean:

package example.postprocessor;

import java.lang.reflect.Proxy;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;

import example.annotation.Loggable;
import example.proxy.ExampleDynamicProxy;

public class ExampleBeanPostProcessor implements BeanPostProcessor {

	@Override
	public Object postProcessBeforeInitialization(Object arg0, String arg1)
			throws BeansException {
		return arg0;
	}

	@Override
	public Object postProcessAfterInitialization(Object arg0, String arg1)
			throws BeansException {

		Class clz = arg0.getClass();
		Class[] interfaces = clz.getInterfaces();

		if (interfaces != null && interfaces.length == 1
                        && _interfaces[0].isAnnotationPresent(Loggable.class)) {

			Class _interface = interfaces[0];
			ClassLoader cl = arg0.getClass().getClassLoader();
			Loggable loggable = (Loggable)_interface.getAnnotation(Loggable.class);
			Object proxy= Proxy.newProxyInstance(cl, new Class[] {_interface}, new ExampleDynamicProxy(arg0,loggable));

                        return proxy;
		}
		return arg0;
	}
}

Annotate an example interface as Loggable – this model can be used to inject lot of other reusable capabilities (error handling, notifications to JMS destinations, or even perform data transformations):

package example.bean;

import example.annotation.Loggable;

@Loggable
public interface Example {
	public String getGreeting();
}

Finally, each consuming interface will have an implementation and has to be defined as a bean along with the post-processor during spring initialization. This is a trivial example but was meant to illustrate the injection of reusable behavior via java annotations.


Enabling Reusable Asset Co-Creation

October 25, 2010

In order to get critical mass for reusable assets, they have to be created and evolved in a collaborative manner across development teams. How can we enable co-creation? Several specific strategies can help:

  • Share the source – ever wondered why open source projects succeed when in-house efforts haven’t? Sharing the source code behind reusable assets makes a world of difference. It increases transparency (with respect to capability, behavior, and quality) and provides an opportunity for the developer community to participate in the analysis, design, and implementation activities. More importantly, it enables teams to modify the source per their specific needs and allows them to submit/merge the changes with the main build.
  • Provide detailed documentation for reusable assets that are both available, in-progress, and planned for the future. It can come very handy when there is a design decision to make in a project – time and time again, you will realize the greater the information on existing assets, the easier it becomes to enhance/change them and combine them in new and innovative ways.
  • Explicitly seek participation and design input when creating/updating a reusable asset. This not only increases buy-in from the tech community but also provides new ideas, concepts, and problem solving techniques that the entire department (even an organization) can benefit from.
  • Encourage questions, specially from new members and junior developers – welcome the most basic questions about the reusable asset inventory. Make sure an environment where open, honest exchange of ideas is taking place constantly. Good ideas come from several places and it is critical that developers don’t feel alienated or ignored due to lack of knowledge about one or more reusable assets.
  • Seek out subject matter experts – several developers and business analysts are essential to increase domain relevance, and domain alignment for reusable assets. Pretending to have all the answers or feigning perfection will only reduce the quality of reusable assets and ultimately prove detrimental to reuse objectives.

Several systematic software reuse efforts fail to get off the ground – it isn’t because of inadequate domain variations or severely limiting technology constraints – due to lack of grassroots appeal among the technical community.

Co-creation addresses several issues at once: it exposes developers to high quality coding practices, increases awareness of available assets, and provides a controlled environment to experiment and evolve reusable assets.


Using Spring Interceptors to Reuse Functionality

August 29, 2010

Spring MVC interceptors (learn more about interceptor design pattern here) can be used to plug in functionality that needs to be executed as part of handling a request. These interceptors can be an ideal place to reuse functionality that is applicable for non-web application related scenarios. Interceptors can be used to execute horizontal, cross cutting concerns – e.g. security, metrics, logging, etc. If you have an existing component that was developed for a command-line application or a JMS event handler and need to reuse it in a web app, an interceptor would be an ideal choice.

Here is an example implementation for a a Spring Interceptor extending the HandlerInterceptorAdapter:

package com.yourapp.learn;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.springframework.web.servlet.handler.HandlerInterceptorAdapter;

public class LoginInterceptor extends HandlerInterceptorAdapter {

 @Override
 public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
 Object handler) throws Exception {

 Boolean userAuthenticated = (Boolean)request.getSession().getAttribute("userAuthenticated");

 if (userAuthenticated) {
    return true;
 } else {
    return false;
 }

 }
}

This interceptor simply checks to see if the user is authenticated by looking for a session attribute. If the result is true, the request is processed further.
Here is an example bean definition fragment for utilizing the above:

<bean id="testInterceptor" />

<bean id="testSimpleUrlHandlerMapping"
 class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">

<property name="interceptors">
 <list>
 <ref bean="testInterceptor"/>
 </list>
</property>

 <property name="mappings">
 <props>
 <prop key="/test">someController</prop>
 </props>
 </property>
</bean>

The actual logic can be in another component that is leveraged in the interceptor. The component itself could be reused across several apps. If such a component isn’t available, you can refactor existing logic to carve out the common functionality.


Follow

Get every new post delivered to your Inbox.