Day Ten: Examining an Article

In IEEE's July/August 2009 publication of Software Domain-Specific Modeling, there is an article by David Garlan, Robert Allen, and John Ockerbloom that addresses the difficulty of software reuse. The article is titled Architectural Mismatch: Why Reuse is Still so Hard, and this title alone was enough to catch my attention. I worked a little with various components and popular APIs in my graphical user interface design class to develop software mash-ups. It seemed difficult to me then because I was learning all of the languages involved, but I just assumed that my lack of experience was the main culprit--who wouldn't struggle with learning three new languages and various APIs for one assignment? The software that we were designing was grossly over-simplified compared to an entire system built for business application, yet it introduced some of the problems that the authors discuss in their article. When trying to design a system from modular parts, one can read all of the documentation and build a system that fits together conceptually; however, when one goes to actually build the system, the interactions between parts can reveal emergent properties, such as architectural mismatch, that impede the development process.

The authors state that a component makes three types of assumptions: assumptions about the application domain, assumptions about infrastructure, and assumptions about components at the same level of abstraction. The main solution the authors suggest for this mismatch is to work withing an "architecturally specialized design domain." This may limit interactions between some components that are built with different domains in mind, but component integration and design standards greatly lessen the headaches involved with trying to link two components that might be incompatible due to an inherent flaw in the way that they were designed.  Ultimately, money decides software engineering best practices. Designing a commercial off the shelf (COTS) product is supposed to be a simpler, more cost-effective way to design products. The next to last paragraph in the article says it all: "Even supposing that you have appropriately modeled evolution's cost, the potential for architectural mismatch might eventually make changing an existing system too expensive to allow effective innovation." Even if the designers make a system that works as advertised, there is a risk for "architecture lock-in" that could outweigh the benefits in the long run.