Architecture for small systems?

It is Friday afternoon and I'm allowed to have some wild ideas...

After a long e-mail conversation with one student of appropriate architectural styles to use in a project course I realised that his ending comment is spot on:

I think the course and it's literature are focused on large systems and seeing that we are new to this, especially with a new language in parallel, its difficult to not apply what we learn during the course.

In my opinion the patterns covered in the book left me half way with the idea that most architectures could fit into a pattern, within its own right.

I have been too blind when I teach, and not even my professional experience helped me to identify the problem:

Most (all) literature about architecture teaches solutions for big systems.

Is there a niche for information on how to architect small systems? Small in the sense of not having millions lines of code, or a large development team, or a long project. I know that the agile manifesto states that that one of twelve important principles are

The best architectures, requirements, and designs emerge from self-organizing teams.

But do a google search on "agile architecture emerge" and see what comes up, a lot of interesting reading that suggest that the issue is not that simple.

A lot of software systems are small, from a bittorrent client (the student project) to the software in the door control unit in a car, to a mobile app. And yet they would all benefit of having some though about what they must meet for non-functional needs that is addressed by a (simple) architecture. Should I write a book on architecting small systems? So that a team member is better prepared when he or she participates in a small project where the architecture "emerges"? You don't need to be an architect to benefit from doing thinking at an architectural "level".

Quality attribute scenarios

Defining a quality attribute, a.k.a. non-functional requirement, is not easy. I know since i did that for a new platform at Volvo. When the verification and validation group comes back and says that it is not possible to verify this as a requirement I can only assume that I did not do a good enough job. But I have to agree with what George Fairbanks wrote in his blog:

Before you get too excited, you should know it’s easier to write these for quantitatively measurable qualities (e.g., throughput, latency) and harder for softer qualities (e.g., modifiability, usability).

There are two recent books that have a more agile approach to architecting: Lean Software Architecture by Coplien and Bjørnvig, and George Fairbanks' Just Enough Software Architecture: A Risk-Driven Approach. Unfortunately the latter isn't available in any Swedish internet bookstore, but as soon as I get hold of them I will post a review, as I have reviewed other books on software architecture.

Lindholmen software development day 2010

I held a presentation with the ambitious title The future of automotive software engineering at this years Lindholmen software development day.
The whole event was filmed so you can watch clips from me and the other presenters giving our talks when they are published (somewhere in the near future). Until then you can view my slides below, including the long list of references.

Architects as managers and leaders?

It is not often I write about management here, in spite of the title of the blog: "Managing..."'

I do believe that architects should not be people managers, at least not simultaneously.
However they should be leaders. An architect should have a vision of what he wants to accomplish and should lead by example. If the architect is successful it seemed like he did not do anything and everything was accomplished jointly by the developers, so don't expect too much credit as a leader...

Back to management: A former student of mine wrote about the difference between good and great companies to work for in his blog and directed me to this series of blog articles:12 Things Good Bosses Believe from Harvard Business Review.

Project presentation

I presented my project at the yearly Volvo Industrial PhD program conference last week.

How attractive it is to work as a software architect...

A colleague sent me this link from CNN Money about how attractive it is to work as a software architect. Go figure...

Hidden leaves

Philippe Kruchten wrote a very entertaining interpretation of Tao Te Ching from the perspective of an software architect. But besides being entertaining it has some very good insights into the nature of an architect, like the following:

The architect doesn't talk, she acts.
When this is done,
the team says, "Amazing:
we did it, all by ourselves!"

Personally I'm more familiar with Japanese texts (more than 20 years of budo training) so I thought of interpreting the Hagakure with the same perspective (you can find a translation to English of the original text here).

Among the maxims on the architect's wall there was this one: "Matters of great concern should be treated lightly." A senior developer commented "Matters of small concern should be treated seriously." In one's project there should not be more than two or three matters of what one could call great concern. If these are deliberated upon during ordinary times, they can be understood. Thinking about things previously and then handling them lightly when the time comes is what this is all about. To face a problem and solve it lightly is difficult if you are not prepared beforehand , and there will always be uncertainty in hitting your mark. However, if the foundation is laid previously, you can think of the saying, "Matters of great concern should be treated lightly," as your own basis for action. (1st chapter, p. 33)

According to a senior developer, even a poor programmer will become substantial in the art of writing code if he studies by imitating a good model and puts forth effort. An architect should become substantial too, if he takes a good architect as his model. (1st chapter, p. 40)

The proper manner of architecting is nothing other than not being careless, but in this way one's design will be sluggish and stiff. One should go beyond this and depart from the norm. This principle applies to all things. (1st chapter, p. 48).

In carefully scrutinising the projects of the past, we find that there are many different opinions about them, and that there are some things that are quite unclear. It is better to regard such things as unknowable. An architect once said, "As for the things we don't understand, there are ways of understanding them. Furthermore, there are some things we understand just naturally, and again some that we can't understand no matter how hard we try. This is interesting."
This is very profound. It is natural that one cannot understand deep and hidden things. Those things that are easily understood are rather shallow. (1st chapter, p. 69)

On plagiarism and referencing

In the architecture course I'm involved in several groups failed the hand-ins due to insufficient referencing when using material from other sources. In academic writing it is allowed, and even encouraged, to base your writing on data from other sources so this in itself is not wrong, but it must be done according to strict academic standards
Worst case: Incorrect or omitted references is plagiarism, which is a serious academic crime that can lead to suspension from the university.

We will arrange a workshop for all 2nd year students on Wednesday 12 October 11:00 since this is a vital skill in all courses and the thesis projects. But in the meantime I suggested they should take a look at the following introductory material:

• A crazy Norwegian introduction to the subject
• A website from the same university on searching and writing academic papers
• Read especially about referencing
• A short (15 min) hands-on video lecture on referencing

The students don't need to use any specific style of references (Harvard, IEEE, APA, Chicago, etc) as long as they are consistent.

Seminar:Trends and challenges in architecting embedded systems

I will be talking at a seminar at the Royal Institute of Technology in Stockholm 4 November: Trends and challenges in architecting embedded systems.
Besides Martin Törngren from KTH and Jörgen Hansson from Chalmers there will be speakers from Ericsson, Saab Aerospace, Semcon EIS, Scania, and myself...