How to communicate architecture – Technical Architecture Modeling at SAP (part 2)
This blog complements my presentation about architecture modeling at SAP TechEd 2007 [TechEd2007a]. After the first blog post giving an introduction and overview of TAM, SAP's internal modeling standardHow to communicate architecture – Technical Architecture Modeling at SAP (part 1), this article presents more details about block diagrams.
Example: An online shop
Let's have a look at a simple block diagram showing an online shop.
Figure 1: Overview block diagram of an online shop
The block diagram in figure 1 shows the compositional structure of an online shop within its environment. We see customers who can do different things with the shop server, for example search products, put them in their shopping carts, and place orders. Inside the online shop server, we see agents that are responsible for customer accounts, for presentation of the products, and for processing the customer's orders. They access ERP data that consist of customer records, product information, or customer's orders. To process an order, the online shop server uses external services, such as credit card confirmation or transport.
This is a coarse model focusing on functional processing of information, providing hardly any technical details. It serves to explain how the online shop is organized, and to set up the terminology that will be used when going into detail.
Who's doing something?
Block diagrams are a general-purpose means to depict the compositional structure of any system that processes information, for example a finance office, a digital television receiver, a controller of a washing machine, or a computer that is currently used as a word processor. Common to all these systems is that you find something (or someone) that processes information.
In a block diagram, we call those who process information Agents. Only agents can do something, all other elements in a block diagram are passive. Of course there are many ways how agents can process information, for example sort a list, read and reject a job application, decode a text, calculate an average, read a sensor and switch on an engine, or de-multiplex a data stream and store it on a hard disk.
In block diagrams, agents are depicted by rectangular shapes. A stick man indicates a human agent.
Where's the data?
Here we come to the second element of a block diagram, the Storages. A Storage contains information that can be processed by an agent. By its nature, a storage is a passive component – it simply cannot do anything on its own. A storage can contain any information, such as a tax declaration, a movie, or the facts of a lecture.
The most important feature of a storage is the fact that it stores information, and that it can be accessed by agents. There are many ways to implement a storage, for example by a piece of paper, a file, a whiteboard, or computer based storages such as memory, file system or database.
An agent can use a storage to store data to retrieve it later on, or to share data with other agents.
In block diagrams, storages are depicted by rounded shapes. Access arcs show which agents can access which storage. Here, the arrow shows the direction of information flow. For read-only access, therefore one arrow from storage to agent is sufficient.
Who's talking?
There are many reasons why agents need to communicate, and they use Channels to do so. A channel connects two or more agents and enables them to communicate, for example to send requests, replies, messages, notifications, or calls. They are, like storages, passive components that serve no other purpose than to connect to or more agents. Examples of channel implementations are telephones, network connections, pipes, or even simple procedure calls.
Of course there are many ways how agents communicate with each other. From simple notifications, calls with complex parameters, requests or replies with a payload to data streaming, anything is possible. One special case is the request-response communication, since it occurs so many times. Here a dedicated client sends a request to a server that sends back a response. The initiative is always at client side.
The notation of channels in block diagrams is a small circle on an connecting arc between agents. You can annotate the circle with the type of request, the type of information, and with the protocol used here. Arrows indicate the direction of information flow. The "R" with the small arrow is a short notation of the request-response channel pair. Here, the arrow indicates the direction of the request, i.e. it points from client to server.
What's inside?
Nesting is an important modeling means for block diagrams. Often, you show an inner structure of an agent, that is yourefine an agent in the same diagram. Other refinements, that is the refinement of a channel or a storage, are usually not advisable using nesting.
Grouping is visually similar to refinement. The main purpose to group elements is to get rid of channels or access arcs. In contrast to a refined element, it is usually not necessary (and often not possible) to find a meaningful name for the group.
Finally, you can group elements that belong to one system (part), are executed on one platform, are located on the same database, and so on.
But there may be more!
A block diagram can be seen as a snapshot view of the compositional structure of a system. Often, you just want to indicate that there may be an open number of elements of the same type. In a class diagram, you would now start using cardinalities. In a block diagram, you can use two means to indicate multiplicity: Either stack the elements, or use 3 dots to indicate that there may be more.
How to start?
I encourage you to start modeling compositional structures with TAM/FMC block diagrams. Here is a small check list for a start:
-
Determine the active elements of your system (those who actually process data). These are the agents. Imagine how you would do their tasks.
-
Find storages and connect them with the agents:
On which data do these agents operate? Do they share the data? Do they store it to retrieve it later on? Is this data important to explain what the system does? -
Find the channels between the agents:
Which agents communicate with which? Is there a direction of information flow or a clear separation between client (sends requests) and server (answers with replies)? -
Check the access arcs and channels: Channels only connect agents with each other, access arcs can only be used between storage and agent. Can you be more precise about an access (read-only or modifying)? Can you indicate the direction of information flow on a channel? Is it a request-response communication? Can you add the type of the request here, or which data is transferred?
-
Can you give all elements (at least all agents and storages) a proper name? Avoid generic names, such as “computer” or “application server” for agents or “storage”, “memory”, or “data” for storages. In contrast, the name should reflect what the agent is doing, and which information can be found in a storage.
-
Can you take advantage of grouping to get a simpler layout?
-
And finally: Can you explain the aspect that you intended to explain to another person using this diagram?
Most important, of course, is to start creating diagrams, and to look at good examples. The Fundamental Modeling Concepts Home page [FMC] provides further information about block diagrams, and a number of documents containing many good examples, such a comprehensive introduction to the architecture of the Apache HTTP Server [AMP2004]. For advanced topics regarding modeling with block diagrams, I recommend the FMC book [FMC2006]. To draw block diagrams using Microsoft Visio, you can download a set of stencils at [VisioStencils].
What comes next?
In my next blog posts, I will cover the description of behavior using TAM.
Literature and Links
[TAM2008a] Bernhard Gröne: How to communicate architecture – Technical Architecture Modeling at SAP (part 1): Introduction to TAM
[AMP2004] Groene, Knoepfel, Kugel, Schmidt: The Apache Modeling Project www.fmc-modeling.org/projects/apache. HPI 2004
[FMC] Fundamental Modeling Concepts Home: www.fmc-modeling.org
[FMC2006] Knoepfel, Groene, Tabeling: Fundamental Modeling Concepts – Effective Communication of IT Systems. Wiley, 2006
[TechEd2007a] Bernhard Gröne: Making Architecture Understandable. Presentation at SAP TechEd 2007 in Munich.
[VisioStencils] FMC Homepage: Visio Stencils www.fmc-modeling.org/fmc_stencils to draw block diagrams using Microsoft Visio
3 Comments
