As I mentioned previously, I spoke to the Architecture Special Interest Group (SIG) of the Indianapolis .NET Developer Association (IndyNDA).  Steve Porter, who is in charge of the group, asked me to present when they founded the group last September and it took a few months for our schedules to align and I am glad that they did.  Steve asked me to do the “in person” version of my Architecture by Baseball series of articles.

I have to admit at first I did not see the value in standing up in front of a group and covering things that I had already written.  As I was putting the presentation together, however, I realized that there are a lot of things that I had not covered in the articles themselves add a lot of color to the topics presented in the written form.  I had a lot of fun putting the talk together (which I did at the last minute, the night before) and had even more fun delivering the talk to the group (about 35 people or so).    Thanks to Steve and to all those who attended the talk.

I promised I would make the deck available to the people there and thought I would share it here as well.  It is up on My Slideshare Account:

This is the eleventh 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.

As a baseball fan, some of the sweetest words that you can hear are “Pitchers and Catchers report today”.  The pitchers and catchers are the first players to report to Spring Training, so when you hear that you know that baseball is on its way.  Spring Training is a chance for the players to get back into shape for the season.  It is also a time when young players get a chance to “make the big team”.  Managers will also use Spring Training to try players at a new position, make changes in the batting order and integrate new players into the team.  Spring Training also involves exhibition games that give the players a chance to experience game play before the official season starts.

The benefits of Spring Training for a baseball team can be lumped into one of three categories:

• Getting back into “game shape”
• Learning new skills / positions
• Jelling together as a team

Spring Training for architects and developers

Typical software development projects usually have a ramp up period before the project is at full stride.  As a matter of fact I cannot recall any project that I have ever been on that did not have a quite protracted period of less than full productivity.  Requirements are still being gathered, environments (servers and desktops) are still being configured, software is still being procured, etc.  This can be quite a frustrating time for the developers, but especially the architects on the project.  You don’t have enough of the facts to design and build the real business application, but the clock is ticking on the project so the need to get started is pressing upon you.  I propose that you use the time to do some Spring Training.  The software development team should spend some time focusing on the same type of activities that you see listed above.

Get back into “game shape” – If you are starting a new release of an application chances are that you spent your past few week not writing new code, but stabilizing the previous release for shipment or doing post deployment activities.  The “new code” muscle has probably not been stretched out for a few weeks.  Practice writing new code from scratch, even if you don’t know if it will be used in the application.  Get those skills sharpened up so that when the rest of the project comes together you will be ready.  Don’t do this in the “prototype” throw away fashion, you may throw away the code in the end, but don’t write it as throw away code.  Write real code with unit tests, error handling, documentation, etc. 

Learning new skills / positions – If you are working on a new application or if you are new to the application there is a good chance that you will be working with unfamiliar technology.  You may be a fantastic ASP.NET Developer, but this may be your first project with ASP.NET MVC Framework.  Use this time to become familiar with the new technologies.  It also may not even be a new technology, but rather a new style or technique that you are applying.  Use the projects Spring Training time to become really familiar with the new stuff.

Jell as a team – Like baseball, software architecture and development is a team sport.  You have to be effective as a team in order to succeed.  Use the Spring Training time to get to know the new team members (if there are any) and to get accustomed to working well together.  As a quick aside you should be open to ideas that new players bring to the team, you should always be open to hearing best practices.

Fielder at the plate

This is the tenth 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.

I started this series off with a discussion of the 5 tool player, which is supposed to be the highest compliment that can be given to a player, especially when they are being scouted as a prospect.  I have gotten a lot of good comments about the article in the months since it was published.  I also used it as part of our recent ArcReady series of presentations on software architecture.  There are some critics of the 5 tool player in baseball, this article will discuss the criticisms and how we can apply those criticisms to software architecture.

Moneyball

