I am a little confused at how best to visually model a space-based architecture (SBA) for presenting the system/software architecture design to a client.

The goal of this modelling is to show:

  • The major components of the system (e.g.: databases, server exposed API, client, server workers, client exposed API)
  • Interactions between these major components
  • Primary end-to-end workflows

Currently I am thinking to use BPMN2 notation with swimlanes; and sequence & use-case diagrams in UML2 notation.

Not sure if this approach is best, would be great to get some feedback :)

  • 3
    Architecture Astronauting at its finest. No wonder they call it Space-Based Archtecture. Commented May 24, 2013 at 15:17

2 Answers 2


Agree with the previous answer. As mentioned there, the model types mentioned in the question will not help you alone.

In case of a non-trivial data model or business domain, I recommend to start with an entity relationship diagram. It is easy to understand, the few symbols are quickly explained. Include proper definitions of the entities. This will make sure everyone has the same understanding of the domain. The relations with the cardinalities will also sort out many misunderstandings in advance.

A block diagram is usually the main diagram to show the runtime composition of the architecture. Indicate protocol and system boundaries. Choose an abstraction level which fits the purpose, and then be as specific as you can with the elements you show. E.g. in a communication channel, indicate who initiates the request, the data flow direction, and the protocol used. Describe the purpose of each component and connection in additional text below the model in case it is not trivial or obvious.

SAP uses a slimmed down UML version for architecture (as described here).

Conceptual Level Component/Block diagram

Design Level Component/Block diagram

You might use the other diagram types if required.

Don't forget that there might be a design time view of an architecture which is different from the runtime view. E.g. you might have layers in the design time which are collapsed by a compiler for the runtime.

  • Good answer. Specially the 2nd paragraph (about entity relationship diagram) Commented May 27, 2013 at 7:18

With any architectural modelling and representation you have to consider your audience and what notations will most easily and accurately communicate the designed structures as well as rationale for those decisions.

Two good things --

  • Using a documented and "standard" architectural style (SBA) helps with communication by way of pattern recognition. If someone knows the style, knowing that you are using it will help that person understand more easily.
  • Using a documented and "standard" notation for diagramming will assist with readability in that individuals who know the notation will be able to infer structures and meaning more easily.

The caveat, of course, is that you cannot assume that everyone will already know the styles and notation conventions so you must still use standard diagramming best practices (e.g. legends, clear labels, not mixing perspectives, multiple views and viewpoints, etc.)

The only other catch regarding UML notations for architecture representation is that it can sometimes be challenging to diagram architecture-level concepts using notations designed for object-oriented design. I don't see how either of the notations you've mentioned will help you model the architecture. Use cases aren't just pictures. And business process modelling has nothing to do with structures -- dynamic, static, or physical.

  • "it can sometimes be challenging to diagram architecture-level concepts using notations designed for object-oriented design." Works nicely, we do that in nearly every of our software products using a slimmed down version of UML. Commented May 24, 2013 at 22:41
  • @AndreasHuppert, I didn't say impossible. But it can be difficult and depending on what views you plan to depict, unnatural. With so many diagrams to choose from using a slimmed down version as you mention is a very good idea. The second half of George Fairbanks' book "Just Enough Software Architecture" gives UML for software architecture a fair and thorough treatment.
    – Michael
    Commented May 29, 2013 at 2:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.