Architecture By Baseball: Spring Training

Photo Title

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.

Plunging your way to better code

Photo Title

I have talked with several customers recently about the benefits of using Continuous Integration (CI) practices as part of your development process.  I am a big believer in continuous integration as I have seen the software quality greatly increase on several projects that have implemented the practices.  The only thing that I have seen increase the quality more is a good base of unit tests and the good base of units tests is pretty much a prerequisite for CI (you can do CI without unit tests, but you are not realizing a fraction of the benefits).

One of the key benefits of CI is that it makes everyone pay attention to the build as a vital part of the process.  When the build is done by a dedicated person, the Build Master as they are sometimes called, you don’t get that sense of ownership. When the team I was on first implemented CI, we wanted to create the sense of ownership in every person on the team.  We also wanted people to take the build seriously, even if it was just an interim CI build.  We also wanted to have a little fun with it, so we bought a plunger. 

We had a very simple team rule: anyone who broke the build would have to have the plunger visible on their desk from the time that they broke the build until the next person broke the build.  There was a bit of shame involved in this, but it was meant to make you more aware before you committed code into the system.  At first we noticed the plunger moving around quite a bit.  As time went the team started following better practices: getting the latest version more frequently, adding additional unit tests and running the build locally before committing source.  The plunger moved less frequently which also motivated the team to increase their quality, because if you broke the build you knew you were going to have the plunger for a while.

These were the obvious benefits that you would expect from people paying attention to the build.  The unobvious benefit was how much more aware that the developers on the team became of the dependencies on each other’s work.  You might commit a change and it work fine, but a corresponding change in another developers code could cause the build to fail later (our plunger rule involved root cause analysis and you could inherit the plunger after the fact even if your change did not break the build right away).  This increased the communication among the developers on the team, which almost always increases quality.

So you want to increase your code quality, one of the best investments you can make is a $3.00 plunger.  And please, don’t try and save a few bucks by grabbing one out of the janitor’s closet.  🙂

Adapting to the situation

I visited the Chicago Auto Show this past weekend and got to see a lot of neat displays of current and upcoming vehicles.  I have gone to auto shows on and off for the past few years and one of the real trends that I have noticed is that the displays that accompany the vehicles themselves have gotten more and more interactive.  In years past you would get to see 10-15 cars from a manufacturer and then would would get one or more brochures to take with you.  The displays of the cars themselves are much more interactive with vehicles that are partially taken apart or turned on their side (so you can see the undercarriage).  There are also a lot of computer based kiosks that you can interact with (to compare models, etc). 

I took the above photo of one of the keyboards that was built into an interactive display (there were several similar kiosks with keyboards like this on the show floor with only minor differences).  You can see that this is not your typical off the shelf keyboard that ships with your desktop machine or that you pick up at your local computer store.  The profile of the keys and the overall keyboard is one of the obvious things.  The hardware is specifically designed to be touched, pounded on and man-handled by the thousands of people that will use the kiosk during the course of the auto show.  I did not test it out but I bet the keyboard it sealed in such a way that if you spilled a drink on the keyboard it would not break the unit; you may need to wipe it up or your fingers will get sticky :-).  Clearly the company that created this display did their homework about the type of abuse that the hardware would take.

Do you observe your software in the field?

There is a lesson that we can take away from observing the kiosk systems that are designed to be used at high traffic trade shows: we need to see our applications in action before we can fully appreciate the full user experience.  This does not only apply to high traffic situations like the trade show kiosks, but it applies to software being used in all situations. 

I see this when I visit my local bank and see the tellers struggle to use the mouse on their narrow workspace (I think that these particular teller windows were built before PCs were common).  If the software developer spent some time observing the application in practice they might build in better keyboard support to the application, or at least recommend purchasing a trackball that would be easier to use in a confined space.

Even if you are developing web applications you can learn a lot about the use of the application by watching someone use it in action.  Simple observation might give you great clues to issues with your software: 

  • Do they use they menus that you provide? 
  • Do they “deep link” bookmarks/favorites/shortcuts in your application in a way that you did not expect?
  • Are they running in a much smaller or larger resolution than you are testing for?

Obviously if your application is broad reaching, you are not going to be able to see even a small percentage of your population using your application, but even seeing a couple of typical users will give you great insight into things that you can improve in your application.

Have you tried Microformats?

I have been giving a lot of thought to interoperability lately (I wrote a little bit on it a couple of weeks ago in Trains and Interoperability).  As an industry, we spend quite a bit of effort on having dissimilar (and even similar) computer systems communicate with each other in an easy and safe manner.  We have spent a lot of time just getting the systems to communicate with each other “on the wire” and we have made great progress in the last 10 years on getting systems to just talk to each other (Web Service standards have made synchronous calls across platforms almost a non-issue). 

