You are currently browsing the tag archive for the ‘ALM’ tag.
ALM (Application Lifecycle Management) means different things to different people, and these views are largely influenced by tool vendors. IBM users may bias their view of ALM to things that the Rational toolset is good at — say requirements traceability and Java-oriented modelling. Microsoft users may see ALM as being about using TFS (Team Foundation Server) — with Visual Studio integrated sprints, tasks and testing tools. Ruby developers may see ALM as being about distributed source control and behaviour driven development — such as using git and cucumber. (I say may because some of these toolsets and frameworks are very broad — more broad than most of their users are aware).
ALM is everything that is supported by those tools and frameworks — and more. Think, without referencing your favourite tools, about the lifecycle on an application. It starts off with an idea, hopefully gets developed and tested, is deployed to production, and supported and maintained for a few years until it is finally retired. Over that period there are a lot of people, processes, deliverables, expenses, plans and other things that need to be organised, utilised, directed, controlled, disposed of — well, managed, really. In that context pretty much everything is ALM.
Business have, over the years, generalised processes, made them more efficient, and developed specialised tools and skills. The application lifecycle that requires those processes would make use of the existing parts of the business. The obvious ones would be things like financial planning and control, human resources, risk and compliance, and project management. It may be contentious, especially with the public cloud, but established businesses have IT processes too — from operations and support, to capacity planning, security, and (enterprise) architecture. This starts narrowing the scope of what is left to deal with in understanding the ALM processes that are needed, as illustrated below:
In addition, certain technology choices limit how you can manage the application lifecycle. I hesitated making this point, as determining the technology can be part of ALM — but ultimately there will be things that are beyond control and processes that need to be included rather than adapted. If you are developing an app to be deployed on iOS, for example, you have little choice but to manage the deployment of (part of) the app according to Apple’s rules. There are also lower level constraints based on the environment and availability of development skills, at least for most projects. An application developed for Windows Azure in a .NET team is going to coded in Visual Studio, C#, and use the .NET Azure SDK — there is not much that you can do about it apart from completely changing the technology choices, which is not always practical. These technology constraints on being able to define ALM processes is illustrated in the diagram below:
When it comes to understanding the need for ALM on the cloud there are two different scenarios — one for established enterprises and one for startups. With enterprises, there may be a lot of processes and technologies that support application management, but they may be totally irrelevant in the cloud. For example, the existing capex-oriented financial modelling is useless when looking at a pay-per-use pricing model. Years of effort and experience on specific technologies, such as running Oracle databases in an on-premise datacentre, is less applicable for cloud applications. The diagram below depicts the reduced overlap between existing process and technology choices and cloud specific ALM processes:
At the other end of the scale are new business ventures that have few existing business processes and little in the way of fixed technology choices. This means that there is a lot of work to do in terms of defining the cloud specific ALM processes. In a lot of software-oriented startups the distinction between business processes and software processes barely exists because everybody is defining, building, supporting and selling the software itself — the software is the business. If it is a cloud-based software startup, virtually everything is about cloud ALM (and it is fine not to call it that). This lack of existing processes is depicted in the diagram below where the overlap of processes and tools are smaller simply because none exist yet:
The reason for failure (or muted success) of cloud applications has been, and will continue to be for the next few years, a lack of skills in designing, building and operating cloud applications. When looking at the problem in more detail, it is not that people are unskilled in general, they just don’t know how to adapt their skills to a new environment. When we looked at this problem last year, we felt that developing cloud specific skills is not about telling people “This is how you develop cloud applications”, but rather “You know how to develop applications, and this is what you need to do differently on the cloud”. The basis for this method of explaining is to assume application development skills and assume that the business already has some ALM processes (whether formal or not) and hooking into those skills and processes.
The result was a book that I wrote and published – “CALM – Cloud Application Lifecycle Management”, which looks at what is different in the cloud from the context of various models. Some of these models deal with upfront processes, such as defining the usage lifecycles (lifecycle model). Some deal with overall processes, such as the cost model. Most deal with fundamental design decisions, such as the availability and data models. There are also models that are important to longer-term success of the application, such as the health and operational models.
CALM is licensed as open source, which also means that it is free to download, read and use. It is available on github at github.com/projectcalm/Azure-EN, with pdf, mobi (Kindle), and raw html available for download on this share. A print version of the book is also available for purchase on Lulu.
CALM forces implementation teams to ask and answer some difficult questions that are important to successful delivery. I encourage you to have a look at CALM, let others know about it, ask any questions, and give me some feedback on how it can be made better.