Loose coupling is one of those suddenly popular great ideas that have actually been around for a long time. With loose coupling come two significant benefits long sought by business and IT managers: flexibility and speed. The concept is about to move out of the technology infrastructure and address speed and flexibility at the enterprise level. It will change the enterprise in profound ways.
I'll let you in on a big secret: You don't have to implement a service-oriented architecture (SOA) to loosely couple the enterprise. In fact, burying the concept of loose coupling in technicalities has kept this important enterprise-level discussion under the radar screen of most senior business and technology managers. Loose coupling can be applied at all levels of the enterprise, including the entire spectrum of the business process, data and technology architecture. So the concept is slowly making its way up the chain of command into the executive suite. It may be riding on the coat tails of an SOA discussion, but we can live with that for now.
Fundamentally, loose coupling is founded on the idea of breaking something complex up into logically distinct parts. The absolute key to loose coupling is that the parts -- including the parts of the enterprise -- need to be designed in such a way that they are relatively autonomous. Autonomous design results in few dependencies. Loose coupling is basically this same idea of modularity. It's a basic principle of advanced design and engineering and a fundamental technique for solving complex problems. If your enterprise is complex, you need to understand the idea of loose coupling at a macro level. This is a CXO-level discussion.
The good news is that loose coupling isn't a very difficult concept to understand. One could argue that "Divide and conquer!" was one of the original ways of saying "Loosely couple!" although I think the original had a bit more pizzazz. Let's take a low-tech example of loose coupling. Skis, boots and bindings are loosely coupled, which results in a tremendous amount of flexibility for customers and manufacturers. There are lots of choices of skis, boots and bindings that work together in a loosely coupled manner. Skis, boots and bindings are "modules" that can be combined and swapped out in an evening's shopping trip.
A result of this modular approach is dramatically faster time-to-market. Parallel innovation occurs because manufacturers don't have to talk to one another a lot. The beauty of loose coupling -- or modularity -- is that it seems to birth a continuous cycle. Flexibility of choice -- speed of innovation -- more flexibility of choice. It can be a dizzying, industry-changing cycle. But not readily apparent in the ski industry example is the fact that someone had to figure out that a good set of autonomous modules would be boots, bindings and skis. None of us are walking around in the apres-ski bars with part of the binding or ski attached to our boots.
There are lots of examples of loose coupling that already exist in our technical infrastructures. The fundamental architecture of a PC is loosely coupled. That gives manufacturers and customers the same amount of flexibility as our ski industry example. PCs can be constructed of components and peripherals from different suppliers. This has dramatically increased the speed of innovation in PC components and peripherals. Remember when you had to buy your computing platform, operating system and network equipment from the same vendor in order to ensure that everything worked together? Can you see how slow innovation has been in those monolithic architectures?
The concept of loose coupling is moving slowly but steadily up the enterprise architecture stack. It's about to have profound impact on the enterprise as we apply this approach to business processes and their supporting core business applications. The approach may come from top down or bottom up, but it's coming whether we like it or not.
One might argue that today's enterprise application architecture is already loosely coupled because it's broken up into hundreds of component applications. The problem is that these applications aren't designed to be loosely coupled. In fact they are so dependant on one another that we can't seem to get new core applications implemented in less than five years, if we're lucky, because of hundreds of dependant interfaces. So how do we loosely couple the enterprise application architecture? An SOA isn't going to solve this problem. We have to modularize our core applications at the enterprise level in a way that reduces dependencies. That means the scope of enterprise applications can't be arbitrary, with or without an SOA approach.
We have the choice of a bottom-up or top-down approach to loosely coupling the enterprise. It's possible that we may first carve off small loosely coupled business processes and supporting business applications from the bottom up because that's all we have funding for (call it a service it you want).
Maybe the first thing that will happen is that the ski boot buckles of our monolithic and inflexible business processes and systems will be loosely coupled. Or it's possible that we will come up with an enterprise design that splits our enterprise up into skis, boots and bindings and turns us loose to innovate across the enterprise. In the latter case, some serious enterprise-level modeling needs to occur. We will likely find that the enterprise should be loosely coupled around natural clusters of information and business processes; it probably doesn't have much to do with technology. You really do need to get on the agenda of the next CXO meeting.
It's even likely, in my opinion, that the concept of loose coupling will change the way we think about structuring the enterprise in the information age. The organizational chart itself is an attempt to loosely couple the enterprise. If the "modules" of your org chart aren't right, you probably have a lot of long, frustrating meetings in big conference rooms. Walking in the snow with part of a binding and a ski attached is cumbersome.
Regardless of whether you believe that the concept of loose coupling will affect the structure of the enterprise itself, the organizations that embrace this concept in the design of core business processes and their supporting applications will gain flexibility and speed that may leave competitors in the dust.
The phrase "Divide and conquer!" was said to be coined around the first century B.C. by Julius Caesar, who was known for his ability to vanquish his enemies through fearsome speed on the battlefield. You have had the tool to gain flexibility and speed in the enterprise long before the SOA discussion. Loosely couple!