Architecture By Baseball: Ground Rules

This is the third in a series of blog posts 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.

Architecture by Baseball: The utility player

This is the second in a series of blog posts 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.

In baseball a Utility Player is one that can several positions well.  In baseball there are 9 distinct defensive positions, each requiring a slightly different skill set.  There is some overlap between the positions (for instance a good right fielder will have many of the skills required to play left field).  But some positions require a vastly different skill set (such as catcher and center fielder).  Often times you will hear about a “utility infielder”; a player who can play 3rd base, 2nd base and shortstop.  You will also hear about a “utility outfielder”; a player who can play any of the 3 outfield positions: Left fielder, Right Fielder and Center Fielder.  There are rare players that have the skills and experience that allow them to play all 8 defensive positions (all save the pitcher which is a highly specialized position).  And there are even instances of players who have played all 9 positions (sometimes in the same game, but that has generally been more of a stunt).

Because there are a limited number of players that a team can have on the roster at a given time (25 players for the majority of the season and 40 players during the tail end of the season) a team needs to have a few players that can play more than one position.  A player that can only play one position may be a valuable player, but they limit the flexibility of the team when it comes to making changes, especially late in the ball game.  Often times these one position players will make up for the defensive inflexibility by shining at the plate.  You will often see these players on first base and in left field, because these positions are thought of as being the easier positions to play.

What is a utility architect?

In the first blog post in this series, I described the 5 general skills that an architect should have (Business Process, Software Design, Software Development, Infrastructure and Communication).  I was focused on general skills required, but not on the various specializations that an architect can play.  You are probably familiar with some of these specializations and might even be able to find some of these on business cards running around your organization:

  • Software Architect – Someone who specializes in designing the custom written code in a solution
  • Data Architect – Someone who specializes in designing the database (or other data storage system) in a solution
  • Infrastructure Architect – Someone who designs the portions of the solution that are closer to the physical implementation.  For example the directory layout.
  • Network Architect – Someone who designs the data transfer portions of the solution
  • User Interface Architect – Someone who architects the flow of the system for the user perspective.  You may be skeptical about this one, but these architects to exist, I met several of them last year when we did our ArcReady event on User Experience.
  • <Insert Technology Name Here> Architect – there is a whole litany of architects who align themselves to a particular technology.  If you don’t believe me, go do a search job descriptions for .NET Architect, SAP Architect or Java Architect and see the results that you will get.

A utility architect is someone who can play more than one of these specializations reasonably well.  For instance they may be really good at software architecture, but they can also design databases or design the infrastructure for the solution.  Or more likely, they are going to be a true software architect and be able to design a system in Java or Ruby on Rails as well as they would on .NET.  Being competent in more than one specialization increases your flexibility to the organization, because you can be used in more than one capacity.  This is good in a large organization, but invaluable in a smaller organization.

I personally think that all architects should strive to be a utility architect and not just specialize in doing only one thing.  The antithesis of this is an organization that requires a room full of architects in order to decide anything.  I personally experienced this years ago when I got on a conference call about a network issue.  The person that I talked to had introduced himself as a “Layer 3 Architect” a reference to the OSI Model (if you recall that).  We determined that the issue was probably caused by a firewall configuration problem, I told him the ports that he needed to check.  He stopped me mid-sentence and said “Stop there, we will need to get our firewall architect involved in this issue and I just checked his schedule and he is not available for another 2 days”.

Architecture by Baseball: 5 tool architect

This is the first in a series of blog posts 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.

In baseball scouting one of the biggest compliments that a player can receive is to be called a “5 tool player”.  This is a reference to the skills that make up a good, all around baseball player:

  1. Hitting for power: When at the plate the player can hit the ball with a lot of power, home runs and doubles are very common.  Runs Batted In (RBI) and Total Bases (TB) are common stats to measure the power that a player shows.
  2. Hitting for average: Hitting for power is only one dimension of the performance at the plate (sometimes a player that hits for power will strike out a lot).  When a player hits for average, that means that they reach base more often when they have a plate appearance.  Batting Average (BA) and On Base Percentage (OBP) are common stats to measure how well the player does in this skill.
  3. Base running skills: How well does the player handle himself when they reach base.  The obvious thought is how fast the player is in running between bases, but many of the best base runners are not the fastest, they are smart about the leads they take and are effective at breaking up a double play.  Stolen Bases (SB) is the most common stat for this skill.
  4. Fielding: Good fielding is essential for a team to succeed.  Sometimes players can be great at the plate, but will be called a “defensive liability” meaning their fielding is sub-par.  Fielding Percentage and errors are 2 stats to measure this tool.
  5. Throwing: how well does the player execute throws once they have fielded the ball.  Double plays turned (for infielders) and Assists (for outfielders) are stats for this skill.

When a player shows above average potential in all of these skill areas, he is considered to be a “5 tool player” and will be highly sought after by major league teams.