In 2004 the book Moneyball: The Art of Winning an Unfair Game by Michael Lewis was published.  Michael had spent a couple of years following the Oakland Athletics and more specifically the General Manager of the team, Billy Beane.  Billy Beane was a highly touted prospect who was heavily scouted while he was still in high school.  He was the very definition of the 5 tool player.  He was drafted by the New York Mets in the first round (which is a huge deal if you don't follow baseball).  As a major league baseball player, he was pretty much a total bust.  After 6 years he had played in a total of 148 games and batted only .219 with 3 home runs.  Certainly not what you would expect from one of the most highly touted players.

Don't feel bad for Billy Beane; his baseball career was far from over.  He went on to be one of the youngest general managers in baseball and guided the Athletics to the playoffs several years in a row.  How he accomplished that with the Athletics being one of the small market teams is the subject of the book.

Moneyball is about how Billy Beane and the Athletics used some unconventional thinking to accomplish their feats with a much smaller payroll than the other major league teams they were competing against.  One of the tenants of this philosophy was to never draft a player like Billy Beane.  They thought that just rating players on the 5 tools was not enough to judge how they were going to perform.  They also felt that drafting players out of high school was not a good return on investment; college players were several years older, more experienced and you could judge better how they were going to perform on the field.

Software Architecture, like baseball is a people game

I am not going to spend the balance of this article refuting or analyzing the tools that I put forth in the first article in that series.  I have talked with enough software developers and architects to know that all those skills are important.  I want to talk about the importance of people to software architecture, because I think that we as an industry focus too much on everything but people when we are making decisions. 

Baseball is a people game; the players that you have on the field, on the bench and in your farm system are your primary asset to make your organization successful.  Yes, new stadiums help and they do draw extra fans, but nothing will draw better than a winning team.

In software architecture we spend too much of our time focusing on everything but finding, staffing and developing our teams.  We spend endless time arguing platforms (Windows or OSX, .NET or Java, PHP or ASP.NET or Silverlight or Flex), languages (C# or VB.NET, C or Objective C, XAML or mXML) or software packages (Dynamics or SalesForce.com, SQL Server or Oracle).  We also spend too much time worrying about the hardware portion of a solution (yeah I know hardware can be fun, but it is such a small part of the true costs of the solution).

The truth of the matter is that good architects and developers will exceed regardless of which platform that you give them, what language you ask them to code in and what software packages they have to build with.  Don't get me wrong, they may grumble and complain about what they are doing, but they will achieve success.  Like baseball, we need to set out with the mission of getting and developing the best architects and developers possible, no matter if you follow the 5 tools approach or more unconventional approached like those in Moneyball.

This is the ninth 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.

I have previously talked about the unique role of coaches in the game of baseball and talked about the special role of the manager in the game of baseball.  The coaches and managers are responsible for making the team successful during a game and across the course of a season.  The manager will spend some time concerned with how the team will play in future seasons with some of the decisions that he makes, but ultimately his responsibility is the here and now.  In a great example of separation of concerns, the long term success of the team (or franchise) rests on the shoulders of another person:  The general manager.

The general manager of the team is an executive position within the business organization of the company.  They are responsible for the baseball operations of organization, but they are beholden to the business operations of the company that is the organization.  Some of the things that general manager does routinely in the organization:

• Player transactions - staffing the 25 and 40 man roster as well as all the minor league franchises
• Player acquisition and development - drafting and developing young players and acquiring veteran players via free agency
• Staffing the coaches and managers - one of the most high profile activities is the firing of the team's manager
• Managing the costs of talent - the salary of the players must be weighed against team revenue and organizational goals

Branch Rickey

The Greatest General Manager of All Time?

It would be an incomplete discussion of the role of the general manager without mentioning the person who I think is the greatest baseball general manager of all time: Branch Rickey.  Like many General Managers, Rickey started off as a player in baseball before going into the business side of baseball.  He was a success General Manager with several clubs, most notably the St. Louis Cardinals and the Brooklyn Dodgers.  But what made him such a great general manager was things that he did that were innovative and beyond the traditional role of the general manager.

Re-inventing the game -  As the General Manager of the St, Louis Cardinals, Rickey created what is now known as the farm system.  The farm system is minor league baseball team that is affiliated with the major league or "big" club.  The Farm system allowed the major league team to develop and retain talented younger players.  Prior to Rickey's innovation, the minor league teams could sell or trade their talent to any team.  The affiliation gave the major league club the rights to the player when they were ready for the big leagues.  This gave the Cardinals a distinct advantage over their competition for many years.

Breaking the color barrier - When Rickey was a college coach for a while and was appalled at the segregation that took place with players of color.  He vowed to do something about it and when he was the GM of the Dodgers he was finally in a position to take action.  He signed Jackie Robinson to a minor league contract and later promoted him to the major league squad, bringing an end to the era of players being denied the rights to play baseball.  This also gave the Dodgers (and the other teams that quickly followed them) a temporary distinct advantage in signing talented players that other teams passed on simply because of race.

These are 2 of the most notable things that he did - there were dozens of little innovations that he made to the game during his years as a General Manager.

Software Architecture General Managers

I have talked before about the different types of architects, but have tried to avoid the hierarchy of architects that some organizations put too much emphasis on.  But talking about the general manager creates a natural point to talk about the role of an Enterprise Architect versus a solution architect.  Enterprise Architects are responsible for the macro view of all the of the systems in an organization and with the long term health and strategy of those systems. 

Some organizations make the mistake of thinking of them as a "super architect" who should be able to do all the things that the other architects do.  Other organizations can make the mistake of thinking that the Solutions Architect should be subordinate to the Enterprise Architect.  Many of the soft skills are the same between the Solutions Architect and the Enterprise Architect, but we should think of them as separate duties, like the manager and the general manager in baseball.  Solution Architects have the scope of the solution they are designing and building and should be focused on the current version and maybe one or two versions out.  They cannot be hung up on the long term strategy of a service bus that is several years out.  The Enterprise Architect should also not be thinking too narrow on the here and now either.  They need to focus on the longer term and not any specific application.

Be like Branch Rickey

If you have the opportunity to be in a general manager like position, studying some of the things that Branch Rickey did is not a bad thing.  He used business process and radical change to accomplish great things.  He did not just focus on being the best general manager; he changed the rules of the game.  I love this quote from him:

"Luck is the residue of design" - Branch Rickey

Branyan at the plate

This is the eight 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 exciting things at a baseball game can be the 2 out rally.  A 2 out rally is simply when a team has nobody on base, 2 outs and they put together a series of hits (or walks) that usually lead to one or more runs being scored.  All rallies are exciting, but a 2 out rally can be particularly exciting, because the team is down to its last out in the inning.  One bad swing of the bat can bring the rally and the inning to a close. 

Probably the most exciting of the two out rallies comes when not only is the inning on the line, but the game is as well.  This comes when the home team is behind (or tied) in the bottom of the 9th inning.  It can get to the point where one swing of the bat can win or lose the game.  There is a real excitement as the hometown crowd cheers their heads off for the rally to continue.

I remember Gene Mauch doing things to me at Philadelphia. I'd be sitting there and he'd say, 'Grab a bat and stop this rally.'
- Bob Uecker

Exciting and Nerve Wracking

If you are a baseball manager you like the 2 out rally, but you would much prefer for the rally to start with no outs.  Probably most players feel this way too.  2 out rallies are very exciting, but they come with the high price that one mistake and the rally is over.

2 out rally in Software Projects

I have never been on a software project where the work was distributed evenly across the time allotted for the project.  If you have 6 weeks to complete the project, you would assume the best way to accomplish the project would be to do roughly 1/6th of the work in the first week, 1/6th of the work in the second week and so on.  I can point to some literature on this, but I think I will keep this anecdotal, because everyone who is reading this article is either nodding along or chuckling at how true this statement is. 

Development teams just don't "pour on the gas" until the deadline is fast approaching (or as I like to call it, until there are 2 outs).  I have been on projects where we did about 25% of the work in the last 10% of the project timeline.  Through lots of heroics and many long hours in the last part of the project, we usually have gotten something put out by the deadline.  When we haven't it is usually because one thing tripped us up (like an infrastructure issue or a bug that is hard to track down).  In baseball terms, this is the one bad swing of the bat that killed the rally.

Architecture has an even harder time with 2 outs

Thus far I have been talking about the habits of the project team a whole, and not necessarily about the role of the software architect.  There is a special burden on the software architect to get moving on a project before there are "2 outs".  A solid architecture needs to be in pace early and all outstanding issues need to be resolved before the pressure of the project deadlines are upon you.

There is another thing to note as part of this discussion.  Baseball is a sport that is not judged by time.  As long as the team keeps hitting, the game can literally go on forever.  How long the game took is merely an interesting statistic that gets put in the record books.  Software projects are usually not so lucky - there is almost always a deadline involved.

Since baseball time is measured only in outs, all you have to do is succeed utterly; keep hitting, keep the rally alive, and you have defeated time. You remain forever young.
- Roger Angell

Top 9th

This is the seventh 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.

"I don't think baseball could survive without all the statistical appurtenances involved in calculating pitching, hitting and fielding percentages. Some people could do without the games as long as they got the box scores." - John M. Culkin

Did you know that for the current season right handed batters that face CC Sabathia (the pitcher in the photo for this article) are batting .218 against him (which is a good opponents batting average for a pitcher)?  But against left-handed batters his opponents' batting average is a fantastic .136? 

Did you know that the 1888 Washington Senators had the lowest team batting average when they batted a mere .207?

Did you know that Cal Ripken, Jr., who is best known as baseball's "iron man" for playing in 2,632 consecutive games, is also the all time leader for grounding into double plays with 350 of them over his career?

All professional sports have a battery of statistics that are tracked as part of the game and the subsequent reporting of those games, but most people would agree that baseball statistics are far more numerous and are actually a part of the fabric of the game.  One of the most fascinating aspects is how we use statistics to compare players from different eras.  Because the game has evolved slowly over the years and has not been radically redefined along the way, we are able to make meaningful comparisons.  As a result we can meaningfully compare the consecutive game hitting streak that Joe DiMaggio had in the 1940s, with the one that Willie Keeler had in the 1890s to the one that Pete Rose had in the 1970s.

More than just being a history lesson and interesting footnotes to articles about games, statistics are actually used in the decision making process before and during a game.  A manager (as an example) may look at the matchup between the batters in his lineup and how they have fared against the probably pitchers for that day's game.  He may chose to give a batter the day off as a result of this.  The general manager will also use statistics to judge whether they should draft a player, or sign a particular player as a free agent.

As much as statistics are important in baseball, we should remember the role of statistics is to enhance the experience, not to become the experience.  Don't spend all your time computing the batting average of the player coming up to bat with runners in scoring position (RISP) with less than 2 outs, which is a statistic that you will hear of frequently.  This quote says it best:

"Baseball isn't statistics - baseball is (Joe) DiMaggio rounding second." - Jimmy Breslin

Software Architecture Statistics

Software engineering has some really interesting statistics that are used as part of the development process.  Some of the most common or the most interesting statistics are:

• Lines of code - when we are working on an application, particularly one that already exists (a legacy application), the number of lines of code is an interesting piece of data.  For example, if you are going to make major changes to an application it will be a lot easier to change one that has 100,000 lines of code than one with 2,000,000 lines of code (just due to the sheer size of the application).
• Cyclomatic Complexity - measures how complicated the application is by analyzing the number of paths through the program.  This adds some "depth" to the lines of code statistic, because a program that is 50,000 lines of code can be much more complex than one that is 100,000 lines of code.
• Function Points - a way to calculate the size of an application by how many things it does.  Function points are very user centric, so "back end" applications are skewed a bit in the number of function points.

While software architecture has some interesting statistics, we as an industry do not use them as much as we should (this statement is part opinion and part anecdotal observation).  We also fail horribly as an industry to track statistics over time, so that we can do meaningful comparisons to past projects.  The best example of past experience would be comparing estimates to actuals on a project and comparing an upcoming release to a past release.  Generally those kinds of statistics are not captured in a meaningful fashion, although modern Application Lifecycle Management and Agile Software Development tools and techniques are changing that for the positive.

As we start to embrace more and better statistics in software architecture, we need to keep in mind that software architecture is still a very human process.  Statistics can help us judge our actions and make meaningful decisions, but the statistics cannot become the outcome of the process. 

"If you dwell on statistics, you get shortsighted. If you aim for consistency, the numbers will be there at the end." - Tom Seaver

Counsell gets a hit

This is the sixth 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.

Baseball Jargon

Last Saturday I watched a baseball game between the Milwaukee Brewers and the Cincinnati Reds.  I noticed that the announcers used a lot of colorful jargon in describing the action that was playing out on the field.  Baseball has built up an interesting language of its own over the years.  Some of my favorites are:

Ducks on the Pond - a term used to describe when there are runners on base, but usually stated when the bases are loaded.

Can of Corn - a term used to describe a pop-up or a fly out that is easily caught by an outfielder.  The term comes from a device that grocers used to grab canned goods that were located on top shelves in their stores.  This device allowed them to quickly and easily grab these cans, without having to stretch or get a ladder.  Of course the term does not translate to modern grocery stores.

Payoff Pitch - a term used to describe a pitch thrown with a full count (3 balls and 2 strikes).  The term is usually used when there are 2 outs or when the pitch could have a large outcome on the game (like bases loaded).  A strikeout could get the pitcher out of the tight situation; a hit could lose the game for him.

Murderer's Row - A reference to the 1927 New York Yankees, who had several of the game's best hitters in their lineup.  In later years, it has been applied to other teams who had similar lineups stacked with great batters.

No-no - a term used to describe a no-hitter.  This is a reference to the scorecard: No runs, no hits.  The no-hitter is one of the best accomplishments a pitcher can achieve (the record for career no-hitters is currently 7 over a 27 year career).  The no-no is only over-shadowed by a perfect game, which does not have a cool jargon associated with it.

Jam - a term with several meanings (you see this a lot in baseball Jargon).  It can mean a pitch that is far enough inside that the batter cannot get a full swing.  It can also mean when a situation where the pitcher is in trouble ala "Smith is in a jam", generally there are runners in scoring position with less than 2 outs.  And finally it can mean when the baseball are loaded (but sometimes the bases are juiced instead of jammed - another term that can mean the same thing).

What I found really interesting is that none of these terms are actually defined anywhere in the official baseball rules.  If you were a new fan, you would have to pick up these terms by asking people when they meant, or by listening to the announcers and inferring what the term meant by looking at the situation.  You would doubtless be confused by the overloading of terms like Jam and by having more than one term applied to the same situation:  Bases can be jammed, juiced and ducks on the pond all at the same time. 

Architecture Jargon

In software architecture we have our own jargon as well - lots of it!  Some days it seems that there are teams of people sitting in a room creating more jargon.  A couple of my favorites are:

Polymorphic - an OO Concept (OO is another Jargon) that allows the use an operator or function in different ways for different set of inputs given.  I will never forget someone telling me, "I had to re-work the code to make it more polymorphic".  I had no idea what he did to make it more polymorphic, but he seemed happy about it.

Service(s) - As an industry we have become service happy, but without a good definition of what a service is.  Most commonly when people say "service" they assume that you mean a SOAP based web service that uses XML serialization and http as a transport, as opposed to something more abstract.  Because the terms are so overloaded, you should always ask "What do you mean by service?".

Separation of Concerns - architecting and implementing your software in such a way that there is little to no overlap in functionality.  Back in the day we used to just call that "good code".

MVC, COM, SOA, etc - There are a veritable soup of Three Letter Acronyms (TLAs) that we use and reuse in discussions.  There are literally too many to keep track of.

As an architect, we are invested in this jargon and surrounded by it on a day to day basis, so much so that it actually becomes part of our natural language.  But the obvious thing to point out is that many people that we will work with are not software architects and may not even be in technology at all.  Note:  If you are a software architect who works in industry and you don't spend time with non-technology folks, you are doing something wrong.

As software architects we have to be cognizant of the fact that our business partners and customers do not speak the same language as we do.  We also have to change our behavior to account for this.  Here are some of the things that I have seen successful to bridge this language gap:

Make it about the business and not the technology - when you are having a conversation with your business partners and customers you should not be focused on the technology, but on what the business outcome will be.  There are exceptions to this of course:  Occasionally there are technologies that your business asks for by name like AJAX as in "We need to get some AJAX in our websites now".

Don't use the Jargon - Avoid the 3 letter acronyms and words like polymorphism.  They are necessary to deliver the software, but not to understand what the software does.

When Jargon slips out, explain it - If you are in a meeting and you hear SOA, just pause for a second and explain that "SOA is Service Oriented Architecture and it is a technique for building the application that makes it easier for other companies to use our software and hopefully makes it easier to maintain".  Be careful to not be condescending or over promise what the technology can do.

Ron Washington Arguing the Home Run Call ...
By Rich Anderson
Used under Creative Commons

This is the fifth 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.

The last post in this series was called "Architecture By Baseball: Coaches", where I talked about how the software architect can work better with the development team by emulating some of the things that a baseball coach does.  Baseball is a little different than other sports that have a Head Coach, in baseball the team leader is the manger.  Like the rest of the coaching staff, he wears the team uniform.  The manager extra responsibility of thinking tactically and strategically during the game and throughout the season.

Tactical during the game

When a player comes up to bat and there are men on base, the manager will often times give the batter instructions about how he is supposed to bat.  If it is a close game with a speedy runner on board, he may be instruction to bunt (called a sacrifice), rather than try to hit safely.  The manager is giving up an out in order to advance the base runner (this is a very tactical move).  Similarly, the manager may give the runner on base the "steal" or the "hold" sign or the "green light" to steal if they feel comfortable doing so.  These choices are not as obvious as they may seem, the manager may chose to give not have the base runner the steal sign even if he is very good at stealing because it might prematurely end the inning.  Nothing is worse than taking the bat out of your best players' hands by ending the inning on a failed steal attempt.

Strategic during the game

The manager must also think strategically during the course of the game.  The strategic decisions start actually before the game begins, when the manager fills out the line-up card.  The line-up card is the list of 9 players (or 10 players in American League Baseball) that will start the game and what positions that they play.  There are a lot of factors that play into the line-up cards on any given day: the opposing pitcher, the historic match-ups, etc.  As the game goes on, there a limited number of players available to the manager during the game for substitutions (25 total players for most of the season and up to 40 for the last month of the season).  The manager must make sure that the best players are on the field at any given time, but they cannot replace players constantly during the game, because unlike many other sports, once a player leaves a baseball game they can not return.  As the game goes on the manager must know when to replace players for fresh players or specialist (pinch runners who are fast, or players who are better at defense).

Strategic beyond the game

Baseball has a very long season with many games (more than twice as many games as most other sports).  The manager must remember this as they are making decisions.  The manager must make sure to give most players a day off here and there throughout the season (there are a few super human players that never need a day off).  The manager must also be careful to not over use the starting pitchers or the relief pitchers during a game, as it can be costly to make the wrong decision.

Software Architects: the balance between strategic and tactical

Like the manager making the scorecard, the architect must make a lot of decisions before the game (or construction) even begins.  Scope is negotiated, technologies selected and proof of concepts identified and executed.  Once the work actually begins, there are dozens of tactical decisions that must be made, but the strategic goals needs to be assessed.  Communication is very key as these decisions are being made.  The manager in baseball has to give signals to the batter, catcher or base runner.  The software architect also has to communicate to the team members effectively so they understand what to do tactically, but he also needs to impart the strategic thought as well (so actually we have it tougher than the baseball manager).   You also have to get the most out of the development team (even if they don't report to you directly).  There is a great quote by one of my favorite baseball managers that talk about this:

I don't think a manager should be judged by whether he wins the pennant, but by whether he gets the most out of the twenty-five men he's been given. - Chuck Tanner

There is no book in baseball or software architecture

Many of the tactical decisions that I talked about have "conventional wisdom" answers to them.  For example, man on first with 0 or 1 outs and the pitcher up to bat, the pitcher should bunt.  This style of management is called "by the book", which is a reference to a mythical set of rules that contain the answers to all situations.  You can imagine the software architecture equivalent.  If it is a function that is needed by more than one platform, or is called by 3 or more applications, it must be implemented as a SOAP Web Service.  That may apply is many or even most situations, but there is no book of rules to follow in software architecture.  There is another quote that fits this notion as well:

"The Book is nothing but a piece of garbage. My book is me." - Chuck Tanner

Third Base Coach

This is the fourth 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.

Coaches in baseball are unique in a couple of ways compared to the coaches in other sports.  One of the most obvious differences is that in baseball, the coaches actually wear the team uniform.  I personally cannot think of another sport where this is the case.  In some other sports the coaches actually have to comply with a dress code that is vastly different than the players (I think it is the NBA that requires the coaches to wear coat and tie when they are at court side).  Not only do the coaches in baseball wear the team uniform, but they are assigned a number just like the players on the field.  The coach is really a part of the team.

Another key difference between coaches in baseball and coaches in other sports is that two of the coaches in baseball are actually allowed on the field of play during the game.  On the first base and third base lines there are two coach's boxes where the team can choose to have a coach positioned during the game. 

There is a distinction between this and other sports that allow coaches on the sidelines (such as soccer, football and basketball).  When a coach is on the sidelines in those sports, they are totally out of the field of play.  A ball that leaves the field of play is dead.  In baseball the foul territory where the coaches stand is still in play, so a player can catch a foul ball in the coaches box and the batter will be out.  A ball can be overthrown during a play and hit a coach, interfering with the play; there are even special rules that govern when this happens - which is not very often, because the coaches are usually pretty good about getting out of the way.

Coach

The coaches in baseball are literally feet away from the action and are able to interact with the players in a deep and meaningful way.  When a player reaches first base or third base safely the coach can give him encouragement and intelligence about how the pitcher is delivering the ball to the plate.  This can help the player decide if this is a good time to attempt to steal a base or take only a short lead off of the bag (to avoid a pickoff move).

The third base coach is an integral part of the action when there is a man on base and there is a ball hit deep into the gap or down the lines in the outfield.  As the runner on the base is rounding third a split second decision has to be made to send the runner to home or to have him hold up on third base.  The player is in the worst position to make this decision, as his back is to the outfield.  The third base coach is the one who makes the decision to send the runner or not.  If you have ever been to a game in person, nothing is more dramatic that seeing the third base coach swing his arm wildly, followed by a close play at the plate.

So what can we as software architects learn from the coaches in baseball?

Knuckles at third

Wear the Uniform - Often times I see people make too much of a distinction between the architect and the developers who are working on a software development project.  This can manifest itself in a lot of ways, and many of them are bad.  The role of the architect is different than the role of the developer, but they should be seen as one cohesive team.  This statement applies equally well to the designers, testers, DBAs, server tech and project managers on the team as well.

Be a part of the action - Architects are sometimes referred to as Ivory Tower dwellers.  Sometimes this is meant as a joke, sometimes is a half-joke and other times it is just downright true.  As an architect we should strive to be as close to the field of play as possible.  The perception when you are away from the field of play is very skewed.  Get out of the Ivory Tower (maybe press box is a better analogy) and get into the coach's box.

Be a coach - One of the things that I did not note in particular when talking about the coaches is that most of them are former professional ball players themselves (I don't think that is unique to baseball coaches).  They bring with them years of experience that they can impart to the players them are coaching.  Most of us who carry architect in our title were at one time developers ourselves and as a result, we carry with us many years of experience.  In addition to architecting the application, we can make the team more successful by sharing our knowledge with the team. 

Cubs vs Padres May 14, 2008 By Anthony Handley, used with permission

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.

Craig Counsell at third base

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".

Pudge on Deck

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.