We have not made as much progress on the data formats that these systems use to communicate.  With a few exceptions, there are not really any universally accepted standards.  A codified system to provide data formats is one of the things that Microformats provides.  For this reason and because they are so easy to adopt, Microformats are and important web standard that we should pay attention to.

Microformat – the example

The easiest way to explain Microformats is to show them in action.  The classic example of a microformat is the contact card (or hCard) which lets you tell people how to contact you.  I used a plug-in for Windows Live Writer to create my card and it is shown here:

Microformat – the mark-up

So at this point you may be saying “Big deal, it looks like just HTML”.  The difference between this and just plain old HTML is that it is marked up with specific tags that are defined by the standard.  The markup is done with specific CSS classes (which are an extensible standard) as opposed to using HTML to mark it up.  If you do a “view source” on your code you will see

and tags that are match the names in the specification.

<div class="vcard">
    <span class="fn n">
        <span class="given-name">Larryspan>
        <span class="given-family">Clarkinspan> 
    span>
    <div class="org">Microsoftdiv>
    <div>
        <a class="email" href="mailto:blog@eraserandcrowbar.com">blog@eraserandcrowbar.coma>
    div>
    <div>
        <a class="url" href="http://eraserandcrowbar.com">http://eraserandcrowbar.coma>
    div>
div>

One of the best benefits of using CSS for the markup is that it degrades “nicely” on older browsers and it does not have to affect the layout of the page.

Microformats – the viewers

The real magic of the CSS / microformat is twofold.  Now that the page is marked up with the microformats, a program that is looking for contacts can easily find them on the pages, as opposed to having to do a lot of complicated parsing and having meta-data about the site.  That is the machine to machine type of interaction.

For human to machine interaction, you can add an extension (or add-in) to your browser that understands microformats and it will “light up” the experience in the presence of a known microformat.  This is a screen shot of upcoming.org (an events site) with an Internet Explorer extension from the oomph toolkit; recently released by Microsoft (it contains several goodies for microformat development).  The extension found 74 upcoming events on the page and will allow you to scroll through them and add them to your calendar with the click of a button (6 different calendars types are supported).

Oomph Microformat overlay

The event (or calendar) microformat is called an hCalendar.  One of the neatest things about microformats is that they are building out a taxonomy of items that you can tag up (events and contacts are just the first formats and most supported ones).  You can see a list of the ones “in the works” on the Microformats wiki.

Note: Microformats were featured on a recent episode of the Thirsty Developer Podcast.  I sat down with Pete Prodoehl who was the first person I ever heard mention Microformats.  Give the show a listen if you want a casual conversation on why they are important.

Social Network Fatigue

Social network fatigue – n. The ennui induced by persistent solicitations to join new social networks. It is especially acute in those who are already members of more MySpaces than they can remember. (from the Wired Jargon Watch)

I have gotten at least a dozen people asking me (via e-mail, SMS or in person) questions about why I am not on Twitter any more.  Last week one person was very concerned because not only was I not on Twitter, but the Thirsty Developer Podcast website that I co-manage with Dave Bost was down (we had a problem with a configuration change that was made by the ISP this past Monday).  So I wanted to let everyone know that everything is okay, I left Twitter and Facebook by choice in early December.  I left both of these very popular social network sites, because I was very distracted by using them and quite frankly I was feeling a lot of fatigue in keeping up with them.

Addicted or distracted?

I hear a lot of people say that they are “addicted to Twitter” and I did a quick search and found that thousands upon thousands of people have written that very phrase on blogs, articles and on twitter itself.  I don’t think I was addicted to twitter (or any social network), but I did find it distracting me from things that I feel are more important.  I had over 300 followers and I was following over 300 people at my peak on twitter (I followed the karmic rule that if a real person followed me, I would follow them back).  When I looked at the timeline, it was very easy to get lost in conversations flowing back and forth.  I found that every time I opened a twitter client I would spend 1-15 minutes browsing the feed.  This usually happened when I had much better things to do.

The final straw

In early December I got a tweet from someone who (politely) pointed out to me that I had not updated my blog in over a month (it was actually closer to 6 weeks).  I really enjoy blogging and I was really disappointed in myself that I had gone that long without posting an article.  So I decided to take the time that I spent on twittering and facebooking (is that a word?) and channel it into more consistent blogging.

Trains and Interoperability

The other day I took the Amtrak Hiawatha into Chicago.  I really love taking the train, because I don’t have to fight traffic, find a parking space, it gets me there at a predictable time (usually) and it allows me an hour and 15 minutes to get some work done on my laptop.  Plus I think that train travel is kind of cool.  They give the train routes cool names like the Hiawatha, Empire Builder and the City of New Orleans.  It gives a little romance to train travel that has been beaten out of air travel.

