Systems user rights in architecture

Last week I was asked for a standard definition of what administrative users are in our company. I wanted to talk a bit about user rights because admin or not admin as a way of thinking is dangerous.

I wanted to share my thoughts on it, and an approach for defining user rights in architecture. I want to start by recommending a read – Modelling Identity In Enterprise Architecture. When it comes to designing role based access control (RBAC) I think this is a good starting point. This blog is thinking more in terms of systems access than designing full RBAC.

Most organizations have a need to adhere to standards such as ISO27k, or even more fully defined security baselines. Its clear that there is a need for segregation of duties, and that security principles should in some way cover the need for least privileged access.

Thinking in terms of administrative usage by itself is dangerous, because its binary – you are asserting that either a user has privilege to administer, or does not. When I started writing this blog that’s all I wanted to point out but in creating the fictitious example below I realized there’s a lot more I could say around my flow of thought.

As with other blogs, the point here is not to design a complete service, more its to explain my approaches. There are a few things I would change if I was going to build a real thing. I would look at my Identity Access Management and fit that in a lot better.

Lets make something up. Our fake example is a backup service.

Backing up a system

In order to fully back up a system it stands to reason you need to have access to everything in it. A non privileged user could not back up files they do not have access to. If we were asking the question should that user be privileged or not, the answer would be yes, that user needs privileges to read all data on that system. In fact all users need privilege’s in a system, the question is normally how much.

Does this mean that user is an admin user?

Here’s where you need to be careful. On a windows or UNIX operating system – assigning admin rights out of the box gives a specific scope of control to a user. people tend to talk in terms of admin rights and non admin rights because of this. if I tell someone they will get admin rights on a windows server they know what they get.

When you do not do architecture, or think about your systems security architecture the exact needs are not designed. I have seen many times in my career people writing code to elevate permissions to admin just because code didn’t work in the current user, and elevating privilege’s solved it. Whilst it made the code work it gave code dangerous levels of access to the systems that could be exploited

When people use the term elevated privilege’s they do not necessarily mean administrative access, they mean they require more than they would have had otherwise.

Using Admin Users For Elevated privilege

In general I would say using admin users for anything is a bad idea – because if you share admin credentials around you are increasing the probability those credentials can be compromised – and you are also making it hard to trace who actually made changes to a system

Giving users admin rights would be a better approach when it comes to identifying change, but still this is generally considered not good enough; A common security principle that you will see in many standards is “only provide needed rights” – so if an account does become compromised the damage is limited.

In the case of our backup example, admin rights may be too much. to perform a backup, I need read access to a system; in specific cases I may need to also be able to write to specific areas, for things like logging.

Designing Backup Scenarios

When designing a system I should be thinking about specific use cases. This example is a simplified one just for demonstration purposes at the top level, if i was providing a backup service, I may have thought of four basic user stories:

  • As a backup technical specialist i want to back up all the files from my server in order to prevent data loss
  • As a backup technical specialist i want to be able to restore individual back to a system in order to recover from a data loss
  • As a backup technical specialist i want to be able to test my backups in order to ensure they work
  • As a quality controller i need to see that backups, restores and tests are happening correctly to ensure the quality of my service

I am not providing a full set of use cases, because we would need to cover things such as restore time and point objectives, and would need to deal with complexities such as single file restore vs entire system snapshots, and I want to try and keep this blog short!

A quick service realization

Off the back of those 4 use cases I drew my first attempt at a service realization. It looks like this:

Figure 1 – A service realization

A full service realization would cover more around the process; our motivation models and user stories would develop this view further, but our focus here is to look at users and their interactions. There are a couple of thoughts that went into the design of figure 1.

  1. From the use cases its clear that there were two business roles i was working with, each needing different levels of access.
  2. In doing this design I know my security principles & control needs, so in the back of my head i am already designing for them. sometimes we may do this in several iterations – especially when i start to do my requirements realizations. It is way faster to develop things if you are familiar with the standards and controls you need to adhere to.
  3. I deliberately separated out logs from actual server data to meet some security principles.
  4. As a principle I already think what is the flow of information and the minimum level of access I need

User vs System Permission

Its important to understand the differences here. In our example our backup technical specialist would need to be able to backup, restore and test. He is a single user, and would probably be authenticated for access to a backup system portal with his own credentials. I didn’t model it here but he would probably be given roles in a backup application which would enable him to run different application processes. Its standard role based access control.

At a systems level things are more complex, and should be designed to be secure.

From looking at the access relations on figure 1 I can quite clearly see where I need to apply different levels of permissions. in our case we have 3 business processes – they are core processes, which make perfect sense to be accessing the systems with their own permission. From the service realization I could easily cut it into pieces to have a sensible scheme for permissions – it might look like in figure 2:

Figure 2 – Breaking down into users

Our view here is telling us

  • Our restore user needs to read backup storage, and read write to our server data & restore logs
  • Our backup user needs to be able to write to backup storage, write backup logs, and read server
  • Our test user needs to be able to read and write test server data, read the backup storage and write test server logs
  • Our backup log reader user needs to be able to read backup logs, restore logs, and test server logs.

Figure 2 – is really just figure 1 organized into different users.

So what’s missing?

I didn’t show that I had specific reasons for creating the user access the way I have done. My thoughts would be lost if I didn’t document them some how. I could easily extend figure 2 to show this. Take a look at figure 3:

Figure 3 – Requirements Realization

Figure 3 tells a story as to why we organized things this way, and like any architecture it is iterative. We would have arrived at our requirements when motivation modelling – we could also choose to show our principle on this requirements realization view in figure 3. I speak about motivation modelling in other blogs. Whatever makes sense to tell our story. Bear in mind we can also document any element and any relationship between elements. on the view i chose to label the relations in some places, but additional information could be stored in the documentation for the relations. Understanding why something is related to something else is something that’s easy to document in most modelling tools.

Note I added some users as application data objects there. From a systems perspective all a user is, is data. different applications use that data to authenticate using there own application process mechanism. I did this because i want to refer to these standard users and their standard permissions in the final part of this story:

Figure 4 – considering technology and locale

I knew already when I was creating figure 3 that rules around information segregation would also need to be considered at a server level and that this would likely mean that the user structures I was creating at an application level would have to be split so i could ensure that compromising a single country does not compromise my entire solution. Figure 4 shows that each country we are operating in needs a data center in order to ensure that backups do not leave the host country. In our case we have allowed log files to leave the country so we can centralize our log management but we have a clear idea of the major data flows.

Summing it up

Designing this way is going to help when it comes to doing things like ensuring we have GDPR compliance, and making sure we follow security principles. At this point I may also chose to do either a basic risk analysis or maybe model some threat scenarios to look at different ways this design may be compromised. That’s a story for another day.

Working With Deliverables

Following my previous blog on Working With Projects & Dependencies I wanted to say a little on working with deliverable’s and avoiding some pitfalls.

I wrote this blog to address some trends I am now seeing with new architects modelling implementation and migration architecture for the first time because its really important to get this right. This is aimed at beginners.

What is a deliverable?

The ArchiMate 3.1 Specification says.

A deliverable represents a precisely-defined result of a work package.

Figure 1: Projects & Deliverables

So simply put, when we do work in a work package, we expect a result. Work packages realize deliverables & in my last blog I showed how I manage link dependencies from one work package to another by accessing (reading) the deliverable that is realized by another project.

Its not the only way we can work with this, but its a way that works.

Common Issues In Naming Deliverables

Correctly Scoping The Name

Each element in an architecture model is reusable and may be used in many views. This means you need to be specific to the context you are modelling in. For example lets say we name our deliverable “High Level Design Documentation”. It is a fairly generic name that would be an object that many architects may want to use. When we are thinking of using specific elements in specific contexts we need to get this level of abstraction right. If we are documenting an element named “High Level Design Documentation” then we can only document things that are specific to all high level designs (HLDs). if we needed to say something specific about a project, we would need to name it in a way that’s identifiable as a project specific element; Its far better to name it “Project A – High Level Design Documentation” in such a case.

