Integration: ITSM and SDLC

[ChasingSleep]

Hi everyone,

I am thinking about the integration between ITSM concepts of Service Design and Service Transition, and SDLC (Software Development Lifecycle).

In my opinion, Service Design is what SDLC calls the Architecture Phase. We don't actually develop the application here. What we do is the architecture of the new application. It is the work of System Architects and System Analysts. It is not the work of code developers.

Service Transition is actually the Application Development, Testing and Deployment in SDLC terms. This is where java/.net/etc developers come into action. The application is developed according to Design (Architecture) Principles, what in ITIL terms is the SDP (Service Design Package).

In my opinion, integrating Devs with Ops is key to ITSM success. We can't talk about IT Services if we only talk to Ops. So the first step is to clearly map SDLC phases to ITSM phases.

There are many others steps, but let's keep it simple for the moment.

I would like to hear from you guys about this mapping between ITSM and SDLC. Is my understanding correct?

Cheers!

[Diarmid]

I'm not sure I understand. But that might be because I have little knowledge of SDLC. So the following thoughts may be naive - or just plain rubbish. But I do agree that if you have in-house development and operations then a single management system is a very good way to give yourself a chance of success.

SDLC seems to overlap with ITIL and that is presumably your issue. However I would guess it takes a simplified view of the service delivery aspect and therefore cannot adequately serve as a substitute, or at least not easily. And certainly ITIL has little useful to say about the development process (quite rightly).

I always find it easier in service management terms to to ignore application development to a similar extent that I ignore server manufacture and factory build. If you do that then service transition does not encompass application development but rather application specification and acquisition. Similar service management is not directly concerned with functional testing, but rather with operational testing - more how it behaves in the live environment than what it delivers to the users and customer.

This last is a tricky area because one can conceive of a spectrum where, at one end, service management makes all the promises of functionality as well as performance and availability etc. and therefore acts as a conduit from the customer back to development for all things, always controlling the specification in detail; and at the other end the development service (especially when in-house) negotiates all the functionality with the customer, perhaps even agreeing the service parameters (in which case service management will be a supplier to development rather than to the customer/user of the system.

It is probably a good idea to establish just where on that spectrum your organization is, or would like to be as a preliminary to integrating the management model. I've worked in places where Ops and Dev have both thought the implicit working model put them in charge.

If you start from this then you should begin to see just what aspects require integration and what more simply require interfaces. In the end it might be more fruitful to analyse what you do and how you do it than to look for a theoretical fit between the two frameworks

I doubt if there is a single useful one anyway. On the one hand, how would it encompass in-house development, bespoke and tailored third party apps and off the shelf apps; and on the other hand how would it cover in-house service infrastructure, out-sourced service infrastructure and cloud- type service delivery? And that is before looking at the wide ranging degree to which an organization can choose to manage interfaces with third party suppliers (from a delivery specification and monitoring outcomes, to hands on tweaking of what and how the third party does things all day long.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[ChasingSleep]

Hi Diarmid,

First of all, thank you very much for your reply.

I could say that for me this is a fundamental issue for ITSM. See, I am not talking about ITIL. I am talking about managing IT services. And in order to do that we must consider how we design them, how we develop them, how we implement them, how we support them, and finally how we get rid of them

In a typical IT internal shop, IT services are in fact applications that support the business. All the rest exist in order to support these applications (which are the IT services in ITSM terms).

So, I can't see how we can talk about managing IT services if we simply ignore how they are conceived and developed. ITSM for me is not ITIL. Or at least is not ONLY ITIL. It is ITIL, SDLC, COBIT, etc. We use all these good practices to build our management system.

I've seen many and many times Dev guys saying that "we have nothing to do with this ITIL crap". But when you start talking to them about service design and service transition they identify themselves. They understand it because that's what they do!

So, to get back to the point of my original post.

A typical SDLC: Analysis -­ Design - Implementation - Testing - Evaluation - Deployment
ITIL Service Lifecycle: Strategy - Design - Transition - Operation - CSI

Let's concentrate on ITIL Design and Transition.

SDLC's Design is where we describe software features based on requirements. This is where the four basic elements of what ITIL calls warranty are considered: availability, continuity, security and capacity

This is exactly ITIL's Design!

SDLC's Testing/Evaluation/Deployment are all in ITIL's Transition volume.

And SDLC's Implementation? Well, this is code development in dev terms. For me, this is what ITIL calls "building a service". If this is the true, then it is part of ITIL's Transition.

I know this sounds a little too much theory. But I am just trying to validate a map between Dev practices and Ops practices. Once we agree on this map, then we can start talking about merging them! Or at least integrating them!

Because if we do not, then it is not Service Management. It is Ops Management. And then ITIL will have lost its whole point!

Cheers!

[ChasingSleep]

To come back to the discussion :

I am now particularly sure that application development is part of Service Design.

Service Design also takes care of tests within development phase.

Service Transition takes care of "integration", "acceptance", "go live" tests and of course deployment.

Just my 2 cents.

Cheers !