4

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

enter image description here

Below describes the relationship I want to display

What components to use

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.

4 Answers 4

3

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.

1
  • Which relationship can be connect the physical application component and the physical data component Apr 16, 2018 at 22:49
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.

9
  • 1
    I think this answer gets to this point, but it could be a little more up-front. As far as I can tell, TOGAF has guidance as to what types of models, diagrams, tables, text, etc. should be created, but it doesn't mandate any particular format or notation. I wouldn't be surprised if there was text somewhere in TOGAF like IEEE 1016: "Standardized design languages that are in common use are preferable to established languages without a formal definition".
    – Thomas Owens
    Aug 4, 2017 at 9:11
  • @mcottle I've updated the question to be a little bit more specific about what im looking for and where i think the model might relate to the meta model. Please have a look Aug 7, 2017 at 0:10
  • @user1605665 I read the updates and the sections of TOGAF you linked to. I still think this answer and my comment apply fully. It looks like Chapter 35 defines what each diagram is supposed to communicate, but the notations used to communicate that information is left to the discretion of the author. My only recommendation is to use notations familiar to the stakeholders that you are communicating with, preferring standardized notations and languages where possible.
    – Thomas Owens
    Aug 7, 2017 at 10:18
  • @ThomasOwens I can't find any reference in TOGAF 9.1 to a mandate to use specific notations - and that's not I remember from my studies. TOGAF is a methodology for generating architectures and has been left very open so it isn't rendered out of date by the emergence of a new standard for describing systems - or contradict anything CSC does with "Catalyst" for example. They do push BPMN (which isn't a help for a database or infrastructure model) and The Open Group has been plugging away with "Archimate" for years without much success
    – mcottle
    Aug 8, 2017 at 8:52
  • @mcottle That's exactly what I'm saying. I do see some mentions of SysML UML, BMPN, SPEM, and a couple of other OMG standards and specifications. My recommendations would be to (1) use notations that the stakeholders are most familiar with and (2) favor standardized notations and design languages over non-standard notations and languages.
    – Thomas Owens
    Aug 8, 2017 at 9:11
1

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.

3
  • Wrong answer. He's asking how to represent the database in the metamodel, not what system to represent the database design in..
    – mcottle
    Aug 8, 2017 at 10:38
  • @mcottle The question mentions the Data Extension and the Infrastructure Consolidation Extensions. The diagrams that most closely show the connection between the application and the database are the Software Distribution Diagram and the Networked Computing/Hardware Diagram. These are the diagrams that I write most about. Database design doesn't live in either of these extensions - the Application/Data Matrix, Conceptual Data Diagram, and Logical Data Diagram are all Core and not Extensions.
    – Thomas Owens
    Aug 8, 2017 at 10:43
  • @mcottle How you represent the database graphically depends on the modeling notation used. It could be as simple as a box. If you were to use a UML Component Diagram, it would be Component node. If you used a Cisco Network Diagram, there is a symbol that represents a database server. You need to first choose your design notation. If you choose a conventional or standardized notation, then the representation is whatever the convention or standard says.
    – Thomas Owens
    Aug 8, 2017 at 10:46
1

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:

enter image description here

I hope it helps.

2
  • Is the system software representing the database type e.g. DB2 or Cosmos or is it representing and instance of a database. Jun 30, 2020 at 22:44
  • The System Software is part of the Technology Layer and its elements are typically used to model the technology architecture of the enterprise, therefore the System Software represents the database type e.g. DB2, Oracle, SQL Server, Cosmos, etc. However, I do not see any harm in putting the instance name under the database name and use the Assignment relationship to assign a Device element to the System Software "instances" to show they are in the same machine/device. Jul 1, 2020 at 0:42

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