I spoke about this in my blog Documenting An Architecture Model.

How we scope the element is dependent on how we will use it. In the case of “High Level Design Documentation” – If every project has exactly the same requirement to deliver exactly the same type of document its tempting to just reuse the same element on each project. That’s a really bad thing if you are trying to dependency Map because then every work package would have a relationship to the same element and you would have no way of differentiating between the different deliverables. Figure 2 is an example:

Figure 2: Using same High Level Design Documentation element (A bad idea)
Figure 3: Navigating High Level Design Documentation

The view looks easily understandable but it is bad in the when we look at this in the model. In figure 3 we can see the relationships for the High Level Design Documentation Element. There’s no way of telling that project A can run completely independent of project C, because project C accesses high level design documentation, and there is no difference between the element realized by project A to the one realized by project B or C.

Correctly Scoping the Element With Specialization

So if we want to show we have a standard high level design and maybe have the documentation of that element reflect the standard, what do we do? The solution to this problem is simple. we use a specialization.

Figure 4 shows several deliverable’s being a specialization of a standard deliverable.

Figure 4 – Specializing a standard deliverable.

Confusing Deliverables With Requirements Or Goals

I have seen sometimes people define deliverable like requirements – where people are thinking about what a project needs to do, rather than what a project needs to deliver. You can think of a set of defined deliverable as a checklist of things that a project should produce. In general I don’t go crazy with this idea. If you saw my blog on High Level Design you could see a design can be composed from many documents, and If I did decide a HLD was a deliverable I wouldn’t model each document, unless I have a very special reason to do so.

In fact if a high level design is part of our standard project documentation – I may not model them specifically at all (See Just Enough Architecture). Some examples of deliverables:

  • Project Standard Documentation
  • Fully Configured Production environment for Project X
  • Updated InfoSec Policy
  • A Deployment Process
  • ISO27k Audit Policy Pass

Looking at the deliverable above you can see a deliverable can be almost anything. I nearly didn’t include ISO27k Audit Policy Pass. The reason being that although it may be a deliverable, its easy to confuse it with a requirement. Deliverable’s are effectively an outcome of the work done to realize a requirement, or goal.

In the documentation for the elements above I might specify further what we need to achieve that deliverable. For example I might elaborate on “Fully Configured Production Environment For Project X” by saying something like:

Production environment implemented and documentation of its acceptance provided by operations and the all the stakeholders shown in the view “Project X Stakeholders”

We don’t need to write a book, but we do need to be precise; specific and measurable.

Focusing On Delivering Documentation

Ok, there are times when documentation is key to the progression of other projects and dependencies, and documentation can definitely be a deliverable. Don’t get lost in doing architecture there – our goal at the end of the day is to have projects deliver value, not to only document. One of my own managers favorite sayings is “Build the hospital, don’t only design it”. The message being is we can spend a long time trying to design a perfect thing, but unless we have a practical implementation for it, its useless. For that reason when looking at any implementation and migration architecture in my own company, we always look to see if there is a deliverable that goes beyond documentation. I think this is good general advice, but I mention this especially for my own architects…

Modelling Too Many Things At The Top Level

In figure 4 we showed Standard high Level Design Documentation as a common deliverable. Standard high level designs may be composed of several documents, and unless there is a very specific need we do not want to model project specific instances of all of them. It would be better to create a view showing the composition of a high level design like in figure 5.

Figure 5: High Level Design Composition View

Summing this Up

This blog was really targeted to address some issues I am seeing right now from some people that are new to modelling completely, and I may have repeated things that I have said in other blogs, but I hope other people find this useful. Having a well defined set of deliverables really helps set expectations.

User Stories

Introducing User Stories, an easy mechanism to capture stakeholder needs and requirements.

The Basics of User Stories

There are many forms a user story can take but I introduce a simple one here in the video below.

To sum it up quickly

As <someone> I want to <do something> in order to <achieve value>

Its an easy mechanism we can use to focus users into creating a basic form of requirement.

A practical example

