Control Services in ArchiMate

Control Services are a mechanism we can use to implement security control measures. I wrote this blog to demonstrate that controls are real things, which we should carefully consider; not just line items on a spreadsheet.

The Common Understanding Of Controls

I’ve seen very varied levels of understanding on control measures.

The most crude level of control implementation I have seen is where a project just runs through an excel with a list of questions. For example, they will simply ask the question “is the web server traffic authenticated?” and a technical person says “yes”.

That’s not really a control so much as it is a check of the current state. Some people argue that the exercise of running through the checklist and answering those questions is a control – and to a limited extent I can except that; This basic checking is better than no checking. However, There are varying levels of control, I tend to think about controls in terms of continuous control.

Its important to note there is a balance to be had; In designing any solution you need to think about your requirements, and you need to think about effort, vs return. Its just as easy to over engineer things as it is to under engineer them. Every now and then when I am designing something I stand back and ask myself – is this too much?

The subject of fully modelling security will take a few blogs, and wont try to cover everything here. A lot can be said around FAIR / SABSA way of doing things. There’s a whole bunch of related concepts and elements that I am not covering here.

The Control Measure

Figure 1 – Realizing a control

There are many frameworks out there that have security controls – for example the Cloud Security Alliance has the Cloud Controls Matrix. When representing a control it can be modeled in standard ArchiMate as a Goal element. Those of us using BiZZdesign’s Enterprise Studio (BES) have a set of elements especially for risk management – so we can represent them directly. In our example we are going to use a fairly simple control – Authentication – a standard control that exists in any number of frameworks. Figure 1 – shows how a control service realizes a control. In BES security controls can be modeled in figure 1.

For those using BES, Control Services can be created in a risk and security view. Although that view type only has a few elements in the create window, its possible to paste architecture from other views into a risk and security view. Enterprise studio will also allow you to assign a control strength to a control and has a number of features relating to modelling risk and security. Control services in BES – have a padlock next to them.

Showing a control service within your architecture

Representing a control service as part of an architecture model is easy. so as an example if I created my Authentication Control Service you could see it represented on a diagram like this:

Figure 2 – Implementing a control service

In this case I have associated my service with some application components. Already this beats the approach of just saying “yes, we have authentication”. Its showing how our controls are implemented; we can see exactly where in our architecture our control is enforced.

Designing a Control Service

The authentication control is a simple example, but right from the beginning I can ask some simple questions:

  • How do I ensure that control is being continually achieved?
  • What do I want to happen if things fail?
  • How much of this control can I automate?

I was talking to a colleague about implementing this kind of a control in a conversation in the office and I came up with something like this:

Figure 3 – A control service

Figure 3 was a quick view drawn to support a conversation, during a conversation. Its not a complete architecture but it does show some elements we can use to control authentication at an application layer. This control would be fairly easy to scale because it doesn’t rely on any person to check it. It leverages policies in active directory, and in this simple example I was demonstrating that we need a mechanism that shows continuous control.

You can see I was showing that we do not just need an authentication mechanism but we also need a mechanism to ensure its applied – you can have the best burglar alarm in the world, but if you don’t switch it on, its useless.

The view doesn’t cover all the IT Aspects; In itself it raises other questions we would need to answer in other views; for example:

  • Where would we run the different application components?
  • Who supports this architecture?
  • How would it be deployed?
  • How are these things supporting business needs?
  • What are the motivations for this?
  • What are the Key Performance Indicators & How Would I Implement Them?

In my example I am showing an application level control service – I can also have business or technology layer control services. There’s also nothing to stop me realizing a security control with a number of different control services or a combination of them.

So Why Bring All This Up?

Controls are important. The point of this blog wasn’t so much to show how to properly design a control service, as it was to show that there are varying levels of control you can apply in architecture, and hopefully to get people to think more seriously about what applying a control actually means.

I have spoken about requirements realization before – I tend to think of controls in a similar way – it is not enough to say we have controls in place – we need to understand how we have controls in place.

