Go or nogo?

Whenever people make decisions on whether to go ahead with a project, they think if it makes business sense. Of course they do. What happens much more rarely is people thinking about how much sense it makes in terms of other architecture layers. The organizational architecture gets some attention but below that, it's all forgotten.

However, most of project/product failures come from the new stuff not fitting with the existing things in terms of functional, technical or support architecture. Of course, discrepancies there will mean changes to the original plan and can ultimately translated into dollars that end up in the business case, but wouldn't it be much cheaper to consider this in the beginning rather than all the way through the project?

This issue is also tied to the "10-minute-crap" problem: whenever people come up with an idea that is really easy to implement and makes some business sense they go "well, it does not bring massive business benefits but it's easy to do so let's just build it". Wrong. Because this is how you end up distorting all underlaying layers. Why would one do something stupid just because it takes very little effort?

To recap: go/no go decisions should be made by considering all the aspects of the project, not just the business top line.

Aspects of an Architect

My friend and colleague Sergei made a comment the other day after listening to a job interview that an architect should really have either some managerial experience or possess the potential to become one.

This is entirely true, I think. Being a leader or having the potential to become one would be even better. Drawing UML diagrams of Things to Be is just a tiny piece of the work an architect has to do. He or she also has to make sure people actually understand the drawings, has to tackle resistance in build or buy situations, guarantee preservation of knowledge if the project is put on hold or team members change and so on. All of this requires some managerial pedigree to be successful at. The thing is, that, believe it or not, the organizations are made of people and the computers are just there to help.

So next time at a job interview when you are asked how to choose between two major technologies, you better mention the skills of people around you in the answer.

Metaphor: Dripping water

It is said that the best way for a leader to communicate his or her vision, values and beliefs is through telling stories. This is also true for architects who, being engineers and pragmatic and all, tend to cut the stories short and turn them into metaphors that help to explain complex concepts to fellow engineers and also customers. XP is big on metaphors and I have found them useful, too. This is why this series is created: every now and then I stumble upon one that seems to work and convey an idea particularly well. Which means that it just might be worth sharing. Let's see how many of those I can come up with.

We had a team at Skype that struggled with incoming feature requests. They were short on resources and their importance in the business was growing rapidly. So everybody was busy throwing business ideas, feature requests, project proposals, bug reports at them to a point where most of the key people spent most of their time reviewing, estimating and designing solutions for them. Which, clearly, had to stop. This is not an uncommon problem and the obvious solution was to introduce a quantization mechanism that would allow to split the constant flow into manageable chunks. the only problem was that the customer did not want to wait, they wanted their thing to happen yesterday. Enter the Dripping Water Torture metaphor. Everybody has probably heard that at medieval times people were tortured with water dripping on their sculls for lengthy periods of time. Even the Mythbusers did an episode on it. This is how it feels being constantly bombarded with all sorts of functional requests.
Now imagine that instead of water dripping on your forehead and slowly driving you bonkers, a man with would turn up once a day and threw a bucket of cold water at you. Unpleasant as that might be, it's not much of a torture. The message was heard loud and clear and now there is at least an understanding of what we are trying to solve with the recent process changes.

Book: Skunk Works

The other day I got my hands on the copy of "Skunk Works" by Ben R. Rich and Leo Janos (thanks, Lauri!) that describes the internals of a unit of Lockheed that was (and still is) focused on developing high-tech weaponry for various parts of US military. Just breathed it in and have probably already bored everybody to death with quotes from it. This is because the book is just fantastic not only because it describes how some people get to build their own hundred-million-dollar gadgets and send them flying over remote parts of Russia but because it shows how to set up, maintain and sell a extremely efficient team of highly skilled people that spit out a constant flow of staggering innovation. Let's take a look at some of the main points the book makes:

Get isolated, concentrated and focused
Kelly Johnson, the legendary leader and founder of Skunk Works, was an engineer. He was also an autocratic and charismatic leader. The former gave him a very pragmatic mind and the latter the ability to enforce his vision of a perfect engineering environment. In addition, the unit was forced to work under heavy secrecy which lead to physical separation from the rest of the Lockheed organization and a very high clearance overhead for every person added to the team. Also, the premises allocated for the team were spartan to say the least as they were yet to prove its worth. All of this combined led to a very small intimately integrated team following a clear vision in a complete isolation from corporate inertia. Which, in my mind, is the receipt for a perfect task force. I think most of the Skype core functionality is written this way (of course, the guys did not have a large organization to separate from in the beginning but that has all changed now)

Get down and dirty
Designers of the aircraft worked as close as possible to the people actually assembling them. Which meant that any part not fitting, any design flaw and any change could be implemented immediately and both parties got instant feedback from each other. This is the way a system architect should work.

2/3HBS=BS
The author describes how he went to his boss, Kelly, to ask for a recommendation for the Harvard Business School. Kelly says:

... You don't need Harvard to teach you that it is more important to listen than to talk. You can get straight A's from all you Harvard profs, but you'll never make the grade unless you are decisive: even a timely wrong decision is better than no decision. The final thing you'll need to know is don't halfheartedly wound problems - kill them dead. That's all there is to it.

After graduating, Kelly asks Ben for his appraisal of the study and Ben writes down the above equation. Until now I thought that I was the only one finding that my MBA studies did little but confirm what I already had learned from experience and it is good to know much smarter people have got a similar impression from much better schools.

The rules.
The fourteen basic rules Kelly wrote down for the cooperation between Skunk Works and the military. They are too long to quote here but they encapsulate a perfect relationship between a technology contractor and its customer.

Always take two steps
After the U2 had flown over the USSR unscratched for about a year it was clear to Kelly Johnson that eventually the soviets will find a way to shoot it down (it eventually happened three years later) and that whatever improvements were made to it, the hostiles would, again, in a couple of years figure out countermeasures. Ergo, the only sensible thing to do is to take _two_ steps at a time and not one. So he went on and initiated what eventually became the Blackbird. That was 2030s technology in the 1960s. The point is, that you should really think big and not let yourself be hindered what is thought to be impossible.

All in all, the book was a true revelation: I have seen too many management books that are just full of crap. This one says it all on a couple of pages and fills the rest with examples of how it all was applied to create technology that some 40 years later is still to be surpassed. Read it.

Goodbye and welcome!

It's time I got serious. Well, sort of. This means that from now on, my serious thoughts and more thorough writings on software architecture and management in general go into a separate blog called Human Architecture and the rest of my passions and moans will stay at The Place for BelZaah. Let's just say that posts going "I had a crappy day" and "A software architect at Skype thinks this or that" really should go to two different places.

About the name. I used to be a technology-oriented person. In recent years, however, I have grown to understand that technology itself does not do anything, it always acts in the context of an organization and its people. Hence, system architecture should always be considered in relation to the people who implement, use and live with it.