What are the 5 tools for a software architect?

Using the baseball term as my guide, I wanted to put together a list of the “5 tools” that make up a good architect.  This exercise was actually a lot harder than you might think.  Like many people I think that an architect needs to be a generalist and as a result there are a 1001 things that a architect must need to know in order to be a good architect.  Categorizing these into 5 tools was difficult.  But here is the list that I came up with.

  1. Business Process – Process is the way that we get things done.  Software is becoming an increasingly integral part of business process, but it is still only a small part of how things are accomplished.  Process is the “Bigger picture” of software architecture.  Being able to understand how the software solution fits into the overall business process is a critical skill to being a good software architect.  The danger of not mastering the process is that the software solution may be a masterpiece of software engineering, but may be totally useless in the presence of the business problem (okay maybe not totally useless, but sub-optimal for the time spent creating it).
  2. Software Design – This is the probably the most obvious of the architecture tools – you have to be able to design a solution.  You might be surprised at how many people who are otherwise brilliant software engineers have trouble designing a software solution, or struggle with designing a solution so that it fits harmoniously with the rest of the software ecosystem.
  3. Software Development – An architect must understand how to develop software.  You don’t have to spend 100% , 75% or even 50% of your time time actually developing software in order to be an architect.  You do have to understand the capabilities and limitations of your software environment.
  4. Infrastructure –  Infrastructure is the architectural foundation of the enterprise and it is the plumbing that makes our software systems work.  Because it is foundational it is often ignored in the same way that we ignore the plumbing when we are walking around in a building.  However when you are designing that building, you have to pay careful attention to it.  And just like other foundational components infrastructure must be maintained and upgraded over time.  A good architect knows how to leverage the infrastructure.
  5. Communication – I know there are some people who get to this point and say “Bah – software development, infrastructure?  Where is the governance?  Architects must know governance!”  Governance is important in architecture, but the real value of governance is not in developing a governance strategy, but in communicating the strategy and the importance of the strategy.  The ability to communicate with the technical and the non-technical audience is probably the most important of the 5 skills identified here.

Note:  My colleague and friend Chris Bernard, who is Microsoft’s User Experience Evangelist for the Central United States, has written a follow-up post to this one where he talks about the tools that a designer needs.

Architecture by Baseball


A couple of years ago I read a great book called Management by Baseball: The Official Rules for Winning Management in Any Field. I am a big baseball fan, so a book that can teach me a little about soft skills while making it interesting I was all up for.  The author did a great job of using analogy and great historical references to make learning about the management discipline interesting to a baseball fan.


In homage to this book, I decided to create a series of articles (delivered as blog posts) comparing baseball to software architecture.  Here is a list of the articles:


5 tool architect (published on April 21, 2008) – In baseball the 5 tool player is one that excels at the 5 baseball skills.  We compare this to the skills that are important for a software architect.


The Utility Player (published on May 7, 2008) – In baseball a utility player is one that can play more than one position, making him especially valuable on defense.  We talk about the many flavors of architects and talk about how an architect is more valuable if they can play more than one role.


Ground Rules (Published on Tuesday, May 20, 2008) – Unlike most sports, baseball is not played on a uniform field (each field is a different shape and size).  Baseball has to create rules specific to each field to accommodate these differences.  Each organization in architecture also has specific ground rules.

Coaches (Published on Wednesday, June 11, 2008) – Coaches play a unique role in baseball as they interact with players on the field more than coaches in other sports.  We will look at the software architect as a coach on the project team.

The Managers (Published on Wednesday, June 25, 2008) – Managers in baseball have to balance the tactical and the strategic both during the game and between games, just like software architects have to.

Jargon (Published on Tuesday, July 15, 2008) – Baseball, like Software Architecture has a lot of unique jargon.  We will explore some unusual baseball jargon and discuss the best practices for using jargon in business conversations.


Stats (Published on Saturday, August 30, 2008) – Baseball loves its statistics.  If an item can be counted it is.  Statistics allow us to make decisions during the game, across a season and allows us to make great historical comparisons.   Software Architecture does not do nearly as good a job of capturing and using statistics.


The 2 Out Rally (Published on Saturday, September 28, 2008) – There is nothing more exciting and nerve wracking in baseball than a 2 Out Rally.  Software projects have their own 2 Out Rally as well.


The General Manager (Published on Friday, October 17, 2008) – The general manager, like the Enterprise Architect, should have a long term view of the organization.


Moneyball (Published on Wednesday, January 7, 2009) – Baseball, like software architecture is all about people.  We will look at some criticisms of the 5 tool player and talk about what really matters.


Spring Training (Published on Friday, March 20, 2009) – Software Architects and developers should take advantage of the project ramp-up to fine tune their skills, like basbeall players do before the season starts.


Conference on the Mound (Published on Monday, December 27, 2010) – In Baseball, Managers and the other players will often visit the mound during a game to confer. This article compares that to the team stand-up.