Every Asset Isn’t Reusable

July 28, 2009

Every software asset in your application, product line, or codebase isn’t going to be reusable. In fact if you are trying to make everything reusable there is a good chance that you are introducing needless complexity into the design. Recognize that there are areas where reusable assets are going to be a natural fit and areas where they won’t be. You might be uniquetempted to make things reusable just in case you need them in another project or application. Pause and reflect at such points because hindsight is 20-20 and you might get better at discerning what is and isn’t reusable over several iterations of a system. There are always going to be assets that don’t fit well together or have neatly packaged interfaces and that is okay!

There are areas where it makes sense to build, adapt/refactor, and maintain reusable assets. For instance – connectivity components, domain specific data and business logic such as data services, business services, model classes/repositories, infrastructural components and utilities are all classic areas for reuse.

Ask hard questions if you are unable to make up your mind. If nothing else always ask if there is business relevance to the asset and if the asset’s functionality varies based on sales channel/user/time/business policies/rules etc. If the answer is no, you probably don’t need to invest efforts in making the asset reusable. At least not right away.

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

Advertisements

Facade Pattern and Reuse – New Podcast Episode

July 26, 2009

Want to listen using iTunes?

Using iTunes?

podcast

New episode is added to the Software Reuse Podcast Series on the Facade design pattern .  It can help reduce coupling and provide a simpler task-centric API.

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


Designing robust interfaces

July 22, 2009

Reuse is all about robust interfaces – check out my latest post on the pragmatic software design blog over at ebizq


Systematic Reuse Success Factor #2 – Ease of Integration

July 18, 2009

An often overlooked aspect of systematic reuse is integration of reusable assets with applications, processes, and services. Most teams focus on building a large inventory of reusable assets – services, objects, frameworks, domain specific language libraries. While that is necessary it is not sufficient for succeeding with systematic reuse. One essential ingredient is ease of integration. What do i mean by that? Specifically:

  • Evaluating the requirement and making a determination whether an existing asset can fulfill the need (as-is or with modifications) or a new one needs to be developed.reachingout
  • Address risks with integrating with a reusable asset (meeting SLAs, solution complexity, etc.)
  • Sharing information on available interfaces (is there a java interface? a web service?)
  • Providing code samples and integration design patterns
  • Provide comprehensive list of error codes and error handling recommendations – if a service throws a particular error what should the consumer do? are there specific business errors or data validation errors that the consumer needs to be aware of?
  • Ensuring the consumer doesn’t starve the reusable asset’s resources. This is essential for services based reuse where multiple consumers are invoking the same service capability.
  • Assistance with testing the integration (provide test data, unit test code, as well as utilities to test response time/throughput)

You can build up a service catalog and magically hope to achieve high degree of reuse and you will most likely be disappointed. Bottom line – reach out to your consumer and help them succeed. Make it easier for them to evaluate, integrate, and test. Slowly but surely your teams will start coming to you as opposed to you trying to ‘sell’ them on the value of 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! : :


Building Strategic Services – Article Published

July 18, 2009

soaworld

Article on Building Strategic Services was recently published by SOA World Magazine. The article covers various best practices and techniques relevant to service orientation and service delivery.

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


Add Transports Iteratively For Service Capabilities

July 14, 2009

You can add transport bindings to your reusable services iteratively as necessitated by project needs and timelines. A service can start out getting consumed over HTTP, and then support additional ones such as HTTP-S and JMS over time. The key is to not place transport logic in your service capability. This will give you a great deal of flexibility in adding and supporting new transports.

For example, your service can be initially consumed by a user interface application via request/reply SOAP over HTTP. Day 2, you might have a backend process that consumes the service via asynchronous request/reply SOAP over JMS. This should be a graceful extension for you if there was nothing in the service logic specific to HTTP or synchronous request/reply.

In essence, you are decoupling request processing, service business logic, and response handling:

transport-svc-capability

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: