Once again, EMA finds itself in a situation where how we cover critical “hot topics” becomes an exercise in acronymic disarray. In this case the culprits are Application Lifecycle Management (ALM), Service Lifecycle Management (the other SLM) and the now notorious “DevOps”. The three weave a stream of sometimes complementary, sometimes conflicting insights into what is primarily a schizophrenic situation for IT organizations.
On the one hand, they are being asked to behave with extreme efficiencies, told that they are becoming “commodities”, and asked rather insistently to cut costs.
On the other hand their services are redefining business models and impacting both business processes and business consumers in often radically transformative ways.
And finally, they are told that if they can't show value, given the shopping mall of cloud services, they may quickly find themselves extinct.
Given this Gordian knot of implications, a CIO may quickly come to wonder what form of medication is most appropriate before even trying to come up with the right action plan.
One way out of this dilemma is to approach the ALM, SLM, DevOps conundrum with the realization that giving equal weight to “commodity” versus “transformer” is a recipe for failure in itself. IT organizations will pretty quickly have to decide which they natively are and I believe that there are plenty of examples of both. However, I also believe that there are many IT organizations lost in the “commodity” hype that are fundamentally transformative but don’t fully appreciate the fact - and certainly don’t know how to measure it, optimize it and communicate it with their business constituencies.
One way to start on the path to clarity and value is to begin with the premise that every IT service consumed internally or externally is a “product”. And that, quite naturally, not all “products” are equal. Moreover, in the world of IT many service products are developed elsewhere, or else are shells of reusable components — as in SOA – making their lifecycle management all the more chaotic and at times ungovernable (much as if the general public had access to automotive manufacturing lines and could walk off with steering wheels, chassis and radios at will).
But where all these “service products” come together is with their consumers who in fact depend on a “portfolio” of services – mostly applications – unique to their roles, skills, and personalities. First recognizing and then acting upon this as a prime source of governance is what I've been calling the “humanization of IT.” From a Service Lifecycle Management perspective, this means better instrumentation for consumer priorities, usage patterns, and business outcomes for superior portfolio planning. And it also means more and better dialog.
It's interesting to note some of what ITIL has to say about this process in what it calls Business Service Management: “Business Service Management (BSM) is a strategy and an approach to enable IT components to be linked to the goals of the business. This way the impact of technology on the business and how business change may impact technology can both be predicted.”
For ITIL, BSM enables an organization to:
- Align IT service provisioning with business goals and objectives
- Prioritize all IT activities on business impact and urgency, ensuring critical business processes and services receive the most attention
- Increase business productivity and profitability through the increased efficiency and effectiveness of IT
- Support the requirements for corporate governance
- Create competitive advantage
- Improve service quality, customer satisfaction and end user perception
- Ensure regulatory and legislative compliance
- Ensure appropriate levels of protection for all IT and information assets
- Ensure that IT services are aligned and continue to be aligned with changing business needs
This is actually quite an impressive and useful list — but also, as ITIL itself admits, merely a departure point. Or in other words, easier said than done when the fundamental data points, cultural reference points, and even a common language are generally absent between IT and the business it serves. The result is that both continue to interact with superstitious caricatures getting in the way of sharing ideas, priorities and values.
Where to Begin
So “Product” Lifecycle Management has to begin with better dialog and better information — and this needs to be a top priority, even if it isn't easy. This is, in fact, not fundamentally different than classic Product Lifecycle Management (PLM) processes as understood by the enterprise.
User Experience Management is a categorical imperative here (apologies to Kant) as it provides a bi-directional mirror looking backward at the efficiencies and responsiveness of application services, while also looking outward at the consumer and his or her behavior, usage patterns, success rates, business impacts and business outcomes. This is, I would argue, not only relevant data, but outside of cost, the ONLY truly relevant data for portfolio planning, which should be once and for all liberated from “project management” where it has been held hostage for years.
OK, so then what are the next steps? How do ALM, Service Lifecycle Management and “DevOps” actually play out?
Here’s a quick sketch as we see it at EMA at least:
- Application Lifecycle Management includes Development, Q/A Test and Production as primarily a technical cycle – which needs to be informed by a deeper set of values achieved from business/consumer-awareness.
- DevOps plays to much of this as a way of accelerating and mitigating the risks involved in application roll out/delivery and allowing more fluid adoption of new releases.
- Service Lifecycle Management should bridge technical with business requirements, with clear definitions for cost and value via SLAs linked to user behavior and business outcomes, and well-defined service catalog expressions of the above so that service consumers can make informed choices — whether the services are delivered internally from IT, or delivered via external cloud providers (factors which should ideally be consumer transparent). Finally, service lifecycles require ongoing monitoring, analysis and dialog to support continuous service improvement in application design, service delivery efficiencies, and service portfolio content.
It's interesting that so much current attention is given to DevOps — which is largely a subset of ALM – and hardly the whole picture. While it is an area of real innovation, it can also be a “bright and shiny” distraction just like other buzzwords — including Big Data and even Cloud itself.
I doubt that “Product Lifecycle Management for IT” will ever hit the buzzword big time – but I would argue that in many respects it deserves your attention more than any of the current rock star acronyms. This is because once you begin to think of “product” you rather naturally begin to think of “consumer” — and once you do this, you may just be on the road to IT organizational recovery.