Design and Process Criteria for Investment in a Reusable Asset

October 29, 2009

Making the right decisions in the middle of an iteration or release cycle is risky and needs good judgment. Investing in a reusable asset is no exception.

What can help you take decisions on whether it is worth investing the time and effort for making a software capability reusable? The single most important factor is business relevance. Is the capability a priority for your business? Even if it is not a priority, is it one for the medium or long term? If the answer to these questions is no, you shouldn’t invest valuable resources into making your capability reusable. Yes, if it isn’t relevant, it needn’t be reusable. Assuming a capability is business relevant, there are several considerations you can think about:

Design Considerations:

  1. Do you have user stories that either directly or indirectly requires this capability? For instance, if you have a login customer user story, and you don’t have a customer component, this is an opportunity to create one. In the same vein, the login customer story itself might have variations. What are the different kinds of login that you need to support? Username/password, username/password/special verification text, email/password, username/random set of questions, username/defined set of questions etc.
  2. Do you understand the extent of variability that is required for the asset? Consider the ratio of the features that vary a lot vs. the overall functionality.  Even if you end up with a gross, high-level percentage it will help you during design.
  3. Consider specifically the aspects that vary and the number of variations you need to support. This is very critical to plan for the reusable asset. Remember, you are pursuing iteration not perfection! Draw a distinction between the variations that are an absolute must vs. ones that can be built over time. If you look back at the first point, maybe your business only needs the simple login using username and password. In that case don’t rush into building in variation support. On the other hand, if they come back and ask for multiple kinds of login you can always refactor to support variability.

Process Considerations

  1. Will the capability add significant schedule or technical risks? If so, you need to make this transparent and get clarity from your sponsors. You can explain the rationale for investing in a reusable capability if there is business relevance. Similarly, if schedule risk is unacceptable or you have other higher priority assets to build, refactor, etc. then add this asset to the refactoring list and revisit later.
  2. Will the capability introduce deployment changes? Does it need an additional resource such as a database, a configuration file, or is dependent on an external service provider? In that case you will want to run it by your production support and operations partners and get their buy-in.

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

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


Software Reuse Quick Tip # 21

October 28, 2009

Tip # 21 – Identify Repetitive Steps Consumers Perform

There are a variety of places to look for reuse opportunities – one that is my favorite is looking for patterns with customer integrations. If a customer is setting ten properties to execute a common service call or method, why not provide a convenience function to accomplish the same in fewer steps? The other classic example is initializing objects. If every consumer is creating the same set of objects and initializing it in a specific way – resulting in a lot of repetitive code – you can provide a factory class or a façade interface. Additionally, look for activities that customers do that should be part of the reusable asset or can be useful to others. For instance, maybe after receiving output your customer converts that data to another format (say from XML to JSON or XML to plain text) – why not provide an option to get that right out of the reusable asset? Note of caution here though: what I am referring to is only common capabilities that aren’t specific to a single consumer. If you place logic that is specific to a consumer the asset is no longer reusable.

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

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


Build an Abstraction API for BPM Interaction

October 27, 2009

Introduce an abstraction API when integrating with a BPM solution. Why do I say that? Several reasons:bpm abstraction api

  • Good software design practice to bind to an interface as opposed to an implementation. So individual applications won’t be directly coupled with an external vendor solution.
  • Provides you the flexibility to augment solution using multiple vendors. Related to above point, you can utilize one vendor for a subset of capabilities and another for a different set.
  • This API can be the ideal place to integrate your enterprise capabilities within the context of BPM solutions. Instead of making one-off or tactical modifications to a vendor solution that could be both expensive and proprietary, you can augment missing capabilities using the abstraction API. For example, if the BPM solution doesn’t support authentication based on active directory, this abstraction API can provide that capability (most likely you already have this component in your enterprise). Additionally, this is also the place to integrate horizontal capabilities such as message routing, metrics, monitoring, and error handling. Do you want your BPM solutions to report exceptions differently than other applications? In the same vein, this API can integrate with services or libraries that encrypt/hide sensitive data attributes before returning process state to a calling application. This has the potential to reduce duplication of such logic across user interfaces that integrate with related business processes.
  • Can potentially simplify complexities associated with a native API. If the native API needs a set of steps for starting process instances or get task/work items for a particular user – this abstraction API can simplify those calls. This not only makes it easier for integration but reduces the opportunities for errors across development efforts. This API in essence can act as a façade.
  • The API standardizes access to BPM capabilities and reduces the possibility of competing integration mechanisms across development efforts. If one team uses the native API as-is and another builds a new one on top – you have two ways of accessing the BPM engine. This problem gets worse as additional teams start to use BPM.
  • This API could also make every business process support a core set of functions in addition to start/stop/suspend/resume calls. For instance, every business process can provide a getCurrentStatus() or reassignProcessInstance() that will make it easier for managing processes at runtime.

This API could be realized as a web service depending on the level of heterogeneity and performance requirements. This would essentially act as a service enabler for your business processes.

The above list isn’t exhaustive – are there additional ones to add to this list?

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

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


Free E-book: Tips When Purusing Agile Software Reuse

October 24, 2009

