aliando agile IT service management, agile ITSM, Dana Stoll, agiles IT service management
aliando methods for agile IT service management, agile ITSM, Dana Stoll, agiles IT service management
aliando agile IT service management, agile ITSM, Dana Stoll, agiles IT service management
aliando methods for agile IT service management, agile ITSM, Dana Stoll, agiles IT service management
aliando methods for agile IT service management, agile ITSM, Dana Stoll, agiles IT service management

Cloud Computing Resolves Conflicts Between Agile Development and IT Service Management!

When interfacing agile development to IT Service Management there is The Threshold, which any service will have to pass when it travels from rapid cycle development stages to best practice driven high quality delivery.

The reason, why best practice IT Service Management slows down RAD practice, is linked to control: IT claims control over certain components and processes, for reasons of delivery or process quality. This claim of control consequently locks developers out from interfering with online services or deployment procedures independently. This lockout is responsible for RAD slowdown.

Why do control conflicts slow things down?

Whenever two enactors control the same the same components within a service lifecycle, a conflict arises, which will require communication to be settled. This communication span can be lengthy and thus introduces delays. Control is shown with blue dashed lines in the above UML (click to magnify). Conflicts are indicated with red circles. Possible controls are:

  • Product Owners control access to users by announcing only welcome parts of a service to the customer. This is possible because users access any service via addresses or locators, which have been advertised to users by marketing, thus forming a single point of control towards the user.
  • Developers may control live application components, which directly interact with users. This is usually forbidden to resolve conflicts.
  • Developers may control replica of application components.
  • Developers may control live and development servers, which is usually forbidden to resolve conflicts.
  • Administrators may control live applications components, live servers as well as development servers.

So there are two conflicts which can cause slowdowns, and they are typically a big issue of discussion:

  • Application developers conflict with Product Owners in controlling components which users access. This is usually due to developers being able to do configuration changes within the running life application after deployment (which is often called customizing).
  • Application developers conflict with Administrators in controlling live components, live servers as well as development servers.

What does Cloud Computing have to do with this?

During an interesting chat with Thomas Uhl at the Information Desire barbecue we came to the conclusion, that developing in the cloud resolves this conflict, as far as application development is concerned. Therefore, the cloud will most likely advance to conquer the left hand side of Cynefin’s quadrants as a development and hosting platform.

Given that “the Cloud” works:

Developing components in and deploying components to the cloud reduces the interface between developers and administrators to the Cloud API. This API may not easily create conflicts.

Within the cloud, live resources have completed their transition to be mass products. Developing in the cloud thus has a couple of side effects:

  • Any component can be forked off for development at anytime to any place within the cloud by simple request, reducing change effort for development environments to a minimum.
  • Any component which has completed development can be upgraded to higher quality environment at any time.
  • Any component may be deployed to a user-accessible suite by pointing the suite to use this component. This form of deployment does not require administrator interaction, thus is independent form IT Service Management.

The domain of IT Service Management thus ends at the Cloud API, effectively confining them back to the cellars, from an application development perspective.

What would be the prerequisites?

For this to happen, the Clouds must fulfill a range of requirements:

  • The cloud API must be a common, open standard, to achieve a level of usability, where application developing organisations will not opt to “host on their own just because the cloud may lack certain, important functionality”. Different vendors may offer rich or lean implementations of this API, at different prices.
  • The contents for any component must be clonable within the same or to any other cloud which supports the same API
  • Additional cloud space must be readily available from multiple resources.
  • Customer data within the cloud must be encrypted to protect them from cloud developer or cloud administrator interaction

Isn’t this only shifting the problem?

In a way yes. Since there is an egg-hen-problem, we somewhere have to define an egg. If the egg is the computation environment which executes the cloud, the hen would be the bunch of developers who are developping the services implementing the Cloud API. Or rather: Our IT Service Organisation is just offering one Service or Service Portfolio called “Cloud”. If the Cloud itself is under RAD, the same procedures as described in aliando will have to be applied.

On the other hand, there are also availability and capacity issues which the application developing organisation will have to deal with. These are usually IT Service Management issues. However at the transition towards the cloud there may be standardised measurements and reports. So availability management can build on readily available performance figures and just deal with evaluating the combination thereof. These figures are much easier to standardize, normalize and bench mark in terms of resource consumption than current, proprietary interfaces to hardware environments.

Will there be other changes regarding agile practice when shifting to the Cloud?

Infrastructure being readily available, which cloud environments provide, converts problems of constructional viability to financial options. This changes the role of product management respectively product owners. At the same time as administrators can no longer claim quality for control, developers can no longer claim architecture for infrastructure expertise. This makes product managers more independent. But I’m still pondering the conclusions we should draw from this with Andreas. I’ll follow up as soon as we have substantial ideas to discuss.

This also means, we will have to pick and define a subset of IT Service Management techniques which are applicable to operate any given application within a cloud environment, which already guarantees us some which we do no longer have to care about.

Bottom line?

This separation would really lift application development to a new level of information science which completes the abstraction from application logic to hardware on a service unit scale. So I assume this is going to happen and strongly encourage rapid application development to shift to Cloud Computing approaches whereever possible. Even if that means a lot of IT Service Personnel will probably feel themselves rather “interfaced” or beyond The Threshold. Then again, they most definitely will operate The Matrix.