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 life cycle (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 and so on.
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 life cycle, 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. |
Key Terms To
Understanding SDLC:
Related Articles
on Internet.com:
|
To define a service we must understand the hardware, software, people,
documentation, facilities and their relationships. This is an important
perspective as it's 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 and so on. 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's 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.
Key Aspects of An SDLC
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;s 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's
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 lifecycle from a
software-only approach to one that recognizes that overall services need to be
architected, built, tested and implemented accordingly to optimize results.
|
DID YOU KNOW...
"It is 100 Times More Expensive to Fix Security Bug at
Production Than Design" — IBM Systems Sciences Institute
|
George Spafford is a principal consultant with Pepperweed Consulting and a
long-time IT professional. George's professional focus is on compliance,
security, management and overall process improvement.
Article
courtesy of ITSMWatch.com.
Last updated: February 08, 2008
ITSM Watch
Insight on IT Service management.
What is SDLC?
A Word Definition From the Webopedia Computer Dictionary. This page describes
the term SDLC and lists other pages on the Web where you can find additional
information.
Security in All Phases
of the Software Development Lifecycle
When it comes to secure coding, today's typical software development
lifecycle (SDLC) is setting developers up for failure. |
