Сots implementation

Commercial Off The Shelf (COTS), increasingly including Open Source (OSS) products, are bought or acquired by organizations to deliver or enable Business Value instead of built directly by the organization.

Many organizations wish to use agile methods while implementing (COTS) products with varying degrees of product customization. Holistic Software Development provides a simple approach to dealing with the selection, deployment and adoption of COTS products. In simple terms the area under the H-Model is mostly unnecessary, other than for heavy customization and configuration, whereas the rest of the H-Model largely applies.

Environments and Operations Integration Quality Business Value Product Delivery Release Planning Portfolio and Programme Management Architecture Requirements Teams People Strategy

Product Selection – Is it the right product?

COTS products are bought to solve a business problem and therefore add Business Value typically by reducing costs or exploiting an opportunity in terms of enabling progress towards Strategic Goals. HSD models the request for purchase and implementation of a COTS product as a Portfolio Request. A Business Case can also be produced to compare and contrast multiple COTS options. In some organizations the Business Case may form the basis of a commercial Invitation To Tender (ITT) or simply be required if the costs are high.

When examining the options to purchase a COTS product or acquire an Open Source solution a number of factors must be considered:

Is there a valid Build or Buy case for purchasing the product? 

If the product is risky or speculative then building might be a better option than buying.

Does it fit into the Enterprise Architecture (or near future roadmap)? 

Deployment, adoption, internal support and internal maintenance are greatly affected by alignment to Enterprise Architecture

Does it meet the user’s needs?

COTS products are often sold to a Business Leader and then forced upon a user base. Engage the user base in the selection and adoption of the Product, as well as the decision making to facilitate wide buy-in and accelerate the desired affect of purchasing the Product.