Controls need to be considered as an integral part of architecture design, and should not be an afterthought. If you design controls into architecture audits become significantly cheaper, because you do not need to burn so much time hunting for answers to auditor questions – you are continuously ensuring a well designed solution which does not only satisfy the needs of the auditors but is also built to actually protect the Information running through our systems.

ArchiMate – Looking Beyond Diagrams

When looking at ArchiMate diagrams its easy to miss the fact they are part of a model, and not just pictures. This blog addresses the difference and demonstrates some basics around models.

Last week someone was commenting one of the views I demonstrated in a blog, and pointed out something that didn’t make full sense in the diagram but had been addressed in the view documentation. Its very easy to forget that we are not talking about pictures when we speak of ArchiMate models. In the blog my ArchiMate views are just images. I wanted to show some practical examples and discuss this.For anyone that doesn’t actually do modelling, but interacts with those of us that do, this blog is for you.

Before I get started its worth mentioning that a view and a viewpoint of architecture is a concept that extends beyond the modelling language. We tend to talk about views visually, but the view taken from a specific viewpoint could expressed in writing if we wished it to be, but you would miss the benefits of modelling elements and relationships with a tool.


The dictionary definition of a diagram is:

“a graphic design that explains rather than represents especiallya drawing that shows arrangement and relations (as of parts)”

Of course there are many dictionaries but they all follow a similar pattern.Technically Figure 1, is both a view and a diagram. On this website its a diagram, which is a representation of an architecture view. the actual full architecture view has a lot more information in that is represented in figure 1.

Figure 1 – An Organization View / Diagram

Of course we can just use something like Paint or Visio to create a view like above – and it has a lot of value, but in those tools are for visual representation, and not modelling.

Documenting Models

I previously addressed Documenting An Architecture Model – but I wanted to give a more complete example in a modelling tool.

Figure 1 is a fairly self explanatory made up view which gives a level of information by itself. But it doesn’t tell us everything. I will show some of the things that differentiate pictures and diagrams from an architecture view in the rest of this blog.

The first thing to show is that views can have their own documentation – Figure 2 shows this – I have selected a view and you can see its documentation in the field below.

Figure 2 – View documentation

Of course if this was a real view I might also have provided links in the documentation to the organization chart. Although the view documentation is short here, it helps set the context for the view, and does provide some valuable information.

Individual elements or relationships can also be documented:

Figure 3 – documentation for an element

As well as elements having documentation relationships can:

Figure 4 – Documenting a relationship

The relationship type gives you an understanding of what kind of relationship the elements have but it doesn’t tell you why. That’s something I will typically do in documentation. This is particularly important when it comes to documenting less defined relationships, such as associations.

The point I am making is just looking at the diagram does not give you a complete picture. Some tools will allow you to auto generate documentation:

Figure 5 – Word documentation


Many tools allow you to connect all kinds of metadata to elements & relationships, and allow varying degrees of customization in the example below you can see a references link I added:

Figure 6 – Properties

Its very tempting to add lots of metadata to a model because you can, but i tend to think carefully about the value of any kind of information I would want to maintain.

Some tools such as Enterprise Studio, allow some pretty advanced analytics depending on the information you store with the model.

Navigating the model

The main thing that sets a modelling tool apart from a visual tool like PowerPoint and Visio is the fact its a modelling tool. We can navigate each element and see its relationships and the different views it appears in. The tool stores the elements and relationships as a fully relational model

Figure 7 – Navigating an element

Auto generating views

Lets say for example a stakeholder came to me and asked me to tell them a little bit more about what an enterprise architect is – With some tools I can automatically generate views. Take a look at a view I generated literally in 5 seconds:

Figure 8 – An Auto Generated View

In previous blogs I have used the enterprise architect role, and because the modelling software knows all the roles and relationships between each element in a model, and the rules for modelling in archimate we can very quickly create something meaningful.

The more work we do with our models, the more value they can bring us.

Architecture Views

An architecture view is a view into a model. Figure 9 shows our auto generated view but on the left hand side you can see in the model browser that our model package contains many elements that are not on this view (because we created this view to only show actor cooperation’s to the enterprise architect element)

Figure 9

The model package contains many elements, views, and relationships. You see them on the model browser. You could theoretically take all those elements and put them onto a view:

Figure 10 – A fairly small model.

Theres too much to remain readable on a normal screen – and it doesn’t make sense to show our architecture in a single view. This is why we break down architecture into multiple views, created for people interested in its different aspects.

Figure 11 – A view

To put in simple then. a view is just a small part of a model we are communicating, As you can see, the view in Figure 1, would be part of something much bigger.

A Viewpoint

So we can see that models have lots of elements and relationships, and different people have needs to see different things. View Points define which parts of an architecture we look at. A viewpoint definition tells us which types of elements we are interested in, and which types of relationships are allowed between them. There are many standard viewpoints defined in places like TOGAF and the Archimate Manual.

Figure 8 was an automatically generated Actor Cooperation View. It was generated from a Archimate 2.1 Viewpoint. The viewpoint definition tells exactly what elements and relationships are allowed within the view, so our tool could find those within the model and generate a view from the viewpoint definition.

Derived Relationships

As your models become well developed benefits start to come from automatically derived relationships. Not every relationship we use is created by hand. You can find more information on them in the Archimate Manual

Summing It Up

As your model grows the value we can gain from it also grows. For a model to realize its full potential requires architects to actually use it, have competency around it and have a level of discipline. When we achieve that modelling can be used to save time in understanding your enterprise and understanding the impact of change across the different IT aspects. At this point it can become an invaluable tool for management.

Modelling Information Flow In ArchiMate

With regulation such as GDPR being in force to protect our users, properly understanding information flow becomes essential. This blog shows some of the ways we can model information flow.

An Overview

There are a couple of different ways we can represent information flow that I touch upon in this blog – I would suggest you use the technique that you prefer but be consistent with it. I don’t normally use more than one method in a model package, unless I have a specific reason to do so.

Using Flow Relationships

I will start with a layered view like have used on several other blogs – our web hosting service serves as a practical example.

Figure 1 – Layered View

The layered view contains both internal and external elements – we will look at them separately. Although Figure 1 shows a layered view I might use to communicate the big picture, as it stands it would need some more detailing before I can fully map information flow.

Mapping Service Flow

In order to properly understand the flow of information between services we need to establish the service interfaces. If my layered view doesn’t have interfaces on – I need to consider and add them. In the example above we have at already done that between the business and application levels – you can see that in figure 2:

Figure 2 – Services and Interfaces

The first thing I will do is look at anywhere the interfaces are serving another element:

Figure 3 – Focusing On Serving relationships.

These areas are effectively where external information flow is happening. I will be looking to replace these serving relationships with flow relationships. In this view i would possibly make an exception though. The service relationship between the HTTP interface and the website hosting interface tells me that there is a relationship between the two. I might normally look further into detailing out the web hosting service to determine how the HTTP interface is used, but in the case of the view above I have answered the question already – its serving the incident management process.

Some architects do not model interfaces against services all the time – myself included. Its dependent on a number of factors; I want to do “just enough architecture”. If we took the interfaces out of the equation we can still map information flows from services to other services.

Considering other relationships

I will also consider the realization relationships in the same way as I look at serving relationships – in this example though I have only an application interface realizing a business interface. the business web portal is only exposing the application layer functionality and there’s no actual data transfer between the layers to consider. Sometimes association relationships should also be looked at.

Putting the flows onto the diagram

Once I have identified the relationships i am interested in I then start to put the information flows onto the diagram. and thinking about information flows. I reorganized the view a little because I decided its not enough to understand which process has access – I want to also understand which role. I then removed the serving relationships from the view, but I didn’t delete them – they are still valid for other views.

The result was this view

Figure 4 – Flows in a layered view

I have labeled the flow arrows, but do not forget that each relationship can also have documentation – where you can further specify what that information means. When looking at application level interfaces, I might want to also think about specific ports we use – and I may either show it on the actual view or in the documentation for the relationship. I chose to not show ports on the view above because I don’t want to turn my ArchiMate views too technical; in some cases depending on who your stakeholder is you may want to do things differently and include the port numbers on the labels.

