ISO Compliance – An Architect’s Perspective

ISO Compliance gets a bad wrap. People roll their eyes, are bored by it, and often don’t see the relevance of it. I wanted to share my perspective on this and address some misconceptions.

International Standards Organisation (ISO) create documents that provide requirements, specifications and guidelines that can be used to ensure materials, products, and processes are fit for purpose.

Although I focus a little on ISO standards here you can apply my thoughts to most standards.

ISO Compliance & internal company process

Its a no-brainer that to be compliant to international standards such as ISO 20000, 9001, and 27001 we need to consider them in our processes. We should have processes for checking compliance and often compliance needs results in changes to our operational processes. Checking compliance basically involves taking a standard, turning it into a set of requirements and then going different exercises of requirements realization, or maybe even scoring your processes against criteria in a similar way to what I described in scoring documentation. My previous blogs on those subjects are just describing one of many approaches you can take.

Its important to ensure company processes validate compliance when they first create their processes but also whenever they change them. You cannot just implement standards and forget about them, because as processes change, so can the level of compliance to standards.

In many cases an ISO compliance certification in one country does not equate to having that certification in all countries. Just because your company may hold an ISO 20000 certification, this does not necessarily mean that it holds that certification in the country you are working in.

Adhering to standards isn’t just the job of a security or quality team. In order to really gain the benefits from ISO standards many different roles and stakeholders need to be considered or involved.

Compliance & Architecture

Its important for architects to be aware of which ISO standards a company states it is compliant to. It has a direct impact on both design and implementation in some cases. Its normal to want to short cut the compliance process. There are a few ways to do this;. One way is to create one set of master requirements that aggregates the requirements from all the relevant standards into a set of non functional requirements (NFRs) Those architecture and security NFRs need to be considered when both designing and implementing solutions, and mechanisms should be put into place to make sure that happens.

As an example – ISO 20000 asks that as part of release management a testing environment exists. An architect should plan for this when building implementation and migration architecture.

It is could be very easy to miss this requirement if architects are not aware of the international standards or company NFRs. These requirements are actually architecture concerns from a security and compliance perspective. Architecture concerns have to be managed in an architecture design.

Just as ISO standards can effect implementation and migration architecture they can also effect core architecture design. GDPR is a hot topic – around security of personal information, but for example ISO 27001 provides standards around all information security management.

Its not just a tickbox excercise

Compliance to standards may seem boring and just a pointless paper exercise and when you view it that way it starts to lose its value. The ISO standards have been put together by groups of smart people, that have developed a set of practices to mitigate risk and avoid pains they may have personally been exposed to.

I have heard from some managers in the past that “You cant expect architects to read a whole ISO standard”. Even if you have good non functional requirements from your quality and security teams I would recommend architects pick up at least one ISO standard and read it all. My personal favorite is ISO 42010 (The International Standard for Architecture Description). Read through an ISO and think about the value it’s recommendations give and the pains you would get from not following each recommendation.

For example, ISO 42010 talks about ensuring architecture concerns are framed by at least one viewpoint. If they were not, then the needs of our stakeholders might be missed. Things might not be managed and potentially a customer may notice it. Maybe even a major incident may happen – there could be a huge cost or risk.

If you start to read through a standard and maybe entertain yourself trying to imagine what kind of disaster may have happened that lead someone to write those sentences you may find yourself with a new appreciation of them.

In thinking about what is written in the different standards rather than blindly checking requirements off a list we can get more value from them, and we can learn from the mistakes of others.

Its an opportunity for group fun!

Those running a security, quality or architecture team wanting to get people engaged in ISO compliance could run a workshop with key stakeholders, and get them a little hands on with the risk management side of things.

If you lay out a set of requirements that have been distilled from an ISO standard, it stands to reason that not meeting those requirements poses a risk. If you are using a simple mechanism to validate compliance you could easily establish standard risks against each and every requirement being missed, and start to estimate impact and cost. Getting stakeholders involved in defining risk gives them a deeper more intimate engagement with risk management, and can also help later when those compliance processes are in use.

Its hard to argue that a risk is not valid, if you are the person that defined the standard risk is the person that violated it.

A message to all architects

If you are designing architecture, you need to be aware of standards you promise to adhere to for your customers. and within your own organization. If you cannot name all the standards your company promises to be compliant to, you need to at least be fully conversant with architecture and security non functional requirements. As architects we have a responsibility to ensure we are managing architecture concerns

Don’t think of ISO compliance as being a boring paper exercise. Think of it as an opportunity to take steps to ensure you have an easier, more relaxing, higher quality life at work.

Scoring Documentation Completion

This blog demonstrates a quick and easy way to score documentation completeness and improving quality which is more accurate than guesstimating,

The Goal

To be able to with a reasonable degree of accuracy estimate how complete documentation is, and to not need to take more that 30 minutes per document to do that. I need a balance between speed and detail.

Its not always the job of an EA to actually do these assessments but as an EA its good to get an understanding of documentation that’s based on an assessment rather than a guess at how complete something is, so I often teach this approach.

Some of the benefits of this approach

In following a structured approach we get

  • Better understanding of expectations. When the document authors understand the things we want to see the chances of getting them increases
  • Easy to visualize status – because we are quantifiable we can easily report status in a number of ways visually.
  • Better trace ability of progress – because again, being quantifiable means we can show improvement over time.
  • More realistic assessment of completion. Normally when i ask someone how complete something is they say 70 or 80% but when you start to look its often not so – people want to naturally please other people and tend to often give higher estimates, or sometimes do not think of the detail involved. This mechanism forces people to look at the work in more detail than if you were to “guesstimate”
  • Raises other quality issues. In doing an assessment like below you are reading and aligning to a set of criteria, which are the things that are important to you. Normally when If run a quick assessment i will come up with half dozen or so comments along side the review.

The End Result

I am looking to get an overall percentage of completion – performing an assessment of something i normally end up with a table which will look a little like this:

Figure 1 – A resultant score of several architectures.

Bear in mind the table is only an example. If I was creating scoring for high level design I may have more detail. You can see across the top I have listed some different architecture documentation. In this example its possible that a project may be composed of several teams working to deliver different things to a customer.

Going down on the left is the breakdown of the things we want to see in the document (Lets call them documentation areas). Each area is given a score of 0 to 5 based on some simple criteria which I will show in a while.

Another important thing to note is this is an estimation of completeness as a percentage and not necessarily work. Some of the things I give points for take longer than others. Reading through an assessment can help estimate the remaining work though.

An Overview Of The Process

The process i use is normally fairly simple. I normally pick a few people that will be assessors and give them an hour of training time with me. We run through a live document together and I explain what each document area means – and this description is normally supported with a template. So for each document we are assessing we normally have one template filled out – and we may go back several times over the course of a project to run the assessments again.

The assessment will happen between the assessor and the document owner. They run through each criteria and agree scores together and make notes to agree improvement areas. It can be done without the document author but i find that the communication between an author and and assessor in a meeting is more personal than just sending a filled in assessment. It also gets better commitment for improvement and enables the assessor to explain each criteria and answer questions.This can also be done as a peer to peer exercise.

I make sure that all people referred to in an assessment (approvers, technical validators) have actually reviewed the work and are aware of its state throughout the process.

Creating An Assessment Template

Its really easy to create a template that can be used for assessing the documentation. It can be done in any format – as a confluence page, as a word document, or as a google form, or Microsoft form for even easier collation.

Minimum Header Information

We always need to know as a minimum:

  • What is assessed – the document name normally – with a version number. I normally keep a copy of the actual document assessed with an assessment, rather than a URL to the current version of a document.
  • Who the assessor was – Just the name of the person who is running the assessment.
  • The document / design author – The person that is actually doing documentation work.
  • When the review was performed – just a date
  • A link back to any previous versions of the same assessment – If you are automating this process for a project in google forms for example the link back to a previous version might not be explicitly stated – you could calculate it if you know what was assessed and when. so if we did three separate reviews of the same thing it would have three different rows of data in your google forms.

The Criteria information

Normally I will expect to see this information each one of the different criteria

  • The criteria – The criteria we are assessing.
  • A short description of the criteria – normally a paragraph just to clarify things
  • The agreed score – using the scoring mechanism below
  • The scored mnemonics – I explain what each letter means in the scoring section.
  • The name of the person that approves the work – has to be a person with approval authority – not normally a project manager. Projects are transitory and end. The architecture normally gets delivered to someone in operations, and they should approve it.
  • The name of the person that technically validated things – normally a technical person who is not the author – its good to get a technically competent person from another team if possible.
  • Notes – any helpful information captured during a review.

In a very large project with multiple architects involved in an assessment I might also add the need for the Architect name, and the individual date You can see part of an example in figure 2:

Figure 2 – A partial example of a template

Scoring Documentation Areas

The Score

I apply a very simple scoring system; the order I show here is the order I assess on. I don’t normally assess something is fully complete until its partially complete. I don’t assess language before something is fully complete, and so on.

You don’t allow people to be their own technical validator or approver.

Figure 3 – The scoring

Short here is a mnemonic letter I use to show easily in assessments what I gave points for. So if something is at least partially addressed a point is given – an extra point is given once its fully addressed.

The Math

The math for calculating percentages in figure 1 is simple, but i will just mention it

  • There are 9 different things to assess and a maximum score of 5 points for each area – giving 45 points total as a possible score.
  • Row 14 is just a sum of the proceeding rows.
  • Row 15 is the percentage calculation – so we are calculating what percentage of 45 is in row 14. For column B that would be =(100*B14)/45

Summing It Up

This has been a quick introduction to how I approach doing quick assessments of documentation status when in large complex projects. Its not perfect but it is fairly flexible and quick and easy to implement. Its saved me many hours of having to do more in depth reviews before teams are ready to do so.

I hope this helps someone out there!

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.

IT Architecture Aspects

Often when we are validating IT Architecture we talk about the need to cover the aspects of architecture. This blog Briefly introduces them, and their usage.

The aspects are:

  • People
  • Information & Governance
  • Processes & Roles
  • Tools & Technology

When do we need to consider the aspects of architecture?

Always. Wether you are looking at a conceptual architecture, a high level design or a low level design we should consider all the aspects, and may make conscious decisions not to include some of them (this should be documented)

If we do not consider them usually we consider a design to be incomplete. In many companies we often talk about tools and technology, but I have often seen the other aspects missed. A technology solution by itself is rarely enough if we havent made plans on how to operate, and govern it.

Lets break it down into pieces:

People

Our architectures need to show the people involved in an architecture. This includes the stakeholders, and the people who are operating the solution. A design should be showing that the right people, teams or roles are involved. It should be showing who is doing what.

Not doing this risks that we may not be scale-able, or even worse, may not have the capability to operate a technology design.

Information and Governance

A design should show what information runs through a system – and how we govern it, throughout the information life cycle. Information is a valuable resource and it needs to be governed and protected. We need to understand where it is kept, how it is transmitted, and who is performing what kinds of operations on it.

The structure of the information as part of a system as well as where it is kept can have a key part in the success or failure of a system.

Not considering information and governance can have huge consequences. A lot of people consider GDPR as a first consideration because companies can be fined up to 4% of their annual global turnover (or up to 20 million Euros).

Because GDPR has had so much much attention I wanted to specifically mention it here. It is not enough to have an architecture that is compliant. GDPR is concerned primarily with personal information. Theres a lot of information out there that is not relating to personal information that also needs governance.

Processes and Roles

Within our systems we normally have processes – either manual or automated. Processes tell us in a repeatable what who does what, and when they do it. I talk about processes & roles quite often because they are key to being able to build a scalable organization that mitigates risks.

Not having processes and roles normally has a big hit to operational efficiency and scalability. Organisations can work without having them formally defined but it means that inputs and outputs might be varied, and the ability to take a top level view or have business agility is compromised.

Tools & Technology

Tools & Technology

Understanding which software or hardware are being used together, and how they are being used in order to provide the technical solution.

I don’t feel I need to explain this one too much because I think its the area of IT & architecture that people seem to understand the most.

What About The Organization?

Where I work we have added an extra aspect – the organization. Technically you could cover the Organization as part of people, but working in a large IT Service provider across many industries has meant that we specifically want to emphasize the points around organizational structure; knowing we have agreements between teams, and which teams do what…. Internally we call the IT Aspects, the Five Aspects, so people from my organization may be wondering why i only mentioned four.

Summing It Up…

Its normally fairly obvious when we have an architecture design that is not considering all of the architecture aspects. Its quite easy to come up with a list of risks associated with missing each aspect, beyond the basic examples I give.

When I look at an architecture I don’t explicitly look for a section of a document or any written statement acknowledging that the aspects have been considered – that would be too much. I am looking at the architecture as a whole.

I might see Tools & technology realized in a Visio diagram of a platform, combined with an application co-operation view in archimate, or I might see it in a series of archimate views. The important thing is not specifically how the aspects are considered, the important thing is that they are.

If we consider individual viewpoints for a moment, not all aspects are considered in all viewpoints. A technology layer view may consider tools and technology, but by design doesn’t consider people. People are not the focus of a technology view.

If you present an architecture design for review that hasn’t considered all the architecture aspects, then the chances are its not a complete architecture design, and there are going to be risks, costs, or further design needs that will have to be considered in the future.

Considering the architecture aspects is a good way to see missing parts of your design now – if you are not designing things, sure you may end up with something that works, but the chances are it isn’t efficient.

Information and Security Thinking