As a result, the sorts of stakeholders who need to be involved in a COTS, or OSS, selection include:

  • Business Leaders
  • Product Customer (the user base)
  • Architectural stakeholders (especially those technical leaders who drive the Enterprise Architecture)
  • Delivery Teams (who are expected to configure or customize)
  • Operations stakeholders (who will need to package, deploy and possibly maintain the product)
  • Quality and Measurement stakeholders (who will assure quality of configuration/customization and build in Return on Investment (ROI) metrication.

Product Deployment and Configuration

The “Product Delivery” part of HSD (the bottom half of the H-model) will look a little different as there is typically no need for requirements decomposition and elaboration below the Portfolio Request, System Architecture or low level technical practices and integration. Effectively the HSD model is short circuited from Portfolio Requests to the Integration Tested level of Done. Some of these elements might be useful for configuration/customization, however if a full scale development effort (and significant System Architecture) is necessary for configuration/customization then this indicates that the COTS/OSS product does not fit the requirements well and the Build or Buy decision should be revisited.

The earlier a Product can be found to be a bad fit for the organization and its needs the better. We recommend using Integration Scenarios as a unit of adoption and/or customization development. The incremental delivery of Integration Scenarios allows for Release planning, iterative development and progressive delivery of business value even in COTS Implementations.

Integration Scenarios describe an end-to-end workflow across a Product or Product Family resulting in Business Value for a Product Customer in flexible format.
Integration scenarios are threads across a number of other requirements such as Features and User Stories that don’t deliver Business Value on their own. They are ideally suited to describing the scope of Releases and providing the input for integration testing, necessary to achieve higher levels of acceptance.
Integration Scenarios can also be used to manage cross-cutting Non-Functional Requirements and drive the discovery of Architectural Mechanisms.
Integration Scenarios provide the context for discussions around User Stories.

COTS Product deployment is primarily a Business Change endeavor; excessive technical delivery is a symptom of a bad fit. Solution Architecture can be used in a Business Change context to describe how the various different communications and change activities will fit together to affect the relevant change – although this is only necessary for complex adoption challenges.

Click any part of the picture for more detail

The concept of Releases, and incremental value delivery, is still relevant for COTS/OSS deployment and rollout in a number of ways:

  • Product configuration/customization can be delivered iteratively or continuously to Feature based Releases
  • Product Adoption, as a Business Change activity can be approached iteratively in terms of:
    • Incremental adoption of the product by sections of the Organization (e.g. team by team if that makes sense in the organization structure)
    • Incremental adoption of product Features (not all of the product feature set has to be used by everyone straight away)
    • Or ideally both

Agility is founded in transparent short feedback cycles. Taking an empirical approach to proving the value of a COTS product and its rollout applies the best of the agile philosophy to COTS Implementation.

Multiple COTS as a Product Family

If adopting a Product Family, or a mix of COTS, OSS and bespoke Products to deliver business value then the cause and effect in terms of generation of Business Value can be hard to determine at a Product level. In this case we reintroduce the Solution Architecture concept and Integration Scenarios. Solution Architecture describes how the various products will work together from a technical and Operations perspective whereas Integration Scenarios express the end-to-end business flows that the Product Family must meet.

These Integration Scenarios are the foundation of integration development, testing, user training if necessary, and understanding Business Value realization.

Incremental Product Adoption – Is it still the right product?

Incremental product configuration/customization and Adoption/Business Change is critical to introduce short-term feedback into COTS deployment. Piloting and staged adoption allows a business to assess the impact of the product on the businesses way of working, culture and Business Value flow. COTS products must demonstrate value vs. cost as early as possible in staged adoption. If value cannot be shown, or worse holistic measures show a decrease in productivity, then the adoption should be stopped.

Just because a product initially seems like a good idea doesn’t mean it actually will be. Similarly, as markets change business needs will change and new products may become available possibly negating the Return on Investment (ROI) case for the product. Purchasing agreements for products are best formed around adoption stages, with no commitment to carry on purchasing if business value cannot be demonstrated. Suppliers unwilling to collaborate in such a way may not actually believe in the value of their product and be driven by a commercial motive – they are best avoided.

Measuring value

HSD describes Business Value in terms of:

 Generating or delivering Business Value is the purpose of a business. Typically, a commercial business will measure Business Value financially however public sector organizations, charities, open source communities and others will measure value differently.

From the work of Mizuno and Akao:

Value is recognized when Business Customers or Product Customers perceive one or more of the following:

  • problem of theirs is solved or minimized
  • An opportunity they desire is seized, maximized or enabled
  • That they “feel good” about themselves
  • That they “look good” to significant others

Value can only be defined from the end customer’s point of view of specific products and specific outcomes.

We call this the “POFL” model as a way of remembering it (Problem, Opportunity, Feel Good, Look Good) and apply it to both commercial and non-commercial organisations.

In commercial terms the opportunity mentioned can be a profit opportunity, but often other aspects of Business Value will be relevant such as reputational impact (both positive and negative).

For non-commercial organizations we recommend looking at the end customer and qualifying their needs in the terms above (POFL). This qualification gives an understanding of the Business Value for each major end-customer or end-stakeholder. If there are many Business Value statements then the business may be fragmented, there may be advantage in greater cohesion or even separation into spin-off businesses.

We recommend incorporating feedback into interactions with end-customers/stakeholders as a primary driver for “creating pull” in the organization and identification of value streams. Creating a top level feedback cycle is one of the best drivers of quality, productivity and success in an organization. This feedback is an excellent way of aligning Strategic Direction with Business Value.

Value must be defined from the customer’s point of view or at least from the holistic business’ point of view when operating in an open market. Organizations that are heavily structured often find that teams, including teams of teams, will describe their customers as other teams in the organization. This undermines understanding of value from the end-customer’s point of view and leads to the normalization of wasteful work. Instead we recommend transparent communication of customer focused business value based on than a holistic assessment using the it using the Problem, Opportunity, Feel Good, Look Good (POFL) model. Misidentification of customers as other teams/departments leads to requirements problems resulting in a significant risk that delivery teams build the wrong products.

Considering value in this way is crucial in the definition of successful products and sometimes requires a realignment of how an organizations  internal departments work. We have seen several dysfunctional instances of organizations producing products where the value is defined by the engineers and delivery teams (or worse proxy Requirements Managers). As a result, when products inevitably don’t meet customers’ needs or product adoption is slow the typical response from the engineers is that the customers did not understand, or were not mature enough, for the product. This is a symptom of value not being consistently understood in an organization. Agile/Iterative and Continuous Flow ways of working are expected to identify this problem early during early deliveries to the Customers, which is why involving the actual Customers, early and often, is critical.

Killer Products

A killer product is any product that is so necessary or desirable that it proves the core value of some larger technology.
Consumers will purchase significantly more expensive platforms specifically to get a killer product that runs on that platform. Killer products are “must have’s” that significantly increase sales of supporting platforms. Many teams and businesses are in search of a “killer app” or product but don’t quite achieve them.
It is evident that “killer products” hit all four of the POFL value dimensions strongly.


Return on Investment (ROI) is based on a simple formula:

 Return on Investment = Business Value – Cost of Implementation

Where business value is qualified in terms of the POFL tests and cost of implementation is the cost of the product (and/or maintenance agreements) as well as the internal Delivery cost of deployment and support (as well as and configuration/customization costs). HSD helps organizations determine cost of implmentation by illuminating all of the work related to a Portfolio Request.

Where business value is not defined financially (e.g. in non-commercial organizations) we end up with a simple “Business Value vs. Cost of Implementation” equation which offers a simple decision to Business Leaders: Is the benefit worth the cost? We recommend that a wide stakeholder group is used to answer that question rather than just the Business Leaders so that decisions have wide support as they are made, rather than trying to gain support afterwards, especially when those decisions relate to tools, environments or COTS selection.