Architecture by Baseball: The utility player
This is the second 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.
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 these and see how many results you 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”.