When I first started working with the Tieto Office 365 internal initiative we hadn’t made too many decisions on how to move forward with implementing a collaboration platform – This blog is about the first thoughts I had back then; which still hold true now.

Information Management

At the core of any business, and any collaboration system is information – the management and protection of that information one of the keys to its success. Tieto, like pretty much all companies has information policies and its essential that we adhere to them. Some core things to consider:

  • Information classification – We have a standard set of classifications and those classifications determine how we manage information. Anyone is allowed to see public information – where as confidential information has a controlled access list for example. any information we store has a classification, and that has to be identified in our information model. Typically the classification of information is related to the risk of its exposure to various parties.
  • Information Ownership – Information is always owned by someone, and that someone is responsible for the classification of information – although there may be some mandatory rules an information owner may need to adhere to. Its also important to know there are differences between an information owner, and information author. although in many cases its often the same person assuming those responsibilities.
  • Information Traceability – establishing ownership is part of this but we need to be able to effectively track or locate information.
  • Information life-cycle – its important to understand if information is current or outdated, and to establish rules around things such as information retention.

What this means in real terms is we need to ensure anyone using our systems can classify information and it means we have to put in mechanisms to in some cases enforce policy. Discussions started early on over minimums that our internal security team needs in place – but at its core, before we can do anything we need to ensure our information needs are managed and then add the layers of security on top of that – for example we need to consider things like multi-factor authentication. Requirements are drawn up by our security team in collaboration with the architects, and in some cases we need to consider modernizing. Our versioning policy is a prime example of this. On most modern systems we have a simple major/minor approach to version management – many people are unaware of the formal policy we have at work, because our information systems don’t support a version that is expressed something like 1.0.1-2D.

Requirements Management

With any kind of architecture engagement requirements management is important; one of the biggest problems I have had working in my current role is getting focus to be more at a business layer than a technology one. 

Security is not exception to this – its very easy for a security policy to be dictated by the functionality of a tool, and we should be very careful not to do that. This is why, with our security team we have tried to lay out the requirements before even talking technology – even so, I sometimes get the feeling that some of the see come directly from a Microsoft manual. Its important that we discuss and balance the requirements – and decide what is and is not in scope. Some things will be mandatory, and some things may not be in scope; that’s OK – it can be managed as a risk – and sometimes the business can decide to accept a risk – because business drives security, not the other way round.

Balancing Security

There’s a balance. The users in the modern age expect a certain amount of freedom on how they work with information, but at the same time we need some controls in place to protect the organisation and its members.

Too much freedom – and you have risks related to information getting into the wrong hands, or lost, or worse. Too little freedom and it invites users to find innovative ways to work around the systems you put in place. If I restrict who can access a site for example, then people will work around it – they may start emailing files around and suddenly you lose control of where the latest version of your file is, or who has access to it. If I cannot create my own teams site, then maybe I will want to use something else. In such a case by restricting access we have effectively lost control of access all together.

We have been very mindful of this from the start of the Tieto project – Tieto has many ways of working, and no one way fits all. When we first started on-boarding users into Office 365 some policy decisions were made – people in specific customers were not allowed to be on Office 365. When it comes to collaboration, Not allowing people on creates a very real problem. suddenly those customer teams are alienated from a wider Tieto community, which means we either loose our connection to them, or they find a way of working around the mechanisms we have in place. In Tieto, any restrictive policy we put in place is going to impact someone somewhere.

So how do we address this? We know already the information we must keep to have a minimal level of security, but more important if for us to understand our information policies

Knowing Your Responsibilities

As information owners we all know pretty much what we should and shouldn’t do, and to be successful we need to have a level of trust that our users will know both our information policy and what their industry/Customer does or doesn’t allow. Rather than restrict we need to educate.

For those users in customers that are not allowed to have information online we need to ensure we have a system in place that makes it very easy for the to understand where they are – whether it be on O365, or on our private internal solution. At the top level we decided we would color code. The site theme for Office 365 should be different to on premise so that we can immediately see where we publish.

We need to make sure that as part of this project our communications team makes it fairly clear what our responsibilities are.

How This Is Realized In Technology Terms

We implement core content types that are mandatory and a basic template that all others are derived from – out of the box SharePoint, and we have taken other decisions on things like Multi-factor authentication. We then continued a discussion on how and what we need to implement around EMS and other technologies. 

These are the things we were considering at the beginning and still form important parts of the ongoing work because of course outside the office 365 conversation, there is also a device management conversation going on.

I hope this gives a little insight into some of the information considerations we had when practically moving to Office 365 & its surrounding technologies.