I have been studying copyright laws a lot lately.  I find our laws very fascinating, but I don't think that I could practice law professionally (Although my wife Jodie does accuse me of being a closet lawyer when we are having an argument a discussion).  There are a lot of things that I enjoy doing, but if I had to do them day in and day out I would lose interest in them.  But I do find the study of our laws, their origins and how they have changed (or not changed) to accommodate changes in our society fascinating.  Copyright laws are especially interesting.

Lizard

Copyrighted when it is created

One of the fundamental principles of the copyright laws (at least the ones in the United States) is that you own the copyright and can assert your rights without having to register them.  This is in sharp contrast to Trademarks and Patents.  Here is a blurb from the US Copyright office FAQs:

Your work is under copyright protection the moment it is created and fixed in a tangible form that it is perceptible either directly or with the aid of a machine or device.

The notion of a "created" work is at the heart of copyright laws and you will see "created" woven in and out of the laws.  I was a bit surprised when I recently saw a sign at a photography studio that said:

If it is created it is copyrighted

along with a very stern warning that the photos that were taken at the studio were property of the photographer, and that taking the photos to a store and having them duplicated was not allowed.  I think a lot of people don't understand this, because it is a picture of you (or your family or child or dog) and you paid the photographer to take the photos.  But according to the law - the photograph is not your yours, it is a work created by the person who took the photo.

Dive

Do we capture or create?

If you have seen me at an event or follow this blog, you will know that I am a photography hobbyist.  I am forever snapping pictures at events and trying to be the official record keeper.  I actually started college as a photojournalism major, so I think it is something that I never quite got over when I changed my major to CIS. 

I also like to take photographs in my spare time as we do things as a family.  Often times it is pictures of Zoo animals, as my son Hunter loves to see the animals at the zoo or other exhibits.  When we the family was on spring break I took some wonderful photos that are on my Flickr Account and I have included some of them in this blog post.  Up until now, you may have wondered, what does a picture of a Lizard have to do with copyright laws?

As I was taking these photos I kept thinking back to the sign at the photography studio.  I was doing a lot of work to take these photos: finding the perfect angle, adjusting the camera to accommodate for the lighting, making sure the focus was perfect.  But fundamentally I don't think I was creating the photograph.  I think the animals that I photographed were the focal point of the photo.  I was just the guy that bought the camera along.  I think I captured the magnificence that was already there.

If you are someone who makes there living off of copyrighted works, please don't take my statements wrong.  I have a deep respect for works that are created, but I think there are times that we overstate the "created" notion.  For example, it is very easy to find photos on photo sharing sights that people have snapped photos of something on the TV and then upload it with "All rights reserved".  There are about a dozen things wrong with that.

Nemo 

Note:  The photographs in this blog post were all taken by me at the Shedd Aquarium in Chicago, IL.  They are all available under a Creative Commons License. 

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.

Magglio Ordonez's Home run

A couple of years ago I read a great book called Management by Baseball: The Official Rules for Winning Management in Any Field. I am a big baseball fan, so a book that can teach me a little about soft skills while making it interesting I was all up for.  The author did a great job of using analogy and great historical references to make learning about the management discipline interesting to a baseball fan.

In homage to this book, I decided to create a series of articles (delivered as blog posts) comparing baseball to software architecture.  Here is a list of the articles:

5 tool architect (published on April 21, 2008) - In baseball the 5 tool player is one that excels at the 5 baseball skills.  We compare this to the skills that are important for a software architect.

The Utility Player (published on May 7, 2008) - In baseball a utility player is one that can play more than one position, making him especially valuable on defense.  We talk about the many flavors of architects and talk about how an architect is more valuable if they can play more than one role.