One of the interesting things about the Hiawatha is that when you are in Wisconsin you are riding on the rails that belong to the Canadian Pacific Railway.  I know this because on occasion you get behind a slow moving freight train, which will add a few minutes on to the trip.  Once you get into the Chicago area, you switch from the CPR rails to rails that belong to Metra, the commuter train company that services the Chicago area.  Most days you never notice the transition between the two rail systems, even though they are 2 completely separate entities.  We take for granted the interoperability of railroads; but they were not always as interoperable as they are today, the issues were worked out long ago, but it took quite a bit of time.

The early days – a standard per company

Rail cars run on a gauge which is the width of the rails and also dictate the width of the cars that run on them.  There are various reasons to have different size gauges – wider gauges allow for faster travel, smaller gauges are cheaper to construct and allow for sharper cornering.  In the early days of rail travel in the United States, the individual railroad would decide on the gauge that they would use.  This meant that the rail cars and the tracks were specific to the company.  Did I mention that there were dozens of rail companies in the United States? 

You can see the problems that this would create; rail cars where not interchangeable as an example.  The real issues came when you reach a point where the gauge changed (called a Break of Gauge).  There are a couple of solutions to this, one actually involves rails cars that can have their gauge changed (a time consuming operation) and another involves tracks that are dual gauged (a more expensive option).  In the early days of train travel the solution was usually to unload the passengers or cargo and reload them onto a different train.

Over time the individual companies in the United States came to the conclusion that they should come to a consensus on one standard gauge.  Which gauge was picked was spurred along by decision that the transcontinental railroad would use the standard gauge (4 feet, 8.5 inches).  This same process was repeated in most countries.  It is interesting to note that even today there is not a worldwide standard of track gauge.

Union Station

Once the track gauges where standardized the next big interoperability leap forward was standardize on the stations in a town.  Originally each rail line had their own stations where they stopped.  For towns that were only served by one train this was not a big deal.  For larger towns, it became a nightmare, especially for passengers that had to make their way from one station to another.  The individual stations were replaced by the concept of a “Union Station“.  A single facility that would serve more than one rail company.  The first Union Station was in Indianapolis, IN, but the concept spread all over the United States (Did you ever wonder why do so many cities have a Union Station).

How important was interoperability?

I had a great, great, great grandfather, Theapolis Smith Hickman, who fought with the 33rd Tennessee Infantry (Confederate) at the Battle of Shiloh.  Shiloh (also known as the Battle of Pittsburg Landing) was one of the bloodiest battles of the Civil War and was very decisive in deciding the outcome of the war.  It also propelled Ulysses S. Grant to prominence and eventually into the presidency of the United States.  What is barely mentioned as a footnote is the reason that they battle was fought at all.  Grant had ordered his generals to seize the Memphis & Charleston Railroad, which was of strategic importance to the South.  The Memphis and Charleston line was the only east to west line across the confederate states, which made it important just by itself.  However at Shiloh was the intersection with a north to south line that was the same gauge as the east to west line, increasing the importance and hence the battle for an area that was otherwise unremarkable.

Interoperability in software

I hope you see the obvious parallels between the railroad industry and what we go through in adopting a standard in the software industry.  Some or the parallels that I see are:

  • Early on individual companies adopt a standard, often times these are in conflict, each standard has its own merits (usually), they are just different
  • We often build hokey solutions to get the standards to work together (dual gauge like technologies – JNI Bridges come to mind)
  • Sometimes it can take outside intervention to spur a standard on (Government intervention like in the transcontinental railroad)
  • Over time the inefficiency starts to wear on everyone.  Eventually a single standard emerges.
  • Conflicts over standards can be unnecessarily bloody (the battle of Shiloh)  🙂

Architecture By Baseball: Moneyball

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

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.

Book Review: Seeing yourself as others do

Seeing yourself as others do

I have mentioned the book Seeing Yourself as Others Do to a number of people over the last several weeks.  We have been talking a lot about soft skills over the past couple of months at our ArcReady program and I have mentioned it each time I have presented the session.  I also attended a professional development training session last week where skills like listening, negotiation, body language and strategic thinking came up quite a bit.  I have mentioned it enough that I thought that I would go ahead and write up a proper review of it.

Disclaimer

Before I jump into the review, I have to disclose that I know the two authors of this book personally.  Carol Keers was my coach a few years ago and I also got to know Tom Mungavan while I was going through the coaching experience with Carol; they both work for Change Masters.  I also got an advanced copy of the book to review, and as part of the review I gave them a quote to include in the book.  While I consider them my friends, I have tried to not let that affect this review.  The fantastic experience that I had with Carol as my coach probably did have an impact on the review.  🙂

Quick Review

