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.
30 April 2010
26 April 2010
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 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.
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.
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:
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.
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.
19 April 2010
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.
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.
Subscribe to:
Posts (Atom)