5 Tips to Ease Reusable Asset Integration

September 9, 2012

Resuable software assets need to be created and evolved with two perspectives – functional value and ease of integration. A library that offers little functional value and is difficult to integrate into an application is unlikely to get wide adoption.  Are there tips to balance these two perspectives? I think so and here are some pointers:

  1. Minimize the number of 3rd party transitive dependencies – if reusing a module means bringing in 100 JARs, there are lots of opportunities for conflicting libraries build time and unanticipated runtime exceptions. I will elaborate specific strategies for this aspect in a separate post.
  2. Carefully assess integration points in your environment – does your company already have a widely adopted library for concurrency, logging, alerting, or messaging? Then your reusable asset needs to facilitate or ease out of box integration. Most importantly, it shouldn’t attempt to provide the same capabilities
  3. When providing overlapping capabilities you will have to convince the right set of folks that another API is necessary and there is a rationale for application teams to switch. Remember that the learning curve, integration effort, regression testing effort, and ongoing maintenance need to be factored into this decision
  4. When you are not sure how an existing library in your organization works, descope integration and instead focus on the core value that is unique in your reusable asset. It is much simpler to bolt that on rather than invest in an integration mechanism that you cannot support well.
  5. Boost developer productivity via IDE plugins, quick start project setup via Maven archetypes, or through code examples and automated tests. Regardless of what strategies you adopt the key is to demonstrate how easy it is to integrate your reusable asset with the rest of your enterprise.

Do these resonate with reuse practices you follow or have seen in your team? What other practices can help achieve adoption objectives?

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?

Evaluating Existing Assets for Reuse Potential

April 25, 2010

One of the often-repeated reasons for not starting a reuse program is the upfront investment required for building the initial set of reusable assets. This is a legitimate impediment that can be addressed by taking advantage of existing code in your team. When you evaluate existing assets for their reuse potential, there are a lot of factors to consider. Here are a few salient ones:

  • Fit within product line: is the asset of relevance to one or more applications in your domain? You want to invest in assets that encapsulate business functionality that can be utilized in multiple business processes and applications. Similarly, if there are assets with business relevance but in a area that your organization intends to divest out of – you will be less inclined to use them.
  • Coupling: How tightly or loosely coupled are the pieces within an asset? sometimes the asset itself might be mixed in – tightly coupled – with a lot of extraneous code. Business logic might be mixed with data access, presentation, and even specific calls to external systems. Every one of these aspects introduces coupling that will need to be assessed thoroughly.
  • Integration: what is the effort required to integrate the reusable asset with applications? The asset might be very difficult to integrate because of platform specific requirements or because of language needs.
  • Business Assumptions: are there assumptions that the asset makes about business rules or business activities? if so, are these assumptions still relevant? will the rules need externalization/refactoring? Often, business assumptions are lost due to lack of alignment between business concepts and abstractions in code.

In a followup post, I will elaborate on robustness, scalability, deployment, documentation & samples. Without thinking through these aspects it is risky to introduce new assets for reuse. You will quickly discover that your consumers are unforgiving when it comes to asset quality. Additionally, a huge learning curve will drive away potential and existing developers and technical leads from evaluating assets for use with new applications.

Systematic Reuse Recipe #1 – Minimize Point to Point Integrations

November 21, 2009

Problem Statement

A consuming application/business process wants to integrate with your reusable asset. However, the consumer doesn’t want to take your standard message – wanting a specific format that will make it easier for them. Why? Could be because of several reasons: lack of time/money/skills or technical limitations (e.g. their system can handle only delimited files and cannot parse XML).

Suggested Approach

The immediate, tactical (and often tempting) solution would be to just format the data per the consumer’s format and integrate in a point-to-point fashion. Don’t settle for this option too quickly! Prefer to publish a standard publication in that is in line with your long-term direction (e.g. offer reusable message publications in XML format indicating changes to critical data entities or state changes in business processes). Create a subscriber that tranforms the standard message to the consumer-specific format.


