Managing Automotive Software Architectures

Writing user stories

2012-01-26T14:29:00.000+01:00

The blog is updated very seldom nowaays. It is not becaus I have lostinterst, it is just that I wite scientefic articles with an unprecedented speed in parallele with doing improvement work at Volvo.

I just wanted to put in a remindre of how you define a user story (e.g. for use in a Scrum backlog), shamelessly stolen from a presentation by Dean Leffingwell:

As a <role>
I can <activity>
So that <business value>

"As a Gmail user, I can select and highlight a conversation for further action"

Keeping it in one’s head

2011-12-17T09:53:00.002+01:00

A friend of mine recommended this text on why programmers work at night. Entertaining but still true.

But the blog post referenced another interesting text written by Paul Graham about the necessity of holding a program in one’s head to be an outstanding programmer. I couldn’t agree more with that he says. I also agree with the corollaries that it is detrimental to treat developers as interchangeable parts in an organisation.

But what got me thinking was the fact that an architect must keep an entire system in the head. Where the programmer has the code as something tangible to base this mental model upon the architect has at best an abstract model and at worst only her own internal representation.
So for an architecture to be successful it both seems to be necessary that there is somebody who has the ability to internalise and reason about an entire system, and that the mental representation is possible to grasp in it’s entirety with (at least) one single mind. There are probably a lot of systems out there that fulfils neither….

More on-line lectures on software architecture

2011-11-21T11:04:00.001+01:00

I was discussing with one of my colleagues at the department if there were any introductory or summary presentations on-line about software architecture. I have already listed some on-line lectures about software archtiecture in the blog, but a quick search revelad some interesting ones:

An Introduction to Software Architecture and the Risk-Centric Model by George Fairbanks. George is a an excellent lecturer and has written one of the best books available on software architecture. If you have the oportunity to discuss with him, take it. Too bad the sound is so bad in this video clip.
Conscious Software Development: Architecture with Jeff Mckenna. Why not look through all parts in the series while you are at it?
Software Architecture Document by Philippe Back. I don't know who this guy is, but he manages to convey a lot of essentials in 12 minutes
SEI has a number of webinars related to software architecture. Unfortunately I can't get them to play on my computer, maybe you can?
Out and About: Software Architecture with Simon Brown. A short clip with a view on what a developer needs to do to be an architect.
Considering a Software Architect Career by Marc Ferrentino. A very short clip on what skills you need if becoming an architect.

MeeGo is out, what is in?

2011-11-18T16:11:00.000+01:00

There has been some turmoil in the world of infotainment platforms. Intel has left Meego and have partnered with Samsung in Tizen. This just a few months after Meego 1.2 vas deemed GENIVI compliant. I have no idea if Tizen aims to be GENIVI compliant as well. But there are already some commercial platforms that are GENIVI compliant.

I have been involved in the Open Infotainment Labs, a project patially funded by VINNOVA aiming att evaluating radically different work methods compared to standard practice at most car manufacturers. We integrated the system in a car this week, 16 weeks after start of development.

AUTOSAR as open source

2011-11-14T08:55:00.001+01:00

This might be the coolest thing I have seen so far: There exist an open source distributions of AUTOSAR!
And it's local to us here in Gothenburg, should I be embarassed for not hearing about this earlier?

Caveat: Note that if you intend to use AUTOSAR in a business setting you need to fulfill the conditions according to the AUTOSAR consortium.
After some e-mail exchange I now know that the open source AUTOSAR BSW software (ver 3.1) is available under a GPLv2-license.

Set-based architecture

2011-10-26T09:25:00.001+02:00

I listened to a presentation from Durward K. Sobek II about set-based concurrent engineering, which is a development paradigm(?) from lean development (more precisely from Toyota Product Development System).

The original principle, as I understand it, is that a designer should work with a set of design proposals towards manufacturing and in the dialogue between what is desirable (form engineering) to what is possible (from manufacturing) iteratively narrow it down to a single design. He concluded the presentation with how one would start with this in the small and the advice was to present two designs instead of a single one the next time

It made me thinking about how an architecture is “presented” to the stakeholders, especially the developers. would it be possible to present two architecture proposals to developers and let them identify the constraints from their perspective in narrowing it down to a single, agreed, architecture.

Choke on cinnamon buns?

2011-10-06T10:35:00.001+02:00

I wrote in a previous blog post about that I get upset about bad programming. I stumbled upon a prime example of bad programming from the excellent website Jävla skitsystem on that it was not possible to buy 20 identical cinnamon buns at 7-eleven at the same time because it crashes the cashier system and it would take 15 minutes to reboot.

I don't know what is most stupid? That there is an actual limit on the amount of goods you can buy, that the system crashes without recovery if you pass this limit or the fact that it takes 15 minutes (!) to reboot. First I cannot understand that the programmer was so narrow-minded he/she could not imagine these situations. Second I don't understand that the company delivering the system did not catch this in their testing. What kind of procedures do they have? And this system handles money...

First International Software Technology Exchange Workshop

2011-10-04T09:28:00.001+02:00

Swedsoft arranges a workshop in Stockholm on Wednesday 23 Novemeber. It is dedicated to transfer academic results to industry. Sounds really interesting.

First International Software Technology Exchange Workshop 2011

The angry programmer?

2011-09-28T07:29:00.004+02:00

My wife thinks I should start another blog named "Ulriks programming nightmares". Or maybe just add another topic of this blog where I mention examples of programmed systems that aren't good. Or to be more precise, where the programmer was too lazy to do a good job, which really gets me going. Unfortunately I get upset when I see it among the students which is a bit harsh, they are here to learn after all.
The examples I have seen so far is everything from the logic of the elevators at the university to how the booking system of SJ places people at a train. Seriously, if there are 3 reserved seats in a wagon, why must two of them be next to each other?
Enough ranting, but is this a good idea to expand the topic of the blog with? Coming to think of it, there must already be sites like that out there. If not there should be, it is always more educational to learn from bad examples than good.

Documentation

2011-09-27T21:54:00.001+02:00

When it comes to documentation I am firm believer in the quote of Antoine de Saint-Exupery:

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

As I see it there are a few main purposes of producing documentation:

To convey understanding - This shows my quite liberal view of documentation since I consider drawings on a white board or a napkin to be documentation. But I also consider this to be one of the most important purposes of documenting things. From a designer’s viewpoint these “documents” are vital in going from an inner vision to an operational image that can be shared by others. Common examples of documentation conveying understanding in large organisations are presentations given at various meetings. These documents can be saved for posterity, but the ability to convey understanding is much smaller for those who weren’t there. On the other hand are written documents one of the most efficient means through history to build on knowledge of others which you never had the opportunity to meet.

To formalise agreements – If there is a business agreement between two organisations it is almost inevitable not to have a more formal document detailing the technical content of the agreement, the specification. many organisations, including my own, also use documents to formalise the agreement between internal teams. Your mileage may vary how efficient this is in various organisation.

To preserve information – The human memory is not infallible. Documentation is a great support to minimise the decay that is inevitable when only relying on the human mind. Software is also about maintenance and any body who has been given the responsibility to update legacy code that is undocumented know how difficult it is (this scenario includes the purpose of understanding as well)

I don’t buy “the code is the documentation” at all. The code by itself does not fulfil any of the purposes above.

I have recently worked in a project which solely relied on Trac to capture all information relevant to the project (except finances). I am positively surprised how much you can achieve with so little formal documentation in combination with having everything in the same place available for everybody in the project. I will try to do a more formal evaluation according to the purposes above when the project is near it’s end.

When to decide?

2011-09-20T10:17:00.000+02:00

I have recently experienced several occasions where people want to decide things as early as possible in a project. This seems to be based on previous experiences that this was difficult in the last project and we want to eliminate things to worry about late in the project since there will be new things to worry about then anyway. So why not solve the major problems you are aware about anyway?

I think this kind of thinking is detrimental for the success of the project, especially if the decision influences the architecture (Grady Booch said something like "the architectural decisions are those costly to change").
If one looks at the reason the problems came up in the first place it is usually things like the implications (especially technical) of the decisions was not fully understood, the requirements were not suitable, or my personal nightmare that my team will not suffer any consequences whatever the outcome so why not decide this now...

If one has superficial understanding of the consequences or if the requirements are unstable it is a better strategy to postpone the decision as late as possible, and also delegate it to those who are most affected/concerned. But this means you and your organisation is comfortable with living with uncertainty. Which may be very difficult depending on the culture or the organisation. For example if all of your project revolves around a stage-gate process (very common in the automotive industry) it really does not fly well to say "let's postpone this decision for another 6 months and make progress with what we can".