Here is a free e-book on tips when pursuing agile software reuse. It introduces the rationale for software reuse, the need for agility, and lists twenty quick tips to help you succeed with your initiatives. Enjoy!

Tips When Pursuing Agile Software Reuse
agile_software_reuse_ebook

Like the ebook? Subscribe to RSS feed or get blog updates via email.


Disadvantages of Building Services Code-First – Podcast Episode

October 22, 2009

podcast Just posted a new episode on the software reuse podcast series on specific design techniques when building reusable services for your SOA initiatives. This short audio episode covers building services code first – i.e. take existing components, implementations and expose them as service capabilities.

Episode Highlights:
Most development environments provide tools for generating WSDL contracts using annotations or platform-specific tools. Existing classes can be easily exposed as service endpoints. Method signatures become web service operations and method parameters become service parameters. This saves time and effort for the immediate term.

From a service-orientation standpoint however, this approach has significant disadvantages:

  1. tools that enable contract generation out of the box often have the risk of introducing platform-specific attributes, service implementation semantics that inhibit interoperability and consequently the reuse potential.
  2. The implementation contract could also have identifiers (database primary key field for instance) or implementation specific attributes (connection parameter to a proprietary system) that will needlessly couple consumers with a specific implementation.
  3. This approach also challenges the provider’s ability to honor SLA policy requirements such as authentication/encryption etc.
  4. Service capabilities also run the risk of not reuse entity definitions – business data model entities that will effectively decouple the service contract with the implementation
  5. Adding to above is the risk of exposing inconsistent error handling, error messaging, error reporting that will be apparent to your consumers. Not to mention it makes it harder for the provider to support several different overlapping implementations!

The next episode will cover the rationale and advantages for pursuing a contract first approach. Enjoy!

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

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


What I am Working On…

October 21, 2009

In the midst of a couple of things:

  • Reading:
  • Learning to build data services using the WSO2 data services server
  • Storyboarding short videos on SOA design patterns and systematic reuse (hopefully i will get to create them soon!)
  • Exploring domains outside software development to get inspirations for software reuse

Reuse-Friendly BPM Capabilities

October 21, 2009

I have been stressing the need for integrating various concepts for succeeding with systematic reuse. BPM is no different. In an earlier post I introduced reusable BPM integration capabilities. In this post I want to list additional capabilities that you can build as part of BPM initiatives:

  • Mature your integration function that helps consumers integrate, use, and discover business process assets. This includes activities, sub-processes, as well as end-to-end business processes. Provide sample source as well as integration documentation to applications that need to leverage your processes. Do remember developers may not understand the differences in interacting with a stateful business process!
  • Significant alignment with information architecture logical model. Your activities that invoke system steps leverage logical data schemas and data types. If you start to reuse sub-processes within your high-level flows this will become second nature.
  • Ensure that your BPM assets are aligned with key performance indicators (KPIs) – if your business wants to analyze time taken between a particular set of steps you might need to persist, report, compute on this data. Why not use a reusable component that can persist updates from any business process?
  • Business process models and orchestrations developed are more standards compliant and adhere to key BPM and SOA standards. The higher the interoperability of SOA assets, the easier it is to reuse them in your business processes.
  • Expand coverage of business processes hosted in the BPM layer – including processes that involve internal clients, external clients, data governance/compliance etc. You will start identify reusable assets over time. For example, two business processes might require fetching customer data or updating customer address or calculate customer worth to the company and so on. Every such need is an opportunity for reuse.
  • Comprehensive modeling and representation of all relevant business processes including placeholders for manual steps, batch jobs, etc. Even if your existing process isn’t transformed completely from manual to one that is fully automated in real-time identify these steps explicitly. At the very least, you can use reusable components that deal with batch jobs (kick off FTP session or create a temporary file and copy to a particular location etc.)
  • Expanded number of event driven services for your business process. The higher the number of events the greater the likelihood of additional consuming applications getting to reuse data and notifications.
  • Support standardized alerts associated with human workflow steps (delegation, escalation, routing, pause/resume task etc.). Your BPM infrastructure can provide configurable capabilities for these steps.
  • Create scripts that perform continuous integration including smoke tests, unit tests, performance tests etc. If your business process are service-enabled, you can run a battery of service requests to instantiate, update, remove process instances.

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

Slide 2

ØWe are completely focused on Enterprise Account Opening and supporting Account Opening – support complex business process orchestrations.
ØWe are not methodically building a collection of reusable building blocks of assets in the business process layer that will help us for the future
§Data service wrappers, PMWS wrappers, Work in progress (WIP) API,  event processing
ØWe have built a set of components to configure events for a business process, capture metrics and perform administrative functions.
ØNot all business process logic is in business process layer for Enterprise Account Opening
ØWeb service the de facto metaphor of integration. Business processes are accessed on demand using  request/reply
ØSchema Contracts
§Schemas, data types, web service contracts are minimally aligned with information architecture logical data model resulting in a missed opportunity to align ourselves deeper with the information architecture direction.
§There is significant of data type, business object reuse across services and event handler orchestrations
ØSeveral utilities for testing, deployment, and continuous integration capabilities
ØClient integration happens on a per-project basis. This often results in increased pressure on the development team leads, lack of knowledge sharing across projects with respect to service integration/behavioral issues

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


%d bloggers like this: