Update on 5/25: Added a couple of new terms to the Twictinary and fixed a broken image (thanks KeVron).

I like the Twitter platform a lot.  I have the very boring handle of @larryclarkin if you would like to add me to your follow list.  My creativity was at an all time low when I picked the handle, but I just tell people that I wanted to be easy to find as opposed to admitting that I have yet to come up with a cool handle to use on the Internet.

If you are not familiar with Twitter, it is a social network built around micro-blogging that is a great example of software + services with multiple clients that implements RESTful services on an Internet scale.  You can also describe it as an Instant Messaging system that all your friends (and even perfect strangers) can ease drop on the conversations.

It is not quite a verb yet...

I was recording a podcast today and the person I was interviewing dropped google (the verb) in the conversation.  Of course he meant "search", but the word google has become synonymous with the word search (note:  Google does not want you to use their proper noun as a verb unless you are talking about their proper noun). 

I started thinking that when we as a society create new words around a platform, then that is a sure sign that it has taken hold.  Google (the verb) is probably the most widely accepted example of this, but Twitter has created a whole new set of words itself.  So I figured I would put together a Twitter Dictionary (or Twictionary).  This is just my quick stab at it, let me know if you have found any that I have missed:

Tweet- The < 140 character message that is sent out as part of your feed.  Proper usage: "I sent that out in a Tweet today".

Tweoples - A reference to the twitter users that are following you.  This is the Twitter version of the term "peoples".

Tweeps - A slang version of the term Tweoples and it is the Twitter version of the term "peeps".  Proper usage: "Good night my Tweeps".

DM - An acronym for "Direct Message" a Twitter feature that allows you to send a message to one Tweep that will not appear in the public timeline or the feed or either the sender or receiver (a private message).  Usage: "DM me the root password to the server".

Twittercon - The square picture (73 x 73 or smaller) picture that you associate with your account (or if you are lame the default picture that Twitter provides you).  Proper Usage: "my smoking obama twittercon is finally going to pay off" - as seen in the feed of @KeVroN in reference to his Twittercon:

Twitterdiction - a prediction that is made in the form of a Tweet.

dWittering - The act of sending a tweet out when you are intoxicated.  This act is often filled with regret and or shame when the tweet or tweets are seen the next day.  This can also be considered the SMS version of "Drunk Dialing".  Special credit goes to @joshholmes for first pointing out this term to me and for perfecting the art of dwittering.

Ninja Tweet - The act of sending a tweet about someone without their knowledge (or consent), usually why you are talking to them (coined by Denny Boynton in his post on Twitter and the new social).

Cross Slide Scripting (XSS) - the act of Twittering/Tweeting to the speaker so his computer displays insults about the talk, DURING the talk (coined by @PHPTek during the PHP|Tek 2008 conference)

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.

LEGO 4915 Mini Construction 02
By BuckLava
Used Under Creative Commons

In the United States we just finished income tax season.  Like many people I do my  own taxes with the assistance of one of the major tax software packages (the one I actually use is not important).  I purchased the software at a local office super store.  I installed the package off of the CD by clicking a couple of buttons on the wizard.  I updated the software online several times (over the course of several weeks).  I gathered all my data and answered all the questions.  In the end I filed electronically and all was well.  I spent a total of about 5 hours on my taxes and saved several hundred dollars over going to a tax professional.

Buying a single user software system (such as the tax software) is as close to a pure "buy" in the "buy versus build" decision as any of us will ever get when there is custom data involved in the application.  But most companies will spend a lot of time and energy discussing / debating / arguing the question of should they buy or should they build without ever question the fact if they are actually buying a solution or not.

Buy then build is what we usually do

When we buy a package based solution of any complexity it does not usually come "out of the box" ready to use like the tax software that I used to do my income taxes.  There is a lot of work that needs to be done to get the application running in your environment.  I am speaking of activities beyond actually installing the application on the servers and desktops (which can be complicated in and of itself).  Even in something as simple as a General Ledger application included in an accounting package there are literally dozens of decisions that need to be made before the system can be brought online and loaded with your data.  And often times, loading of the data is the hardest part of all. 

We (as an industry) tend to compare the cost of building a solution with the cost of purchasing a package based system.  When we do the math, we usually include a very naive and extremely low estimate of the cost of getting the software up and running.  We tend to underestimate all the configuration, test and integration cost (that usually involves some software development) to get the package integrated into our environment.

Configuration is building

If you have ever been through the due diligence process on a packaged based software evaluation, you will often hear from the vendor something to the effect of "that is a configuration item, not custom code".  The vendor is telling you that this is a parameterization option in the software.  While you may not have to write code to get it to work, you do have to get the parameters correct and more importantly, you have to test the application with the specific parameters that you have configured and you have to do all that in the presence of your data.  The configuration process is "building" software, even though it is not writing code.  I have actually been involved in packaged based implementations where there have been literally dozens of people on the "configuration team".  They may not be developers, but these are still resources that you need to acquire (sometimes scarce resources that can cost you more than developers).

Yes I believe in purchasing software

I want to make sure that nobody confuses my stance on package based software.  I think it is a very healthy thing for organizations to buy software packages, especially in areas that the software will not provide them a competitive advantage (easy example: you will almost never get a competitive advantage out of your account process - so that is a good thing to purchase).  As an industry, we need to be a little more honest with our terminology and not call it Buy versus Build, but rather Build versus Buy then Build.

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