Lets take a look at some basic examples.

  • As a customer CxO I want to outsource my website management in order to reduce risk of unexpected maintenance costs
  • As a customer CxO I want to outsource my website management in order to reduce operational costs
  • As a customer end user I want to have an uninterrupted service experience in order to reduce wasted time
  • As the web service product manager I want to have efficient operations in order to maintain a 30% margin
  • As the web service product manager I want to have a completely automated deployment of my core services in order to be scalable
  • As the web service product manager I want to have a completely automated deployment of my core services in order to reduce the chance of manual error
  • As the web service product manager I want to have a completely automated deployment of my core services in order to have fast deployment times

Above are some typical examples that might come up in a planning session with product management. I could easily go to my stakeholders in separate meetings, and work with them to build a more complete list.

Turning this into ArchiMate

Is fairly easy. Again I showed it in the video but I will demonstrate. I don’t normally insist architects create a view like the one below but it has advantages if you are trying to extract value. Take a look.

I’ve done this quickly. Note I slightly changed the wording for both values and requirements – this is because we have to remember they are elements in a model. This means they need to be able to stand as independently and tell a story by themselves.

Viewing them this way means makes it easier to see which requirements yield the most value, and makes it easier for us to tie things together. We could use these user stories as a motivation view in our work planning.

You can of course also use this very basic motivation view as the basis for a requirements realization.

You could also use the work to group together values.

I will be talking a lot more about requirements of different kinds and approaches to them. Its a big subject – needless to say, User stories offer an easy way to get started capturing the needs of stakeholders.

Aligning ArchiMate to BPMN

ArchiMate is fantastic and connecting different layers of architecture together, and BPMN is fantastic at modelling process – This article demonstrates my approach to marrying the two languages.

Playing To The Strengths

As I mentioned in my article Architecture Languages, Standards, And Frameworks, BPMN strengths lay in creating process detail – and whilst it’s possible to create processes equally as detailed in ArchiMate, generally speaking those processes tend to require more views, and do not look nearly as tidy without a significant amount of effort.

A question I am often asked is which modelling language should be used, and to what level of detail? Both Languages have pros and cons.

For that reason I tend to model the process and its connection to the rest of the architecture in ArchiMate and leave the details in the BPMN model.

The order you do this very much depends on the level of understanding you have of the process. Some people prefer to do the detailed process and then fit it into the context of the organisation and others prefer to do the general overview and then detail out the process later. As part of my standard approach to creating high level designs I normally create the ArchiMate process overview before the BPMN one.

The ArchiMate Process Overview

In ArchiMate, my overview generally looks something like this:

Fig 1 – A process overview

I start with the actual process in the middle. I have found many architects can have a challenging time fully defining a process; its easier to understand what you need from a process and what your expected inputs and outputs to process are, and who needs to be involved, than it is to understand all the minutiae. So the key elements here:

  • Business Process – I normally start with one process – with a name suffixed with the word “process”, because its just easier that way to be clear when talking in conversation to other people.
  • Business Actor / Role – I prefer to use roles rather than actors, because it helps with abstraction and re-usability of the process; it’s important to understand the differentiation – actors are assigned to performing roles. Sometimes I might use both or a mixture of two if i have good reason.
  • Business Events – In the ArchiMate specification it says that events denote state change in an organisation – The way I am using events here is to denote the events that cause the process to start running, and the outputs of the process The direction of the trigger relationships tell us which are which.

In the view above (fig. 1) we can see that our process serves the “My Software Service” – its good to put a process into the context of either a service or a function within the overview. Of course I can just take one or several elements from such a view and include them in other views as needed:

Figure 2 – A layered view

In figure 2, you can see a support process as part of a layered view; in this case we are connecting a process also into the application layer, you can see how if we had a process overview of Support Process our understanding if it work be better. We may have included some elements that would appear on a process overview; but not probably not all of them – this is a judgement call – when creating a view, I am telling a story, and I use whichever elements are relevant to that story. Of course the story of a process overview, is “this is the process from end to end, and this is how it all works”. Its views like the one above where we are able to use the process in the context of other architecture in a repository – that make modelling the process in ArchiMate worthwhile.

