The first of three (1 of 3) types used to Organize Enterprise Solutions is Products. Product is a general term for any Business Application. In other words, it applies to any IT Solution which supports or enables one or more Business Processes.
For information on the two other types, look to Systems and Services.
Indeed, there are many similarities between all Solutions. However, it is their differences which drive the need for multiple Solution Types. Later ITM sections discuss such differences. For now, understand that one key difference is that each type has its own Solution Delivery approach. That is, not all Solutions need to follow all ITM steps. Some types are much less complex than others.
Product Overview
Product Description
Without a doubt, Products are the most complex Solution Type. Generally, the reason for this is that their major purpose is to support business processes and operations. As a result, the complexities inherent in those often drive complexity for the underlying Product. Of course, the less complex the process and operations can be made, the less complex the underlying Solution can be. In short, more people → more problems.
In-house personnel, or contracted 3rd parties (as distinct from an outsourced SaaS provider) manage Products. Moreover, a primary differentiator between Business Applications and other Solution Types is the opportunity and frequency to introduce change. For instance, consider the implementation of an ERP or CRM solution. If plans are to permit ongoing or frequent change to support specific business operations, then the Solution is likely a Product.
Typically, within the ITM, Products have the following characteristics:
- A unique name.
- A defined, or identifiable, Feature set.
- A defined delivery approach.
- A list of one or more supported Business Processes; and
- Accompanying Operating Procedures.
Product Delivery Approach
Any Solution which is a Product requires both Solution Definition and Solution Delivery. In general, the amount of work and change involved drives the need for each. Accordingly, such efforts require appropriate implementation tools and processes.
Some of the major stages within the Product delivery approach include:
- First, Business Process Definition captures and conveys the desired, future-state of: business operations; action sequences; organizational ownership and responsibilities; rules or policies to support; and business requirements.
- Second, Iterative Product Planning covers plans for short, medium and long-term change over the periods of weeks, months, and quarters.
- Third, Analysis & Design defines and captures what functionality the business wants as well as how that functionality will be provided. Analysis & Design makes Features and Stories "Ready" for subsequent development.
- Fourth, Build, Test & Deploy develops and tests the changes conveyed by Features and Stories. This encompasses the tasks which take Features and Stories from "Ready" to "Done".
- Fifth, because of the complexity of the changes made, because change is ongoing during Build, Test & Deploy, and because Business Applications so often must integrate with other Products and/or Systems, there is usually a need for Candidate Validation. This QA level of testing validates, or certifies, a candidate set of changes after reaching a steady state and before deploying those changes for use in Production. This delivery stage is unique to Products.
- Finally, Production Operation enables the ongoing use, maintenance, and operation of the Production version of the Solution.
Product Definition
Each Product has high-level definition which consists of a Vision and a set of Epics.
To begin, a Vision describes a desired future-state. It consists of:
- A statement of the Product's objective; what should it accomplish.
- A description of intended Customers; who will use it.
- A list of their Needs; what will it address.
- A list of the Solution's components; what it consists of; and finally,
- A list of Goals; what the Product intends to achieve.
Afterwards, the Epic(s) describe the broad set(s) of functionality which the Product supports.
Typically, at the onset of Iterative Transformation there is some set of existing Business Applications (i.e., the legacy Products already use). At that time, those existing Products are likely undefined. In this case, consider creating a high-level definition, as described here, for each.
Regardless, the ITM's Portfolio Management processes introduce new Products. Specifically, these tasks either align new, large-scale business needs to existing Solutions & Epics, and/or drive the identification of new Solutions & Epics. Accordingly, all Solution types begin with tasks which lead to their definition, as well as proper transition on to delivery. Whether dealing with a single Product, a limited set of Products, or an entire Solution Portfolio, these tasks apply. Even if your organization does not consider "Portfolio Management" a thing.
After that, use each new Phase of a Product's lifecycle as an opportunity to update its Vision and Epic(s). However, during a Phase, a Product's definition should remain relatively unchanged.
Product Analysis & Design
Because of their nature in supporting Business Process(es), Business Applications require an Analysis & Design stage of work prior to the actual build of the desired functionality.
Certainly, it is possible to begin the initial levels of Process Definition even before a supporting application is known. Defining scope and operational objectives, these levels should be application agnostic. In fact, such definitions are important inputs to making an application, or software, selection.
Later, after selecting a supporting application, it's time to complete the lowest levels of Process Definition. At this point, the Definitions align desired operations to application functionality. Indeed, this activity is part of Solution Definition, which occurs in a non-iterative fashion, prior to the Analysis & Design associated with iterative delivery.
Feature Planning & Story Analysis
After defining the relevant Business Process, the task of breaking them down into individual Features begins. Solution management prioritizes Features for delivery. After that, Teams work from highest to lowest priority to refine, or groom, each Feature. Accordingly, they gather business requirements and design desired functionality. In effect, these are the actions which make a Feature "Ready" for delivery.
Note there is no need to refine all Features for the Business Application at this time. In fact, the ITM requires only a number sufficient to get iterative delivery activities underway. Thereafter, Teams make further Features "Ready" on an ongoing basis as Solution Delivery continues.
Correspondingly, again based on Feature priority, Teams similarly refine, or groom, Stories to describe how they will implement individual Features. In this case, they capture detailed requirements and produce the equivalent of functional and technical specifications. Generally, these are the actions which make a Story "Ready" for development.
Again, there is no need to refine all Stories at this time; only a number sufficient to get development activities underway. The Team will continue to make further Stories "Ready" on an ongoing basis as Solution Delivery continues.
Product Build, Test & Deploy
As with all Solution Types, Build, Test & Deploy activities take Features and Stories from their state of being "Ready" for development, through their creation or update, corresponding testing of changes made, and deployment of changes to various environments. As a result, when successfully complete, the Features and Stories progress from "Ready" to "Done".
Of course, a Business Application's build activities typically involve configuration and/or coding related to the Product's components. Accordingly, those changes are subject to several types of testing to verify the veracity of changes made. Ideally, a small, discrete number of changes and tests occur over a short period of time, then this cycle repeats. During each cycle, or iteration, the objective is to complete some number of Stories.
In time, after a set number of small cycles, a longer cycle concludes. Like completing Stories in the small cycle, this middle cycle seeks to complete some number of Features. Basically, a Feature becomes "Done" once all its related Stories are "Done".  As both the middle and small cycles repeat, there are opportunities to adjust short- and medium-term plans at each iteration. Moreover, each iteration allows participants to evaluate productivity, identify opportunities for improvement, and to adopt those improvements as soon as possible.
Story Build & Feature Release
Undoubtedly, while these build cycles are underway a lot of change is taking place. Accordingly, while much testing occurs in parallel with the build, it is done with the understanding that the Product never achieves a steady state while the cycles are in progress. In other words, last minute changes may affect some completed testing.
Sooner or later, at the end of the longer cycle, a new steady-state version of the Business Application becomes available. Indeed, the intent is to deploy this version into Production. However, before doing so, it is advisable to apply additional, incremental testing to verify the release candidate. Additionally, it is helpful to provide a few users with early access to the new functionality before it becomes available to all.
This verification, or certification, cycle serves two purposes. First, it is a test run to introduce many changes to Production. Second, it offers a chance to prevent potentially serious problems within both the Product and/or related Products and Systems.
Both the small and larger cycles repeat until one of three things occurs. First, the completion of desired changes. Second, the end of funding for further change. Third, a new Phase begins.
Next, look to the description of how Products, and all Solutions, break down into manageable objects.