It may sound I ampreaching the agility gospel, but that is not the case. I have full understanding that once you have made an architectural decision you don't want to change it. I just want to argue for the heuristic that you should not decide something because you can, postpone it to when you have make it.
And as a consequence I really dislike when you have to decide things just to feed the process, especially if the process is very slow to change.

WICSA 2011

2011-06-30T13:45:00.000+02:00

I was at WICSA last week. I am a lousy trendspotter, but here is what I have seen as “trends” so far:

There seems to be several efforts, especially on the tool side, that focuses on capturing and navigating architectural information. Is this a sign that architecture information is getting bigger and bigger and is distributed among different sources/artefacts? I thought one of the tangible deliverables from an architect was a comprehensive documentation/model/wiki/whatever with architecture information. As a contrast there wa a tutorial the last day by George Fairbanks on writing a 1-page architecture document. I would say this was a highlight of the conference, to bad most people had gone home by then.

In general it seems architects are more aware of the need to adopt to agile development. I don’t think there is any contradiction, contrary I believe that it is necessary for agile developers to be more aware of “architectural thinking” and what benefits there is of having an explicitly defined architecture. But I do agree that often architecture is the same as Big Upfront Design. At the panel debate I understood better the historical background; many of the originators of the agile manifesto were active developers already in the late eighties and nineties when a lot of focus where on software design. people who started as developers in the last decade don’t have that background and think that the last years focus on process is all that is necessary for developing good software.

There was some discussions on architecture-based testing (this is a good strategy to define a new research area, combine two or more buzzwords), but it was confusing. some people seemed to mean an architecture where it was easy to verify the quality attributes it was designed to achieve. others seemed to mean an architecture for a systems that was easy to test for testers. I like the latter better, and hope there will emerge more patterns for this than the general patterns of encapsulation etc.

Compared to the last WICSA in 2009 I think the acceptance rate was much higher, above 40%. I think this could be one explanation to why some papers had a rather weak scientific methodology. One other thing I did not like at all were some studies based on industrial practice where the results were too polished. if you present a case study you should include all the small (and big) problems that occur in real settings, otherwise the cases are not of more interest than textbook examples.

Reference architecture, what is it?

2011-06-21T13:42:00.000+02:00

I am at WICSA 2011 and the words “reference architecture” come up now and then in discussions. I am not sure I like the definition in Wikipedia, I think relies too much that you already have knowledge or experience of a reference architecture.
One simile (parable?) would be to a building code, a set or rules that underlie the actual architecture and construction of a house. The architect is free to build any type of house, as long as the code is adhered to.
But I like to use cooking as an example. A recipe is like an architecture, when you actually cooks the recipe and serve it is the implementation of software. You need to do certain things that are implementation specific, like tasting to see if the amount of salt suits your taste etc, and maybe you need to double all the ingredients to fit your dinner party.
Julia Child writes in her book Mastering the Art of French Cooking that there are 6 principal ways to make a sauce, one being an emulsion of melted butter with egg yolks, which is common the common method for béarnaise, hollandaise and choron sauces. The type of emulsion is similar to a pattern while the three different recipes are designs.
For a restaurant; a product line architecture would be the menu they have based on the ingredients they stock, for example chicken could be used in more than one dish.
So what is a reference architecture for a restaurant? It would be the “rules” that guides and controls what is possible or desirable. It could be for example driven by the business domain, e.g. it should focus on French or Hunan cuisine. Woking as a “development method” would not be relevant in the former, but certainly in the latter.
Or it could be driven what is technically possible, e.g if the kitchen has no deep fryer it is impossible to for example make french fries.
Or there could be other restrictions, such a desire to only use locally produced ingredients.
Maybe I went to far with this simile (parable)?

Architectural views in practice

2011-05-25T21:50:00.002+02:00

My research is not really focused on identifying the “best” architectural views for in-vehicle software. But as a side effect to the studies I am presently doing I got to think about three views that could actually make a difference in how well large projects succeeds (or fails). I have thought about the need of addiitonal views, but cannot think of an immediate need of more.

