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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.