Very cool

Huh, These guys have created something really cool. Have not been so excited about new piece of software since Blurb it would really solve some problems I have. Am yet to try it out (will let you guys know), but it sounds really good.

Sir Winston and a Lady

Sir Winston Churchill and a Traveling Lady. London, March '07

Greenfinch

A greenfinch in the Spring.

Went there

I went to the altar of friendship
the road there was long
finally got there
with some help from Ramones

I went to the altar of friendship
and there were familiar faces
god, I was glad
and so were they

I went to the altar of friendship
and I brought a sacrifice
it was accepted
I don't want to do without

I went to the altar of friendship
some of the faces were sad
that will come to pass
that will come to pass

I went to the altar of friendship
and found out
not everybody is on a quest
for dead presidents

Called the cops

The other day driving home through Tallinn I called the cops. It's not something I do often, but that one really pushed me over. There was a youngish woman driving in a medium-sized french car with a 4-5 year old girl in the passenger seat. The kid could barely see out of the window and I'm damn sure she was not wearing a belt or if she was, that would have been even worse. So I called the police and told them the make, model and license plate of the car plus the direction it was going.

What kind of sick people do stuff like this? If you want to make a head-shaped bump into your windshield, be my guest. If you attempt this with your kid, the kid should be taken away from you and you would be forced to drive without the belt till the kid is 35 years old.

Redpoll in the morning

Redpolls on their way back to north. 20th of March 07

Apparently, it's spring

Snowdrops in my back garden.

Girls

Kelly and Edith in Pärnu. January '07

Here were the tanks

Probably last photo from the Beijing series.

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.

The Forbidden City

The Forbidden City. Another take from the October '05 trip.

Start of a tradition?

I have been quiet for almost a week because last weekend kind of slipped past before I could grip it and this week I have been in London (missing my camera badly as the weather was brilliant). On flights and airports I did some organizing on my feeds, added a bunch of friends and decided to start posting daily (or at least very frequent) photos, maybe with some stories attached to them. Let this be a good start and let's see how far do I get.

A guard at Tiananmen Square at sunrise. October 2005.

Correction on the smokes

Apparently, when writing about the wolf smoking cigarettes the other way around a couple of posts ago, I was plain wrong. As a friend pointed out, he is smoking a specific brand of soviet smokes called "Belomorkanal" (White Sea Channel, also look at my post about history) which have a very long white filter and short gray part with tobacco.

Silly me, then. Also, he was kind enough to point out that 1411200 roubles will get you a railway wagon (560 000 packets) of those things. The fact that somebody actually knows that is kind of spooky. Anyway, thanks for helping out!

It's spring

This morning I discovered that it is almost possible to take a shower without turning on the lights, it's that light outside. Also, the weather is getting warm (ish), the birds are singing like crazy and there is a crow building a nest right behind the window of some of our developers. Weee!

Comments on the Architecture post from 3/3

Sergei made a valid comment on that post. The thing is that the layers are of different dynamics: the organizational structure changes much more often than the functional architecture which is in turn more dynamic than the technical architecture. Which means that any reorganization creates tension on functional architecture. If the tension is not handled and the two layers not synchronized, one of them breaks: either the functional architecture breaks apart with all the consequences to the underlying layers or the reorganization fails and is reverted.

Some old photos

Got delivery of Epson R800 last week which, after some initial issues with paper handling, is doing brilliant work. Printed out some views of the Golden Gate Bridge I took almost a year ago and discovered they are not in flickr yet. Fixed it. Also uploaded some new pictures of our Maine Coon. What a tail, eh?

Wait for me, rabbit

The other day somebody sent me a link to a youtube video that had scenes from an old Russian cartoon, "Nu pogodi, zajets", remixed and combined with a soundtrack by Rammstein. The video was not that good but the "Related" links rocked: somebody has uploaded all the old Nu Pogodi episodes every soviet kid adored! I had jolly good times watching them. They just do not make stuff like this any more. The whole thing is full of platnoi (sort of crook in Russia, amazingly google could not spit out any good links and my keyboard is too weak to go into detail here) references, signs of Soviet everyday life, reflections on different campaigns that frequently sweeped the great country and so on.

Also, they are refreshingly politically incorrect. And not in a way South Park is (which is apparently created under influence of controlled substances without any desire to reflect reality) but it shows how things really were. Look at the very first scene of the third episode. The wolf steps out of a makeshift garage (a _very_ familiar sight for everyone who has lived in the USSR) and lights a cigarette. And he lights it from the filter side.