Integration is always an in issue in large projects that has some form of iterative development. With the increasing inter-dependencies between various parts of the system it is almost impossible to know what should be integrated when, for example what can actually be tested. There actually is already an architectural view defined that addresses this concern, the anatomy. I would describe the anatomy as visualisation of the complete system seen from an integration perspective, for example if a feature depends on a MOST interface it is no use to test it if the interface is not implemented. The visual picture means everybody should have the same understanding of the “.
The anatomy should dictate the order of development, delivery schedules and integration order. And the progress should be measured in how much of the anatomy is implemented, not in customer features. There is a relationship between customer features and the anatomy, but it is not one-to-one. you can read more about “Integration Centric Development and Anatomies” in a PowerPoint presentation or the article “Manifesting Shared Affordances in System Development – the System Anatomy” by L. Taxén and J. Lilliesköld.

The second view is the systems view, i.e. how the complete system is decomposed in smaller parts. I prefer to see this view as equivalent to the development view in Kruchten’s 4+1 views, i.e. it is aligned with the development teams. One can discuss if the system decomposition follows the organisation, as predicted by Conway’s law. The other extreme is that the development teams follow the most “logical” decomposition, i.e. ECUs, which is the most common unit to be outsourced to suppliers in the automotive domain.

The functional content of a vehicle is often defined by a list of customer features, which can be quite long, and this in itself can be considered an architectural view that concerns for example the business project, the marketing department and the end customer.
What is important for the development project is the relationship between this feature list and the two other views, i.e. what systems/development teams are responsible to implement the features and how the features relate to the anatomy. I don't know if these two relationships/mapping between views should be considered as separate views, which would make the total number of views 3+2.

What is a "good" architecture?

2011-04-08T22:34:00.000+02:00

Hopefully you recognise it when you see it...

I believe every system has an architecture, documented or not, and intended or not. So I think it is reasonable to discuss if the architecture of a system is good or not, and that the question if the architecture description is good is a different, but related question.

So what criteria could you use to establish if an architecture is good? Is it suitable for it's purpose is a more precise question? But this probably differs depending on the stakeholder, a system could be very nice and intuitive for the user, but very difficult to develop and maintain for the developers. In the rest of this blog post I will writing about goodness from a developer perspective (including the architect, if one is involved).

I think there are different levels of how well the architecture suits it's purpose to guide and control the implementation.

The ideal level is where the developer understands the architecture and following the architecture is the obvious way to implement something. Doing it differently is seen as more difficult and less elegant.

The next level is where the developer understands the architecture, is able to follow it on her own and can evaluate if the implementation follows the architecture or not. The developer also understands the "debt" that would occur if she deviates from the architecture, for example in terms of compromising some quality attributes. At both this and the previous level the developer can contribute to the design of the architecture itself, and an appointed architect doing the design may not always be necessary.

The developer may need continuous support from the architect to be able to understand the architecture when working. This is very common and requires more work and puts limits on the the ratio between the number of architects and developers in large projects.

The worst level is where the developer cannot understand the architecture and the only one that can determine if the implementation follows the architecture is the architect by reviews. This is very work intensive on the part of the architect. The architect is also viewed as a police that interferes with the developers rather than supporting them.

I have worked at all this four levels in various projects, and I think that you need to be on the upper two if you talk about a good architecture from a developer perspective. I also think that if you want to be truly agile in a self-organising team it is at the two top levels you nee to be.

Embedding Linux for an Automotive Environment

2011-03-21T15:10:00.000+01:00

I thought this presentation was interesting enough to share, even if i have absolutely nothing to do with it: Embedding Linux for an Automotive Environment. I guess you need to have a thorough understanding of Linux to understand how the optimisations were implemented.

You can watch a videorecording of the talk as well.

Jävla skitsystem!

2011-02-23T13:06:00.003+01:00

Pardon the Swedish!

The heading is actually the title of a Swedish book about how people can be stressed in a digital working environment. I think this is one of the most important books written about IT-systems and the problems they can bring on a personal level for the people who are forced to using them. Too bad is is not translated to English (yet?).
It is not a technical book, the primary audience are people using IT systems, secondly it is targeted at people planning and buying IT systems. It systematically lists 8 major stress factors and what can be done about them. Not all are caused by ignorant developers...
I think it is very valuable to read for people developing systems, so much I would make it mandatory reading for students in software engineering, if only it was published in English. There is some information in English, including a short slide presentation.

