IT talents in Sweden

For my Swedish readers:

Skill har skickat ut enkäten till studenter vid samtliga svenska lärosäten som har IT-utbildningar. 1140 IT-talanger har besvarat enkäten och det är deras svar som ligger till grund för denna rapport. Av de som har svarat är 20% kvinnor och 80% män. IT-talangerna är 27 år i snitt och åldersspridningen är mellan 19 och 54 år.

Improving quality with well-written requirements

I discussed with a colleague about how to improve specifications and we agreed that one of the actions that would yield quality improvements with very little investment was to educate people in our organisation on how to write good requirements.
Unfortunately such a course is not available internally at Volvo Cars (don't ask me why). But a search found some useful pages that could serve as an introduction:

• The Story of the Paperclip: Writing Good Functional Requirements from StartupCTO
• Writing Good Requirements – The Big Ten Rules from Tyner Blain
• Writing good requirements is a lot like writing good code by Jim Heumann, IBM
• Writing Good Requirements (A Requirements Working Group Information Report)
• SMART Requirements by Mike Mannion and Barry Keepence

Is software engineering immature?

Is software engineering an "immature" engineering discipline? I have often heard this both in presentations and in reading, for example SEMAT states on the homepage:

"Software engineering is gravely hampered today by immature practices."

If I draw parallels between software engineering and civil engineering (arguably the most mature engineering discipline) my spontaneous conclusion was: Yes, software engineering seems to be more like how cathedrals were built in medieval times. The construction of them were based on rules of thumb and the practical skills and experience of architects and stone masons instead of the type of engineering practices taught at universities today. Interestingly enough, one can still see the "successful" cathedrals still standing several centuries later. But it would have been impossible for the architect of  Lund Cathedral to build something like the nearby Turning Torso. So the engineering in civil engineering has certainly "matured".
But where is software engineering failing? Everyone has heard of software projects running over time, over budget or have not been used as intended (or not used at all). But wait a minute! Exactly the same thing is common within civil engineering as well. There are many examples from a single contractor renovating a small house up to world known buildings such as the Sydney Opera House:

"The original cost estimate in 1957 was £3,500,000 ($7 million). The original completion date set by the government was 26 January 1963 (Australia Day).[16] Thus, the project was completed ten years late and over-budget by more than fourteen times."

So in this respect software engineering is as immature as other engineering disciplines.
So what is the fuss about? I agree that there is no consensus in the software community on how to do the equivalence of structural mechanics calculations or stress tests. Are we more hampered by this lack of consensus on how to do engineering tasks than by the difficulty to run large projects, which seem to be common to other engineering disciplines?

Available infotainment platforms

I have previously written about various platforms for infotainment systems. I also had a slide about it in my presentation on Lindholmen Software Development day, where my point was to say that it is possible to use either a commercial platform, such as Windows Embedded Automotive or an open source such as Meego. It is a business decisions which way an OEM wants to go, not a technical.

I have probaly missed some, but here is a list of infotainment platforms available today for an OEM to build an in-vehicle infotainment system on:

• Windows Embedded Automotive, used for example in Ford's Sync.
• QNX Aviage
• Mecel Betula Suite - Automotive Bluetooth Platform
• Meego
• GENIVI, but there is little informaiton about the techical solition on the webiste. They will most likely utilise the Meego platform.
• Harman has an infotainment platform. They recenlty acquired AHA Mobile which probably will be integrated.
• There are alot of notices on using Android for in-vehicle infotainment if one searches the web, but I have not been able to find any open source software based on Android for in-vehicle use.
• Continental's Autolinq seems to be Android-based, but is not open source in the same sense as e.g. Meego, and apps must be approved (by Continental?) to be downloaded.
• Luxoft offers LUXnet, which is also Android-based, but I cannot find any information besides a press release on their homepage.

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?

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

InfoQ: Model-Driven Development: Where are the Successes?

I found a good blog post about more experiences onmodel-driven deleopment at InfoQ: Model-Driven Development: Where are the Successes?. Read it and the articles mentioned.

I have also read through a summary of the study of Sascha Kirstan which was very interesting.Unfotrunatley i don't know if it is avaibale on thenet yet. However both he and Jon Whittle clearly stated that in practice the advantages with model based develoipment are not so much efficiency as quality. In practice the efficiency gains tend to be around 20-30%, not 3-5 times as one can hear among certain the evangelists. And the quality gains are in the same order.
But reducing the number of faults and errors with 20% impresses me more than reducing development costs with 20%.

What is a model?

My previous post got me thinking about what a model is and why we model. I think everybody agrees that a text specification written in Word is not a model, while something in UML is.

The Cambridge Advanced Learner's Dictionary defines a model as

A representation of something, either as a physical object which is usually smaller than the real object, or as a simple description of the object which might be used in calculations.

I like the informal definition I heard from Jon Whittle last week: A model is an abstraction of the real thing for a specific purpose. However with this definition even a specification document written in Word will be a model and I don't think that makes sense.
Mellor et al. defines a model (Ludewig defines even more formal criteria):

A model is a coherent set of formal elements describing something (for example, a system, bank, phone, or train) built for some purpose that is amenable to a particular form of analysis, such as...

With this definition it is quite easy to exclude a Word document as a model, since it isn't composed of formal elements. It can incorporate diagrams based on a model, e.g. a class diagram from an UML model, but not the model itself.

In addition to this there should be a purpose with the model. John Daniels identifies three different types of models, each with a different purpose:

• Conceptual model
• Specification model
• Implementation model

When reading the article it is obvious that just by stating one has a UML model or a Simulink model really does not say anything about the purpose. What I am curios about is if one is using the same model for different purposes? Is it possible to use a model for completely different purposes with any degree of efficiency and quality? I am not talking about a transformation from one model to another, for example code generation or MDA. Do you use the same Simulink model for both conceptually understand the problem, specify properties of the solution and describe the implementation?

I had great help from my colleague Niklas Mellegård in his licentiate thesis Method and Tool Support for Automotive Software Engineering, which is defended on Thursday 30 September at 13:00 in room Torg 2, Patricia building, Lindholmen. Discussion leader will be Prof. Martin Törngren, Dept of Machine Design, Royal Institute of Technology.

Software quality attributes

I got the following e-mail from a student after discussing definitions and frameworks of quality attributes:

Hello,

It seems there are 2 main groups of ISO standards dealing with software quality:

1. a 4 part ISO 9126 standard (QA considered are reliability, usability, efficiency, maintainability, portability AND, actually, functionality)
2. second generation of ISO software quality standards referred to as SQuaRE (Software product Quality Requirements and Evaluation): ISO/IEC 25000:2005, ISO/IEC TR 25021:2007 and ISO/IEC TR 25060:2010.

I couldn't find any free copies of these standards, so we can't really use them.

Anyway, it would be interesting to get during the lectures some additional information about different quality attributes models out there (early McCall and Boehm models, FURPS, ISO models etc.).

I replied with this:

You are correct. You can't access the ISO standards (without paying).

• For a very soft introduction to quality attributes, read this: http://www.stellman-greene.com/2009/10/03/using-nonfunctional-requirements/
• An in-depth analysis of a few quality attributes are available at http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm
• For a definition of terminology I suggest IEEE std 610.12, bit this covers much(!) more than just quality attributes. It is available at http://ieeexplore.ieee.org/
• You can also read what the PhD students at Blekinge Technical University wrote down in a course about software quality: http://www.bth.se/tek/besq.nsf/pages/017bd879b7c9165dc12570680047aae2!OpenDocument
• And as usual, wikipedia is a good introduction, look at "software quality" or "FURPS" for example.

I think it will be a little too much to go into detail about different quality frameworks in this course, above they dedicated an entire course at PhD level to the subject.

Hope this helps,

Ulrik

Do you use model based development?

I heard an interesting keynote speech from Jon Whittle this morning with the title The Truth About Model-Driven Development: Who's doing it, how and why?
He presented some findings on experiences from using model-based development in industry from the EA-MDE project. I talked to him afterwards and there apparently had only been one automotive company in the study, and I personally think that the conclusions might have been different if they were more data from them. If you are working model-based in your company and want to participate in the study you can do so by answering the questionare on the project web site.
One benefit of model-based development which I expected to see in the study was that it allows domain experts to actually do implementation, for example can chassis control experts actually do code for use in ECUs.
Note: You can substitue model-based development with several other acronyms and Jon's study is still relevant; MDD, MBSE, MDA, ...

I find this study to be similar to what Sascha Kirstan is working on in the automotive industry. I participated in Sascha's study this spring and just got a report with preliminary results, which I haven't had the time to read yet. I sure hope these two researcher will look at each others result and see if they can corroborate their findings or if they are contradictions.

Jon concluded his talk with the top ten tips for companies wanting to adopt model-based development and here they are (but to truly utilise them you must know a lot more about the context where they were found):

1. Keep the domains (modelled, I assume) tight and narrow.
2. Target well known domains.
3. Put MDD on the critical path (he means that pilot projects never get sufficient attention and resources).
4. MDD works best form the ground up.
5. Be careful of gains that are offset elsewhere.
6. Don't obsess about code generation.
7. Not everyone can think abstractly.
8. Most projects fail at scale-up
9. Match tools and processes to the way people think, not the other way around
10. Ok, there was only 9...

Why I don't like formal methods...

I know the title of this port is a bit controversial and with it I alienate a lot of researchers, even at my own department. But I will try to clarify my arguments and hope that someone can prove them to be wrong.

• To be more precise; it is not the formal methods in itself I dislike, but the prominence they seem to have at prestigious software engineering conferences. I think it is not at all in proportion to how well-used formal methods are among professional development.
• Formal methods are really attractive from a researchers perspective. You can use concepts as theorem, proof and deduction and other nice things. But nice is not the same as relevant.
• Even though I have heard about formal methods as one of the enablers to establish software engineering as a "real" engineering discipline for almost ten years I still don't think they are nearer being well-established now than then.
• Some claim that you can never be sure of the software unless you can prove properties about it, and I agree that presently formal methods are the only technique that promises to do so. But there is a lot of successful software out there which have not been proven.
• Specifications that fulfil the requirement of being interpreted formally are hard to write. Compare it to learn a new programming language and be proficient enough to use it without any side effects.
• I don't know if formal methods scale well. It is one thing to use it on a nice prototype system with 30 entities developed in your lab. It is another thing to use it on a system with 500 entities, many of these with quite varying quality in requirements and code.
• I still don't know of any that uses formal methods for real; i.e. as part of the normal way in products shipped to customers in business intent on making money. Not in one-shot attempts, pilot projects or by non-profit organisations.
  A search on google skolar of industrial+software+formal+methods list papers from the 90s as the top results. And these seem more to be arguments against what I claim above rather than actual reports of usage. I really would welcome examples.

Software product line engineering

Software product line engineering is apparently about modelling variants and achieving formalism in feature descriptions. This is the conclusion I make after attending some workshops and the first morning sessions at the 14th International Software Product Line Conference in Jeju, Korea.
I presented an interesting  paper together with Håkan from Scania of how architects work with maintaining and updating existing architectures over time in the automotive industry. And we did not get a single question!
Last year when I presented another case study everybody was interested in the case and wanted to hear more from industry, but this time it didn't seem to interest the audience.
I find it quite difficult to find venues to present research based on industrial experience and not theoretical examples.

Besides that, I find the notion of feature used in many presentations different from what I am used to. To me a feature is something which is discernible for the end user, same as the definition found in the original work here. For example an adaptive cruise control is a marketable feature in a vehicle. But if I would model that similar to feature modelling prevailing here the model would consist of an optional radar, a compulsory engine, compulsory brake, etc.This means a much higher degree of knowledge about the realisation of features.

Tacit knowledge

At the ECSA conference there was a lot of talk about tacit knowledge and the importance of tacit knowledge when architecting systems.
I completely agree that one thing that differs an experienced (and productive) architect from a fresh graduate is is the amount of tacit knowledge the former possess. However I thought that in the discussions at the conference there was some confusion of what is exactly meant by tacit knowledge.
On one hand there was the view that tacit knowledge was simply the architectural knowledge that was not documented, i.e. stuff that only resided in the peoples' heads. To improve the management of this is mostly a question of capturing it in the right form and with the best tools.
On the other hand one sees tacit knowledge is such knowledge which is difficult to express using language, which is the tradition I'm used to.
In order to capture the latter type of tacit knowledge it is not just a question of having the time to do so or the right tools. The difficult part is for the person having this knowledge to be able to formulate in in such a manner that he can express it.

Meego

I have previously written about GENIVI and Moblin in this blog. I have to confess that I haven't followed the progress of either initiative.

GENIVI seems to be progressing, there is a new report on Marketing Requirements with a summary publicly available. But for an open source project it does not seem to be very open. It is interesting to note that they see themselves as different compared to a Linux platform, at least commercially.

Moblin seems to have been replaced by Meego as the in-vehicle Linux platform, with backin from Intel and Nokia. Meego had it's first release for In-Vehicle Infotainment in August this year. If I understand it correctly you can download it and run it as a infotainment system already now if you like, though I have not tried this...

I still believe that technically GENIVI will build on Moblin, or now Meego, but I cannot find anything about that on their homepage.

The future of software architecture research?

There are two areas which I judge to be of great interest to the industry regarding architecture, and I see very little interest from academia

First, how much effort should be put into architecting? In industry there never are unlimited man-power and indefinite time plans. So how do you know that you have done enough architecting? Or did too many people working with the architecture for a too long time? Or when are the gains in putting another man-hour too small to make it worthwhile?

Second, how to define an architecture based on imperfect premises? In practice the architects never have the full picture. There might be requirements missing, stakeholders unavailable or implicit constraints. Similarly the architects themselves are no super-humans, there will be inconsistencies in what they do, things forgotten, lack of crucial knowledge or personal biases, all which cause an imperfect architecture.

Personally I think that these two areas are more important from an industrial viewpoint than further software architecture research on Architecture Description Languages, formal methods or Service Oriented Architectures (the latter may be contested, but I think I am not alone).

At the 4th European Conference on Software Architecture the workshop in imperfect architecture was cancelled, probably due to too little interest (I heard only 3 papers were submitted). On the other hand I found 7 papers when I scanned the LNCS proceedings which in their title relates to the subjects above.
I don't find this very promising. Eoin Woods had a similar conclusion on the state of software architecture research at his ECSA talk when talking about the relationship between code and other design information, such as architecture, where he thought the academic research and the industrial needs are diverging and not converging.

You can also read this related column from IEEE Software: The Top 10 Burning Research Questions from Practitioners. Especially #4 "Architecture and agile—how much design is enough for different classes of problem?" should get more attention at software architecture conferences.

A colleague of mine at Volvo had an interesting proposition: Since software engineering as a dsiciplin comes from the practitioners the research community wants to keep some distance, in contrast to the "fundamental" researchers in e.g. physics who would be enthusiastic if somebody is interested in applying their theories.

ECSA 2010 pt3

The conference had three interesting keynote speakers: Jan Bosch, Philippe Kruchten and Jim Webber.

It must be quite nice to be a keynote speaker, then you have the authority of making statements like "Control is an expensive illusion causing inefficiency in the system" (JB) or "When ever you hear Service-Oriented Architecture think of orange men in rubber suits coming to rescue you" (JW) without having to prove them scientifically. Convincing and entertaining statements nevertheless.
Philippe Kruchten's keynote was a summary of the tutorial he gave together with Paris Avgeriou. The slides for both are available on-line.

ECSA 2010 pt2

I did not find this year's conference as inspiring as last year's in Cambridge. I don't know why. I think both the quality of the presentation and the gap on what was presented to industrial application varied more.
There are some papers which I plan to re-read, for example

• Lightweight and Continuous Architecture Software Quality Assurance using the aSQA Technique, on how to to architecture analysis in agile-type development.
• Experiences in Making Architectural Decisions during the Development of a New Base Station Platform
• Unifying Software Architecture with its Implementation, on the need to include architectural documentation in what actually gets maintained, i.e. the code
• Structuring Very Large Domain Models, if you think you have big models see what was studied here...
• Towards a Process Maturity Model for Evolutionary Architecting of Embedded System Product Lines, interesting but also similar to Knowit's Architecture Capability Evaluation.

The last three papers were all from the industry track (which also included the presentation by myself), which I thought was as interesting as the rest of the conference together. For some reason the industry track papers was not published by Springer in their LNCS series, but I was told they would be available at the ACM digital library.

ECSA 2010 pt1

I'm at the 4th European Conference on Software Architecture in Copenhagen. The presentations varies, both in presentation skills, scientific rigour and relevance (at least to me).

Jan Bosch stressed 3 key take-aways in his keynote last morning, he might post the presentation on his homepage:

1. An increase in speed trumps any increase in efficiency
2. Software engineering is moving from integration to composition
3. Software architecture is the key to delightful products in software eco-systems

I'm not convinced that all of his conclusions are valid outside of pure software business domains. But I guiess there are som things to learn even if one makes software for systems like cars, communication satellites etc.

Now I'm of to listen to Philippe Kruchten.

Geely owns Volvo Cars

Volvo Car Corporation is now fully owned by Geely. The deal was closed yesterday.
You can read the full story at Reuters or Gasgoo Auto News. New CEO will be Stefan Jacoby, formerly of VW North America.

Exploring variation mechanisms in the automotive industry: a case study

I supervised a thesis project on run-time variability in an AUTOSAR architecture.
You can read about the project, and download the thesis report, at the student's web site: quandoo.

Books on programming embedded systems

I'm looking for a good text an programming embedded systems (for example an automotive ECU) but I can't find any that suits the bill. I was hoping to suggest something to students that avoids the trial and error learning methodology I had to endure.

A quick search on Amazon shows some which could be relevant:

• Programming Embedded Systems: With C and GNU Development Tools by Michael Barr and Anthony Massa
• An Embedded Software Primer by David E. Simon
• Embedded C by Michael J Pont
• Embedded Software Development with C by Kai Qian, David Den Haring and Li Cao

Especially the latter sounds interesting since I like the software architecture book from the same author.

I was thinking of writing a book myself on the subject. But it would mostly haven been a collection of data one can find on the internet with some detective work. Subjects to include would be:

• Introduction to C, since embedded systems are programmed in C. Period....
  I like K&R, but you can choose any book that suits the bill.
• Good coding practices in C, for example MISRA C rules.
  Read some example of MISRA C-rules here, here and here.
• RTOS basics, since this is what is used on most embedded systems.
  Read chapter 1 in the User & reference manual of rt:kernel from rt:labs for a good introduction. But personally I prefer the "run-to-completion" type of tasks which don't wait for external events for predictability.
• Interrupts, stacks, and memory handling - ISR, RAM, NVRAM, ROM, Flash and every other acronym you can think of...
• Development environments, and compilers for embedded development
  My experience is that this is pretty much decided by the OS you are using. I have experienced very mysterious bugs just by not having the correct compiler version, so I can' imagine what could happen when having a compiler from a different vendor... IAR graciously provides all of their manuals free of charge and their IDE and compilers on 30-day on a 30-day free trial.
• Various hardware on a typical embedded controller - Details on how to access hardware with code examples.
  You can see examples of typical hardware devices in the Freescale MC9S12XS256 Reference Manual, a typical automotive processor, especially chapter 10-19. Mind you that this manual is 738 pages long, so it's pedagogical value is limited.
• Debugging - Too much to cover for this blog post. This is the real dark arts...
• Architecture of embedded systems
  Almost all embedded systems are layered, but why? And how do you know which layers to have in your system? And how do you identify the tasks you should have when schedule the system?

Competitiveness from structuring of AUTOSAR applications

AUTOSAR 4.0 was released some time ago, and in certain areas it was a major update compared to version 3.1 of the standard. Besides the changes to the Basic Software one of the things I think may have a great impact when it comes to sourcing software from suppliers are the results from the 10.x work packages that deals with application interfaces (i.e. interfaces of the software components above the RTE).

In my mind structuring the applications and standardising their interfaces pretty much defined what quality attributes ("-ilities") the software would have, especially when it comes to "Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system" to quote wikipedia. So with the OEM-supplier relationships that most vehicle manufacturers have and with the static structure standardised by AUTOSAR it would be almost impossible to compete with the "-ilities above. So how does one use AUTOSAR and "cooperate on standards, compete on implementation"?

I got the answer in a paper by Simon Fürst et al. presented at 14th International VDI Congress Electronic Systems for Vehicles 2009 in Baden-Baden.

"In general, applications are the competitive edge of an ECU. AUTOSAR is not going to standardize the functional internal behavior of an application (e.g. algorithms, optimization) but the content exchanged between applications. This clarifies the exchange of applications between the automotive community, from OEM to suppliers as well as supplier to supplier and so forth."

So competitiveness is "only" achieved by algorithm optimisation? A typical control engineer's viewpoint and not a software engineer's? This means that an OEM can only distinguish itself from the competitors by run-time qualities and not by qualities such as evolvability or testability?

Do I even need to say that this is my personal opinion based on the teaching I do in software architecture and does not necessarily reflect my colleagues' opinions or the company I work for.

Blogs

I follow two "professional" blogs:

• Heartbeat Development by a former colleague of mine, Johan Segertoft
• SEI Architecture Technology User Network Blog

The latter had in a recent post some links to other blogs which also deals with architecture.

ICSE 2011

The International Conference of Software Enginering is on Hawaii in 2011. Deadline for the main research track is Friday 20 August 2010. Time to hurry if I want to submit something...

Swedsoft meeting

Last week I attended a meeting between DICE and ABB with additional participants from Volvo Cars and Ericsson as well as some from academia. The meeting was arranged by Swedsoft.

I know nothing of the game industry so it was especially interesting to listen to the presenters from DICE, who all worked with the development of their game engine Frostbite. Some things were of particular interest:

• There is a fairly strong architecture for the Frostbite engine. Both for the runtime architecture (client-server) and even more important for the development architecture where the runtime architecture is just a "small" part besides e.g. the FrostEd editor for game objects and the build database(s).
  
• They use extensive knowledge about the game (domain knowledge) to minimise necessary information sent to/from the server and the clients (the latter being the software you buy at a gaming store and run on your Xbox360/PS3/PC).
• The run-time architecture uses parallel processing in multiple cores and distributes "jobs" between the cores dynamically.
  
• They use continuous builds, i.e. as soon as a programmer checks in new code it is built into a working program. This for the game developers always to have something to run.
• They only do positive testing, e.g. the program shall have this feature. No test on the program shall not...
• The Frostbite team consists of 19 developers and they update and maintain 1.5 MLOC for all 3 platforms (Xbox 360, PS3 and Windows). It is like we would maintain the entire in-vehicle software with 20 people.

I hope I didn't misunderstood anything...

Lindholmen Software Development Day 2010

Lindholmen Software Development Day is a yearly free get-together for local "software developers, managers, project managers and business developers" here at the north river shore in Göteborg. The theme for this year is

• Perspectives on and analyses of the changing market situation
• Software development philosophies supporting the changed situation
• Discipline Integration challenges and solutions, e.g., in H/W-S/W codesign
• Processes, Methods or tools to improve speed, efficiency, or quality
• Experience reports from new ways of working

I was asked by some people at Volvo Cars to present something relevant to us, and after some thought the topic of my talk would be "The future of automotive software engineering". Not pretentious at all...
Here is the outline I proposed. Any acceptance notification will come in August.

• General briefing on current and future trends in automotive software engineering
• Exponential increase in size, complexity, innovations, …
• Cycle times are dictated by what?
• Industry-wide ways to cope
• Standardisation
• Model-based development
• Architecture
• Soft issues
• Knowledge and maturity in the industry
• How to earn money?
• Some examples (from Sweden)

Concurrent architecture

To continue my thoughts about the programming language Erlang and especially how an architecture for a system implemented in Erlang would look like...

Joe Armstrong's PhD Thesis provides a very good understanding of the basic principles of Erlang. I think that some of the mechanism in the language makes several pattens in Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects unnecessary.

I think it would be quite useful to describe the architecture in views. I think the "standard" 4+1 views could be used quite easy for a system implemented in Erlang as well.
However it may not be the logical view that the other views are derived from, rather I would think that the process view would be the basic view. Kruchten has an underlying assumption that the logical view is object-oriented. This is obviously not relevant for a system implemented in Erlang so a different notion of the logical view is necessary.

Joe Armstrong strongly suggest a hierarchy of processes. A problem domain model could be a good way to identify the top-level processes, e.g. the PDM classes could be the initial processes and the asynchronous interaction will be implemented as messages, since reality is asynchronous. I need to try this in practice though...

Architecture reconstruction pt. 3

These are some random notes the students took while doing the intial reconstruction (I translated some notes in Swedish to English).
I don't know if they will finish, since the semester has ended.

Why does the camera know about the state of the Robot?
The camera, having a relative angle could not properly determine the angle of an identified object when the vehicle is, for example turning.

The event handler gets information from the wheels and sends to the camera. Now there is both idle and turn. But the camera runs the same function regardless of the message it gets, why does then turn exist?

Conclusions:
Different ways to send states thorughut the system, some are event driven and some are conditional.
Naming standard and file structure are not the same throughout the system.
The protocol files were located in different places.
The fact that the different modules use different architectures is OK since the circumstances for them are very different.
The name OS of one of the applications on the Arduino Mega is not very suitable since it is situated at the top of the hierarchy.

"Trust is good, control is better" - a quote from a former architect colleague of mine which the students liked enough to write down

Erlang

I don't do enough programming!

It has been years since I actually was allowed (asked?) to write any production code that goes into any of Volvo vehicle, since we buy a majority of our in-vehicle software from suppliers. Besides that, most of the in-house code we do nowadays are auto-generated from Simulink and Stateflow models.
Mostly I have reviewed what others have put in our vehicles, which is not nearly as rewarding. And this usually only happens when there is a problem, usually not a bug fix but rather more complicated, like real-time scheduling or improper use or configuration of the basic (or platform) software.

Since I will take a more active part in the a project course at the IT University which uses Erlang I think I will look into that. Erlang has some features which appeals to me personally:

• Support for asynchronous parallel processing, ideal for multi-core processors
• Functional paradigm, in contrast to the dominating OO paradigm, so I need to brush up old knowledge of things I haven't used since graduating in 1993.
• Freeware from the erlang website
• Access to some experts on the language

Confession: I'm not really that skilled OO programmer either, I could probably not write a Java program if my life depended on it. I'm too old school, almost all professional programming I've done have been in C and Fortran, with some Assembler and IDL.

Architecture reconstruction pt. 2

The students wanted to have some tool support in identifying the relationships between various functions (i..e. who called who). This was simpler in theory than in practice.

A not-so-quick search on the internet listed some potential candidates:
Code Visualizer
Crystal FLOW for C
Code Visual to Flowchart
http://www.EtherPad.com
http://www.metamill.com/
http://rigi.uvic.ca/
http://www.informatik.uni-stuttgart.de/ifi/ps/bauhaus/index-english.html

However none of these were very easy to use, or could not handle C as a programming language.
They also tried Rhapsody since they had a student license form another course and Enterprise Architect since it was possible to download a time-limited demo and these programs had no problems importing the code and identifying modules and functions, but they did not identity the calling relationships.

The students did not want to spend to many hours fiddling with tools so in the end they settled for manually inspecting the C code and identify what files included what other files. Since it was a distributed embedded system with 4 microprocessors and about 30 kLOC it was a doable task. Let's say that the 7 development teams had
quite different "strategies" for decomposing their code.

My personal observation is that even such a "simple" thing as decomposing you C program into files actually needs structuring principles if several development teams (or developers) work in a project, otherwise maintenance will be very difficult.

I still haven't decided if I should publish the more "awkward" ways to do it as examples to learn form, I don't want to point fingers at any particular students.

Architecture reconstruction

Each spring a project course called Industrial IT and Embedded Systems is given at the IT University. A description of the project from 2009 can be read here.
The students used trac to support their project and you can access the public project pages here.

This year I coached the students responsible for defining the overall architecture at the beginning of the project.
The project is finished with an official demo of the robot's capabilities, but some students approached me with an interest of doing a "post mortem" of the software as an additional learning experience. I thought this would be quite interesting, enough so to share any experiences on this blog.

These were the primary goals the students defined for the exercise:

• Learning more about architecture
• Only analysis, not update current project (code)
• Reconstruct existing robot architecture
• Automatic reconstruction using a tool
• Create "logical view" from source code, showing dependencies on function level
• Variable scope, global variables
• Process view
• Evaluation, compare against first architecture

Second priority goals:

• What could have been done in other ways and what impact would those changes have made
• Improvement Ideas

The students doing the reconstruction use the excellent tool Pirate Pad to capture notes and common ideas. Pirate Pad is a simple pre-runner of Google Wave where you don't have to register to create a pad, everybody just access the same web address and start collaborating.

Yet another article

The blog is updated on a very irregular basis. the main reason is that I presently have 3 articles in the pipeline and this takes priority over anything else. The latest article which I need to update is to ECSA 2010:

Dear AUTHORS,

Unfortunately your paper has not been accepted 'as it is' for inclusion in the program of the 4th European Conference on Software Architecture 2010 (ECSA 2010), which will be held on August 23-26 in Copenhagen, Denmark.

However, the program committee felt that the work reported in your paper has a number of interesting ideas, hence, I would like to invite you to prepare a shortened version of your paper for inclusion as "Emerging research" category Paper in the ECSA 2010 proceedings. As noted on the conference website, the "Emerging research" papers (8 pages of Springer formating) present promising achievements from work-in-progress and are intended to stimulate discussion related to ideas and experiences. For further details about the "Emerging research" papers, plesae visit ECSA 2010 website (http://www.ecsa2010.org). To accommodate publication schedules, final papers must be submitted by June 11, 2010.

... snip ...


4. The camera ready copy of your paper is due by June 11, 2010 (This is a hard deadline!).

... snip ...

Once again, congratulations on having your paper accepted as an "Emerging research" paper. We look forward to receiving your final camera ready paper, and to seeing you in Copenhagen, Denmark.

If you have any question or comment, please email me.

Regards,

Ali

ECSA 2010 Program Chair.

Time to plan a trip to Korea...

The paper Architecting Automotive Product Lines: Industrial Practice by Håkan Gustavsson from Scania and myself have been accepted to the 14th Software Product Line Conference.

"Dear authors,

Thank you for your submission to SPLC 2010.
We are pleased to inform you that your paper has been accepted for inclusion in the SPLC full paper program.
Due to strong competition, we could only accept 28 full papers out of 90 submissions, giving an acceptance rate of 31%.
Congratulations on being included in this select group.

... snip ...

Once again, congratulations on having your paper accepted.
We look forward to receiving your final revised paper, and to seeing you in September in Juju Island, South Korea.

Sincerely,

Jan Bosch and Jaejoon Lee
PC Co-chairs
SPLC 2010"

More books on architecture

I previously wrote about some textbooks about software architecture. I have have since received three more books.

The first, Software Architecture: Foundations, Theory, and Practice, I disregarded fairly quickly. I think it is too verbose (712 pages!). I could not find the brevity and clarity I think a good textbook should have to should support understanding instead of overwhelming the reader with facts.

I have not had the time to read through The Art of Software Architecture: Design Methods and Techniques yet, it arrived today in the mail.

Software Architecture and Design Illuminated covers a number of different types or styles of architectures, and does so in a manner familiar to the students at SE & M (i.e. in UML models and in Java code examples). It takes a completely different approach to quality attributes compared to Software Architecture in Practice (SAiP), it is structured according to different architectural designs and explains what they are good and bad at. So rather by learning by reason about concepts if focuses on learning by examples. This means that the coverage of quality attributes and tactics is not as comprehensive as in SAiP, for example attributes and tactics related to embedded systems are lacking in comparison since there are few examples of those in the book.
However since the course presently is structured according to theory and not examples of different types of architectures it would require more update of the course compared to the other texts.
The book also has some on-line material for instructors which I have not yet been evaluated.
Summary: Good book which I think presently is the best undergraduate book out there. I like the example-based approach, but it might just be appealing to me because of the fresh approach to an already familiar subject.

On variants...

During my research I gained some inside information into how various automotive manufacturers work. One very interesting observation is to see how different companies approach variants.

I know of two high-end companies having as a general architectural strategy not to have variants of systems or ECUs. Note that the electrical system as a whole may me different due to e.g. feature content, but if the system has a body control module there only exist one variant of that module both in development and manufacturing. To my understanding they are only using the optional variant in F. Bachmann and L. Bass, "Managing variability in software architectures," SIGSOFT Software Engineering Notes, vol. 26, 2001, pp. 126-132, and not any of the other types.

Personally I think that this is very beneficial for a company, both from an engineering and from a manufacturing perspective, even if it seems wasteful not to cost-optimise an ECU.

But this strategy is probably not for everyone. There are some common characteristics between these two companies:

• The are both high-end brands and have customers that can afford to buy the best.
• They are not mass producers, only in the order of 100k vehicles per year. This means that development costs are not negligible to article cost, even if they are smaller.
• Tailoring to the customer needs is an important business strategy.
• The have unusually high ROI compared to the average for the automotive industry. Being successful is another way of describing it.

And no, Volvo Cars is not one of the two companies...

The question is how you "dare" to go for such an architectural strategy if you are not already doing it? I think developing a business case to show that you would earn more $$$ with such a strategy would be extremely difficult.

Fallacies towards lean architecting

If architecting is seen as an effort on which you can spend more or less resources with a better or worse result I wonder how you identify the trade-off where you get the "most bang for the buck"?

I think this is a fundamental question to ask if one discusses architecture from a lean perspective. To use the standard lean criteria, to eliminate everything that does not contribute to end-customer value, disregards several important (?) quality attributes of an software architecture. One could argue that a product line approach benefits the end-customer, but to be honest I think it is the developing (creating?) organisation that reaps the main part of any benefits.

What are some fallacies that would detract from the most efficient architecture? A personal list would be something like this:

• Completeness of the architecture - To aim for an architecture that describes 100% of the system at some abstraction level is not efficient. I don't think I need to detail this argument besides Pareto's law.


• Formality - Strictness in describing the views may hinder the stakeholders' understanding of their concerns. To much effort on defining and/or understanding modelling rules is not efficient.


• Detail - An architecture is a top level design, and I would put an emphasis here on top-level. It should not bother with details best left to other tasks (and stakeholders)


• Traceability - To require traceability to all requirements that affect the design of an architecture and traceability from all requirements resulting from architectural decisions is not efficient. On the other hand to have no traceability is not efficient either.
  There should be enough to convince the stakeholders that vital concerns have been addressed. So it basically is the stakeholders that define the necessary level. Note that very rigorous stakeholder may completely big down an architect with demands on traceability...

I would like to expand these thoughts in a more rigorous way, enough to present at some workshop, or at least have more discussions with researchers and practitioners. I'm still waiting for the book by Coplien and Bjørnvig.

Presentation on lean product development

I got a link from a colleague with a presentation on Lean development at Jaguar and Land Rover by Baback Yazdani. The interesting part starts after 14 minutes.

See the presentation, it is one of the best I've heard that focuses on lean product development (instead of lean manufacturing), and acknowldges the fact that not all value created by PD can be measured in money (for example the ability to do rapid development is a product of doing development). He also states that the critical issue of lean in PD is about reducing lead time.

One of the key things I think everybody should remember from the presentation is that you should not (cannot) utilise a development organisation more than 70-80% if you want to go lean. If you do that there will not be enough "thinking time" to identify potential improvements.

Volvo is sold to Chinese Geely

Yes, I am aware that Volvo Car Corporation has been sold to Zhejiang Geely Holding Group. We, the employees, was informed by the newspapers, same as everyone else...

Read more about it from Gasgoo Autonews, Detroit News, Dagens Industri and Göteborgsposten (the latter two in Swedish).

Some more thoughts on agility and architecture

This is a quote from Grady Booch's blog:

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

One interpretation I can make of this quote is that it seems to be an inherent contradiction in aiming for agility in the design decisions that constitutes the architecture. Architecture is those decision that you don't want to change since it is costly to do so (in $$$, man hours or lead-time). But this is not the same as making those decisions up-front.
Maybe a lean approach is what benefits agile development the most:

...an architect should make as few decisions as possible, deferring the rest until later in the lifecycle.

Tyree and Akermann in IEEE Software 22(2), 2005, pp. 19-27.

SEI has a webinar 22 April about Agile Development & Software Architecture. Maybe that can shed some more lights on how to reconcile architecture and agility. To bad they are broadcasting it at such an awkward time for us in Europe.

Authors of the top papers...

Good news, but more work...

Dear Ulrik and Carl,

We are pleased to inform you that your research paper,

"A Case Study of the Architecture Business Cycle for an In-Vehicle Software Architecture",

has been selected to be extended and submitted to a Special Issue of the Journal of Systems and Software (JSS).

This JSS Special Issue will include the extended and revised best papers selected from the 2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture (WICSA/ECSA 2009).

Indeed, we announced at WICSA/ECSA 2009 that extended versions of best papers of WICSA/ECSA 2009 would be selected to be submitted to JSS.

We have better news: our cooperation with JSS was upgraded to have this year a JSS Special Issue including the best papers of WICSA/ECSA 2009, instead of submitting papers that would be included in different issues.

Based on review scores and reviewer comments, we are inviting authors of the top papers to substantially extend (at least 30% of new material) their papers and submit them to this Special Issue. Congratulations on being included in this select group.

...snip...

Looking forward to hearing from you and hoping that you will accept our invitation to contribute to this Journal Special Issue.

Yours Sincerely,

Flavio Oquendo, Eltjo Poort, Judith Stafford
JSS Guest Editors (Program Chairs of IEEE/IFIP WICSA/ECSA 2009)

Auto news sites

Some sites for those who want current news about the automotive industry:

Gasgoo Automotive News - the most in-depth information I have found so far about the global automotive industry, maintained by China's largest automotive B2B marketplace...

Detroit News Auto Insider - marginally better than Gasgoo on "the big three", but lacks on the rest of the world.

Auto Bild and Auto, Motor und Sport are two major German auto magazines with extensive websites. It helps if you know German. The latter also have an ambitious Swedish website.

Ny Teknik Fordon - Sweden's largest technology newspaper focusing on technology (what else?). Good on Volvo and Saab, in Swedish.

Dagens Industri Bil & Motor - Car news from Sweden's largest business newspaper. Also in Swedish...

Ford's new infotainment

It should come as no surprise that Ford is one of the leading automotive companies when it comes to infotainment systems and vehicle connectivity. Read an in-depth interview with Alan Mulally on the topic.

The new Ford My Touch just confirms this position. As an architect I am impressed by how they manage to coordinate suppliers as Gracenote, Nuance, Sony and Verizon into what appears as a seamless system based on Microsoft Auto, a system that can directly use services from Inrix, Pandora, Stitcher, Telenav and Twitter.
One side effect of connecting the vehicle with everyting else is the security of the information stored in the car, as described in this blog by Steve Cypher

Read what other blogs have to say about Ford My Touch.

Is software a product of creativity? Or?

I think the phrase "development process", or rather the concept of development as a process has become a paradigm in software. A google search on software development process results in 724 000 000 hits!

The view of creating software is done through a "development process" is so established, at least in the software industry, that no-one seem to question if this is a valid view on how to design stuff. This regardless if one talks about waterfall, spiral, agile or lean.

Since I am not a native English speaker it could be a lack understanding the connotation of the words, but I'll try to explain what I mean.

First, software is developed. No-one talks about a software creation process. To me development is more akin to refinement, exploitation or progress. I think software is created, it is one of the very few intellectual pursuits besides the arts where something is created from nothing.

Second, the development (or creation) is done through a process, something which in an engineering perspective means that by combining the right inputs and having the right circumstances, a desired output is achieved. And the process is repeatable as long as the inputs and circumstances are the same. I don't think anyone disagrees when I say that not two software projects are alike, regardless how similar one tries to keep the process.

So the question is how should we view software creation? I think it would be helpful to see it as a creative endeavour similar to what a writer does. There is usually some idea of what the end result should be, but that may or may not be very detailed when starting to make sentences. Some write in a very linear fashion, starting with the first chapter. Some start with an outline which gets more and more refined until it actually is the full text. Some writers are very disciplined and can write for 8 hours day, some can just write when they are inspired. And everybody has heard about "writer's block"...

If software is not developed in a process, but seen as a work of creativity I think efforts should be to make the people writing software as creative as possible (and therefore also productive). Maybe this can be used as a "lean" principle on how to manage a software project.

EAST-ADL2 and AUTOSAR

EAST-ADL2 is an automotive architecture description language "with improved means for capturing the requirements, characteristics and configurations of cooperative systems and the related analysis and V&V."
I was involved in the first ATESST project on how to align the ADL with the AUTOSAR meta-model.

There is a webinar presenting the latest results from the ATESST 2 project on EAST-ADL2 and AUTOSAR. More information about the results and registration for the webinar can be found in the ATESST2 newsletter.

Is an archtiecture description always necessary?

I wrote in an earlier post about the importance of being able to write in a concise manner, based on the assumption that key issue for an architecture description is to convey an common understanding of the architecture (more on the validity of that assumption later in the blog).

What would happen if that line of thought is taken to it's extreme, i.e. nothing is written down about the architecture? How would one reach a degree of understanding among the team members? And especially a common understanding? Does it even need to be common?

Answering these questions could easily expand to an entire literature review of organisational learning and I'll try to avoid that. But an architecture description is a way to convert the tacit or internal knowledge (of the architects?) to explicit knowledge which in turn other stakeholders can internalise again. The question is of this transfer of knowledge can be spread through the organisation by other means?
I certainly think so, the same way I learned about electrical system in vehicles "on the job" rather than learning from books, but this requires working side by side on a recurring (daily?) basis. Feasible if the team is co-located in the same room, but it does not really scale if the desks are to far apart. One architect and 15 other developers is not a problem. One architect and 200 other developers is a problem.
I have a gut feel that this is related to how well agile practices scale to big projects...

After reading this post I realised I made an assumption that the architect is the main person having the knowledge about the architecture. Of course this must not always be the case. One alternative is the committe architectures I wrote about earlier, but there of course must exist other alternatives...

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