Breaking things down

I broke my initial diagram into two parts to make the blog a little bit less cluttered as I focus into part of it, and that’s ok. In the same way as I have now shown flow between business and application layers, I could do the same between the application and technology layers. To keep diagram complexity down sometimes we break things into smaller chunks. The initial layered view showed how they all fit together at the highest level.

Identifying issues

Doing this information flow exercise highlighted some design issues. The second I came to create a flow from website support to the HTTP interface I realized I should be using HTTPS. I could either change that element (which effects the whole model) or I could establish a second interface.

Because in this modelling exercise I am focusing on information flow between elements other issues come up too. For example – when I am looking at the website support role – I ask myself the question what if the HTTP interface into the website application service isnt enough to diagnose a problem? In the old days I might add an Remote desktop Interface – but if I am using third party cloud providers to provide the underlying service this might not be an option – instead I might define a separate special admin interface.

These questions came up just through looking at the information modelling on a layered view. Information flow could also be shown on a whole range of other views. When you actively focus on different component parts of the view and their relationships, thinking in terms of what kinds of relationships fit and why, we quite often see new things.

Associating Passive Objects

Figure 4 could have been written another way:

Figure 5 – Layered view with passive elements.

Here I created some passive objects – (Business objects & data objects). Doing this has an advantage over flow relationships – if I am reusing elements in different views then I can easily get an understanding for example where Admin Login Credentials are used throughout my model.

You may have noticed I have web pages as a business object and an data object. That’s because conceptually in the view they are at two different levels. at the business level web pages are a concept, but they are made more tangible at the application layer.

Another important thing to note is that some of these relationships do not denote the direction of information flow. For example – the HTTP interface is Serving Website Support – this does not mean that admin credentials are flowing from the HTTP interface to the website support role.

Information Location

I can easily add Locations to my view to make it a bit more complete from a GDPR perspective:

Figure 6 – Layered View With Locations

Normally those elements are orange, but for me that’s a complete aesthetic color clash so i changed it. There’s nothing in the ArchiMate rule book that says you cannot do that!

Modelling Internal Information Flows (and Application Cooperation)

In the same way as we can show information flows on a layered view we can do the same thing on many other views – such as service realization views, technology views and so on. Remember sometimes we might want to have two viewpoints showing the same things in different ways for different stakeholders. We might have a normal service realization view, and one for GDPR compliance work. We can use exactly the same approach as i showed on the layered views with most other views. I would take copy of the view and start removing relationships from the view (not the model) replacing them with flows.

With regards to application cooperation views, they can be done at different layers of detail dependent on need. the best application cooperation views include processes, events, interactions and services. They do not include interfaces and are internal views. As a bare minimum I would expect to see interaction between application components and the services – as an example:

Figure 7 – Basic Application cooperation view with information flows.

Figure 7 doesn’t really show the cooperation! I am focusing on data flow rather than any causal relationships and elements. This works as a starting point. I have seen some architects do variations on figure 7. Some people like to emphasize the more important information flows.

Other architects do not include what they consider to be less important flows, and produce more abstract views. For example the web page request – is a good example of low level communication that is essential to a low level view but may not be important if we are trying to provide stakeholders an overview.

Personally I like the level of detail in figure 7.

Using Access Relationship.

Where accesses relationships are possible within different views they should be used if those views are for presenting information flow. The access relationship is a data dependency relationship in ArchiMate. its indicating that a process, function, interaction, service or event does something with a passive object.

Using The Path

The Technology layer has an element for representing flow of information – the path. Take a look at figure 8:

Figure 8 – Web Data Transmission

You can see here I have represented the path information takes to get from the web server to the end user by creating a Web Data Transmission path. Note that the two end points are not considered to be part of the path. This is because the path denotes to path from end to end – when we reuse the Web Data Transmission element we are likely to want to use it to convey transmission from many different end points.

Summing it up…

Most views can be remodeled to include information flow, and going through the process of doing so will enhance your understanding of information flow and risk.

I focused mostly on business and application layer within this blog but the same practices apply when working with the technology layer

