From Software to System to ServiceApplication development cannot take place in a vacuum of software and hardware, writes ITSM Watch columnist George Spafford of Pepperweed Consulting.
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.
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 isnt configured correctly, capacity hasnt 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.
Lets 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.