Architecture reconstruction

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

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

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

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

Second priority goals:

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

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

Yet another article

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

Dear AUTHORS,

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

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

... snip ...


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

... snip ...

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

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

Regards,

Ali

ECSA 2010 Program Chair.

Time to plan a trip to Korea...

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

"Dear authors,

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

... snip ...

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

Sincerely,

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

More books on architecture

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

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

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

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

On variants...

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

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

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

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

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

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

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

Fallacies towards lean architecting

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

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

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

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


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


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


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

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

Presentation on lean product development

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

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

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