When doing High Level Design Work as a minimum I like to see either the basic information flows in the application cooperation views, or information flows in the layered view.

Having these information flows enables us to ensure compliance to different regulations and gives us the ability to do some very cool things with risk management.

Creating High Level Designs

High level design is a subject of much discussion in pretty much every organization I have worked with. The question “How Much Is Enough?” is often put to me. This blog addresses this question.

If you ever have to bring a High Level Design (HLD) to me for review – this blog is a good read because it sets a level of both design and review expectations. I promised a colleague I would publish this blog, so it was written in a bit of a rush and I may go back and update it later.

HLD Overview
Figure 1 shows the key areas in a HLD.

What is a High Level Design?

I normally break architecture down into 3 basic levels

  • Conceptual Architecture – Is a single view that sets the scope of the architecture at the highest level of abstraction
  • High Level Design – Is something in the middle. It gives us the answers to all the fundamental questions, whilst normally staying at a level of abstraction from actual technology implementations.
  • Low Level Design – Is architecture at its lowest level – which can include actual machine and network configurations, and exactly how things are implemented


Its not practical to build designs without putting them into the context of the business. Architecture is about building a solution which solves the needs of our stakeholder. With that in mind there is some related documentation we should have.

A Business Case

The business case is basically setting the scene for what we expect from the architecture. If an architecture isn’t providing a benefit to our business we shouldn’t be doing it.

Bear in mind, this doesn’t necessarily mean that the benefit is profit. Whatever the benefit is, it needs to be stated, it needs to be clearly defined in a way that is measurable and not subject to opinion.

“We need to make a lot of profit” may be a true statement – but “we will make 1 million Euros in the first year” – is a lot more clear.

The business case is establishing the goals, and business requirements. It basically needs to lay out what it is thats being proposed, and the value we get from it.

Basic Business Case Validation

When assessing business cases I am normally looking to see also the reason behind the numbers. If a product states it will make a million Euros per year i want to see the rationale behind that number, and to see that such numbers are realistic. The most realistic cases are based on existing numbers.

If Microsoft reports an 64% growth in Azure sales, it doesn’t mean its partners see the same growth. Growth and profit are influenced by many factors including how fast you can get an idea from idea to realization, and how well your solution can be scaled.

For basic validation of business cases I normally think as TELOS related questions.

A good business case demonstrates the thinking behind the numbers. If it states we need to hit a revenue target then these goals are part of our architecture motivation.

The key takeway here:

If you don’t have a clearly defined business case, then you cannot know that any technical design or service design will be fit for purpose.

A Conceptual Architecture

Conceptual architectures can come in many forms – I am normally looking for a single view in ArchiMate that shows the concept of the business case architecture. I normally am focusing on scope.

A conceptual architecture for a product normally shows the product and the services within it (Like a product view), as well as showing the key application components, or technology layer components relating to the product, as well as the teams that support it, and other related products & dependencies. In product service architectures i am normally showing Business Application and Technology layers, but not showing data or information flows. This is because of how we use conceptual architectures as part of business validation – adding relationships and information flows makes it messy.