And the music. It's a miracle: every scene has it's very own piece of music perfectly matched to it. The authors have not confined themselves to one style, oh no. They have picked tunes from folk to propaganda to rock to pop. Marvelous!

As opposed to Tom & Jerry and others, these cartoons were produced in very low volume. Between 1978 and 1985 only 15 episodes were made. In fact they produced more but the ones above 15 are not true to the original spirit and can not really be considered as part of the series.

Part social experiment, part attempt to amuse the crowd, I played one episode to my class during a coffee break. They are a mixed lot of various ages looking to get an additional degree in accounting. Most of the people enjoyed it and knew most of the scenes by heart but there actually were a couple of people to whom it really didn't say anything. On one hand it is a pity we don't remember good things that are not yet that ancient. On the other, it is probably better there is a new generation for whom the Soviet times is just something their parents sometimes talk about.

On architecture

I have been thinking that there should be a generic way to express the role of an architect in an organization and thus also helping people be better architects. So here it comes.

The layers
Architects know that system architecture is not a thing in itself, it is strongly bound to how an organization works in general. There are authors who have thought about that to some extent (like Christophe Longépé) but they usually only look at the technical or functional side of the systems. It seems to be much wider than that, let's build a stack here:

1. Organizational architecture. This layer answers questions like what business are we in? How do different parts of organization relate to each other? What are the core principles the organization lives upon? What business processes do we have?
   
2. Functional architecture. Every organization performs a certain set of functions in its everyday life. This layer deals with what clumps of functionality (like accounting, HR, customer service etc.) there are and how they interact.
3. Technical architecture. This is the domain usually attributed to technical architects and deals with logical components, integration methodologies, middleware and so forth.
   
4. Support architecture. The layer consists of processes tools, and organization that works underneath the technical architecture. Version control setup, release and testing procedures, coding conventions, team interaction, development methodology etc.
   

An example
Let's explore this layering using an example. Let's say a system architect has three projects on the table for evaluation, each of them approaching the concept of a corporate customer from three different angles creating a technically unsolvable puzzle: although the architect sees that it would make sense to have the three systems talking to each other this can not be done because one treats companies as phone numbers with some fields attached, the second one as a source for authentication information (several customers can operate under the same legal agreement) and the third as an entity that has to pay VAT.

How did it come to this? Apparently all of the layers were affected. Firstly, the organization was set up as a set of silos which do not talk to each other, which leads to the three different unsynchronized projects being initiated.

Secondly, the functional architecture consists of a phonebook, a list of warrants describing who can do what business with the company and an accounting system. This poor setup gives the business units no support in their quest for solving their business problems and getting money pouring in.

The technical architecture, the third layer, now has to face the situation and figure out a way to solve this. As forcing the business people back to the drawing board does not work (remember, there are silos and nobody has ever spoken to them about the concept of a unified customer view) and re-writing all existing systems would blow the budgets of all three projects all there is to do is to build three separate systems. Which, as the architect knows, will lead to an integration nightmare the moment somebody discovers it would make sense to have the ability to have the company phone number displayed along the agreement information so the legal people can conveniently place calls.

The support layer now faces even more trouble: instead of having one or two applications to deploy there is three, all of which have different availability requirements, different release cycles, different versioning schemes and so on.

In short, a problem in an upper architecture layer leads to a growing amount of issues on its way down. Actually, the same applies to the opposite direction. Imagine a setup where two different outsourcing partners (one using RUP and the other XP) are forced to work together to tightly integrate their applications as there has been a change in the organizational structure. The very least that will happen is that the applications remain separated and the business guys suffer acute schizophrenia while participating in a planning game in the morning and compiling requirement artifacts in the afternoon.

The conclusions
Following conclusions can be drawn from the layering concept:

1. A poorly set up layer "radiates" issues to the neighboring layers. For example, a poor technical architecture leads to problems in deployment because of unmanageable dependencies and a weird organizational structure leads to a weird functional architecture.
   
2. A major change in any of the layers causes changes in every layer with the impact getting weaker the further you get from the source of the change. What is interesting about this one is that it usually only applies downwards. If changes start filtering upwards, something is very badly broker somewhere as there should not be any technical change without a business cause.


3. The model shows a weak spot most of the companies happily ignore: the fact that nobody is really responsible for the functional architecture layer. However, it acts as a filter between top and bottom layers and thus, if undeveloped, hinders all cooperation between them. The only conclusion to draw from here is that a system architect needs to make darn sure that part of the stack is under control taking it to him or herself if necessary.

Comments from Sergei added as a separate post

Utterly therapeutic

Nothing more to add, really: