The IT process of Accept Demand is core to the Application Service Lifecycle. The demand for new functionality may arise with particular urgency from business partners recognizing a new revenue opportunity, or responding to environmental forces. The ability to quickly capture, assess, and prioritize dynamic demand is essential as the speed of business accelerates, as is the ability to understand what is truly essential for business value in a new service and how to deliver this in smaller, more iterative chunks.
Demand management should track the ordered and delivered IT service through what can be called the “inspire to retire” lifecycle of IT solutions/services. Silos are often seen between
- Governance, architecture, planning and authorization,
- systems development and integration, and
- systems operation functions.
Novel applications may impose net new demand on the infrastructure service lifecycle, but that is only part of the equation. Existing services may see gradual increase or sudden spikes in demand, which do not affect the application lifecycle per se (no software need be rewritten), but do impose new demands for infrastructure. Demand management is essentially equivalent to the concept of Capacity management when considered for the infrastructure lifecycle.
The IT operations area in too many organizations does not have visibility into “what’s coming,” and the result is sub-optimized from an operations point of view.
Dialog: Advance notice
Pat: Why would you need this?
Kelly: Have you ever heard of “over the wall”?
Pat: Yes, our data center and applications support people are always mumbling this.
Pat: Right – because they don’t have enough warning that a new system is coming, and aren’t able to influence its development sufficiently to meet their needs: application architectures that are compatible with data center operations, re-use of existing platforms and skills, instrumentation for availability, support documentation and procedures, and all the rest.
Most of this gets sorted out sooner or later, but it seems like we’re always painfully re-inventing the wheel here, and when you dig into the root cause the fundamental issue always seems to be one of visibility.
Sometimes, demands for increasing infrastructure service capacity can be met in house. Other times, they require the acquisition of new physical assets. A key concern is how backup capacity, also known as “white space,” is managed and in particular funded – a common topic in discussions of IT Financial Management. Such capacity can be construed as a buffer and therefore waste from a Lean perspective, but IT service demand spikes can be instantaneous and insufficient capacity installed and ready “on the wire” can lead directly to service degradation and even loss of revenue.
The Asset Lifecycle may also drive demand, if a large contingent of assets is approaching a refresh date, that effort itself may be handled as a project. The impacts on Applications need to be considered but the effort is not driven by functional Application needs.
Technology products – reproducible combinations of hardware and/or software, not yet acquired or pressed into service – are also subject to demand. Demand for increased processing power translates into demand for new kinds of infrastructure capabilities. Demand for ongoing platform services translates into demand for current, well supported versions of key infrastructure technologies (OS, data management, middleware).
New forms of security hazards translate into demand for new technical solutions. And new application services may require new technical products developed and marketed by specialist firms. All of this demand translates into value engineering kinds of activities, as the technical requirements are translated into functions and candidate solutions assessed for best fit at lowest cost.
The Technology Product Lifecycle may also drive demand; product obsolescence (e.g. due to a new version) is a frequent demand driver, as noted elsewhere.
