Architecture Solutions Without Problems

This blog discusses the impact of having solutions documented with no architecture behind it.

Deep thought, a super computer in Douglas Adam’s Hitchhikers Guide To the Galaxy was commissioned to find the ultimate answer to life the universe and everything, and after 7.5 million years managed to do so – the answer being 42. The mice were not impressed; deep thought pointed out that the real problem was that they cannot understand an answer when they didn’t really know what the question was. So they had to build a bigger computer (The Earth). There’s a little bit more about that at the video at the bottom.

In terms of time, that was a fairly costly mistake, and one that I see sometimes repeated in architecture design – it is directly relevant. Some people create Architecture Solutions, but its only really a solution if we can clearly identify what the problem is.

The Earth Mk 2.

Solution Needs

I’ve said it before – A solution needs to Identify stakeholders and ensure their goals and requirements are captured; along with their rationales. There is a need to show in design how the needs of all the stakeholders are met. If that’s not happening methodologically there’s a real risk something will be missed.

For a solution to have properly captured requirements, you need to know where the requirement came from, where it went to, what the requirement was and why it was. You then need to show how its been either realized in the design, or in some cases why it has not been included in a design. If you fail to answer any of those questions you will potentially force someone to have to spend hours tracking down the information later.

If I come into a project which only has a solution document it presents huge problems to myself as an EA – because I can have no confidence that the architects have full control of a situation. I cannot understand a full solution without potentially spending 100’s of meeting hours, in an attempt to build or understand a basic design. That’s effectively trying cover the work of dozens of architects and it really isn’t practical. That’s not really my job so more often or not it ends up in pushing back towards the project.

Some technical specialists with experience will naturally do a fairly good job at planning and implementing a design and just focusing on creating a solution document. They have seen the common challenges and know how to guide projects. Because these guys can seemingly pull solutions out of the air, its easy for people to mistake a technical specialist for a solutions architect. In organisations with poorly defined competency programs I have even seen the roles of tech specialist and architect confused.

The problem is that in this case you are leveraging the expertise of the individual in a way that doesn’t scale very well. It means you need very highly competent and expensive technical specialists. If you are doing this in a large organization the ability to quickly adapt and change as well as the ability to scale is compromised severely – because your architects lack the vocabulary and disciplines needed to talk with each other and properly manage requirements that come from different directions.

Its really painful to become the architecture lead of a project with 20+ architects only to discover that none of them are creating architectures, they are just writing solution descriptions based on discussions. Its hard to lead a team of architects when you don’t have the same vocabulary and in such circumstances is difficult to achieve tangible results. Its also hard to explain to management why architecture is not providing the benefits it should when you have so many architects on paper.

Do you have control?

At this point if you have architect in your job title and you work in a large organization, I would ask these questions:

  • How well do i understand all the developments going on in projects that impact your work?
  • How well do you know which standards your designs my comply to?
  • How compliant is your architecture to the needs of all its stakeholders?
  • Does your architecture design not only show what you need to implement, but how it should be implemented, and how it should be operated by who?

I have met architects whom despite being very competent, smart people, would feel a bit uncomfortable answering all those questions, even if they are routinely building architecture “solutions”. They are still excellent resources with a particular set of skills that provide value; and still have an important part to play in the role of architecture design, but they are not always architects.

Understanding the risk

If your solution doesn’t fully and clearly identify requirements in a way that’s easy to consume and is collected together in a single place, then I would challenge it. Risks are things that may impact your ability to meet your requirements. if you haven’t identified all your requirements clearly, then you have no way of properly understanding or managing risk.

You also have no way of ensuring your test and acceptance criteria are really fit for purpose, and may risk scope creep.

If you have architecture solutions without architecture design I would log at least one risk – that the architecture design may contain un-managed levels of risk and not be fit for purpose.

The Solution

Now I have scoped some of the problems I will point out the obvious solutions – We have to do proper architecture design including requirements and risk analysis preferably following some kind of standard for description such as ISO 42010.

We need to ensure that architects are trained to do architecture, and expected to deliver architecture artifacts. If working in a line organization, for managers who do not understand the architecture roles, I would suggest they should also report to a lead architect. Those resources should be allocated time to do architecture properly, and the lead architect should directly contribute into their goals and job assessments. Failing to do this can denigrate the effectiveness of architecture. I can personally attest to how frustrating that can be.

And for Hitchhikers Guide To The Galaxy Fans

Now I have finished talking about architecture, Here’s a clip from the TV series where the mice are given the answer to the ultimate question. You will hopefully see the comparison between this, and providing a solution without a design.

It’s not a complete architecture unless…

I often get given parts of architecture and am told the architecture is complete. This blog shows the bare minimums I use for assessing completeness.

Here I am laying down some minimums I ask for before I consider architecture to be complete, in terms of the types of things I need to see. In terms of actual subject matter, because the world changes is may be that architecture never stays static.

It can be very frustrating to repeatedly be told an architecture is ready when the basics are missing, so I thought I would lay them down here for all to see.

Although I am speaking from my own perspective, much of what I think, and how I practice architecture aligns to standards such as ISO 42010.

Its worth noting that I will sometimes be a bit relaxed with how I assess architecture depending on who is giving it to me. I don’t want to lay down law so much as provide direction for improvement and avoid having to spend to much time in a cycle of reviews. This blog is written with architects that work for/with me in mind.

It’s not a complete architecture unless it clearly identifies requirements

Requirements should be in some kind of list, saying where the requirement comes from, where it goes to, who is managing it, the priority and why it exists. Often extra information around status is also directly available on a requirements list. It is not enough to say the requirements are in the solution description we sent to the customer.  The solution description is normally a text document, and unless you pull the requirements out of it, its easy to miss some of them. Also the solution descriptions normally are very customer focused. There are a whole bunch of internal requirements solutions normally have to adhere to if we are designing something to be compliant with ISO 27k for example. Have requirements in a list, so we can address them one by one. Take a look at the TOGAF ADM Model – requirements management is at the heart of this model. Understanding needs of stakeholders is key to ISO 42010 as well.

It’s not a complete architecture unless it shows how requirements are met

Every single requirement has to be addressed by a solution or it is a risk or vulnerability; because by definition if you don’t address a requirement, somebodies needs are not being managed. Its OK if an architecture will not address a requirement – but that kind of a decision still needs to be tracked in your design; the polite thing is to agree it with the originator of the requirement or failing that to agree it with someone who has authority to make such decisions.

If you cannot show how requirements are met, the architects coming after you will have a hard time understanding why architecture decisions were made. This can, for example, lead to people innocently making changes at a technical level that breaks how things work from a business one.

ISO 42010 says that architecture concerns should be framed in one or more views.

Collaboration

It’s not a complete architecture unless its been agreed with the stakeholders

Your architecture should be identifying stakeholders – the people it provides value to. It stands to reason that means that how it provides value is of interest to those stakeholders.  If your architecture doesn’t meet the stakeholder needs, it hasn’t succeeded. This doesn’t mean all stakeholders will always be happy. Quite often architecture may be an agreed compromise. A customer is not the only stakeholder!

ISO 42010 has some great examples of different stakeholders your architecture may want to consider.

It’s not a complete architecture unless it addresses the appropriate aspects.

I speak often about covering IT Aspects. Having a brilliant diagram of how different system components fit together is almost never enough.

We have responsabilities to follow regulation, and those fancy technical designs are often going to be operated by someone who didn’t design the solution. This means people need to understand how the technologies work. How we operate things, sell them, and implement them all need to be considered as part of design and communicated.

When this isn’t done as part of an architecture design you end up quite often with something that isn’t scalable. Sometimes what will happen is the talented technical designer will hold the hands of the people that will support things and for a while things will run OK. Over time, people change in the different roles, and what was once laid out clearly becomes less clear as the IT equivalent of Chinese whispers happens.

Of course because you haven’t built and implemented a consistent design people may do things in different ways, leading to cost overhead, a loss in scale-ability, trace-ability and a diminished ability to do any kind of real optimization or effective cost reduction.

It’s not a complete architecture unless its been documented as one contiguous solution

If you do not have all the parts of a solution documented together in one place, or at least tightly connected to each other, its very easy to lose things, and to lose track of your solution.  That doesn’t mean everything is in one word document. If you are using word to describe your solution then its OK to refer to other documents containing information you rely on – such as the requirements. If we do this though,  we have to make sure that a) everyone reading a document actually has access to all the associated links, b) that information across the different information sources is properly versioned.

When you don’t properly maintain versions then you can end up in a situation where a solution refers to a requirements Excel, and someone else developing requirements may make changes that your solution doesn’t address, leading to a great deal of confusion for anyone reading your work. A good architect will be aware of the company documentation standards, and will be also designing solutions that cover whichever modelling standards are in place.

It’s also not OK to make decisions in meetings and not document them, or only documenting them in a set of meeting minutes. Its so very easy in those cases for a decision made in a meeting half a year ago to just disappear.

ISO 42010 makes mention of tracking key decisions in a log. I find that keeping things together relating to a particular work stream makes a lot of sense. It doesn’t have to be in depth – just knowing the date, the person or people working on something – and what they achieved – can save a lot of time when new people are on-boarded or when questions are raised during escalations.

Anyone that’s read my blogs or knows me, knows that I prefer to have my architecture be in a model, rather than documents.

Summing It Up…

If you have a good technical solution – that’s great. I do not argue that a technical diagram detailing how servers connect to different networks is not a valid part of architecture. It is. There’s also an argument that architecture always exists whether it is documented or not. Take a look at my blog on Designing Architecture Through Document Templates if you are interested in that..

The point i really want to make is that in order to have an architecture solution, you need to have clearly identified & scoped the problem, and show exactly how it is that you are keeping promises to your stakeholders, Not doing this will more often or not lead to extra cost later on down the road.

Applying Information Classification To Systems

I wanted to share a simple way I learned of practically applying information classification to IT systems.

I’ve spoken already about Information Security Thinking – this blog is more about ways to practically apply information security to networks and devices. This isn’t the scheme I use in my current job, but one I periodically find myself talking about.

Classifying information

Normally there are variations on a theme for information classification that may go something along the lines of this:

  • Public – Anyone can see, no real restrictions
  • Internal – Limited to people within the company
  • Confidential – Information has a controlled audience of stated members
  • Secret – is the information that could cause significant harm.

This can of course be customized, but as a rule of thumb most people agree we want to keep the information classification structure as simple as we can.

Establishing Controls & Control Goals

Each Information classification is expressed as a control goal – I made up a random example below; its not complete, I modeled this just as an example and to show how we can model this..

Figure 1 – Control Goals

The reason I show the influence relations between the classifications is because we effectively ranked information classification, and layer controls on top of each other. What I mean is if we had confidential information (Layer 3) it was expected that you would apply the confidential controls, but also the internal controls (Layer 2), and the public ones (Layer 1). Secret classified information would effectively necessitate the application of all the controls from the lower levels.

In this way its fairly easy to see how much control we need to apply depending on information classifications.

Applying Information Classification

Effectively once doing this you can designate an information classification to a network, or to a device on the network. Like this:

Figure 2 – Assigning Control Goals

In the example above I simply showed control goals associated with networks. In Figure 2, Effectively I have created Public, Internal and Secret security domains. In the real world I may map the different networks against the different security domains, as in larger organizations there are normally many networks. I simplified for demo purposes.

All devices and networks have an information classification. The rule is, that you are only allowed to have information up to the level of its information classification in any given system. For example a web page from public would be allowed to reside on either internal or secret systems, and its normal to put mechanisms in place to ensure that information coming into systems does carry an information classification, and also that the information classification is allowed on that system or network.

If a lower security classified server is on a higher security network it must adhere to the rules of the higher classification. For example, a web server might have been classified Public – meaning anyone can have access to the information. If we put a web server on a secret network, that’s OK – but it needs to adhere to the rules of the secret network – which in our example might mean that this public web server may not be allowed to have access to the internet.

What happens when the rules are violated?

If for example someone was to put secret information on an internal classified network, a couple of actions may be taken, for example.

  1. That information can be removed, and in depending of the seriousness of the infraction disciplinary action may be taken.
  2. Because a network has to provide a level of protection for the highest level of classified information on it, you could reclassify the network & the servers on it and apply the necessary security controls.

The actual rules should be considered carefully and included as part of a security policy.

Some Security principles

Following the discussion above these are some basic security principles:

  • All networks and devices are designated an information classification.
  • The information classification of a device may not be greater than that of the networks it is connected to.
  • All networks and devices must implement the security controls related to their corresponding information security classification.
  • All devices on a network must also implement the controls of the network they are on.

So whats good about this?

There are a few reasons I like this way of doing things.

  1. It makes the connect between the information we store and the controls we need to secure it.
  2. It can be easily represented in a few architecture views, and is a simple scheme that’s easy to understand, teach and communicate. Less is more.
  3. Because you are applying controls at a network and device level its very easy to see at a quick glance where security is, and gives simple clear rules that help us protect information
  4. It enables IT people to be focused on the protection of information rather than the protection of technology.

Summing it up

When trying to apply security to large organizations the security landscape can get really complicated fast. Its not uncommon to have comprehensive security rules that have grown in complexity and are not followed. This isn’t always because people do not want to follow security rules, its more often because there are already many demands on people & they do not always understand the value of applying security and don’t prioritize it

In designing any kind of security its important to get a balance between ease of use, and effectiveness, because if security policies and rules are too restrictive people will look for and find workarounds.

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.