Friday, 29 August 2008

ALM or SLM?

I have a question about ALM ... The 'A' obviously stands for 'Application' a term we used in the past to refer to a blob of software residing on a single computer.

These days 'application' is more like a logical concept. Modern composite 'applications' are made up of many different components, some of them may not even reside inside your organisation. Is the workflow engine part of an apps, is the .NET library part of it, what about a data feed?

I don't know the answer but it has implications when we talk about Application Lifecycle Management (ALM). How can we talk about ALM when we can't even define application boundaries?

We have been discussing this internally and the term 'Service Lifecycle Management' came up a few times... and I have to say I like it! 'Service' might be a better description of what a modern application is really about.. what do you think?

I added a poll (on the left) titled SLM or ALM (Service Lifecycle Management) ? Let me know what you think is a better term...

1 comment:

Jerry said...

Great topic! I firmly believe that the future as it relates to the business is what you define as SLM. To me it is really a subset of ALM which encompasses both the software creation and the production operations/delivery of software in the Software as a Service model.

I have started a new blog on the topic: http://www.absolute-performance.com/blog

The focus of this blog is the process the ensure business satisfactory delivery of software applications in the SaaS model. It does not address the core development stage elements of ALM but focuses on the production deployment and ongoing operations of software applications (SaaS or traditional enterprise deployed). The for key tenants can be summarized as:

* Business Requirements development (application and operational)

Define application delivery requirements and use those to drive the technical requirements for the application and it’s delivery to your customers. The ongoing management/delivery of the application should be measured against those requirements in near real time. These are your KPIs or SLAs for production operations.

* Application Development (with an eye toward operational requirements)

Develop your application using modern software development practices but add pre-production and iterative pre-release stress testing to identify performance bottlenecks in end user experience coupled to the underlying technology and fix the issues before you release to your customers. Adopt a “measure everything possible” approach that can follow the application into production. Application internals instrumentation should become part of the application release process.

* Performance and Capacity Planning (support operational requirements)

Ongoing performance and capacity planning are crucial as you gain success with your application. It costs too much to get customers to loose them when you start generating the traffic and revenue volumes you were hoping for.

* Ongoing Production Support

Use the instrumentation from the development phase to continuously enhance your ability to proactively deliver the application with the highest quality possible. Feedback from the production management team to development is critical. Enhancements to application monitoring happen here which are often not passed back to the development teams — make sure that is not allowed to happen.

You can learn more about my thoughts at:

http://www.absolute-performance.com/productsandservices/application-lifecycle-support

or

http://www.absolute-performance.com/blog