bernhard.groene

Previous post Next post
Currently Being Moderated

How to communicate architecture – Technical Architecture Modeling at SAP

This blog is the result of the very positive feedback I received after my presentation about architecture modeling at SAP TechEd 2007. It is the first of a series of blog posts about architecture modeling, giving an introduction and overview of TAM, SAP's internal modeling standard.

Let's talk about architecture

“The business of software building isn’t really high-tech at all. It’s most of all a business of talking to each other and writing things down.” [Tom DeMarco 1995]

There are many occasions where people need to talk about technology and architecture, for example getting requirements or approval for a design by customers, aligning development efforts with other groups, or reporting progress to management.

In some scenarios, you have to get technical information from people, in some you discuss with others and exchange experience, and finally in some scenarios you spread information to many people in a presentation or via a document.

Common to all scenarios is that both background and expectation of the communication partners may vary considerably. This requires an adequate abstraction from technical details.

Conceptual models are a means to support this communication. Models can establish a common language for communication. Using a graphical representation of models helps communication partners to conceive an idea more quickly, and in a discussion, there is something “to point at”, to focus the discussion.

SAP builds software on a large scale with division of labor. The need for communication about technology and architecture is therefore obvious. For this, SAP uses an internal standard for architecture models, TAM (Technical Architecture Modeling).

Why standard UML falls short or: Look at the reality

Isn't UML the de-facto standard to describe software architecture? Well, it depends. UML has a good tool support and supports the majority of object oriented programming languages with their variety of language constructs. This leads to the complexity of the UML standard that has to cover all aspects from high-level to low-level modeling of software, supported by tools. This complexity is the main obstacle for using UML to communicate architecture.

Take a look at typical documents that give an introducing or an overview on the architecture of a product. They start with a system overview, where you find the major building blocks and their connections. In most cases, these are just “box-and-line” diagrams using an ad-hoc notation without clear semantics. Only in rare cases you find a UML compliant diagram. More exaggerated: The industry standard notation for conceptual architecture diagrams is – Microsoft® Powerpoint®.

SAP has recognized this problem years ago and now uses an internal standard for architecture models based on UML and FMC.

What is TAM (and what not)?

TAM stands for Technical Architecture Modeling and defines an SAP-wide standard for technical architecture models. TAM has a long history at SAP (the predecessor was introduced at SAP in 1990) and is based on best modeling practices. On the other hand, it is now based on the UML 2.0 standard, and defines a reasonable subset of diagram types and elements needed for SAP's purposes.

TAM assigns diagram types and elements to two levels of abstraction:

  • The conceptual level is needed to describe the system structures and the concepts. Models on conceptual level can be used to communicate with all stakeholders.

  • The design level focuses on the implementation of the system, for example the description of the code structures. These models are mainly used within development.

Finally, TAM extends the UML meta model by the FMC block diagrams that have been used at SAP since 1990. They are the most important diagram type for conceptual modeling with TAM.

TAM distinguishes, like FMC, three aspects of architecture and offers the corresponding diagram types:

TAM diagrams on conceptual level
Figure 1: TAM on conceptual level: The three aspects and the diagram types

Compositional Structure: Block diagrams

Block diagrams show the static structure of the system. Here you find agents that process data, storages to store or share data, and channels by which agents communicate. Only agents are actually doing something, storages and channels are passive elements. A block diagram does not describe any behavior, and it is an exemplary structure, a snapshot of the system at a certain point in time.

Behavior: Activity / Sequence / State diagrams

Behavior is the second aspect. Usually you either describe the behavior of one agent or the interplay among multiple agents. TAM offers three UML diagram types for that:

  • Activity diagrams are multi-purpose means to describe behavior. You can use them to show loops, concurrency or decisions in an intuitive way. Using swimlanes, you can also map the actions to agents and therefore show the interplay among agents.

  • Sequence diagrams describe behavior on an example level, as typical scenarios. They should only be used to depict the interplay among agents.

  • State diagrams are useful when you want to describe the various states and their transitions, for example the states of a transaction or of a sales document.

