Does the architecture matter when the ways-of-working change?

More and more embedded companies adopts agile development as their way-of-working for software. For small systems this is straightforward, but for large development projects with hundreds of developers working on the same product there seems to be a typical evolution that an organisation goes through before successfully scaling agile.

Typically the transition starts with individual teams adopting agile practices, but fast iterations and shorter lead-times on team level does not automatically lead to shorter lead-times for new or updated products. The organisation as a whole still uses a stage-gate process or V-model for the product development. If the organisation is successful in changing their entire ways-of-working across all departments it becomes evident if the product architecture supports or hinders the new way-of-working.

The presentation concludes with some general guidelines for how software should be designed to support agile development of large embedded software systems.

Testing as inspiration

Good testing is one of the bottlenecks that needs to be solved if your organisation wants to embrace shorter iterations and quicker feedback. On team level it seems possible to do almost continuos testing, but when it comes to testing integrated systems and products, with deliverables from numerous teams it is critical to have a well-understood test strategy, in the sense what to test, why doing it and when does it needs to be done.

I am the first to admit that I am not a tester, but as a software designer and architect I have been inspired by skilled colleagues who are testers, which is a skill in its own. I regularly follow the blog thoughts from the test eye since they have a view of testing which inspires me as a software architect. Not only do they have a an approach to their craft which I think resonates very well  with how I think software design and development should be done in ana agile context. They also produce some really useful reference material, for example i regularly use their Software Quality Characteristics 1.1, which is the best summary of quality attributes in a concise form I know of. They have other useful material, like Den Lilla Svarta om Teststrategi (unfortunately only in Swedish).

When is there too much architecture?

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 and the process of architecting as a separate activity. Inspired by the idea from lean to eliminate everything that does not contribute to end-customer value, the value of an architecture can be seen as small. Architects (and researchers focusing on software architecture) assumes an architecture supports several important benefits with respect to software development. 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.

But what are some fallacies that would detract from the most efficient architecture (most bang-for-the-buck)? 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…

Is an archtiecture description always necessary?

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. This is based on my assumption that the key issue for an architecture description is to convey an common understanding of the architecture.

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. this is feasible if the team is co-located in the same room, but it does not really scale if the desks are too 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…

I realise I also 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 in a previous post, but there of course must exist other alternatives…