From Software to System to Service

There is a traditional animosity between development and operations teams. Part of it stems from systems being developed and then handed off to operations to put into production with minimal coordination. For programmers, the software development lifecycle (SDLC) spells out the organization’s standards surrounding the creation and maintenance of applications.

The system development lifecycle took the application creation concept a step further to include the combination of software and hardware. The typical system development lifecycle covers matters such as requirements definition, development practices, testing, deployment, etc.

While all of these are good, the problem is they follow the traditional hardware and software orientation. Instead, we need to think about IT Service Management (ITSM) and the services we are provisioning to the business. Instead of a system development lifecycle, we need to be focusing on the service development lifecycle.

The IT Infrastructure Library (ITIL) presents us with a framework for meeting the needs of the business through ITSM. The idea is IT needs to provide services that meet the needs of the business. One of the core concepts is this notion of services. In ITIL, a service has a far broader context than the traditional view of a system being a collection of hardware and software.

To define a service we must understand the hardware, software, people, documentation, facilities and their relationships. This is a very important perspective as it is truly not just an application, or software, that goes into production but an array of resources tied together to meet the needs of the business.

In alignment with this mindset we need to ensure the traditional SDLC is expanded to understand what is needed to develop the service and not just the software or system. After all, far more of the IT world comes into play to provision a service so the development and testing should reflect this.

A Broader View

The idea is to shift to a more holistic perspective that better ensures the needs of the business are met. Not just during development, but throughout the service's operational life as well.

Failure to develop services results in all kinds of problems when services are pushed into production. Network gear isn’t configured correctly, capacity hasn’t been adequately planned, security systems block access, etc. Problems such as these could be avoided by recognizing what will constitute the new or changed service, involving the right teams, planning accordingly and then working together.

IT operations groups have the ITIL Release Management process as a reference to help identify what is needed in terms of project management to plan and introduce a given release into production.

The organization specific release management policies and procedures set forth need to dovetail with the SDLC, project management and change management in that they need to support one another in this context. In a sense, release management is the bridge between development and operations and both the SDLC and project management help to ensure the quality of services entering production.

3 Keys

Let’s now look at three key aspects of an SDLC to highlight the services mindset: requirements definition, architecture and testing.

Service Requirements Definition: To understand and meet the needs of the business requires relevant stakeholders to be involved including security, compliance and IT operations.

The intent is to understand all requirements up front not only so appropriate management decisions can be made regarding costs and benefits but also because it is far cheaper to build requirements in from the outset than trying to add them later. These groups need to not just provide requirements but also evaluate the impacts of requirements.