Documenting and Presenting Architectures 2009-12-18

Some interesting blog posts (and other links) about documenting and presenting architectures:

Architecture Documentation: Courage to Fly in the Face of Convention
Top Ten Tips for Presenting Architecture Information
All about IEEE 1471

A notice that puts my blog on a Swedish geographical blog map: Jag har placerat min blogg på Lindholmen på bloggkartan.se!

Organisational changes 2009-12-17

There will be some changes to my research group. I don't know how this will affect me in detail, but in general I think it will strengthen software research in Göteborg.

In short there wil be a new software research center (at Lindholmen?) which will be a merger with software resarchers from the departments of Applied IT and of Computer Science and Engineering. Software engineering will organisationally belong to the latter department, so I will change department.
The two masters' programs Software Engineering & Management and Software Engineering & Technology will be one, which makes sense since they have a lot in common (e.g. course in software achitecture). It does not seem efficient to give two different master level programs in the same area.

On-line lectures on software architecture 2009-12-14

It is surprising what you can find with some searching, for example full-length lectures about software architecture:

• Usability and Software Architecture: The Forgotten Problems
• O'Reilly Webcast: 10 Things Every Software Architect Should Know
• Agile Architecture Is Not Fragile Architecture
• Handling architecture in the agile world
  
• How to Effectively Evaluate Software Architecture and Identify Risks
• The Method Framework for Engineering System Architectures
• Service-Oriented Architecture (SOA) (an introduction)
• Transforming Software Architecture with Web as Platform
• Reliability Estimation During Architectural Design
• A Secret to Understanding Complexity_ A Temporal Approach to Engineering Software
• On Snowflakes and Architecture
• Winning the DARPA Grand Challenge [Robotics]
• Big ball of Mud

Note that I have not watched all of them (they are about 1 hour each) so I cannot vouch for any content and that the recording quality can be quite low.

Concise writing 2009-12-11

I was involved in the software archtiecture course this year, more than the last few years, not surprising since I developed the coruse in 2006. One of the things I did was to evaluate the hand-ins of several assignments, which was disappointing in more ways than one. But the thing I want to bring up in the blog is the lack of concise writing.
I think that one of the most important abilities for an architect (even more so than for other developer roles) is to present the "fundamental ideas" in clear, concise and short manner.

In the hand-ins, a lot of answers covered two pages when a paragraph with less than ten lines would have been sufficient. With a good picture maybe even less.
I don't know if this is beacuse the students were not comfortable with terminology (if you use a model-view-controller pattern, how much more do you need to say about it?). Or if they think verbosity is the same thing as showing understanding? Or if they did not have the time to strip away the "fluff"...
Next year I will propose a maximum number of pages in the hand-ins and deduct points if they write more than that. Obviously they still need to fulfill the task...

It is an art and craft, to write as short as possible, but it helps getting the message across! An architect should hone this skill.

Matt Deacon's talking architects 2009-12-07

I stumbled upon a channel with an interview series with various software architects. I must confess I haven't seen any of the interviews yet, but nevertheless I thought somebody else also might be interested:

Talking Architects
Matt Deacon, an Architect in Microsoft UK, talks to other architects about their experiences, their issues and challenges they face in the ever changing industry of IT.

Who is the customer? 2009-12-04

Very often I hear one should have a customer perspective when developing software. Some agile methods propose working close with the customer.

But who is the customer? Is it the person paying for the development?

The end-customer is usually not difficult to identify for consumer products, which is what I work with since I'm in the car business. But even for such a closely related product as heavy trucks it is not obvious who is the customer. Is it the user of the truck (e.g. the driver) or the company buying the truck?

And looking inside the developing organisation it gets even more unclear. I work with developing architectures. Who is the customer of an architecture? Is it the end-customer? I think he could not care less if the car has an architecture or not, as long as it has the features and properties he wants.

Sven Grahn, former scientific director of the Swedish Space Corporation stated the best "test" of identifying the customer I have heard so far (freely translated from Swedish and maybe so distorted by memory Sven does not recognise it):

The customer is the person, or group, that when you remove them the activity (or product) becomes meaningless.

So for an in-vehicle architecture the primary customer of the architecture are the developers. If there would be no developers who who look at the architecture? (The end customer is also a customer, if he's not there what is the point of developing the car in the first place?)

Can I use this test to identify who is the customer of research? In most cases it is not the ones who sponsor it (e.g. government, foundations. etc).