You can buy the book directly at the website or at major Swedish online bookstores.

You tend to favour the solutions you are familliar with...

2011-02-22T16:25:00.000+01:00

When I talk to students about the role of the architect I always make a point of the architect must know when not to use a particular solution/pattern/style (the old "Kill your darlings"). Regardless of this I have seen examples when an entire class thinks that a 3-tier architecture is the best solution in a project because they took a course on databases the previous semester.
Likewise, when I talked about component-based architectures in a lecture and gave examples based on AUTOSAR, a lot of students thought that components was the thing, even if it complicated the solution for the developers and the benefits with components was not really relevant in the student project.

This is not surprising since I am talking about students with limited experience to various problems encountered when developing real systems. But I also think this is a problem for professional developers as well, including myself. We tend to stick to what we know and don't reflect if what we know actually makes things worse than better.

Infotainment systems news

2011-02-14T18:34:00.003+01:00

I have been more involved in development of infotainment systems this year. BMW demonstrates what they call ConnectedDrive and Ford updates their Sync system to what they call myFord Touch

Compared to the amount of information at the links above there is very little about the comparable 2010 Volvo infotainment system at the official Volvo website. Note that the BMW is just a concept vehicle, while the Volvo system in in production, and still has less information about it on the web.

When the car gets connected, it also gets exposed: Telematics and security: Protecting the connected car

Therer are some interesting news about some major players as well: Nokia announce a strategic partnership with Microsoft on 11 February. I have no idea how this will affect Meego and GENIVI. Time will tell...
On the other hand there was a lot of activity around GENIVI at the Consumer Electronics Show in Las Vegas. And GENIVI is based on Meego...

Research in software engineering

2011-02-01T10:54:00.002+01:00

Researching software engineering is to study the artificial. Other engineering disciplines have "truths" that exist even if no humans are involved. The laws of physics that determine what is possible in mechanical and civil engineering are there regardless if applied when constructing a particular building.
Because of this I strongly believe that research in software engineering must be based on what practitioners do. I started to write professionals, but realised that a lot of important stuff in the world of software are actually made by amateurs (in the sense they are not getting paid to do it). And I also think research methods from the social sciences can provide great insights into software engineering.

A colleague of mine said that a good researcher in software engineering should have three base pillars to stand on:

A good knowledge of real problems that practitioners have
An interest in developing solutions to these problems
Knowledge and experience in evaluating the solutions in practical (real) settings

I have previously written about why I don't like formal methods. I think this is an example of where researchers tend to focus on the appealing solutions without a strong foundation in practitioner's problems or a thorough evaluation in practical settings. The most interesting solutions to investigate from a researcher's perspective are not always related to the most critical problems.

A short litmus test to discern if a researcher has enough experience of practical problems:
Describe the difference between a software process and a software project.

Development tools

2011-01-16T14:52:00.005+01:00

I think you should select the tool that supports the way you are working, not the other way around. This is one of the reasons I think tool discussions usually focus on the wrong thing. They tend to get very long-winded and troublesome since the underlying process is not clear or decided.
However if you are a small team, I think the following tools are of use to you regardless of what process you are using (the version control software are useful for any project size). Many of my students seem to use them when they are doing project work.

Version One Team edition - A free tool that supports managing agile software development.
Trac - An enhanced wiki and issue tracking system for software development projects.
GIT - A free & open source, distributed version control system. I think it is a major upgrade compared to SVN, even if the initial learning curve is steep.
If you run Windows I suggest you use TortoiseGIT as GIT client.
Mercurial - A modern, open source, distributed version control system (sounds very similar to GIT?). I think the learning curve is not as steep as for GIT, and a transition from SVN is probably easier. TortoieseHG is a good client for Windows users and what I use myself.
In this user-friendly, six-part tutorial, Joel Spolsky teaches you the key concepts.

If someone can comment with suggestions of free simple tools that supports testing/verification or integration I would be very grateful.

Confused by Simulink

2011-01-11T15:42:00.001+01:00

The most common modelling tool in the automotive domain is Simulink. It started as a Matlab-based tool to graphically model and simulate differential equations needed in control design. Now it has expanded way beyond that to enable generation of production code for embedded controllers.

