Some more thoughts on agility and architecture

This is a quote from Grady Booch's blog:

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

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

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

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

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

Authors of the top papers...

Good news, but more work...

Dear Ulrik and Carl,

We are pleased to inform you that your research paper,

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

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

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

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

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

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

...snip...

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

Yours Sincerely,

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

Auto news sites

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

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

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

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

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

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

Ford's new infotainment

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

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

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

Is software a product of creativity? Or?

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

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

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

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

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

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

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

EAST-ADL2 and AUTOSAR

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

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

Is an archtiecture description always necessary?

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

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

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

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