Lean or Agile Enterprises and Architecture

A Lean Enterprise is very different from an Agile Enterprise as witnessed by the following definitions.

• Leanness is an organization's ability to create its products cost efficiently and still meets its customers' requirements.

• Agility is an organization's ability to respond effectively (quickly and successfully) to unexpected challenges and opportunities.

An example of a "lean" professional football team would be one where the coach decides to specialize in one play, say the off tackle play.  With this decision made, the coach could then hire best, toughest, and largest interior linemen in the league, with the biggest, fastest, and toughest full back.  He could then hire walk-ons for the rest of the team, minimizing the salary costs.  He then will practice the off tackle play until everyone knows the play so that they could run it in the dark or blindfolded.  With the best players in the league (for that play) executing it perfectly every time, "three to four yards and a cloud of dust", the team will be unstoppable--for a time.  However, when another team stops them, they have a major problem; they don't have another play to execute and no personnel to execute it with.  So their financially rationale lean strategy will lead directly to the "losing streak" and the "going out of business curve". 

While this example may seem far fetched, I have seen a fair number of economic organization's that have adopted exactly this strategy, in the form of continuous improvement using lean principles. These companies do many right things, but they focus so much on increasing cost efficiencies (and their margins) they forget what will keep them in business over the long haul. 

For example, in the 1960s, General Motors decided to standardize their engines among all their lines of vehicles.  This meant a greatly simplified engine assembly and supply chain processes; that is, a much leaner system using the principle of group technology.  One engine that they decided on was the 350 cid engine.  To go a step further in their "lean initiative", they built a new plant to assemble these engines.  This assembly line of this plant was 1/2 mile long and as fully automated as possible for that time.  So, from the finance engineering lean perspective it should be much more cost efficient than having several lines all producing the 350 in several variations.  The plant and assembly line were truly impressive; even economic textbooks of the time touted it as the ideal of what cost efficiency should be.  However, there were significant start up problems and just as the plant worked these out, new EPA regulations and the first gasoline crisis hit.  The automation of the assembly line was so tightly coupled (one workstation feeding directly into another) that changes proved to be nearly infeasible--tight coupling is a way to increase cost efficiency across the interface of two workstations.  So GM spent a great deal of money to optimize (make lean) a process and an automated assembly line that within a few years could only produce obsolete products.  They designed out most of the plant's agility.  PS--GM learned enough that when they built their Saturn Plant, they built it for agility.

However, it's not only manufacturing that falls prey to lean financial engineering.  In the 1990s, SAP and other software suppliers sold many Enterprise Resource Planning (ERP) systems.  These ERP systems have the same lean characteristics as the GM engine assembly plant.  That is, they used a monolithic IT architecture to minimize and optimize the interfaces among the business functions the system performed.  This reduced the number of processes that the system could support to nearly a single process.  Since many organizations order the functions of their processes to attempt to optimize their complete set of business processes, these ERP systems had a variety of parametric and coding tools and processes to tailor the system.  I saw examples of ERP systems that were so highly tailored, that the tailoring of the system cost more than the original system.  This expensive tailoring is reasonable as long as the business/political and technology environment remains constant--and that is a heroic assumption in this age.  The more tightly coupled a system is, the more difficult it is the change the process the system supports and the more difficult it is to insert new technology.  So most IT software suppliers have abandoned monolithic architecture for Service Oriented Architecture (SOA).  (There are several posts on SOA and more will be coming).  The key architectural concept in SOA is that the functions are loosely, rather than tightly coupled.  IT systems suppliers, like SAP, have and are migrating the systems to this much more agile architecture to avoid both of these issues.

As private, for profit, organizations move through time from producing knowledge-based value to capacity value (that is, their products and services loose their differentiation from others) cost efficiency becomes much more important than product/service effectiveness (see my posts "Knowledge Value" and "Capacity Value").  Economic organizations can have one of three reactions to attempt to survive this change.  First, they can invest in research, development, education and training, second, they can attempt to continuously improve their cost efficiency, or third, they can purchase new knowledge.  Pharmaceutical companies do the first and the third because it is very difficult for them to improve the cost efficiency of their manufacturing processes.  And, if they let quality slip to increase the cost efficiency, they run directly into a very bad time from various agencies of the US Federal government.

However, most industries opt for the second, continuous improvement with respect to cost efficiency, especially for companies producing only capacity value.  They attempt to make their processes continuously more "cost efficient".  Frequently, that means becoming sloppy about fit, finish, and the tolerances of components.  In other words, they sacrifice quality to short-term ROI.  In the process they lose their customer-base, as the "Big Three", now "The Detroit Three" found out the hard way.

Notice that of the three reactions that allow an organization to survive and thrive, only the first will increase the organization's future agility, but this reaction and strategy reduces short-term ROI.  From the perspective of Wall St. traders (people that purchase a stock for less than 5 years, not investors like Mr Buffet), this is very bad.  The reason I chose 5 years is that it seems take a new (transformational or market disruptive) product or service to market.  Further, the Gartner Group's Hype-cycle tends to fall into the 5 to 10 year range from the roll out of the first implementation until it reaches the "slope of enlightenment" and the "plateau of productivity" where it is producing the maximum value.  Therefore, it would seem sensible that, if the objective for investment is to maximize long-term gains and have a continuing ROI that 5 years on an investment would be reasonable.  But Wall St. traders don't see it that way because it would greatly reduce their income.  They could no longer simply attempt to maximize the number of trades (the amount of virtual paper they push) and therefore maximize their bonuses; which is nothing more than "Political Value" some of the mediated type, but much of the exploitative type.

As suggested, the problem of creating an agile enterprise is part cultural.  It is also, part architectural (the functional design used), and part the metrics used to measure success.  All organizations attempt to be both effective in meeting their goals, mission, and vision while increasing their cost efficiency.  Architecturally, it is much easier and simpler to construct a system using monolithic architecture than a modular based architecture, like SOA.  This is the reason the SAP and others used monolithic architecture.  Because it's simpler it's more cost efficient; at least initially (but, as discussed, much higher Total Cost of Ownership, TCO).  

Measuring both how lean and how agile an organization is, is difficult, at best; and, unfortunately, it is much easier to measure the cost efficiency of processes and tooling than it is to measure the process effectiveness.  The reason is that the accounting processes have a long history of measuring costs and ROI.  These processes have much more difficulty dealing with "cost avoidance"--which makes cost/benefit analysis hard.  But, they are ineffective as measuring the increase in Production Capability (see my post Infrastructure: A Mission of Government and Govenance for the definition and desciption), especially when the investment is simply to increase an organization's agility, to successfully respond to the unexpected.  So most organization's focus on creating lean processes and managers get bonuses based on increasing cost efficiency.  However, as discussed, if an organization attempts to optimize its leanness, be as cost efficient as possible, it looses its agility.  And that is the rub.

There is one way to get both.  Simplifying the processes can make the organization both leaner and more agile under certain conditions; but, that requires good Enterprise and System Architecture processes, which cost money, which most organizations, currently, do not spend.  Instead, the accounting systems and finance engineering processes ensure that organizations either go out of business, long-term, or spend orders of magnitude more funding and time fixing and repairing poorly architected systems or constructing new systems, than they would by really implementing these processes.