Software architecture—the highest-level components of your application and the way they communicate—is a crucial part of your enterprise application. Small, standalone applications may be able to survive (for some amount of time) a lack of high-level organization and a philosophy of structure (that’s right, I said “philosophy”). But since another common definition of software architecture is “the stuff that’s hard to change,” it’s foolish to ever embark on a project without conscious attention to architecture.
Discussions of software architecture have become less common as the industry has embraced lean processes and code-first approaches. This has furthered the most common architecture: The “Big Ball of Mud.” Big Ball of Mud systems are characterized by high-level units of arbitrary and inconsistent size. Sometimes everything is just in one big directory structure, but more commonly today, a Big Ball of Mud consists of source code that is spackled over some potentially useful infrastructure.
The source code, though, is wildly interdependent and filled with assumptions about distant concerns. If you’ve ever worked on a system where it took two weeks before you dared make the first check-in, or where you had to talk with someone in another office before fixing a clearly-doesn’t-do-what-it-claims defect, you’ve worked with a Big Ball of Mud.
Older readers may remember an analysis concept called “Perfect Technology Assumption.” This concept held that, when sketching out the scope of a project, one ought to assume infinitely fast processors and capacity, foolproof messaging, and whatever input and output technology one wanted. Of course, one didn’t really believe in absurdities such as multi-gigahertz processors, 300-DPI displays, and voice input, but the idea was that one needed to avoid, in high-level discussions, linking the system to be developed with the limitations of technologies as they are.
“Perfect Technology” became counter-productive with the rise of dominant operating systems with extensive APIs and, more recently, the advent of “opinionated frameworks” such as Ruby on Rails. For the past two decades, software design has started with an assumption of a target operating environment (perhaps Windows, perhaps the Java Virtual Machine, perhaps a browser and an Apache server). That operating environment generally restricts the choice of programming language and often strongly suggests an entire set of choices regarding physical architecture, storage technology, and even component structure and design.
#!
Technology stacks provide so much prepackaged functionality—and opinionated frameworks embody so much good thinking—that there’s no question that the “Perfect Technology Assumption” is now the wrong approach. However, Perfect Technology did have the benefit of requiring developers to consciously address software architecture (or, if they didn’t, to have no one to blame but themselves for developing an unmaintainable system).
Software architecture is not the same as the technology stack, your frameworks, and their accumulated decisions. Those things may constrain or facilitate the architecture of your application, but it’s incorrect to just rattle off a list of technologies or show the diagram that illustrates the architecture of the framework. Your application’s architecture consists of your decisions about the highest-level parts of the application and how they interact.
It’s true that if you use a framework and your application is small enough, you might avoid (or at least hide) the charge of having developed the dreaded Big Ball of Mud. But most SD Times readers aren’t in the business of small applications. Most SD Times readers are in the business of enterprise applications, with multiple users, dozens of use cases, and interoperability with legacy systems and various services. And those developing mobile applications are facing a market where iOS is no longer on the majority of devices and Android is maddeningly fragmented; attention to architecture is crucial to cross-platform mobile development.
Martin Fowler’s “Patterns of Enterprise Application Architecture” remains, a decade after its initial publication, an indispensable text for enterprise architects. Its greatest strength is its clear discussion of layered architectures in systems that use a relational database for storage. This still describes the large majority of enterprise systems. However, the past decade has seen an increase in the sophistication of service-oriented architectures, a renewed interest in alternatives to relational storage, and, of course, the shift toward a mobile “post-PC” world.
System architects need to cast their nets wide to incorporate the best thinking. Another fine text (especially considering the price) is “Microsoft Application Architecture Guide, 2nd Edition,” published in 2009. It is, of course, written in service to the technologies of Microsoft, but the general discussions are quite good and it has many helpful links to additional resources.
Other than Fowler, the most valuable texts on architecture are, in my opinion, the three volumes in the “Pattern-Oriented Software Architecture” series (starting with Buschmann et al., a.k.a. “The Siemens Book”). These texts are a little long in the tooth now, but their age actually throws some of the benefits and drawbacks of the patterns into starker relief. For instance, I’m not sure that I’ll see a 21st-century enterprise using the Unix-style “Pipes and Filters” architecture, but I’m quite positive that, in some discussion, a knowledge of “Pipes and Filters” will help clarify an issue. And, hopefully, keep some system from being a Big Ball of Mud.
Larry O’Brien is a developer evangelist/advocate for Xamarin. Read his blog at www.knowing.net.