Committe architectures

I have observed that sometimes an architecture tends to get defined by a committee of all stakeholders (or representatives for them) rather than an architecture team. This in itself may not be bad but there are some things that seems to happen when this is the case:
First the architecture tends to be defined by a set of separate decisions that solves separate problems the stakeholders have. There is no overall vision of what the architecture should be. A lack of what Frederick P. Brooks call conceptual integrity.
Second the balancing of quality attributes seem to be an average of everything. The architecture is not really good on anything (maintainability comes to mind). On the other hand no quality attribute seems to be totally forgotten or neglected.
Third the description of the architecture is done at low level, e.g. a design or implementation level because this is what a majority of stakeholders are used to in doing their usual work.

"The other" car manufacturer...

"The other" car manufacturer has a new owner after General Motors. Good for them! We need the local competition to stay alert. Read the news here.

Publications in the pipeline

The blog originally had the intention to cover topics I'm intersted to research. So here is a short status update of what I am doing right now in my research project.

Together with a fellow researcher I made an extensive interview series with architects at two major automotive companies. So far the data from these interviews is used for 3 papers which will be submitted this spring:

1. A compararative case study on how two similar companies work with maintaining architctures.
2. A short paper describing how archtiects view themselves in terms of skills, experience, attitudes, etc.
3. Another paper which I'm not authoring

Last year I made extensive observations of architectural decisions for the architecture of the next generation electrical system at Volvo Cars. So far the data from these observed decisions will be used for 2 papers:

1. A new classification scheme for archtiecture decsions, based on empirical data
2. A case study of the 80 decisions observed at Volvo Cars

I also have an idea about an interesting AUTOSAR-paper which partly will use information from a student thesis project I will supervise later this spring.

Object-oriented programming in C

In the automotive industry C is the totally dominating programming language. I guess this is because of the limited resources in automotive-specific CPUs but also because of tradition among programmers, if you have a program that is proven by use you don't rewrite that just because there is some new language around.
And to be honest, it still is hard to beat C if you want real-time properties and a garbage collection that don't risk overflowing memory.

But if you want to keep C but write programs in a more object-oriented style how do you do? It is not as hard as one would think.
Here are some web pages which give some useful tips. Note that they are not always compatible!

• Phil's guide to object-oriented ANSI C
• Object-oriented programming in C by Paul Field
• Object-oriented programming in ANSI- C by Axel-Tobias Schreiner

I have reviewed code for several ECUs used in Volvo cars, and none have used an object-oriented style. The reason I bring up object-oriented programming in C in this blog is that it simplifies the implementation of many patterns, the subject is not really new...

Empowered architects

In the course on project management and leadership for PhD students we are talking about the role of the project leader. The lecturer Max Rapp Ricciardi writes in an article by about empowerment and refers to an article by Quinn & Spreitzer.

Anyway, he mentions four characteristics of empowered people:

• They feel they are masters of their own destiny (they can do the work without management interference)
• The understand the totality of the business they are operating in
• They have confidence and a feeling of doing a good job
• They are convinced they can influence others, which is the opposite of learned helplessness

If you are to be an efficient architect I think you need to have all of these four characteristics, or in short you need to be empowered!
An architect which works in an organisation where he or she is not empowered have probably little chance of doing a successful job. I would even go so far to ask why such an organisation would even bother with having such a role?