Entity and Relations: Class diagram

UML class diagrams are used in TAM for Entity-Relationship models on conceptual level, for example for topic maps or as a glossary. Of course, you can model data structures or relations between data stored in different storages or exchanged via channels as well.

A TAM example

Let's have a closer look at block diagrams using an example taken from a report about SAP Service Provisioning [SAP2006a].

Elements of a block diagram
Figure 2: Service Enabling the SAP Application Server: Block diagram with its most important elements

Service Enabling the SAP Application Server

Figure 2 shows an SAP Application Server with some business applications operating on common business data. It also shows an environment where people use consuming applications to consume Web services provided by the SAP Application Server. On the other hand, there are some external “Providing Applications” that offer Web services for the SAP Application Server. Assuming that the standard business applications are not capable of offering and calling Web services, the “Web Service Enabling” agent is required to enable the SAP Application Server for providing and consuming Web services. While this diagram only gives an overview, figure 3 shows more details, including the inner structure of the Web service enabling layer.

Building Blocks of TAM block diagrams

The most important building block is the agent, depicted by a rectangular shape, in figure 2 for example the business applications. Agents are the only ones that do something, that is they process and operate on data, and they communicate with other agents. A special case is the human agent, depicted by a stick man symbol. Agents communicate via channels that can be annotated by the kind of request or protocol (here: Web service call). The “R” and the small arrow can be used to indicate a request-response communication where the arrow indicates the direction of the request. Finally, storages are used to store and share data. Access arcs indicate which agents access which storages. The arrows show the direction of data flow, that is whether an agent has a read-only access (one arc from storage to agent), or a modifying access (two arcs, one for reading, one for writing).

Abstraction and Refinement

Of course, figure 2 only shows a very abstract and coarse view of the system that is mainly useful to introduce the main building blocks of a system and its terminology. Figure 3 shows a more detailed view which refines the Web service enabling layer and adds some other components that were not helpful for the abstract view of figure 2, for example the HTTP communication layer.

Service Provisioning: The Web Service Layer
Figure 3: Refining the Web Service Enabling Layer

We see that the Web service enabling layer provides agents to parse and create Web service calls, and that a proxy framework routes incoming calls to the registered Web service proxies that do the actual mapping to the business applications using local calls. In comparison with figure 2, there are more technical details, such as protocols or data types. There are of course further refinements that get closer to the implementation. Look at [SAP2006a] for more information.

What comes next?

This was just a quick glance on what you can do with TAM. My next blog posts will go into details of the three aspects and the corresponding diagram types. But of course, there is more to architecture modeling than just the notation of diagrams. And finally, I encourage you to use TAM to create your own models and use them for communication. Stay tuned.

Literature and Links

[TAM2008b] Bernhard Gröne:    How to   communicate architecture – Technical Architecture Modeling at SAP    (part 2): How to communicate architecture – Technical Architecture Modeling at SAP (part 2)

[FMC] Fundamental Modeling Concepts Home: www.fmc-modeling.org

[FMC2006] Knoepfel, Groene, Tabeling: Fundamental Modeling Concepts – Effective Communication of IT Systems. Wiley, 2006

[SAP2006a] Introduction to SAP Service Provisioning. SDN, 2006

[TechEd2007a] Bernhard Gröne: Making Architecture Understandable. Presentation at SAP TechEd 2007 in Munich.

[TomDeMarco1995] Tom DeMarco: Why does software cost so much? And other puzzles of the information age. Dorset House, 1995

[UML] Unified Modeling Language Home: www.uml.org

[UML04] Martin Fowler: UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison Wesley, 2004

[UML05] Booch, Jacobson, Rumbaugh: The Unified Modeling Language User Guide. Addison Wesley, 2005

Comments