Systematic Reuse Success Factor #8 – Business Value

November 13, 2009

There are two critical risks with reusable components – they are needless complexity and domain irrelevance. Needless complexity results in more learning curve for developers to consume the asset and increased development and maintenance costs for the provider. Domain irrelevance results in assets that are of little business purpose and inhibits the ability to reuse capabilities across applications within a domain. Adding business value to a reusable asset should be your #1 priority above everything else. I will focus here on broad categorizations to illustrate this success factor:

Increasing Revenue: reusable assets should help reach new markets, create new products and services. Reusable assets need to be domain-specific for the most part and strive to map to business capabilities. Most importantly, strive to focus on what provides competitive advantage for your firm. Invest in reusable assets that no one else in the market can build because they lack the expertise or resources. Finally, reusable assets should help you drive time to market down. If it takes longer to integrate and test reusable assets than to develop from scratch, guess what your developers and tech leads are going to prefer?

Decreasing Costs: Reusable assets should help by saving you duplicate work. Likewise, reuse can help reduce maintenance costs – but only if the assets are relevant. If your products are for a domain that has no reusable assets, you won’t be able to save costs. Also, when you reuse, there is potential to consolidate vendor solutions, data feeds, and proprietary implementations as well. Do factor in less licensing and ongoing upgrade costs. Note: don’t underestimate the cost of integration – at least during the initial stages of your reuse efforts. There is additional training and integration cost that has to be accounted for, before cost savings can materialize.

Increasing Agility: You can also add value by focusing on increasing agility. This is critical to avoid big design up front (BDUF) and big investments. Instead of trying to build perfect assets, try to build assets that meet your needs. If reusable assets can help you evolve capabilities that can benefit multiple applications, business processes, and services that will aid organizational agility as well – e.g. you can provide vendor agnostic abstractions, provide simple interfaces to complex orchestrations, automate repetitive manual steps etc.

Increasing Productivity: Reusable assets can drive increases in productivity for both business users and developers. For business users, reuse can facilitate access to same or similar capability across applications and processes. For developers, reuse can reduce learning curve (when they are using something repeatedly) as well as manual steps involved in integrating certain assets together (assuming you have not only thought about assets in isolation but when how they work together as well).

Reusable assets have to provide value so there is incentive to create, maintain, and consume it over and over again. This is easier said than done but it will make a big difference to your business objectives.

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

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


Achieving Agility Using Decision Management – New Article

October 17, 2009

bpminstituteCo-authored an article with decision management guru James Taylor on achieving organization agility using decision management – it was recently published at BPM institute.

 

 

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

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


Pursue SOA with reuse in mind

June 11, 2009

Many organizations are pursuing SOA initiatives to achieve business process transparency and agility. While executing on projects you don’t want to lose sight of a reusable inventory of services that you can build for meeting your current and future needs. As much as immediate deliverables are important you should always look for reuse opportunities in the following areas:

  1. Integrating user interface tier with the business tier – look to create reusable business services to initiate business processes and get status of business processes. If a business process needs to be customized encapsulate these variations using business rules and configuration. Aspire to define a “template” process which hooks for plugging in product-specific or line of business-specific variations in functionality. Also define a standard set of business actions that any user interface can leverage. This is effectively to decouple the user interface from the business layer so additional apps can leverage your processes
  2. Integrating with legacy systems – this should be your #1 area for reuse. Never let go of an opportunity to wrap a legacy capability as a business or data service. Ensure your service capabilities are categorized appropriately and service interfaces are devoid of legacy semantics. Often you will find legacy systems have capabilities that are tightly coupled to additional data or processes that might need to be refactored. In those cases look to identify business rules and place them separately for reuse.  If legacy system needs data asynchronously publish standard messages and have the legacy system subscribe to them. Avoid one-off point to point integrations as much as possible and you will significantly increase the level of reuse
  3. Integrating business processes with data services – look to reuse data services for managing your core data entities. Services may not always exist and it is tempting to build project specific services but you should resist that and strive to build standardized services. If necessary refactor existing services, plan a migration path for your existing consumers, and build towards reusable service capabilities.

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


Have a plan for every reusable software asset

May 10, 2009

Have a plan for every reusable asset. At a minimum the plan needs to address:plan

  1. The scope of the asset’s functionality for your immediate deliverable
  2. The asset’s place in within your product line
  3. The impact to your existing design and overall architecture
  4. Tentative road-map for evolving the reusable asset over several iterations or releases

You don’t have to get answers for all these areas rightaway! The point is to think about them so you can make decisions on scope and effort. In the midst of an iteration there will be several questions about whether or not to invest time in refactoring or developing a feature. You can use this tiny list as a guide to help you make decisions on what to refactor or build and whether or not it is in line with your overall strategy.

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: