MAM from Betty Brinn

On Sunday the family and I went to the Milwaukee Art Museum to see an exhibit (the exhibit was wonderful, but that was the last day, so I won't tease you with the details).  Milwaukee has a wonderful art museum, but there is one downside to the museum and that is that the building itself can be a huge distraction from the works of art inside the museum.  The building itself is a real work of art.

The art museum itself is actually a couple of buildings, and what most people think of as the museum is actually the Quadracci Pavilion that was built years after art museum was opened, although the building is quite often referred to as "the Calatrava", after the architect.  The building was designed by Santiago Calatrava a Spanish architect who has built dozens of structures around the world (including such great works as the Turning Torso).  The crowning glory of the building are the "wings" that raise and lower during the day.  But as you wander around the building (both inside and out) you notice there are many great features to the building.  You can easily spend hours in the building amazed at the elegance of the structure (while you are there, do spend time looking at the art that the building contains).  To me one of the most fascinating parts of the building is actually the parking garage.

MAM Parking Garage

There are a couple of parking garages that you can use, I am talking about the one that is actually a part of the building itself.  It is an underground structure that is located below the Quadracci Pavilion.  The building is actually on the shore of Lake Michigan, so I am sure it is an engineering marvel because the garage is below ground so close to the lake.  But I am amazed how the parking garage has been incorporated into the structure and the theme of the overall building.

Hunter at MAM

Normally you think of a parking garage as a very utilitarian structure and the design usually reflects that notion (imagine concrete pillars that are evenly spaced through the structure).  The garage at the Milwaukee Art Museum reflects the design of the overall structure.  You can see how the lines of the pillars in the photo above are harmonious with the lines inside the building in the photo photo of my son; the spine type structures run the length of the building on both sides (the shape of the garage pillars are different because they are in the center of the building).  I can honestly say that it is the only parking garage that I have ever been in that I would consider elegant.

Gallery Entrance

Applying the principal to software design

Like the parking garage at the museum, most software applications have components that are utilitarian in nature.  The canonical example is the administrative interface that is only used by the system administrator.  Often times these are "CRUD" interfaces used to maintain reference tables used in other parts of the application.  These interfaces are often slapped together (I have heard more than once phrases like "that is a good job for the summer intern").  Even if the interface is not used by every member of the application it does not mean that it should not flow with the rest of the application.

Not just user Interfaces

The administrative interfaces are an obvious example, but there are also non-visible portions of the application that some times don't get the attention that they deserve.  There are always components that are not as "sexy" to build (think of the rating engine for an insurance company), so often times they are neglected.  Often times that are components to the system that don't fit in with the rest of the application just because they lack some attention to detail (no XML Comments, missing or inadequate unit testing).

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

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.

SXSWi 2008 Sketchnotes: First Spread
By Mike Rohde

Recently I found myself listening to a presentation in a lecture style room and the speaker was giving out some fabulous information (articles to look at, books to reference and blogs of subject matter experts to check out).  I was sitting in the front row of the room and did not want to break out my laptop to take notes.  I think it can be very distracting to the person giving the presentation, and I have a twitter addiction that I have to feed if I have an open laptop in front of me.  I wanted to jot down some of these gems that the speaker was sharing, so I started to send myself e-mails on my mobile phone with the subject containing the item I wanted to check out. 

My thought was that I would later transcribe it into tasks in outlook or just look up the book online to see if it was worthwhile.  I don't know if you have ever done this, but you think for a second that it is terribly clever but after 2 or 3 e-mails to yourself it become tedious.  Also you loose the context in which the "note to self" was written if you don't translate it quickly after sending yourself the e-mail.  I found myself thinking:

If only we had an easy way to take notes during a presentation or a meeting without breaking out your laptop

Then bam - it hit me.  This problem was solved in several thousand years ago: paper.  I promptly went out and bought myself a moleskin notebook and have been carrying it ever since.  Now I can quickly breakout my notebook (opening it is much faster than booting up a laptop) during a meeting and take notes that are all in context. If I need to transcribe it into an Action Item for later I put an asterisk (*) next to the line and create an outlook task next time I have the laptop open.  I also have this great record of the event to look back on.

But don't take my word on it.  Take a look at the sketchnotes that Mike Rhode put together from his recent trip to the SXSW Interactive conference in Austin, TX.  He captures the emotional awakening that paper can give you in his recent blog post about his sketchnotes:

For many SXSW attendees the sketchnotes seem to awaken positive memories, even several days later. This is one of the reasons I keep a travelogues when I go on trips. Notes and sketches of my activities help me recall clear memories — even years after the trip. Hopefully this will be true of my SXSW sketchnotes in the future.

I grew up in the Trapper Keeper generation, so I was used to paper.  I was a sophomore in high school before I was in the same classroom with a computer, and that was this mammoth Tandy computer that we used in economics class to simulate a shoe company for economics class, certainly not something to take notes on (after all floppy disks were "kind of expensive", you know).  Somewhere in the last few years I shunned the use of paper as "not cool".  I have taken a complete 180 degree turn on that decision.