A lesson learned on why software architects fall short of expectations and how to fix it by changing the focus.
Detailing the design that is already clear in the head comes natural to an architect. Afterall most architects are basically aged developers. Consequently, this haste to get started - and even excitement about the technical challenges - prevents them from being effective. This paper is about the two small parts which make a developer become an architect: Discipline and Scope.
The following chapters cover the challenges as well as the lessons learned in the development of an embedded automotive software architecture. Based on the experience from different embedded applications the following structure will be followed:
Part 1: Where to start with a new design
This is the main question asked by new software architects. A good design starts with a clear value proposition. What is the goal and scope of the architectural design? Different answers are discussed and a good example how to start software architecture is shown.
Part 2: How to make the project content obvious to developers and stakeholders alike
Software architecture needs to provide all kinds of information for numerous people. From developer over safety manager to client. With a few simple steps, the number of diagrams and views can be reduced to an expressive minimum.
And Part 3: Which decisions improve agility the most
The biggest challenges of all is to postpone decisions to the time when all required information is at hand. When practiced this discipline might become the motor of a fast, high quality delivery. A strategy is presented to find the ideal time for decisions.
The development of a cluster instrument is taken as the example. Proposed techniques are shown that provide an answer to these questions.