Category: Software Architect

As with any profession, jargon is used so that individuals within that profession can effectively communicate with one another. Lawyers talk to one another about habeas corpus, voir dire, and venire; Carpenters talk to one another about butt joints, lap joints, and flux; Software Architects talk to one another about ROA, Two Step View, and Layer Supertype. Wait, what was that?

It is imperative that software architects, regardless of the platform they are working in, have an effective means of communication between one another. One of those means of communication is through architecture and design patterns. To be an effective software architect you must understand the basic architecture and design patterns, recognize when those patterns are being used, know when to apply the patterns, and be able to communicate to other architects and developers using them.

Architecture and design patterns can be classified into four basic categories: Enterprise Architecture Patterns, Application Architecture Patterns, Integration Patterns, and Design Patterns. These categories are generally based on the level of scope within the overall architecture. Enterprise architecture patterns deal with the high-level architecture, whereas design patterns deal with how individual components within the architecture are structured and behave.

Enterprise Architecture Patterns define the framework for the high-level architecture. Some of the more common architecture patterns include Event Driven Architecture (EDA), Service Oriented Architecture (SOA), Resource Oriented Architecture (ROA), and Pipeline Architecture.

Application Architecture Patterns specify how applications or subsystems within the scope of a larger enterprise architecture should be designed. Some common pattern catalogs in this category include the well-known J2EE design patterns (e.g., Session Façade and Transfer Object) and the application architecture patterns described in Martin Fowler‘s book ?Patterns of Enterprise Application Architecture?.

Integration Patterns are important for designing and communicating concepts surrounding the sharing of information and functionality between components, applications, and subsystems. Some examples of Integration Patterns include file sharing, remote procedure calls, and numerous messaging patterns. You can find these patterns at http://www.enterpriseintegrationpatterns.com/eaipatterns.html.

Knowing the basic design patterns as described by the Gang of Four book ?Design Patterns: Elements of Reusable Object-Oriented Software? is a must for any software architect. Although these patterns may appear to be too low-level for a software architect, they are part of a standard vocabulary that makes for effective communication between architects and developers.

It is also important to be aware of and understand the various anti-patterns as well. Anti-patterns, a term coined by Andrew Koenig, are repeatable processes that produce ineffective results. Some of the more well-known anti-patterns include Analysis Paralysis, Design By Committee, Mushroom Management, and Death March. Knowing these patterns will help you avoid the many pitfalls you will most likely experience. You can find a list of the common anti-patterns at http://en.wikipedia.org/wiki/Anti-patterns.

Software architects need the ability to effectively communicate with one another in a clear, concise, and effective way. The patterns are there; it is up to us as software architects to learn and understand these patterns so we can “walk the walk and talk the talk”.

A system consists of interdependent programs. We call the arrangement of these programs and their relationships “architecture”. When we diagram these systems, we often represent individual programs or servers as simplistic little rectangles, connected by arrows.

One little arrow might mean, “Synchronous request/reply using SOAP-XML over HTTP.” That’s quite a lot of information for one glyph to carry. There’s not usually enough room to write all that, so we label the arrow with either “XML over HTTP”—from an internal perspective—or “SKU Lookup”—for the external perspective.

That arrow bridging programs looks like a direct contact, but it isn’t. The white space between the boxes is filled with hardware and software components. This substrate may contain:

* Network interface cards 
* Network switches 
* Firewalls 
* IDS and IPS 
* Message queues or brokers 
* XML transformation engines 
* FTP servers 
* "Landing zone" tables 
* Metro-area SoNET rings 
* MPLS gateways 
* Trunk lines 
* Oceans 
* Cable-finding fishing trawlers

There will always be four or five computers between program A and B, running their software for packet switching, traffic analysis, routing, threat analysis, and so on. As the architect bridging between those programs, you must consider this substrate.

I saw one arrow labeled “Fulfillment”. One server was inside my client’s company, the other server was in a different one. That arrow, critical to customer satisfaction, unpacked to a chain of events that resembled a game of “Mousetrap” more than a single interface. Messages went to message brokers that dumped to files, which were picked up by a periodic FTP job, and so on. That one “interface” had more than twenty steps.

It’s essential to understand that static and dynamic loads that arrow must carry. Instead of just “SOAP-XML over HTTP”, that one little arrow should also say, “Expect one query per HTTP request and send back one response per HTTP reply. Expect up to 100 requests per second, and deliver responses in less than 250 milliseconds 99.999% of the time.”

There’s more we need to know about that arrow.

* What if the caller hits it too often? Should the receiver drop requests on the floor, refuse politely, or make the best effort possible? 
* What should the caller do when replies take more than 250 milliseconds?
Should it retry the call? Should it wait until later, or assume the receiver has failed and move on without that function? 
* What happens when the caller sends a request with version 1.0 of the protocol and gets back a reply in version 1.1? What if it gets back some HTML instead of XML? Or an MP3 file instead of XML? 
* What happens when one end of the interface disappears for a while?

Answering these questions is the essence of engineering the white spaces.