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

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 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 post to facebook

Systematic Reuse Success Factor #7 – Document

October 21, 2009

You have a shiny new reusable asset. You successfully refactored it and tested it as well. Now what? Take some time and document it. This will help you clarify the scope and purpose of the reusable asset. It could be a single document with all the reusable assets. Or if all your team is collocated even a flipchart would suffice to start with. This doesn’t have to be perfect from the get go.  Something lightweight that captures what the asset does and how to use it, limitations, and assumptions would be fine. If you have several external teams that you provide assets to, you can capture their application name and contact person.

It is less important what tools you use. All your documentation should be in one place. I document all the services and components using a Wiki and include the relevant set of bugs/changes for this asset from our issue tracking system JIRA. I find this convenient but I didn’t start with a Wiki. I put up a bunch of assets on a whiteboard and marked them ‘do not delete’. It hung out there for a few weeks over multiple iterations. As the list grew with new assets I moved it to the team Wiki. I use a simple template for everyone in the team to use and made minor tweaks to the basic set of fields we document based on the type of reusable asset. This keeps the documentation fairly consistent but still allows us to capture specific fields. I also tag each asset with client names so I can easily identify asset usage. The same idea can be extended to tag specific protocols, file formats, and authentication requirements so you can rapidly query things off the Wiki.

Here are the fields that I use to document our stuff on the Wiki:

  • Name: name of the reusable asset. Simple conventions used for library component, service, message
  • Version: major, minor, and patch version
  • Status: in production or in development
  • Description: brief description including any major assumptions and limitations
  • Where is it: the path to the asset in our source code control repository
  • Available interfaces: java interfaces, a WSDL document, or needs message queues.
  • Security: type of token to pass to invoke the functionality
  • input/output parameters: the path to either a language  API or xml schemas based on asset type
  • Code Samples for typical usage: source code accessing the asset’s functionality.
  • Error Handling: business and technical errors returned by the asset. Sometimes remediation steps are included as well.
  • Known Issues/Defects: this could be a bulleted list or integrated with your issue tracking system
  • Notes: Any other useful information about reusable asset you need to document

You are not “done, done” till your reusable assets are documented in a central location for all your team to access. Make this a habit every developer follows and it will soon become second nature. Now you are ready to integrate this asset with the rest of your codebase and even communicate about the new asset to folks external to your team.

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

tweet this add to post to facebook

Create interfaces from a product line context

October 20, 2009

If you ask developers about interfaces they typically build you will hear some form of create, read, update, and delete (CRUD). CRUD-type interfaces are simple to understand and are intuitive. They tend to be used heavily in the data access layer operating on your various data entities. At a high level these interfaces seem to meet your product line needs. This may not always be the case though! Why do I say this? The interfaces you create for a product line depends on the variations you need to support and manage. Variations will require interfaces that vary in granularity. Some operations might operate on a data entity while others might operate on an aggregate. Still others might operate at a subset of a data entity. For example, say you develop solutions for the banking product line where in you have an online portal, mobile bank, and branch services. All these products in your product line might support money transfer. Online portal might display a complete set of from and to accounts while mobile might display only a primary account. Branch might provide only accounts eligible when initiated by a branch. To address the variations you have to go beyond just getting the right set of accounts and have a reusable asset use a mechanism to access and execute business rules.

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

tweet this add to post to facebook

Systematic Reuse Success Factor #6 – Address Support Needs

October 19, 2009

How often you have worked on a project that didn’t consider support needs? I bet your quality of life as a developer was largely influenced by this factor. A supportable application makes a world of difference. Your reusable assets are no different in this regard. Reusable assets need to be robust against failure, scale up to handle additional volume gracefully, and provides relevant runtime metrics for diagnostics and troubleshooting.  Here are some common requirements for support:

Handle errors appropriately – this could mean logging, notification alerts, integration with existing support tools, or even calling a particular person.

Instrument reusable assets – log error information, runtime data parameters, processing/transaction metrics, system variables and provide an interface to access all this stuff

Design for things to handle runtime failure – can you use an alternate path to fulfill a request? Can you store requests and process them after a time window? Even if you cannot do any of these, throw the error and report it. Never swallow exceptions

Report metrics – provide standard metrics reports as well as ability to perform ad-hoc queries.

Integrate errors with issue tracking when applicable – Link known errors happening in production with the relevant issue from the issue tracking system. Make it easy for the support person to know that it is a known issue, possible workarounds, and escalation paths.

Regardless of whether your team or an external group supports your applications, the support requirements need to be addressed. Without addressing supportability your reusable assets won’t be reliable, robust, or dependable.

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

tweet this add to post to facebook

%d bloggers like this: