'Lean IT': another buzzphrase for something we've been trying to do all along?

Customer in a restaurant: Waiter, bring me a steak, and make it lean.

Waiter: Okay, sir. Which way?

As reported in my last post, Sandy Kemsley has done a great job of covering Forrester's Business Technology Forum, which focused on Lean IT.

But which way is IT supposed to lean?  Alas, it seems Forrester is helping to heap another buzzphrase on the world that seems to describe things that have already been in motion for years. (Some say this is the case with service oriented architecture as well, by the way.)

What, exactly, is 'Lean IT'? Wikipedia's definition of Lean IT is vague and convoluted:

"Lean IT is the extension of lean principles to the development and management of information technology (IT) products and services. Its central concern, applied in the context of IT, is the elimination of waste, where waste is work that adds no value to a product or service."

Yeah, so? Again, haven't organizations been battling waste in IT since day one?

I don't know who coined the phrase "Lean IT," but it takes a page from "Lean Manufacturing," which tightened up that sector in the 1980s and 1990s to survive the onslaught from more efficient and quality-driven overseas competition. Noah B. Kindler, Vasantha Krishnakanthan, and Ranjit Tinaikar of McKinsey & Company discussed the concept back in May 2007, claiming that application development and maintenance (ADM)  productivity can be boosted up to 40% by eliminating waste from routine processes. "Application development and maintenance is a prime candidate for lean methods not only because it involves a great many processes with the potential to be optimized but also because large differences in productivity among organizations suggest that some are far less efficient than others," they said. As they put it:

"Each category of waste in manufacturing has a counterpart in ADM, which can be thought of as a kind of factory that develops new applications according to business requirements. Changes to an application’s requirements are one common source of ADM waste, causing many of the classic varieties identified in lean: designers rework their specifications, coders wait for specifications to stabilize, testers overproduce as their testing environments have to be set up repeatedly, unmet requirements pile up in a large backlog. As in manufacturing, systematically eliminating these sources of waste improves the delivery time, quality, and efficiency of the ADM end product."

So they equate IT operations with a manufacturing process. Which makes sense, and is something we've discussed in this blogsite before (here, here, and here). By introducing assembly-line processes and greater automation to software development, we can definitely tighten up the process.

In past posts, I quoted IBM's Dr. Irving Wladawsky-Berger and Microsoft's Jack Greenfield, both who said we were at the dawn of a new era of IT -- "industrialization.” Wladawsky-Berger said that IT-delivered services are starting to become more componentized, standardized, and mass-consumable across the spectrum, just as manufactured goods were a century ago. Greenfield talked about the concept of the "software factory," defined as "a development environment configured to support the rapid development of a specific type of application. While software factories are really just the logical next step in the continuing evolution of software development methods and practices... introducing patterns of industrialization."

He said, however, that “our IT infrastructures are nowhere near ready to handle this explosive growth of information and service.  Much of IT, - including applications, data centers, systems management, and so on, - is way too ad-hoc and custom designed, sort of like manufacturing was decades ago…."

So, is Lean IT the right thing at the right time to seize upon this impending industrial revolution of IT services? The McKinsey authors identify the following areas for "waste reduction" in software assembly: flow processing to reduce overcapacity or excess inventory; release schedules to help prioritize projects; staff and supplier workload balancing; greater standardization; segmentation of projects by complexity to route projects to the proper resources; and  and by avoiding unnecessary overhead for simple tasks; and quality ownership that extends to all groups involved in software production -- not just QA.

These are are well and good goals, and I'm sure every organization can benefit greatly by applying these principles to their IT operations. But is there anyone who hasn't been already trying to move these efforts forward? What does Lean IT bring to the table? Consider everything that has been underway in recent years:

• Service oriented architecture: Formerly siloed applications are decomposed into reusable services that are made available across enterprises.
• Agile development: Developers work side by side in an iterative way with business users throughout the process.
• Virtualization: Physical IT systems and resources are abstracted into a software-based enterprise service layer.
• IT automation: Routine IT processes formerly handled manually are handled on a systematic basis by the software and machines themselves.
• Cloud computing/outsourcing: Non-critical IT tasks and applications are acquired from more specialized providers, mainly on a pay-per-use or contractual basis.
• Business process management: Business workloads are decomposed and automated.
• ITIL: Best practices and principles for IT services applied uniformly across organizations.

References I've been seeing to Lean IT seem quite provincial -- optimizing IT processes at the ground level without bringing in the larger picture -- the transformation of the business. Lean IT lacks the expansive thinking that Wladawsky-Berger and Greenfield have in mind for the coming industrial revolution in IT services.

And, again, it begs the question: what does Lean IT offer that we haven't been trying to do already?