- Constant Rapid Change and Organizational Agility
- The Case for Lean Integration
- What Is Integration?
- Integration Maturity Levels
- Economies of Scale (the Integration Market)
- Getting Started: Incremental Integration without "Boiling the Ocean"
This chapter is from the book
This chapter is from the book
This chapter is from the book
Economies of Scale (the Integration Market)
As stated earlier, the benefits of Lean are economies of scale and reduction in variation. As a general rule, doubling volume reduces costs by 15 to 25 percent, and doubling variation increases costs by 25 to 35 percent. The ideal low-cost model, therefore, is maximum standardization and maximum volume. But how exactly is this accomplished in a Lean Integration context?
A core concept is to view the collection of information exchanges between business applications in an enterprise as a "market" rather than as a bunch of private point-to-point relationships. The predominant integration approach over the past 20 years has been point-to-point integration. In other words, if two business systems need to exchange information, the owners and subject matter experts (SMEs) of the two systems would get together and agree on what information needed to be exchanged, the definition and meaning of the data, the business rules associated with any transformations or filters, the interface specifications, and the transport protocol. If anything needed to change once it was in operation, they would meet again and repeat the same process.
For a small number of systems and a small number of information exchanges, this process is adequate and manageable. The problem with a hand-coded or manual method is that it doesn't scale, just as manual methods for other processes don't scale well. Certainly if a second integration point is added to the same two systems, and the same two SMEs work together and use the same protocols, documentation conventions, and so on, the time and cost to build and sustain the integrations will indeed follow the economy of scale cost curve. But in a large enterprise with hundreds or thousands of applications, if each exchange is viewed as strictly an agreement between the immediate two parties, diseconomies begin to creep into the equation from several perspectives.
Imagine trying to follow a flow of financial information from a retail point-of-sale application, to the sales management system (which reconciles sales transactions with refunds, returns, exchanges, and other adjustments), to the inventory management system, to the general ledger system, to the financial reporting system. In a simple scenario, this involves four information exchanges among five systems. If each system uses different development languages, protocols, documentation conventions, interface specifications, and monitoring tools and was developed by different individuals, not only will we not receive the benefits from quadrupling volume from one integration to four, but we will in fact increase costs.
This example reflects the two largest factors that drive diseconomies: the cost of communication between teams and duplication of effort. Additional factors can drive further diseconomies, such as the following:
- Top-heavy organizations: As organizations get larger and add more layers of management, more and more effort needs to be expended on integrated solutions that require collaboration and agreement across teams that each play a narrow functional role.
- Office politics: Disagreements across teams are a result of different motivations and agendas, usually a result of conflicting goals and metrics but also sometimes caused by the "not invented here" syndrome.
- Isolation of decision makers from the results of their decisions: Senior managers may need to make decisions, such as how much of a budget to allocate to a given group, without a clear picture of what the group does and what value it brings to the organization.
- Slow response time: Delays are caused by multiple handoffs between teams or by queuing requests for information or support from other groups.
- Inertia: People are unwilling to change or are opposed to standards.
- Cannibalization: Limited resources (such as SMEs in specific business domains) are consumed for project B, slowing down progress on project A.
The degree of integration variation in many organizations is staggering in terms of both the variety of technology that is used and the variety of standards that are applied to their implementation. That is why most organizations have a hairball—hundreds or thousands of integrations that are "works of art."
The alternative is to view the need for information exchanges across applications as a market economy, and to serve the market with an efficient shared-services delivery model in order to gain economies of scale. For example, multiple groups within an organization may perform similar activities but do so with varying degrees of efficiency and consistency. Centralizing the activities makes it much easier to standardize and streamline the work, thereby reducing the cost per unit of work while improving the quality and consistency.
The two graphs in Figure 1.3 are borrowed from the field of economics and show the relationships between costs and volumes. These graphs reflect the well-understood laws of diminishing returns and economies of scale. The chart on the left reflects a manual or low-tech operation, such as when information exchanges are developed using custom hand-coded integration solutions. In this scenario, there are few (if any) capital costs since existing enterprise tools such as COBOL, Java, or SQL are used to build the integration. The overall average cost per integration initially falls as the individuals doing the work gain experience and are able to share some of their experience and knowledge, but then at some point it starts to increase as diseconomies emerge. In terms of the marginal costs (i.e., the incremental cost for each additional integration), initially the curve is somewhat flat since the first integration developer can develop a second or third integration with a similar effort. The average cost also falls initially since the fixed costs of the developer (hiring costs, office space, desktop PC, etc.) are amortized over more than one integration. As the volume of integrations increases, however, the marginal costs increase on an exponential basis, and the average costs begin to increase as more and more diseconomies emerge from the increasing complexity and number of unique integration points.
)
Figure 1.3 Diminishing returns and economies of scale
The chart on the right of the figure shows the cost curve as a result of a capital investment in tools and infrastructure (such as an Integration Factory) to largely automate and standardize the development effort. Note that in this scenario, the marginal costs are small and constant. For example, it might cost Microsoft $5 billion to develop a new version of Windows, but once developed, it costs just pennies to make another electronic copy. The marginal cost per copy of Windows is essentially the same whether 1 copy or 1,000 copies are made, but the average cost drops significantly and continuously in this scenario as volume increases and as the up-front fixed costs are amortized over more and more units.
The key challenge for organizations is to determine at what level of integration complexity do diminishing returns begin to emerge from manual hand-coded solutions, and how much capital investment is warranted to achieve the time and cost advantages of a high-volume Integration Factory. The answer to this will become clearer in Parts II and III, where we discuss the Lean principles related to continuous improvement, mass customization, and process automation, and the financial management competency area.