Creating a BPMN model

Going to the next level of detail, if we did a BPMN view for Figure 1, we may have created a process that could end up looking like this:

Figure 3 – A BPMN process

A couple of key things to note

  • The swim lanes in figure 3, match the roles in Figure 1; of course, if figure 1 had actors, they would be here too; I need to understand easily how the detailed process in BPMN connects not only into the process overview in ArchiMate, but the rest of the model.
  • Its really important to give the process in ArchiMate the same name as the process in BPMN so later its easy to search and find it.
  • We match up the events with same names in BPMN as ArchiMate, It makes sense. I think of them a little like being interfaces into the process.
  • I deliberately didn’t make the BPMN more complex – Its one of those languages that you can get started with easy, and there’s a few things you can do with gateways, and events, and a lot more possibilities than I show on my example. As I have probably said, I am a great believer in keeping it simple – and the 80-20 rule – you can get 80% of the work done in 20% of the time. Of course encourage architects to learn the standards properly and fully utilize them, but the elements i use in figure 3 cover most of my needs – and I would rather not have architects engaged in hour long discussions over what kind of gateway to use, when it is evident from just leaving the gateway empty and seeing it in the context of the view. I have found in the past, after getting comfortable with the basics, most good architects like to explore these modelling languages and will start to figure these things out themselves.

Why Am I Calling It A Process Overview?

So the elements shown in Figure 1 – could be considered to make up a standard process view like is showing in the ArchiMate 3 manual. I consider the process overview to be a specialization of that – because I am asking for specific elements, in a specific configuration – I tend not to want to clutter the view. I also do not limit this kind of model to the business layer – I could just as easily apply exactly the same concept in the application layer, an application process would be triggered by application events, and may serve application functions – Actors & roles would be replaced by other active elements in the application layer – typically the application component.

How Do You Practically Do This With Tools?

Typically I am using BiZZdesign’s Enterprise Studio (BES), which makes it easy, because the model allow me to create models in either ArchiMate or BPMN. I normally connect those view via hyperlinks – both on navigation pages, and in documentation. Enterprise studio also supports cross model relations – so I can link the navigation of one object directly to another and state the type of relationship; so for example, I could create a relationship on my Software Acquisition Process in ArchiMate to show it is refined in my BPMN model; a number of cross model relationship types exist. I could also tweak the meta-model to give me better options, but I haven’t done that.

Enterprise studio has some new compliance functionality – I did a quick video on it (with some notes in another blog) –

If I was using Archi & Visio, I would create a custom property on the element in the Archi Model and link it to the Visio file in a shared space. All of the modelling tools out there support hyperlinking in one way or another. Another option would be to link from the actual views rather than the specific process elements – but I don’t do that.

Summing It Up…

Of course we don’t actually need to do produce both BPMN and Archimate in all cases, but I do like to leverage the benefits of both together.

The approach I have presented today has a few advantages:

  • The ArchiMate view is quick and easy to get started with when you don’t have all your process detail.
  • BPMN is easy for process developers and other people to develop the detail in parallel. This is important if you work in an organization where process is developed separately from architecture.
  • Following some of the rules I presented will make it really easy to understand ArchiMate in the context of the more detailed view – because the inputs and outputs align.
  • Having naming aligned, and hyperlinks in place helps you find things – the alternative to this is to have disconnected processes.

I personally believe that not aligning your BPMN models with your ArchiMate ones, is effectively disconnecting process from architecture. But of course, Let me know what you think.

Enterprise Studio Compliance Color View

A quick introduction to some rather cool functionality recently introduced into BiZZdesign’s Enterprise Studio.

Note – If you are do not see a Quality tab in your interface, it may be either of these issues:

  1. You are running the wrong version of Enterprise Studio. Its possible to have two versions installed at once.
  2. You are running on a model repository that doesn’t have the latest version of the meta-model schema. You can check this. If you create a new model package and have the quality tab but it doesn’t work when using a team server, you need to talk to an administrator.