How to represent and application and database in TOGAF full meta model?

Question

I want to capture the connection between an application and the database in a way that is consistent with relationship between entities as defined in the content meta model.

• We are using the full meta model ref 34-8 i beleive my question relates to the data extension and the Infrastructure consolidation extension.
• This is being captured in a modelling tool (useful for later impact analysis)
• The viewpoint is intended for a techincal audience that need to understand which applications and databases that will be updated. In this environment in most case application to database is one to one

Below describes the relationship I want to display

What is a good way to describe this relationship that is consitent with the meta model and will help the audience understand what they need to change? What are factors that will alter the best way to describe it.

Answer 1

Although the answers above are thoughtful, they don't answer what is a very straightforward question, which is what is the entity in the TOGAF metamodel that one would use to represent a database.

The answer, very simply, is if it is a physical database (i.e. you are creating a physical architecture model) then you'd use the Physical Data Component; if it is a logical database (i.e. you are creating a logical architecture model) then you'd use a Logical Data Component.

Answer 2

There's no magical template for TOGAF - TOGAF is a methodology for describing existing architectures, future architecture states and the road maps to get from one to another. This question makes about as much sense to TOGAF Certified individual as the question "How to represent and application and database in PRINCE2" would to a PRINCE2 qualified individual.

Use the most appropriate representation that works for your audience. TOGAF advocates having a number of "viewpoints" of the architecture targeting different stakeholder groups concerns and different levels of detail. Decide what viewpoints you need to create and ensure that each viewpoint has a clear targeted diagram that tells your stakeholders what they need to know.

In the above example, you'd want to include or hide technical details for certain audiences but both diagrams would be appropriate for one level of detail so don't stress over the colour or shape of the boxes so long as the information is accessible and comprehensible.

Edit following the changes to the question

When I did a TOGAF course prior to my certification exams the trainer explained that the Models provided with the TOGAF materials were a compromise between all of the participants (Look at the list of members from pages xxv - xxx in the 9.1 edition of the book and imagine getting all of them to agree on anything - CA, CSC, HP, IBM...) and as such were pretty much useless.

He provided real world examples (with names redacted but otherwise complete) of the collateral produced by his company on the understanding that we as students could not take copies but could look. This was a liberating experience as it freed us from the extremely limited "Models" provided in TOGAF itself and showed us how to create high quality materials using nothing more sophisticated than Visio.

So, what I'm saying is - look at the examples given but DO NOT USE THEM RELIGIOUSLY as they are too compromised to be anything more than a guide. I'm looking at the TRM (Chapter 43) for the first time since I passed the exams (which should be a clue) and it's even more useless than I remembered :). Back issues of "The Journal of Enterprise Architecture" (available to members) often include examples and these are usually better than anything provided officially by The Open Group.

Build up your own architecture based on what you need to document and explain to your stakeholders. A technical audience will expect a full data model, a technical business user may want a conceptual data model, C-Level Executives will be happy with a box representing the database. Use colour to indicate areas requiring attention.

Answer 3

Based on your description of wanting to capture the connections between an application and a database, I would agree that both the Data Extensions (defined in Chapter 34.4.4) and Infrastructure Consolidation Extensions (defined in Chapter 34.4.5) are appropriate. Specifically, two of the purposes of the Data Extensions is to capture the "creation of physical data components that implement logical data components and are analogous to databases, registries, repositories, schemas, and other techniques of segmenting data" and the "creation of data lifecycle, data security, and data migration diagrams of the architecture to show data concerns in more detail". Some of the purposes of the Infrastructure Consolidation Extensions are to capture "creation of logical and physical application components to abstract the capability of an application away from the actual applications in existence" and "creation of logical and physical application components to abstract product type from the actual technology products in existence".

If you were to fully create both of these extensions, you would need to create the following diagrams:

• Data Security diagram
• Data Migration diagram
• Data Lifecycle diagram
• Process/Application Realization diagram
• Software Engineering diagram
• Application Migration diagram
• Software Distribution diagram
• Processing diagram
• Networked Computing/Hardware diagram
• Communications Engineering diagram

All of these diagrams are defined in Architectural Artifacts (Chapter 35).

Based on the drawing in your question, the Software Distribution Diagram and Networked Computing/Hardware Diagram most closely matches that. The Software Distribution diagram shows application structure and physical distribution across physical pieces of technology and geographic location. The Networked Computing/Hardware diagram shows the logical connections between components of the application. Since you also mention updates to applications and databases (I'm interpreting that to be a deployment of a new version or a technology refresh to a new vendor), the Application Migration Diagram seems appropriate as well as it shows how you intend to move from the baseline versions of components to the target version across all of the environments. It should be noted that all of these fall under the Infrastructure Consolidation Extensions.

Looking at the full definitions of these diagrams (and glancing through the definitions of the other diagrams), TOGAF never specifies a particular modeling notation or technique. Each of the TOGAF Extensions describes a particular facet of architecture, a set of models that help you capture information relevant to that facet of architecture, and gives specific names to diagrams that serve specific purposes.

If you must comply with TOGAF standards, the best thing to do would be to choose your Extensions (it looks like you have), ensure that the purpose aligns with what you are trying to communicate, look at the list diagrams that support that extension, then look at the intent and purpose of those diagrams. Then, work with stakeholders who will be using the documentation (it's not just the diagrams - there is likely to be text, tables, and other information) associated with that Extension.

Another recommendation that I have comes from IEEE Standard for Information Technology -- Systems Design -- Software Design Descriptions (1016): the use of standardized design languages is preferable to other design languages. The idea if you are using a standardized design language (and using it properly), then you do not need to explain what your notation means to readers. If you are not using a standardized design language or using symbols from a standardized design language in a non-standard way, you need additional content to explain to readers how to interpret your diagrams and design notations, which leads to a more verbose architectural or design description.

In short: First, consult with your stakeholders. Find out what diagrams and models would be easiest for them to understand and use. There may be organizational standards or conventions already in place. If there is no standard, convention, preference, or consensus, seek out a standardized notation that can be used to communicate the information that the diagram is intended to communicate. If there is no standardized notation, then you can choose to use a notation of your own devising as long as you also make it clear to a reader how to understand that notation.

Answer 4

Refreshing the topic with more information.

Based on the pictures in your question, I will assume you use the Archimate as a modelling language.

According to the Archimate specification, you can use the System Software element for this purpose as described in the Archimate 3.2 Specification item 10.2.3 System Software page 85 (online reference here):

System software represents software that provides or contributes to an environment for storing, executing, and using software or data deployed within it.

System software is used to model the software environment in which artifacts run. This can be, an operating system, a JEE application server, a database system, or a workflow engine.

Therefore, the representation in TOGAF using Archimate as a modelling language would be like this:

I hope it helps.