Architecture By Baseball: Ground Rules
Cubs vs Padres May 14, 2008 by Anthony Handley used with permission
This is the third in a series of articles about how we can learn about software architecture by studying and comparing it to the sport of Baseball. This series was inspired by the book Management by Baseball.
One of the most interesting aspects of baseball is that it is the only sport where the field of play varies so widely. Most sports have a very uniform field of play that does not vary from stadium to stadium (a football field is always 100 yards long and a basketball rim is always 10 feet above the floor). One of the reasons I like baseball so much is the charm that the ballparks have with their unique dimensions. Sure basketball and baseball are played in stadiums and arenas that are different sizes and shapes, but that really does not affect the field of play like it does in baseball.
The quirks found in the ballparks themselves can lead to some interesting occurrences. For instance the ivy that grows on the outfield walls at Wrigley Field in Chicago, IL will often swallow up a ball so that the outfielder cannot make a play on it. The flag pole in center field at Minute Maid Park in Houston, TX is actually in fair territory and any ball hit off of it is considered to be still in play (A few years ago this turned a 400+ foot home run by Richie Sexson into a very long single). Ballparks with roofs also present interesting scenarios as well, like what happens if the ball actually hits the roof? All these quirks have led to a class of rules know as Ground Rules. Some ground rules are the same no matter where the game is being played; other rules are specific to that ballpark. If you are ever at the first game of a series, you will notice that the umpires spend a couple of extra minutes with the manager of the visiting team, making sure that they are aware of the ballpark’s ground rules.
What are the ground rules in architecture?
Often time you think of software architecture as a universal discipline. We have a set of design patterns that we study and use (sometimes we use them weather we know it or not). Most software is built on a few platforms (mainframe, midrange, UNIX/Linux, Apple, Windows) and we all rely upon a set of standards that are pretty much Universal (TCP/IP, HTTP, Telnet, etc). One of the real benefits of this is that from a software architecture perspective we can easily move from organization to organization and our skills can be applied pretty quickly, as long as we learn the ground rules of the industry and organization.
Ground rules in software architecture are anything that is specific to the organization (or the industry), as opposed to universal to our discipline. One of the first questions I usually ask a customer when I talk to them is about their propensity to build or buy then build. Does the organization have a mix of desktop and web applications or do they only build web applications? Do they prefer Java or .NET? Are there industry standard data formats like ACORD that they must use? Are their regulations like GLB or HIPAA that they must comply with?
Each of these items has nothing to do with the pure discipline of software architecture, but they are things that will affect the design of any system that you will create. Not knowing the ground rules can greatly impact the solutions that you create, are can even lead to you being “called out”. When you start working with a new organization, you should strive to quickly get a feel for the ground rules.
Can ground rules be changed?
Some of the examples I mentioned can be changed. An organization that purchases packaged based systems could decide to build a solution from scratch (and the converse is true as well). A Java shop can decide to try .NET on a new application. Other ground rules cannot be changed, for example a bank cannot decide to ignore GLB. In general it will be a significant effort to change a ground rule, so approach trying to change a ground rule with caution, and be prepared to invest a lot of time in the change.