Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Saturday, March 21, 2009

Software and System Architecture

Currently, I am involved in a large-scale project where Siemens Healthcare is building a couple of very innovative and exciting particle therapy systems. These systems are rather challenging as they consist of complex software, hardware  - for example, a circular particle accelerator - and all the other constituents such as the building, the CT devices. It is a typical project where software while being a major element is only contributing a small part of the system. However, within our company which yields revenues of over 70 billion euros a year, software engineering has become a major business factor. According to an estimation 60-70% of these revenues already depend on software.  Now imagine, 10% or even more of our projects would fail - what a nightmare! There are two implications: first of all, lead software architects must be well educated in software architecture and technology and show the right leadership skills. Secondly, system and software architecture must be treated as two sides of the same coin. So, what are the responsibilities  of software architects and system architects and how should they cooperate? I tried to find an appropriate definition in Wikipedia and failed. Especially, system architecture seems to be not well understood or ambiguous.

From my viewpoint an effective partitioning in software and system architecture depends on the characteristics of the project itself. If software constitutes the main part of the product or solution, then the lead software architect could and should also be system architect. Obviously, an additional IT architect  makes a lot of sense if the underlying infrastructure is sufficiently complex, but that's a different story.

In projects where hardware and software are of the same relevance or where hardware dominates, for example in most embedded systems, a system architect should be in the lead and co-operate with a hardware and a software architect. The system architect then should care a lot about testing. I have been involved in projects where I was in charge of the software system but got only rarely access to the target system. Thus, we had to use the development system where everything worked stunningly fine, but got deadlocks when finally moving to the target system - the OS of the target system had a faulty implementation of  the Sockets libraries. This implies, that the system architect should allow software and hardware development to happen almost independently, but introduce a lot of sync points where software/hardware integration is checked thoroughly. By the way, a similar problem occurs when partitioning a software system into modules which are then designed and implemented by different teams - think of outsourcing in the extreme case. If integration and system testing is neglected, you will encounter a lot of bad experiences. It is much more complex and challenging to check hardware/software integration than the integration of software modules - at least in theory :-;  One of the bad experiences you might need to cope with is that hardware requirements are often considered almost fixed, while software requirements are considered "soft". Would you ever change the main specifications of an airplane shortly before it is delivered? Definitely not! But this does not hold for software systems.  One of the consequences of this fact might be that the hardware team has already finished their part, being reluctant to change anything. As the software requirements have changed in the project, software development has fallen behind schedule. In these situations, software architects sometimes become the scapegoats of system development. A good system architect should be capable of handling these situations effectively and efficiently by better synchronizing the different teams.

A system architect should also make sure that the overall system requirements are mapped consistently and completely to software architecture and hardware related requirements. He or she should care about requirements traceability, especially for those requirements that have to be implemented in software and hardware as well.  If hardware comprised the core part of the system, software architects should have a sound understanding of the overall system, not just of the "soft" parts.

Basically, you could consider the partitioning of software and system architecture responsibilities in almost the same way like splitting responsibilities between software architects and the lead architect. The system architect is in charge of the whole system, while the software architect is in charge of a part of the system.

There is a lot more to say about this topic. But I am curious what you think and I am wondering about your experiences with software and software architecture as well as with the respective roles. Any comments highly appreciated.


  • Hi Michael! Ive just started reading your blog and find it very interesting, good work! Regarding architects and different departments (software, hardware, mechanics, it etc), may brief experience is that it is important to have well defined roles. One key factor is to make sure there is a responsible at the system level, and this person should not be involved in any other departments at the same time. Because the system architecture will not get as much attention as the other department architecutural work. In my experience from a smaller company, there were simply no system management keeping it all together, just a couple of architects caring for their own business. And because software was a major part of the system, the software architect was supposed to "do-all-the-rest". That was ok from some view points, but I dont feel like it was the software department that should be alone responsible for system level documentation. Here, we needed feedback! And that was not sufficiently performed.
    So, yes, if it is for example a software intense system, let the software engineer become more involved in the system architecture, but be sure to define a peer - a system architect that has the final responsibility for the system as a whole.
    Best regards, Bjorn

    By Anonymous Anonymous, at 10:39 AM  

  • That's a very good and valid point. Software architecture alone keeps us very busy so that taking care of system architecture is not always feasible. In the ideal case, there is a person responsible for system aspects. Unfortunately, in many development projects software architects need to become jacks-of-all-trades. That's why a person keeping track of the whole system is so important. But as you also stated, software architects should feel at least involved in system engineering. Otherwise they may design a software system that does not integrate well with the overall system architecture. Guess, there are lots of consumer devices suffering from exactly that kind of problem

    By Blogger Michael, at 11:26 PM  

Post a Comment

<< Home