In a non product related conceptual we make sure the view we provide hooks into the current existing architectures (services or products normally.

With any architecture I am looking to ensure It has considered the architecture aspects.


I recently wrote about Architecture Concerns and will not go into too much detail. For any architecture, having a defined set of requirements to validate is essential. This can take many forms (such as User Stories). This could also be done in a set of ArchiMate views.

Basic Requirements Validation

I want to see the following when I validate a HLD:

  • A set of requirements – which are clearly defined and unambiguous.
  • Documented evidence of requirements management – Showing how requirements have been managed, and pointing to where in the architecture requirements have been realised.
  • Considerations from all the stakeholders perspectives. Lets break that out separately.
  • Consideration of incoming and outgoing requirements – we need things from other teams – for those things we need agreements with respective teams. On the flip side we may also have requirements towards us. If our solution uses monitoring for example, the monitoring team may require a specific agent to be installed on something.
  • TELOS – As mentioned in the business case phase a more detailed look into TELOS is warranted as part of the high level design to ensure that our requirements consider Technical, Economic, Legal, Operational, and Scheduling needs.


When we talk Stakeholders its very easy to be preoccupied with just the customer or the end user but in reality many teams or people either provide something to your architecture, or require something from it.

ISO 42010 has a good list of potential stakeholders of a system which includes users of the system, designers of the system, owners of the system – the list goes on. As a minimum need to know that an architecture will meet these needs:

  • Customer – this includes different roles within customer organization – for example the end user cares if they get a easy to use continuous service – where as the person that is buying the service from you wants to be able to show their management how well the service is used, or the value it brings.
  • Internal Business – around revenue and profit for example. or if its needed for strategic reasons we need to keep tract of that kind of things. Sales teams may also have concerns with architecture.
  • Internal Ops Team – They need to be able to operate the solution the architect gives them in an efficient way – there are normally Staffing, Training, Capacity, monitoring, and procedural related requirements for example.
  • Partner – If we are using partners a business interface needs to be established with them – a set of requirements together with an SLA is a fantastic way to do this.

Validating the Architecture Model

One thing to note is the old adage “If its not documented, it doesn’t exist”. Its important for all information around your architecture to be stored together. a High Level Design can be produced completely in an Archimate model, or maybe part of a document (I discuss this in Designing Architecture Through Document Templates.

Our High Level Design is telling a story. Effectively all those prerequites we have described are setting a challenge. Its the job of architecture to describe a solution that addresses all the needs of a challenge.

Regardless of if you chose to use a document or an ArchiMate model, or in Word, the story needs to be threaded together in a single solution. There may be multiple parts – such as several prerequisite documents, but they need to be referenced together in one place.

Within any solution or service design there are normally many meetings, and its essential we track decisions that are made in a single space that is available for all. Where i currently work i normally track all decisions relating to a specific architecture on a single page so its easy to follow. Its ok to reference external sources for things liike requiremetns or supporting information, but when this is done you have to consider the following

  • Ensure there is version control so we know what version of a particular document or source we are referring to on our design. normally when i am doing a review meeting i will take a copy of related documents and store them together so that there is a timeless copy that cannot be interfered with
  • You have to know your stakeholders and ensure they all have access. I have lost count of the times information has been locked up so i cannot see related information.

I also want to ensure as far as possible that i do not duplicate information – its better to refer to master information sources for things when required.

If we are creating an entire high level design in ArchiMate you have to remember to document the model. We are not using our architecture tools to produce diagrams, we are using them to produce views of architecture. Our tools enable us to document the architecture view, to explain what we are showing, as well as the elements and relationships. Remember to address the audience.

Covering Architecture Aspects

Remember just as with our conceptual an architecture has to address architecture aspects. This doesn’t mean i have to address them all in a single place in the architecture – but I do have to ensure that we consider all aspects and not only technology. For example you may address processes and roles in many different views.

A minimum set of views

For those of you that do not know where to start I present to you a minimum set of views to consider. We do not document or create views just for the sake of having them. There may be reasons why you wish to use other views, or deviate from this structure. Thats Ok.

Lets take a look at some of the views I would expect to see. in an archimate model:

We will walk through this bit by bit. An ABB is an Architecture Building Block. Normally I prefer to deal with architecture at a service level but there are times where thats not practical. In those cases related architecture may be together in a grouping box which is named something to explain what it is. For example I might have everything relating to application monitoring described (including its interfaces, triggers and processes) in a grouping box named “Application Monitoring”. You would use a grouping box where you might want to represent a group of elements that are cross layer. Some of our application monitoring processes may be business related or technology related for example. Where possible I prefer to use services or functions to ABB’s.

Conceptual Architecture or Layered Views

The order of things I am showing can happen in two different ways. where I work currently normally at the point architecture begins a business person has already got a conceptual idea in their head and want to start there. Our product management teams are used to working in a specific way – I normally have to start by asking what is it they are trying to do, and then when I understand what – I am wanting to understand why.

Conceptual architectures are normally a good starting point when you are in this situation, as are layered views. I normally take a service focused approach to building architecture. Take a look at my Services In Archimate blog – it shows some layered views.

I normally start with a conceptual view and then refine and define services from there. Every Service or function I have defined at the upper level needs further detailing:

  • It should appear in a requirements realisation view
  • It should appear in a Service realisation view
  • It should appear in a implementation and migration view.

I do not necessarily have to see all services defined in their own service realization views, although I often will. As a rule of thumb if i have more than 30 elements in a view i am asking myself if I need to split it into sub views. Again remembering each view tells a story it may make sense to group together several services in the same service realization view if several services are realized in the same way – or if theres another logical reason to do so.

Requirements and Rationale

Working with requirements realization views, my key element of focus is the requirement. Working with motivations views I like to ensure i have the drivers, goals, and requirements clearly defined. other elements just supporting the story of how a need (driver) leads to a set of requirements that will achieve a goal.

In my Planning Work With Archimate blog i talk a bit about creating motivation views for stakeholder concerns, and I also show a level of motivational modelling in my User Stories blog. Those mechansims are good for capturing different concerns from different stakeholders, but the important thing to note here is that we need to align the motivation model with the actual business case.

I already described the order i do things in normally because its the quickest way to deliver some value in my particular case. However, an excellent approach is to start with a motivational view, to create some requirements realization views from that where i figure exactly which services and processes I need to put in place to meet the requirements.

All requirements need to be shown to be managed within an architecture design. If we are working with ArchiMate we do not necessarily need to see every requirement on a view – its ok to group together requirements on the view to make it more manageable:

Figure 3 – Requirements realization

The above (Figure 3) is OK- if in the documentation for those requirements you link back to a source where those requirements are all managed together – so we can easily see the working status of each underlying requirement.

The important thing here is that requirements are mapped to their respective areas of architecture. Figure 3 showed a very high level view – I would expect in such a case we would also need other requirements realization views to show more detail because although figure 3 gives me a level of confidence that we are managing requirements, it doesn’t really tell me how.

As an example. Consider customer requirements/user stories for our Web Hosting product:

Figure 4 – Example User Stories

The point I am trying to make is different requirements may be realized in very different ways. There are different ways we could address each of the needs of our stakeholders, and we need to show in the high level design that we have considered them. If we have 100 requirements for an application by all means group them together, and put them in a single element, but only if it makes sense to do that, and you can show in other documentation how each requirement is handled separately.

Sometimes the choices we make do not appear to make sense. For example, if we had chosen to have a manual business process for billing rather than an automated application process. There might be a good reason – like not having resources to do the automation, or maybe the billing is only once a year and a 2 minute job in another system and doesn’t justify the expense. That’s a business decision. Such a decision quite often gets made in a meeting, maybe minuted and dropped into an email and forgotten about. It is vitally important that decisions are tracked in a work log and not just in a meeting; I have seen thousands of hours burned because of a decision not being tracked and then trying to track back with the relevant people how and what was decided. Sometimes people leave positions in an organization and sometimes you never find out why. Its wasted time that can be easily avoided with a little discipline.

Take a look at my blog on Requirements Realization Views if you are interested in going into more detail.

Business, Data, Application, Technology

Borrowing from TOGAF – Business, Data, Application, Technology, we need to ensure we describe these layers of information. We could do this in a detailed layer view – but I normally break things down into several views.

The Service Realization

Every Service has a service realization view (Several can be part of a single view). This may be small if a service is provided by a third party – because then you are only defining the business interface – but regardless we need a complete picture.

The service realization view is showing how the business layer connects into the application layer. In our web service hosting example, our business service might be realized by two different application components – Apache & Internet Information Server (IIS).The view shows how this service is provided.

The Business Process View

In my blog on Aligning Archimate to BPMN – I introduced the idea of creating process overviews, such as this one:

Process Overview
Figure 5 – A Process Overview

In a high level design I don’t expect to see fully defined processes. For the business processes I only want to understand:

  • What the process is
  • How the process connects to the rest of the architecture
  • What events trigger the process
  • What the possible outcomes of the process are
  • Which roles or people provide the process

Normally this can be done a lot quicker than actually fully defining a process.

The Technology Usage View

Within the service realization I have identified a number of different application layer items (Apache & IIS) which should exist within a technology usage view. The technology usage view is connecting the application layer to the technology layer. I might have a simple view which shows how IIS is served by a technology device – or the scenarios could be more complex – for example we may be using virtualization.

Application Usage or Cooperation Views

These views are useful for seeing how application elements connect together, and how they tie into application data elements and flow of information, which is a good baseline for work with GDPR for example. If you have data elements in the Information Structure Views its good to show them here if it makes sense to. When looking at HLD’s I normally like to see both of these views – however sometimes I find application cooperation and service realization views have a little bit of overlap when people model these views.

The Technology View

The technology views show how our technology layer fits together. Following our example if we have technology devices for Apache and IIS I would want to understand how they fit together and are connected via a network.

At this point I would remind people we are still looking to build high level designs. I am not normally going down to the point i have IP addresses. Quite often with services we offer them with a variety of different service levels, and dependent on the service level we may have different technology views. For example, our best service level might necessitate us to build a technology architecture that has complete redundancy and multi site. Our lowest service level may be a single server in a data center. Model the common scenarios.

Information Structure Views

These views show basic information structures/taxomomies relating to the architecture. We create structures that make sense in the context of what we are producing. For example, if we are implementing a new service in service now then we need to determine a CMDB structural template, or maybe even a service now structure. We can lay out the relationships between the data elements and can even document the relationships to explain why they exist.

For more complex structures we could of course use something like a UML class diagram – but most of the time the structures I use are simpler. Figure 1 showed a simple information structure in the business layer, but of course we can create information structure views in the Business, Application and technology layers, or structures to show how they are related. Take a look at figure 6

Figure 6 – An information Structure View

I chose to use a Grouping box rather than create individual compositions to each data object. Depending on how i was going to use this architecture model I might have done it the other way, but we should visualize in a way that makes sense to our stakeholders.

There is a balance to be had. In a high level design we do not want to go to too much detail – Figure 6 has value because in our fictional example it shows our audience the configurations that we will need to support and helps set scope. We can see clearly that we would need to define two virtual machine templates and a standard network configuration for implementing our basic Apache – and we might chose to reuse these elements. The view gives context to some data objects that would need to be defined in the implementation views.

For more complex structures we could of course use something like a UML class diagram – but most of the time the structures I use are simpler. Figure 1 showed a simple information structure in the business layer, but of course we can create information structure views in the Business, Application and technology layers, or structures to show how they are related.

Relating to information structure is information flow. Its important to document how information flows throughout your architecture. I talk about how you might approach this in my Modelling Information Flow In Archimate blog.

Project & Lifecycle

I talk about modelling projects in my blog Planning Work In Archimate. That blog covers the basic minimums I would expect to see in order to understand a project and its road map. It doesn’t cover more complex concepts such as using plateau’s to represent different states of architecture. I will save that for a future blog.

Using Vendor Or Other Reference Architectures

I am fine with the idea of reusing with pride; several vendors have standard reference architectures. Just because a vendor has a standard reference architecture or a standard set of best practices, it doesn’t mean our job is done.

We still have requirements that need to be realized and we still need to cover the architecture aspects when using a vendor architecture. We also probably need to establish a proper interface and set of requirements for the vendor.

Summing It Up…

Theres a lot of things that go into any architecture design and this is only one approach to creating one. The reality is, that depending on your requirements the amount of emphasis you put into different areas of architecture radically change – for example if we are using Amazon Web Services as a provider of our technology platform we might not need to fully define that platform – although it may still need a small amount of architecture – just for us to state we use the technology level services from Amazon, and maybe what the interfaces into those services are. There could also be related requirements realizations needed of course.

I’ve done my best in this blog to address a fairly complex subject in a relatively short blog. The approach in the blog isn’t perfect, but its one I have developed and used over time to meet the requirements placed upon me by various stakeholders.

Implementing a High Level Design, as described here goes a long way towards creating a solid design that mitigates risks and significantly reduces cost to business.