JAOO 2009 - I'm going :o)

I have just returned from JAOO 2008 in Aarhus and that was all I hoped for. I can tell on and on about all the inspiration you get by going to such a conference but I won't right now. It might pop up on this blog in the months to come.

One of the things that settled in my mind was the fact that architecture isn't about structure - it is all about roles and responsibilities. Class diagrams aren't architecture - they are just a representation of one way to implement a given architecture. I don't know how many times I've drawn squares on a board to boxes representing "Person" and "Order" and by drawing a line between the two I believed I had the beginning of an architecture sketched. I couldn't have been more wrong and after these three days I'm beginning to understand why. Now I learned that in an architecture:

• Roles needs to be defined
• Responsibilities needs to be described
• Represent objects and actors to act on the roles and responsibilities you figure out

No wonder I repeatedly hit my head against the wall when trying to abstract my "architecture" a little, because building abstractions on top of implementations which have been built without a larger picture in mind is next to impossible. Programmers aren't used to describe intent which basicly is what an architecture is in itself - we just build stuff that works. I didn't get that one until this week.

I came to think of one approach I tried a year ago when modelling a new domain for an auction site: Object Modelling in Colour. Object Modelling in Colour essentially describes 4 types of objects, Party-Place-Thing, Moment-Interval, Role and Description. Using these four types of objects you can model an entire domain using archetypes to describe responsibilities and because each archetype is coloured you are able to quickly inspect a domain or describe a given domain to a non-technical person. We used it to model a new domain and the original domain model actually survived throughout the entire project so the initial approach made us deliver a very decent first shot at describing our new business domain. Just about everything else from there went horribly wrong on all levels but that's another story. Buy me a beer some day and I'll tell you all about it ;o)

Maybe this approach could be used again to model architecture? I haven't read up on it or heard from Modeling in Colour since then so the concept might have evolved since last time I used it but it could prove to be worth a try the next time we face an architectual challenge which requires us to take a helicopterride to get a birds-eye view on the things we work on.

One of the best quotes I heard during these three last days is this: "All code is cost. Only some code has value". Everything you do you should do only to deliver code that has value once delivered. You should focus on writing code that not only you care about. Sounds easy, right? It isn't...

I'll stop for now - I have numerous notes that I have reworked tonight. I am sure I will get back to reading them more often than previous ones because they are really good, I think, after reading them again during refinement and rework.

Regards K.