If point to point integrations go ungoverned, you will end up with a rat’s nest of tightly coupled integrations that ultimately hurt business agility.Your long-term intent is to have multiple consumers (web applications, backend systems, business processes, etc.) consume reusable message publications.If several business processes need the same core data or notifications about state changes, why would you want to integrate with them separately? Publications will not only reduce integration effort, they place less strain on your system resources – publish once and subscribe several times. No need to query databases or invoke external systems every time there is a new integration.

Note: The additional transformation logic will require extra logging/error handling but over the long haul is a better option than going for a point-to-point integration approach.

This will enable the asset provider, to integrate new applications faster (no need to custom develop messages and integration code for every new consumer) and reduce the cost of maintenance. Reducing application to application coupling is a key motivation for pursuing this approach as well.

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

tweet this add to del.icio.us post to facebook

Addressing Integration Complexity with Reusable Assets

November 19, 2009

One of the often-cited concerns with leveraging reusable software is design complexity. This is indeed a legitimate concern and as designers, we ought to ensure that it is managed appropriately. In this post, I want to provide some strategies for tackling integration complexity:

  1. Build Iteratively: this is undoubtedly an effective way to avoid over-engineered assets. Building assets iteratively means realizing functionality in small bites, over multiple releases even. Instead of trying to implement a perfect reusable asset, prefer building in increments. This has several benefits: reduced risk, increased relevance for your applications, early feedback on whether the asset has captured domain relationships appropriately, and opportunities to remove code or refactor behavior on a continuous basis.
  2. Capture natural variations in the domain:  reusable assets that don’t reflect the natural variations in the problem domain run into lots of issues. If you keep scratching your head trying to infer what the asset is trying to accomplish – examine the consumer-facing interfaces and ask yourself, does the interface reflect domain variations or is it providing needless variations or worse, ignoring must-have ones?
  3. Prefer convention over configuration: This is one of the foundational principles behind why frameworks such as Ruby on Rails are so popular. You can use this idea and simplify assets in many ways! For example, instead of forcing configuration for files, maybe a standard location would suffice. This idea can be leveraged with scripts that setup developer environments, automated regression tests, and reading/saving program output etc.  There might also be cases where input data is used to determine class instantiation or stylesheet selection. Again, if you come up with a simple convention, many lines of configuration can be eliminated.
  4. Loosely Couple Capabilities: Loosely coupled capabilities are easier to change and integrate. By creating reusable assets in a loosely coupled manner, you will also make it beneficial for consumers. Loose coupling provides another important benefit – making it easy to isolate assets and test them as individual components. If you are building service capabilities, explore the use of asynchronous message publications for real-time notifications to data/status updates.
  5. Strive for consistent naming and behavior: consistent naming reduces learning curve for developers as well as makes it easy for the asset provider to debug, integrate, and test reusable assets. Consistent behavior should go beyond simple method calls – you can extend this to services and business processes as well.
  6. Make Assumptions Explicit: A lot of design complexity can arise due to incorrect assumptions – for instance, there may be operating assumptions about security, data integration, tracking, and error handling.  There are a lot of design assumptions that get made as a natural part of the development process (e.g. every customer will always have a address, or that every customer needs to get authenticated prior to instantiating a business process). Make sure these assumptions are put in the open and for everyone to validate. It often turns out that an asset doesn’t have to implement a feature or that it may be implement an existing feature incorrectly.
  7. Provide consumer-friendly interfaces: Start designing from the consumer’s standpoint and strive for simple yet functionally rich interfaces. This has several benefits: you won’t expose needless internal complexity associated with the asset to the consumer (i.e. achieve right level of encapsulation) and also make it simple for consumers to integrate with the asset. If you have 10 options for a reusable asset but most customers use 2 frequently, why not set the other parameters with sensible defaults? Consumer friendly interfaces also ensure that you build assets that have tangible business value.
  8. Avoid abstractions for the sake of technical elegance: not every abstraction is meaningful, especially with respect to your problem domain. I wrote earlier about the domain-specific nature of variations and why one set of abstractions isn’t always appropriate for your problem. Experiment and iterate to get the right abstractions – they will help establish a shared language within the team and reduce needless complexity because of overly generic interfaces.
  9. Minimize compile-time and runtime dependencies: Reducing the number of moving parts – both in terms of compile time libraries and runtime libraries, services, and systems will make it easier to manage design complexity. Always, ask yourself – is this dependency absolutely essential? Does it introduce a single point of failure in the overall architecture? Is there a way to cache frequently accessed data or return that isn’t 100% up to date?
  10. Provide Mock Interfaces: When possible provide mock data/objects that can help consumers integrate and test assets quickly. This is related to the earlier point about minimizing dependencies but is also useful for customers to get a flavor for the kind of data or business rules that get executed as part of the asset’s functionality. Mocking also helps with another key benefit: asset co-creation. If you are developing in parallel with a consumer, mocking is a great way to agree on interfaces and develop in parallel.

