Ranking of Software Engineering Journals

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

ICES-INCOSE Architecting Seminar - presentations now on-line

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

More on quality attributes

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

Trends and challenges in architecting embedded systems

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

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

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

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

Contact Us

dagzzhidalgo@gmail.com

For Suggestions and your Questions.

Thanks

Architecture for small systems?

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

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

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

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

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

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

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

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

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

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

Quality attribute scenarios

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

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

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