Over a million developers have joined DZone.

What Software Architects Can Learn from Baseball Teams

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

WhiteSox20130513_81_1

My friend Larry Calrkin did a whole series on Architecture by Baseball, but after going to a recent White Sox game I got to thinking about the how baseball mirrors my experience.  For me it boils down to specialization, team work and leadership.

Every team member has their specialty.  Infielders have great reactions and throwing accuracy.  Outfielders can cover distance quickly and throw long distances.  There are starting pitchers who have great control and endurance and closers who throw nasty pitches for a short time.  Likewise, there are specialized positions on a development team.  There are UI developers who improve the user experience.  Your have performance experts who can find every potential roadblock in a a piece of code.  Then there are security specialists, database gurus and product experts.  Each specialist has something to add to the quality of the final product.  As an architect you need to give each of these specialists room to do what they do best.

This then leads to team work.  You can have a team of great specialists, but if they don’t come together as a team it can mean failure.  If baseball players don’t communicate you end up with errors that can gift wrap runs for the opposing team.  The problem with a software team is that the opposing teams are called missed requirements, missed deadlines and poor quality software.  As an architect we can help identify which of our specialists are best to attack a particular problem and also help the entire team understand how their tasks fit into accomplishing the project.  This helps to bring the team’s focus together instead of working as individuals.

Who brings all this together?  The manager is the leader on the field.  I look at this position being where the architect works.  Yes there is a project manager, but I think of them as the general manager who clear the way so the manager can get the goals of the team accomplished.  The architect should be the person who brings the team together and gives it direction.  I also believe it is part of my job as an architect to help the developers on my projects to improve their code quality and the way they interact with stakeholders.  Leading also means being willing to build proof of concepts or even taking on coding components so that your team members understand that you really practice what you preach.

Ultimately you need know as much as you can about every position, leverage your specialist like pitching and hitting coaches to fill in missing information, bring your players together to win and be a leader on the field.  Good luck.

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

Topics:

Published at DZone with permission of Tim Murphy, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}