What is your view on these strategies? Can you share some of the ideas/approaches that you have pursued to tackle integration complexity?

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

tweet this add to del.icio.us post to facebook

16 Candidate Reusable Capabilities for Business Processes

November 15, 2009

Here area set of ideas, candidate  assets if you will, of reusable software capabilities for your business processes. Please don’t take these as capabilities you have to build from scratch. Instead, view them as part of your overall BPM software infrastructure. Most of these capabilities could be provided by a single vendor or using an abstraction layer, you can realize these using multiple ones. You can also prioritize this list when evaluating vendor offerings.

  1. Rule driven Exception Handler: Integrate exception handling with business rules engine. The rules could  determine how to resolve, mitigate, and handle errors. It will also specify routing instructions for errors requiring human intervention.
  2. Internationalization Support: Status messages driven by a resource bundle as opposed to a single locale. Additional locale-specific resource bundles can be added as required for your business needs.
  3. Seamless Cross Channel Movement: Enable a business process to start in one sales channel and get completed in another. Idea is to support business processes that start, pause, and get reactivated via an alternate channel. For example, a user can start ordering a book online and request a customer service rep to finish the process. The idea is to have the user’s in-progress process instance data get placed in appropriate work queues in a new business process or in a new state on the original one .
  4. Business Process Completion API: Ability to determine % complete for any business process based on the state of the process instance . This API can provide the ability to get current status, estimate completion time (e.g. based on historical data), and what steps are remaining for the process instance to finish.
  5. Business Activity Hold & Retry API: Facilitate pause, resume, and delegation of any business activity based on business rules. This interface would put processing on hold as well for one or more process instances.
  6. Authentication: Enabling integration with a LDAP store, or providing digital certificate based security for interfaces that instantiate the business process are examples here.
  7. Entitlements  API: Enable fine grained authorizations for business activities and business processes. Role based entitlements for events – i.e. if a particular user role cannot initiate a business process or execute a particular activity, the software  infrastructure should prevent those actions.
  8. Content Management integration: Integrate with content management system to serve targeted content based on state of business process or to augment data in a process instance.
  9. Event Integration API: Capture or derive events and handle them using one or more business processes. This could also impact existing process instances that are in-flight.
  10. Indexed Search Integration API: Ability to execute full-text search as well as categorized search using an indexed search engine against completed and in-progress business process instances. E.g. search all process instances from a particular division or with a particular customer code, or category etc.
  11. Process Dashboarding: Provide key business process metrics – report real time status of availability, performance, usage statistics, escalations, etc. Also provide ability to override/adjust in-flight process instances based on business scenarios.
  12. Business Process Preferences API: Manage a set of process-level preferences. E.g. default logging level for all tasks could be set to high or all notifications get delivered to additional recipients, or data fixes will get audited a different way etc.
  13. Document Integration: Attach documents using information in a process instance and attach/route content as part of the business process orchestration.
  14. SLA Adherence API: Manage service level agreement specifications associated with end to end business process as well as key business activities. Ability to define/handle, and proactively prevent SLA violations.
  15. KPI Definition and Monitoring API: Monitor business processes to capture key process indicators based on business process. E.g. number of accounts opened today, number of accounts opened after multiple validation errors etc.

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

tweet this add to del.icio.us post to facebook

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

%d bloggers like this: