Chapter 1: The Moon is Blue

Businesses and markets appear to have an insatiable appetite for new application functionality. I have yet to hear a product manager say after a product release, “This product does everything our customers want; there is nothing we need to plan for the next release. Let’s all go home.” Around a release date, you are more likely to hear, “No, this release doesn’t do that-we might be able to add that feature in the release after the next one.” In the universe of software applications, these functional requirements occasionally align themselves so that they appear, from a distance, as one universal requirement. Sometimes, one of these universal requirements gives birth to a new universal concept that holds the promise of meeting that universal requirement. On occasion, interest in this universal concept fuels the development of a new technology that allows developers to apply that concept to their applications, thereby fulfilling the universal requirement. And every once in a blue moon, the universal requirement, universal concept, and subsequent technology are so large and overarching that they force us to reconsider software designs. I’m not sure whether you noticed, but the moon was blue the day Microsoft released Windows Communication Foundation (WCF). It is time to rethink the way we design and build distributed applications.

The Universal Requirement

For the most part, businesses are no longer in search of the “magic” application suite that will solve all of their computing problems. Over time, many software vendors, like the big Enterprise Resource Planning (ERP) and middleware vendors, have sold these sorts of systems with varying degrees of success. Businesses, however, place so many demands on software that no single vendor can deliver a comprehensive product suite that addresses every one of these demands. Furthermore, as businesses grow, they often need to improve their infrastructure and processes to accommodate their growth. Software that worked well when a company had 100 employees doesn’t work well when that company grows to 1,000 employees. The problem is even more complex when considering mergers and acquisitions. Migrating an acquired company to the software of the parent company is often a painful, tedious, and expensive undertaking.

As a result, most corporate computing infrastructures contain a mix of applications that meet department-level and enterprise-level needs. This mix is often called an accidental architecture. The chances are good that these applications were developed, either internally or by a vendor, to solve a specific set of business problems, and each of these applications often manages isolated sets of information. Occasionally, this accidental architecture is standardized to run on one hardware type, operating system, and platform, but this is hardly ever true. More often than not, the computing systems in an enterprise are composed of independent, stove-piped applications, running on different hardware, operating systems, and platforms, all working for the betterment of the business (we hope). If you look at this image just right, you might be reminded of an M. C. Escher drawing.

From a business perspective, applications are seldom totally independent, as their very existence is tied, in some form or fashion, to helping the business run more efficiently. As a result, someone is bound to demand, in the name of cost reduction, increased sales, or regulatory compliance: “I want to know in Application A something from Application B.” The catchy phrase for this sort of a requirement is connectedness.

Connectedness typically comes in two flavors: application-to-application, and application-to-enterprise. Simply put, application-to-application connectedness is connecting two applications, such as accounts receivable and shipping. An example of application-to-enterprise connectedness is an airline that wants to publish, to any concerned application, every time an airplane takes off or lands. This information has far-reaching impacts in the enterprise, including maintenance, crew scheduling, and quality assurance. People, markets, and businesses are now demanding both forms of connectedness in their applications to the point that connectedness has truly become a universal requirement. Whether you work for a software vendor or an internal IT department, you have probably seen this demand to connect applications. If this is the first you have heard of it, just read some of the comments made by the heads of major software companies and take note of what they are saying about future product and service releases. Almost without exception, you will hear and see the terms integrate, connect, and interoperate at least once. These all imply connectedness. In short, connectedness is the new universal requirement.