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. 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.
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.
With the service perspective, we want to understand what it will take to deliver the service. This means understanding the impacts of requirements on the IT infrastructure, staffing, vendors, support capabilities, security, networking and so on.

Service Architecture: In terms of architecture, to optimize a service means there must be recognition that a system of inter-connected components are being assembled to deliver the services needed by the business. Service architects need to plan how all the various configuration items (CI) connect together. Dependencies need to be identified and any issues identified and dealt with.

All too often only the application requirements are the focus; at the expense of the overall organization. Selecting an open source tool that causes the project to be within budget, but results in far higher support costs and unacceptable total costs because it is non-standard, is one common example.

Service Testing: The development of test plans also highlights the need for a services mindset. In order to understand how a service will perform in production requires testing in a manner that reflects how the service will be delivered. Performing unit testing in a vacuum excluding the balance of the service’s CIs introduces risks that the production service will not perform as planned.

There are recognized testing regimens such as integration, load and operational testing that can help test the overall service provided the test service adequately mirrors the production service. Differences in database sizes, network speeds, levels of integration, network security systems and so on can cause there to be different behaviors in the test environment vs. production.

For some organizations it is financially impossible to have a test environment that mirrors production. The intent is to come up with procedures that reduce the risks of introducing a deficient service into production to a tolerable level.

In closing, IT doesn’t simply deliver applications or systems for the use of the business. Organizations need to evolve their development life cycle from a software-only approach to one that recognizes that overall services need to be architected, built, tested and implemented accordingly to optimize results.