There a probably 1000+ books that cover soft skills from a variety of perspectives and I am sure that many of them are quite good.  Seeing Yourself As Others Do has a few advantages that make it a great book to read if you are interested in exploring soft skills.  The book is very easy to read, written in conversational that that is easy to consume and uses “real world” stories as examples to communicate the techniques presented.  It is so easy to read that if you take it along on a business trip, you will probably have it finished by the time you get back.  One of the best things about the book is that within a couple of chapters, you will already be able to start applying the techniques that are presented to you.  Finally you will learn about yourself, not some program or theories that the author is presenting.

The Decade Shift

One of my favorite parts of the book and the coaching that I got from Carol years ago is the concept of the decade shift.  To summarize the concept:  As you move from decade to decade (from your 20s to your 30s to your 40s – not from the 1980s to the 1990s) the expectations of you and how people expect you to behave changes.  Your job or your role may not change as your age does, but how other people treat you will change and you will need to evolve your behavior in accordance with the change in your age.  At first glance it may seem “unfair” for the expectations to change, but that is human nature.  If you get nothing else out of this book, this section will give you wonderful insight.  One of the reasons this book has been on my mind is that I re-read it over the past couple of weeks just as I turned 40, I figure that would be a good time for a refresher course on the decade shift.

The importance of soft skills to an architect or developer

As I mentioned, we have been talking about soft skills in the latest ArcReady programs.  The “dirty secret” of the ArcReady content is that 95% of the content was not targeted at architects in particular.  Virtually all of the conversation would apply equally well to any technical audience and most of it would apply to any profession, even outside of technology altogether.  We gave the content an architecture slant simply by sighting examples from our own experience as software architects.  Since the content is really job agnostic, you might be asking yourself “Why did Microsoft devote an entire series of their architecture program to soft skills”.  The answer to this question is two-fold, first Soft Skills are just as important as technology skills to architects and developers.  Secondly most architects and developers could use some improvement in their soft skills and will make great leaps in their career by making a small investment in soft skills.

Diversity, Inclusion and Legos

WomenBuild Creation
WomenBuild Creation

Last month I got to attend the Microsoft Professional Developers Conference (PDC) in Los Angeles, CA.  The PDC is a special event in an of itself and I plan on writing a blog post specifically about the PDC soon.  One of the neatest things about the PDC is some of the extra events that take place before the actual conference starts (the pre-con) or that take place each night during the conference (there are lots of parties and other events to attend while you are at the conference).  On the Sunday afternoon before the conference started I got to attend the WomenBuild event. 

WomenBuild was an event focused on bringing to the forefront some of the issues around Women in Technology.  I have been interested in the subject of Women in Technology for a number of years.  Dave Bost and I recently did an episode of our Thirsty Developer podcast on the issues of women in technology were we interviewed four of our colleagues on their experiences and what they are doing to further the cause and how guys can help in the cause to.  It is still one of my favorite episodes of our show.  The WomenBuild event was going to be a different event than other Women in Technology events, because it was an interactive session involving Legos, specifically the Lego Serious Play program.

Lego Serious Play

Serious Play is a product of the Lego corporation.  It is a tool to help foster discussions with trained facilitators leading the discussions.  The discussions can be around any number of topics, but one of the popular ones is around diversity and inclusion.  This is the one that WomenBuild used at the PDC.  The Lego blocks are used to tell stories and to get the people in small groups acquainted with one another.  The focus of the session is on group interaction and problem solving, not on playing with the Legos (the fact that you get to play with Legos is just a bonus).

My Experience

I have to admit that I did not know quite what to expect as I entered the room to join the WomenBuild event.  The event said that it was open to males, but as a guy I was wondering how accepted I would be to join the session.  I certainly did not want to make anyone feel uncomfortable with my presence.  My fears were quickly put aside as I was welcomed when I walked in the room and when I joined a group.

I was quickly amazed as I started to work with my small group.  I sat down at an 8 person table and we had people from 4 continents sitting with us (Europe, Asia, North America and South America).  As I side note, I know that Australia also had representation at the event.  Even though PDC is a global conference, I was still surprised that we had such a diverse group at such a small table.  The breadth of experience at the table was also apparent.  There were people who were early in their careers (only a few years out of college) and people with many years of experience.  The seven incredible women that I worked with helped make the event very special for me.  I had one particular eye-opening experience when the person at my table described the cultural differences in her country which is in Southeast Asia.  Hearing the differences gave me a new respect for people from her society as they overcome barriers.

Want to get involved?

The easiest way to get involved in future WomenBuild events and other Women in Technology events is to join the Facebook Group that has been setup.  The Facebook group is a conduit for information and is meant to be a launching point for future events and a way to get the conversation started.  The team behind WomenBuild has great stuff in the works. 

WomenBuild is not just for people who work with Microsoft technologies, Microsoft is just sponsoring the group.  The group and the events are also not just for women, the team behind the group and the events want it to be a showcase for diversity and inclusion, so if you are a guy join the group and get involved too. 

Technorati Tags: ,

Architecture By Baseball: The General Manager

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