For someone like me, with a background in software and systems engineering and only the mandatory control engineering course, Simulink is confusing. Not the model elements as such, since it basically is an executable time-discrete data flow model. But the terminology used in the Simulink community is really confusing since they are using terms very common in software development, but with different meanings. I am not even sure the explanations below are valid...

Some examples:

A layer in Simulink is not what what one usually calls a layer in software. What is called a layer in Simulink I would personally call a view since it adresss a specific concern, see some defintion of the J-MAAB layers here. But I have also seen a layer as something found at a certain level in a functional hierarchy (boxes in boxes...). Maybe these two even are the same in the Simulink world?
A software layer would rather be called a subsystem in Simulink, but that is a generous interpretation from my side. (See Pattern-Oriented Software Architecture by Buschmann et al. for a definiton of software layer).
There are classes and objects in Simulink. Data objects are used to "specify values, data types, tunability, value ranges, and other key attributes of block outputs and parameters", where blocks are the basic entities that one build the simulink model from.
The Simulink software uses objects called data classes to define the properties of specific types of data objects." So in a sense the class is a template for the objects. On the other hand the data object does not specify a behaviour or input-output relationship. But classes seem also to be a special type of objects in thelast quote above. Ouch!
Contrast this to common OO design where the class is the template for the object, which is the main item encapsulating both a behaviour and associated data. A block in Simulink most closely resembles a function in a procedural language such as C or Pascal.

The importance of the team

2011-01-04T10:58:00.000+01:00

I am reviewing and grading documentation in a student project. Or rather 12 student projects, all trying to develop similar software. The context is this: The students work in teams of 6. Each student has a separate role; project manager, architect, designer, quality/testing responsible, GUI designer and communications expert (it is an peer-to-peer application based on TCP). Alla students have to write code, and in addition to this they are supposed to turn in documentation related to their role.

What strikes me is that in the teams with good documentation all documents are good, regardless of author. How come? There could be several explanations:

