Volvo Cars will become Chinese...

It is now official that Ford will sell Volvo Car Corporation to the Chinese auto manufacturer Geely. To be more precise this is what Stephen Odell (Volvo CEO) wrote:

"Later today, Ford will confirm that all substantive commercial terms relating to the sale of Volvo Cars have been settled between Ford and Geely.
...while some work still remains to be completed before signing – including final documentation, financing and government approvals – Ford and Geely anticipate that a definitive sale agreement will be signed in the first quarter of 2010, with closing of the sale likely to occur in the second quarter, subject to appropriate regulatory approvals."

The information was sent out to us employees by e-mail in the afternoon before Christmas Eve, the biggest holiday in Sweden, so most people had already gone on vacation and probably first saw the announcement in the newspapers. Personally I think the timing should have been better for informing all the people working at Volvo Cars.

I have not found a lot of information in English speaking newspapers, but here is a short notice in Detroit News.

On a personal level I don't think this will affect my research project or my PhD studies at all.

Documenting and Presenting Architectures

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

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

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

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

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?

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

Confidence in an architecture

How do you get confidence in an architecture? Lot's of extensive verification?
(This raises the quesiton on how to verify an archtiecture when you have not yet built a system based on the archtiecture. More on this at a later time...)

I think that you get confidence in an architecture by throwing things at it when various stakeholders gets involved and see how well it can handle them (all prerequisistes are never known in the beginning).
If the architecture can absorb a particular issue, scenario or feature, without deviations from the fundamental cornerstones or adding extra elements each time, the architecture gets stronger for each thing you throw at it. And your confidence in the architecture increases.
On the other hand, if you need to modify the architecture for each thing you throw at it and after enough times it is not recognisable when compared to the initial draft the architecture gets weaker and after some time there is little confidence left. And you should re-evaluate if it is the right architecture.

An architect must be able to have this "outsider" perspective and kill his/her darlings when necessary.