Recurring architectural decisions

A lot of academic (and industrial) research is looking at architectural decisions. One of the ideas pursued is that by capturing and managing this type of information it can be reused. I guess in practice it means that if you need to make a similar decision in the future you can look at what you decided the last time. I myself also saw this as an appealing idea. But today it struck me that we really don't have recurring decisions when we work as architects at Volvo. I think that if we had there would no be any need of an architect at all.

What we do have is a long succession of architectural decisions, each with a new set of prerequisites. The task as an architect is to be able to extrapolate from what has been done previously and still maintain some sort of conceptual integrity. To preserve the "feel" or "vision" of the architecture while still fulfilling necessary functional and quality requirements (including cost) and operate within the constraints given by for example our organisation and what is available/possible form suppliers.

Software testing

I have to admit it, I suck at software testing. I do believe in my naive notion of test-driven design, i.e. write the tests first and the program later. My problem is that I just don't have the skills of programming test cases.
Example: I wrote about the "walking skeleton" design principle some days ago.One could write a suitable set of test cases to ensure that the skeleton, with it's various units, always walks. The tests should automatically run before you check in more elaborate units, with more features in them. If the unit doesn't pass you know that you will have integration problems.

There are a lot of resources on testing out there, for example I got an introduction on creating JUnit test cases for Java programs from a colleague. Since I'm trying to learn Erlang I should probably look into EUNIT.
You should also read the blog thoughts from the test eye.

I started working with system integration testing at Volvo Cars many years ago. I learned the basics of test planning, writing test cases and report test results then. Probably very outdated since both it was ten years ago and since the automotive industry has never been on the cutting edge of software development practices. We still have a notion that a specification should be written so that it can easily be tested:

"This easily results in requirements being quantified and often in a contractual style, instead of describing the real needs and desires."

There are many other ways of Synthesizing Test Ideas!

So if experts on testing are open to the notion of having specifications focusing on understanding and real needs, why are we still clinging to contractual requirements ? Is it because of so much of the coding is outsourced in the autotmotive industry?

If one aspires to be a software architect I think working with verification & validation (testing) is a good starting point. You learn a lot about good, and bad, design when you are exposed to the errors and unintended behaviour in a system and the effects they have.

Architectural modelling

To have a more formal definition of what I mean when talking about modelling an architecture (summarised from to IEEE 1471):

An architectural description is organized into one or more views.
A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.
The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modelling methods or analysis techniques to be applied to these representations of the view.

I am not against using models to represent architectural views, but there are some fallacies that often seem to happen when using various modelling approaches in architecture descriptions.

• The purpose of the architecture model is unclear (in 1471-terminology: It is not obvious what concerns the model addresses). UML is especially problematic since it provides notation that can be used for so many purposes. Read John Daniels paper Modeling with a Sense of Purpose as an introduction.
• Everything is modelled to the same level of detail. Not everything is equally important to know. For some parts of the system it is important for the architecture (and realisation of qualities) to know the details, for other parts it is not.
• Every part of the system must be represented in the architecture, for example if every class must be traceable from some element in the architecture. This could even be a rule of the architecture, "if it is not explicitly allowed it is forbidden". This reeks very much of waterfall mindset with the architects doing much of the design before any developers get involved. I think it is presumptuous  of the architects to claim to know everything that needs to be implemented.
• Modelling tools always demands a precision in notation, which is not always desirable when sketching an architecture. You cannot model "sort of a class", or "could be a function" when using a tool, which is possible on a whiteboard or a napkin. In a tool it has to be a class, a function or a package, not something in-between.

Presentations from Lindholmen Software Development Day 2010

All presentations form the Lindholmen Software Development Day 2010 are now up on the web site. I know we were filmed as well, but I don't know when they are finished editing.

"Start with a Walking Skeleton"

I try to explain to my students that they should start with structure before programming any features. Get the OS to run with some reasonable tasks, exchange some information/messages/... between sub-systems or processes, etc.
There seems to be a proper term for this: Start with a Walking Skeleton. Apparently the term originates with Alistair Cockburn. It is often used in conjunction with the Incremental Architecture pattern.
I feel rather stupid of not knowing what others had done before, but at least I know of the concepts...

It says that this is a useful strategy for large systems. I think it is quite useful for small systems as well, especially if you are not very familiar with the features to be developed. A walking skeleton allows you to try different things in a running platform and with decent version control you can always reverse to something that is running, even if it has little customer value. And the effort of making the skeleton work is never wasted.

Ranking of Software Engineering Journals

I got a link to a ranking of the top Software Engineering Journals from my colleague Robert Feldt.
This is based on how prestigious these journals are in the scientific community based on some bibliometric index. But I would also like to see a similar ranking of how prestigious a journal is in the community of practitioners. Would it be possible to identify an index for that?

ICES-INCOSE Architecting Seminar - presentations now on-line

The material from the ICES-INCOSE-seminar: Architecting Embedded Systems is now available.
There is also a summary of of the day, including the ending panel debate, which I personally found very interesting.

More on quality attributes

Not so long ago I wrote about quality attributes. A friend on facebook gave a tip about a blog post on Software Quality Characteristics 1.0. The bloggers claim it is "the perhaps most powerful public two-page document in the history of software testing." I don't know about that but it sure is a useful document.

Trends and challenges in architecting embedded systems

Architecting is not even a proper word (I even heard someone at SPLC suggest all papers with architecting in the title should be rejected) , but is quite popular nevertheless. I think it has to do with Swedish allows you to construct a verb from just any noun, and still making sense....

I was in Stockholm to talk about architecting automotive software at an ICES-INCOSE seminar. You can find the slides from the other presenters (and mine in PDF) at the ICES homepage.
Staffan Persson is an architect from Scania and he presented a very interesting view on architecting in lean organisations (an introduction by Staffan can be found in Lean Magazine #5).

The finishing panel debate was interesting. I don't know if the notes from that will be published on the site, but I have a few reflections when thinking about it afterwards:

• One trait of a good architect is to freely move between different levels of abstraction. An architect needs to see the whole picture all the time, but he also needs to be able to dive down into details, "the devil is in the details".
• You can teach, and learn, fundamental knowledge for an architect, such expressing quality attributes, be familiar with architectural styles and patterns, know architecture platforms such as AUTOSAR or .NET, and being able to express designs in various views etc. But there are also another set of key skills that are very hard to teach, such as understanding the company culture (the common value ground), earn respect, know not only what technical parts that are affected by various decisions, but also who. So it would be difficult to move form one organisation to another an be productive as an architect.
• An architect needs to be comfortable with uncertainty. I know I am not, and this is one of my weaker points as an architect. And how do you assure other stakeholders that one should not make a decision now since we don't know enough?