Good students want to work with each other (they could choose their teammates, they weren't assigned by us teachers).
In good teams they cooperate on everything, inlcuding reviewing each others documents. In not-so-good teams they instead might try to split the tasks and work as independently as possible.
In the good teams there is an exceptional student that functions as a mentor to the others.
Excellent documementation from one role supports the others in their roles, e.g. an excellent architeture description supports testing etc.
The good teams had not only a notion about what to deliver when they started, they also had a good notion on how to do it early on, e.g. they discussed so they had a common understanding of coding responsibility (everybody had to write code) and they choose an interative process or SCRUM already the first week.
The good teams started with coding as quickly as possible. This is counterintuitive, but I think they felt more comfortable spending time on documentation if they already had some prototype running.
It seems that analysis paralysis actually produces worse documentation. I think this is due to an inability to focus on the vital concerns and stop when they are sufficiently covered.
It is hard to excel if your teammates drag you down. This could explain why there are no groups where just one role shines above the rest.

I'm sure there could be other explanations that I didn't think of...

IT talents in Sweden

2010-12-22T20:57:00.000+01:00

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

2010-12-09T19:04:00.000+01:00

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?

2010-12-03T16:43:00.001+01:00

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

2010-12-02T12:11:00.016+01:00

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

2010-11-29T14:18:00.001+01:00

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

2010-11-26T15:00:00.024+01:00

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

2010-11-25T11:50:00.001+01:00

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

2010-11-22T10:59:00.000+01:00

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"

2010-11-22T10:44:00.001+01:00

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

2010-11-19T17:29:00.001+01:00

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

2010-11-17T14:10:00.000+01:00

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

2010-11-10T22:22:00.000+01:00

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

2010-11-08T16:12:00.002+01:00

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?

2010-10-29T18:14:00.000+02:00

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

2010-10-28T16:10:00.005+02:00

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

2010-10-27T12:39:00.002+02:00

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?

2010-10-26T10:28:00.000+02:00

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

2010-10-19T10:48:00.000+02:00

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

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

2010-10-12T15:39:00.001+02:00

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

Hidden leaves

2010-10-10T20:15:00.002+02:00

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

2010-10-07T11:04:00.000+02:00

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:

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

2010-10-04T18:52:00.000+02:00

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?

2010-09-24T17:32:00.000+02:00

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?

2010-09-24T16:47:00.002+02:00

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

2010-09-23T14:08:00.000+02:00

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:
a 4 part ISO 9126 standard (QA considered are reliability, usability, efficiency, maintainability, portability AND, actually, functionality)
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?

2010-09-16T15:03:00.000+02:00

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

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

Why I don't like formal methods...

2010-09-16T09:08:00.000+02:00

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

2010-09-15T08:00:00.001+02:00

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

2010-09-02T23:05:00.000+02:00

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

2010-08-30T15:39:00.004+02:00

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?

2010-08-29T22:48:00.001+02:00

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

2010-08-27T15:04:00.001+02:00

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

2010-08-26T11:25:00.000+02:00

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

2010-08-25T08:48:00.006+02:00

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:

An increase in speed trumps any increase in efficiency
Software engineering is moving from integration to composition
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

2010-08-03T13:33:00.003+02:00

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

2010-08-02T14:12:00.002+02:00

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

2010-07-02T14:42:00.008+02:00

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

2010-06-24T10:24:00.009+02:00

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

2010-06-24T10:05:00.002+02:00

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

2010-06-23T15:08:00.000+02:00

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

2010-06-18T14:44:00.008+02:00

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

2010-06-16T13:30:00.005+02:00

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

2010-06-15T15:45:00.001+02:00

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

2010-06-11T11:59:00.000+02:00

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

2010-06-08T17:13:00.005+02:00

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

2010-06-04T17:18:00.003+02:00

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

2010-05-28T12:05:00.009+02:00

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

2010-05-26T15:58:00.004+02:00

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

2010-05-04T20:36:00.004+02:00

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

2010-04-30T14:02:00.005+02:00

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

2010-04-26T09:53:00.005+02:00

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

2010-04-26T09:48:00.002+02:00

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

2010-04-19T15:30:00.004+02:00

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

2010-03-29T18:12:00.005+02:00

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

2010-03-29T11:55:00.008+02:00

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

2010-03-27T08:17:00.004+01:00

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

2010-03-19T12:08:00.006+01:00

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

2010-03-09T13:37:00.008+01:00

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?

2010-03-05T12:07:00.000+01:00

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

2010-02-05T14:39:00.005+01:00

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?

2010-02-05T12:38:00.007+01:00

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

2010-01-27T09:59:00.004+01:00

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

2010-01-27T09:50:00.005+01:00

"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

2010-01-20T15:16:00.006+01:00

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:

A compararative case study on how two similar companies work with maintaining architctures.
A short paper describing how archtiects view themselves in terms of skills, experience, attitudes, etc.
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:

A new classification scheme for archtiecture decsions, based on empirical data
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

2010-01-08T13:10:00.000+01:00

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

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

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

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

Empowered architects

2010-01-05T12:25:00.005+01:00

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

Anyway, he mentions four characteristics of empowered people:

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

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

Volvo Cars will become Chinese...

2009-12-28T09:43:00.005+01:00

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

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

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

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

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

Documenting and Presenting Architectures

2009-12-18T12:45:00.001+01:00

Some interesting blog posts (and other links) about documenting and presenting architectures:

Architecture Documentation: Courage to Fly in the Face of Convention
Top Ten Tips for Presenting Architecture Information
All about IEEE 1471

A notice that puts my blog on a Swedish geographical blog map: Jag har placerat min blogg på Lindholmen på bloggkartan.se!

Organisational changes

2009-12-17T11:09:00.000+01:00

There will be some changes to my research group. I don't know how this will affect me in detail, but in general I think it will strengthen software research in Göteborg.

In short there wil be a new software research center (at Lindholmen?) which will be a merger with software resarchers from the departments of Applied IT and of Computer Science and Engineering. Software engineering will organisationally belong to the latter department, so I will change department.
The two masters' programs Software Engineering & Management and Software Engineering & Technology will be one, which makes sense since they have a lot in common (e.g. course in software achitecture). It does not seem efficient to give two different master level programs in the same area.

On-line lectures on software architecture

2009-12-14T16:53:00.007+01:00

It is surprising what you can find with some searching, for example full-length lectures about software architecture:

Note that I have not watched all of them (they are about 1 hour each) so I cannot vouch for any content and that the recording quality can be quite low.

Concise writing

2009-12-11T10:18:00.000+01:00

I was involved in the software archtiecture course this year, more than the last few years, not surprising since I developed the coruse in 2006. One of the things I did was to evaluate the hand-ins of several assignments, which was disappointing in more ways than one. But the thing I want to bring up in the blog is the lack of concise writing.
I think that one of the most important abilities for an architect (even more so than for other developer roles) is to present the "fundamental ideas" in clear, concise and short manner.

In the hand-ins, a lot of answers covered two pages when a paragraph with less than ten lines would have been sufficient. With a good picture maybe even less.
I don't know if this is beacuse the students were not comfortable with terminology (if you use a model-view-controller pattern, how much more do you need to say about it?). Or if they think verbosity is the same thing as showing understanding? Or if they did not have the time to strip away the "fluff"...
Next year I will propose a maximum number of pages in the hand-ins and deduct points if they write more than that. Obviously they still need to fulfill the task...

It is an art and craft, to write as short as possible, but it helps getting the message across! An architect should hone this skill.

Matt Deacon's talking architects

2009-12-07T16:39:00.003+01:00

I stumbled upon a channel with an interview series with various software architects. I must confess I haven't seen any of the interviews yet, but nevertheless I thought somebody else also might be interested:

Talking Architects
Matt Deacon, an Architect in Microsoft UK, talks to other architects about their experiences, their issues and challenges they face in the ever changing industry of IT.

Who is the customer?

2009-12-04T11:30:00.004+01:00

Very often I hear one should have a customer perspective when developing software. Some agile methods propose working close with the customer.

But who is the customer? Is it the person paying for the development?

The end-customer is usually not difficult to identify for consumer products, which is what I work with since I'm in the car business. But even for such a closely related product as heavy trucks it is not obvious who is the customer. Is it the user of the truck (e.g. the driver) or the company buying the truck?

And looking inside the developing organisation it gets even more unclear. I work with developing architectures. Who is the customer of an architecture? Is it the end-customer? I think he could not care less if the car has an architecture or not, as long as it has the features and properties he wants.

Sven Grahn, former scientific director of the Swedish Space Corporation stated the best "test" of identifying the customer I have heard so far (freely translated from Swedish and maybe so distorted by memory Sven does not recognise it):

The customer is the person, or group, that when you remove them the activity (or product) becomes meaningless.

So for an in-vehicle architecture the primary customer of the architecture are the developers. If there would be no developers who who look at the architecture? (The end customer is also a customer, if he's not there what is the point of developing the car in the first place?)

Can I use this test to identify who is the customer of research? In most cases it is not the ones who sponsor it (e.g. government, foundations. etc).

Confidence in an architecture

2009-12-02T09:55:00.005+01:00

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

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

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

Google wave

2009-11-26T12:33:00.005+01:00

I read about Google Wave in Ny Teknik (Sweden's biggest technology newspaper) and this was the first hands on description I had about how it could work, even though I had read about it before.

My immediate idea was that this could be used in science. Researchers could include data and/or hypotheses in a wave and other researchers could contribute to this wave with further data, analysis or conclusions. It could be very useful for collaboration between reserchers which are not co-located.

Remember where you read it first, in this blog!

Now I'm just waiting for an invitation from Google...

The difference between Academia and Business

2009-11-23T15:45:00.007+01:00

From xkcd.com

What is a project...

2009-11-19T10:56:00.008+01:00

I'm taking a course in project management and leadership for PhD students. Quite interesting...

One of my immediate observations is the discrepancy between the academic definition of a project and what we call a project in the car industry. According to our Swedish textbook a project is an activity with

a well defined goal
during a well defined time period
with pre-defined resources
under particular work model

A vehicle project, for example a model year update, certainly fulfills the first three, but the work model is/should be the same as the one we use for a model year update of another vehicle (not including any kaizen).
There is not something unique working with a particular vehicle model that warrants creating a project, it is just another task. A huge task, but nevertheless...
A research project is a different thing, for example developing the architecture for a new generation of electrical systems. There most work and deliverables are new and have not been done before or at least not in the last 10 years...

The other thing that I noticed as major difference is that the textbook states it is (or should be) impossible to participate in more than one, or at most two, projects simultaneously. An engineer at an EESE department usually works in more projects than that...

This post is in a response to an email I got about my previous post on more personal observations...