What do software architects do? Are they the chief developers or the platform
specialists? Well, the architect of a house, at least, is not the chief bricklayer!
We investigate the role of a mediator between technicians, project leaders, and
system owners respectively, and discover as the central task of architects to handle the
technical aspects of division of labor.
This relates to both, the self-image of software architects, and
their clients' image of them. Today, expectations often do not match, and hence people face
conflicts endangering entire projects. Can we learn a lesson from house architects?
What are Component-Frameworks? What do they provide? What are the important properties?
How can you systematically construct a good component framework?
Using a simple and didactic example, we show a number of lessons to answer the above
Tales from Component Hell — Blame Assignment as a key issue of Component Software
Software components promise some kind of component heaven. Systems are assembled from
components made in-house or bought from third parties.
As the only prerequisite for the system to work, components have to meet their respective
specifications and interface standards.
Unfortunately, assembled systems often do not work and it can become quite a task to point
to the component causing the problem. Component vendors blame each other in turn and
system integrators find themselves in component hell.
At the end of the day, it is the software architect's responsibility to hit a way out of any such
crisis. Being aware of this already during the architectural design phase, it is a good idea
to design the interfaces between components so that mistakes get prohibited, or, those
that can happen nevertheless, can be clearly assigned to one of the components.