Architecture building blocks and ArchiMate

ArchiMate isn’t only about drawing views and relational models. Understanding the language fully helps how we shape our architecture.

In a meeting last week there was a fairly lively debate about architecture design. In that meeting we had some people wanting to comment the semantics of the ArchiMate language (the more analytical people). Some people were just wanting to understand the relationships between the applications. Quite a lively conversation ensued, and want to share my thoughts on this.

Architecture Tells A Story

I have spoken about Storytelling in previous blogs. In ArchiMate terms, a view of architecture is created for a purpose for a specific audience – its defined in the viewpoint definition. So its important we address the intentions in the viewpoint definitions.

Following ArchiMate Standards Help Structure Architecture

Using the right elements for the right things is important when it comes to wanting to generate specific views. For example If someone mistakenly stated “ISO42010” as a strategic capability rather than “ISO42010 Compliance” as a requirement, then if I want to automatically generate a view of our strategic capabilities, I am going to have things on there that don’t make sense. If many elements have incorrect definitions or relationships between them then the usage of the model as a whole is greatly diminished.

Understanding the elements and the metamodel fully is key

Understanding and using the full metamodel properly gives so much more than just defining elements and relationships. Services are a fantastic example. Rather than building one massive view of interconnected application or technology components, breaking things down into smaller services gives us opportunity for reuse. This can be done at the business, application and technology level. Building a service is like building a Lego block. You can think of the block as being a service – and the interfaces to that service being the connectors like this:

Figure 1 – Lego Web Service

We can build our services in several layers of course; either stacking services, Business on Application, which sits on Technology – Alternatively our Lego block here could also contain elements from other layers. It could be argued with the example above that the interfaces for directory services or databases shouldn’t be there – because they are part of the internal make up of the building block, but this is one of the key things we need to decide when building architecture – what are the logical blocks that make the most sense for reuse, what is internal, what is external. We are building architecture building blocks. Within our services of course there could also be sub services within these building blocks – so one building block can be made of others. I previously wrote a little on Services In ArchiMate that goes into a little more detail on the subject of Services.

I have already spoken extensively on the benefits of having an architecture model rather than word documents, and an ArchiMate relational model making it possible understand the implication of change, but in understanding how the elements and relationships in the metamodel come together to create a service base thinking we truly start to see some real power.

Putting it all together

At the end of the day, we want to be able to do this:

Figure 2: Building blocks

We start to build standard architecture building blocks, with standard interfaces. connecting into standard services we unlock a myriad of advantages – We can can more efficiently reuse our resources, and we can put our services together in interesting new ways. With Lego the focus isn’t on the blocks – its what you can build with them – the same holds true in architecture.

Summing it up

How we model something and follow the language of ArchiMate is important. We don’t just want to understand the elements, or only have a relational model, we also want to ensure what we are doing is building architecture building blocks that make sense, and make it easy for us to have reuse.

Practicing architecture in this way may mean a learning curve for architects but its key for making efficient use of a companies resources, and maximizing the benefits to business.

Motivation Layer Modelling – Part 1

I Wanted to share how I approach motivation modelling, as there are many approaches, and I often see important things missing in this area. .

I will be breaking this down into two parts. This first part is focusing on stakeholders, drivers and goals. There are of course many approaches that could be taken but this one is mine; I would love to hear others. I have in fact spoken about simple motivation views in my Planning Work With ArchiMate blog. This blog talks about creating full motivation views rather than the minimal things I wanted to express at the time of writing that previous blog. Bear in mind this example isn’t fully realistic. I made it up.

The Finished view

I will start by presenting a view I created for the CEO of my fictional web hosting service provider. As I mentioned this is only half a model – in the next part I will be talking more about outcomes, principles and requirements..

Figure 1 – Motivation view

When I was drawing this originally I was going to create a motivation view including multiple stakeholders, but just in real life it didn’t work out that way. There’s so much that can be going on it didn’t make sense to start everything on one view. So I created one for the CEO – just as I may well do the same for other stakeholders. I may then go back and create a master view that brings all these views together in a singular view that tells a story.

Stakeholders

I blogged about Stakeholders In Architecture previously; and ensuring we cover as a minimum a set of stakeholders. The reality is that I still sometimes see stakeholders missed – so as a double check, especially in large projects – its a good idea to look at the organization chart. The heads of business and key roles are normally stated there and usually have an interest in our architectures. I also sometimes look at the examples of stakeholders in ISO42010; It mentions users, operators, acquirers, owners, suppliers, developers, builders, and maintainers. I don’t think the writers of ISO42010 meant for this list to be definitive but it has always served as a good starting point. The only issue I had there is it requires a fair amount of thinking to ensure you do not miss stakeholders – for example think about security.

When I state stakeholders I try not to mention names in the elements. because names often change over time and you need a record of how things are at a specific snapshot of time. In the tool we use, Enterprise Studio, we sometimes put labels on the stakeholders to identify specific people in specific views. The advantage there is that the labels are not in the actual object model. For example if a stakeholder was “Owen Richardson – EA” then in 6 months time another architect came in and we renamed the element, all the views that were once Owen Richardson, would now be named with the new architect – which may not be representative of what happened in projects past. Labels stop that from happening.

Its important that the defined stakeholders are resolvable. As in you can identify who they actually are from your model – whether it be by looking them up in the organization structure or by having the actual names of people on the labels.

Relationships

I tend to use influence relationships in my models. I do not do any advanced decision analysis with them. Sometimes I will put positive and negative strength indicators on them. This often confuses people, so sometimes I will leave them off if I think it doesn’t provide value. You can see some examples of how I use influences, and the indicators in figure 1.

Drivers, Assessment & Goals

Drivers are the reasons why someone does something, goals are the things you do to satisfy those motivations. Some drivers are obvious, we normally get the drivers and assessments from talking to our stakeholders. They will normally tell you what they want, and give you reasons – those reasons I treat as assessments. Sometimes they will also give you the goal; or sometimes it may be down to the architect to suggest the goals. In those conversations with the stakeholders I normally create a high level goal then I need to think about how to make it quantifiable, so i go a level down. and have lower level more defined goals influencing the higher level ones. These are important because later on when we start doing implementation architecture and deciding how goals are reached we will be reusing these. Its possible several stakeholders are going to have the same goals; at that point i will sometimes consider creating a higher level motivation view showing just how the stakeholders and goals fit together. You can create as many motivation views as you need to tell the story of how your architecture is motivated.

When creating assessments its very easy to end up with statements like “we need to do ” which could end up as goals or requirements – I try to avoid requirements until later and will sometimes reword elements to avoid confusion. “We need to automate” might be a good example. This could be a driver of a stakeholder, or it may be a goal, or even a requirement. You need to think a little in the context of what you are doing and ask is it really something that drives a stakeholder, or is it something that’s a result of whatever drives them?

Some of my goals in figure 1 influence each other:

Figure 2 – Goals influencing

You will find talking to different stakeholders that in some areas they have a more defined idea of what they are needing. It may also be that you are already thinking about how your goals will be realized when you create your motivation view. In the example we can see our goal isn’t really fully realized until all the goals below it are met. Sometimes you will have this level of detail at the outset – other times this will come up later in design conversations. Motivation views can go through several iterations, as can any architecture view. Its worth mentioning SMART – when it comes to goals (Specific, Measurable, Agreed, Realistic, Time Based). More specific goals in general are more useful when it comes to actually realizing them. The more vague and fuzzy a goal is the more different possible ways there are to make the goal happen, and the less likely that it is that all the goals working together will end up in a desired outcome of your project or architecture.

Values

Goals provide value. I like to have a standard set of values that i map onto different architecture models. Values like cost reduction, risk reduction and improved efficiency will come up time and time again when management start new initiatives to improve things. Its good to get ahead of them. if next time my manager asks for a cost reduction i can show him a value, connected to a goal, which is connected to a work package (which would be created in an implementation and migration view), It would be very easy to show how we are already working towards those goals, and then reprioritize work with the management if need be.

Prioritizing goals

Sometimes we may chose to prioritize our goals. Priority may have a significant impact on project planning when we come to do implementation and migration work and when it comes to thinking about how we realize our project. In BES we use MoSCoW prioritization (Must Have, Should Have, Could Have, Won’t Have).

Figure 3 – Our Prioritized goals.

Representing Out Motivation To Stakeholders

ArchiMate is a fantastic way for architects to iterate through a design process; and more important than the actual views we create is the process we are running through of identifying stakeholders and connecting them together with the drivers and goals.

I would always think twice before sharing a motivation view with a senior stakeholder in the organization. They can look complicated and do nothing for the more senior members of the organization, beyond maybe showing that architects are doing something! The value we are bringing is in making sure that all the motivations are considered, so when somebody presents a PowerPoint with our goals on, you can be sure the goals are considered from different directions, and are good.

Validating the motivation views

Its important that the stakeholders feel ownership of the architectures we create; our value comes through ensuring that the needs of all our stakeholders are being managed as part of our architecture. Its important that we get this part of the architecture right, before we go on to look at how to realize these stakeholder desires. Understanding the goals and drivers of all our stakeholders may give cause to reprioritize how we do our developments. Sometimes it takes multiple iterations to get this right, but its important to do, because without understanding the things I show today there is a real risk that a project, or architecture may not be fit for purpose, or we may never be able to show that it achieved the value or goals that were intended. There’s nothing worse than being half way through a project and then realizing a stakeholders needs have not been met and have to redesign things..

Continued in Motivation Layer Modelling – Part 2.

Architecture Principles

This blog quickly runs though some basics on architecture principles & how I use them.

The company I work for, has a specific set of architecture principles. Within our hybrid Infra team, we limited it to 5 principles so it would be easy for all architects to memorise and learn them. Whenever someone comes to me with a design idea, or an architecture to review, or even an architecture concern the first thing I do is in the back of my head, think about architecture principles. Principles are in the motivation layer of an ArchiMate model.

I tend to think of a principle in architecture as being the same as a principle in the real world – its a rule that we strive towards achieving. The ArchiMate manual defines it as a statement of intent or general property that applies to any system in a context.

An example principle

I will use a simple example principle. Lets say our architecture board established a principle “Systems must be available 99.9999% of the time”

When we define a principle, it should be a simple statement like above, but normally there is a need to document further the exact meaning and scope of a principle, as well as its issuing authority.

If it was a principle applied to our unit, or is in scope, in our design documentation we would state it – and we could connect it to a set of requirements like this for example:

We might decide that we will not be able to achieve a principle. having a high resilience is often expensive, and we may have a requirement to keep costs low, or to implement interim solutions quickly. The important thing is we:

  • identified the principle
  • identified how we meet it
  • if we cannot meet it,we identify that we cannot meet it
  • We flag principles we cannot meet
  • We have it agreed with the relevant stakeholder that it is OK to go against the stated principle.

Establishing new requirements

When I drew the view above for the fictional web hosting solution I have sometimes developed in my blogs, i quickly came to thinking of many requirements. I used “…” to represent them above for brevity, but this is another important part of working with principles. Automatically when I started to think about the principle I started to ask myself the question “What do i need to do to achieve it?”.. Suddenly, I started to think about the IT Architecture Aspects and think, I would need to consider people and resourcing, to have resilient processes in place, and so on. Many requirements started to come to mind that I might capture. I may also identify risks when we cannot meet principles.

Had this been a real project i would be validating the principles against the requirements, and I may even define new requirements to meet the needs of the specific principles. I would of course also make sure that in addressing the principles all relevant stakeholders and actors stakeholders were considered.

Of course we do not have to do all our work in ArchiMate, but its a good flexible approach.

Authority

Principles have owners. If a leadership team sets a principle, then I would normally say that that leadership team (or someone they nominate) needs to approve any deviation from that principles

Summing it up

Many times I have worked with architectures and stopped work happening early. because I know our principles by heart, and can state that doing something would be a risk and go against our defined business needs.

Principles are a very good way of representing the intent of an organization, unit or specific stakeholders. They can ensure that all the work architects do head in a commonly defined direction.

Just Enough Architecture

How much architecture is just enough? Is a common question I get which I will try to address in this blog.

Determining the right level of architecture design can be challenging; its very easy to get caught in a loop of over engineering for some people, and hard to know where expectations start and end for others. So what is the right level?

The High Level Design

The high level design template I created for work runs to 42 pages. Its an extremely long document that was built out of necessity. It has a lot of helping text and example views. It attempts to do a couple of things:

  • Provide a document structure that is ISO42010 compliant
  • Provide a document structure that provides Business, Data, Application, Technology Descriptions, and can be aligned to TOGAF
  • Provide extra spaces for common integrations and considerations we have within our own organization.

It aims to be usable by architects of very different levels of experience. When new architects look at it – it can be scary. Even though I wrote it, I really do not like it. I have discussed my thoughts on documenting architecture in document templates in the past, and I would much rather focus on the views we need to see to address the concerns of the stakeholders than trying to crank something into a rigid template.

Architecture View Points

I previously showed in this blog this diagram of the different types of viewpoints I like to consider as a minimum in a design, and my HLD template covers these, however there are times this can be considered overkill.

HLD Viewpoints
Viewpoint Structures

We determine standard viewpoints in architecture to make sure the concerns of our stakeholders are addressed and communicated. For architecture to make sense, it has to provide value. There are cases where it may not make sense to create all the views shown above.

An Example – Transforming On Premise Services to the Cloud

For example, lets say we have a team that’s been supporting on premise versions of Exchange & SharePoint, and we are creating an architecture as part of a proposition to extend the scope of services they provide to include Office 365 cloud based solutions.

If we are going to consume office 365 as a cloud service it may not make sense to create technology views, given that the technology layer is by Microsoft. It doesn’t provide value to anyone for me to rehash Microsoft’s standard material in ArchiMate.

In the same way, if we are going to be reusing an existing team, with existing processes, it doesn’t make sense to redefine all the processes – we simply do the definition for the things we need to specifically provide. If creating a specific view doesn’t make sense, there’s probably no need to create it. There are cases when its not obvious to your audience why a view doesn’t make sense – and you can document that.

If it doesn’t make sense to do a technology view, you may want to mention the reasons why in the service realization view for example. Sometimes if you just miss something, it will lead to an unnecessary volley of questions that could have been avoided if you had just written a sentence.

We are telling stories

We are trying to tell a story to our stakeholders, and explain an often complex set of elements and their connections. We are also trying to address stakeholder concerns and provide consistent easy to understand architectures. We should structure information in a way that is easy to consume. Sometimes that means changing the way a standard template is, or building custom views to clearly indicate our subject to our stakeholders. I spoke about telling stories in a previous blog on Improving ArchiMate Modelling Quality.

Documenting what we need to

Last week I was designing a solution based on Microsoft Sentinel in Azure. The challenge here is in the way that solutions are built – I could go into great detail about how data sources connect into the analytics engine, how rules are created and processed, and how they trigger playbooks. This is all detailed at some length in various places in Microsoft, and to define everything doesn’t make much sense.

But I did have to define a basic skeleton of azure architecture at an application level, because without it, it wouldn’t be possible to understand my architecture at all in a connected way without experience on Sentinel – which I cannot assume my audience has.

Not missing the essentials

There are some things you always need for an architecture design to be complete – and forgive me if you have heard this before:

An architecture should define and show how it meets the concerns (or requirements) of different stakeholders, and identify and manage related risks.

Without that an architecture is not complete, and will raise problems and there will be consequences in the future. The same thing is true if you do not design to meet the needs of all your stakeholders.

I speak often about things such as the architecture aspects, and architecture principles, and security non functional requirements – the point of these things is always the same – to ensure that we have captured the needs of our stakeholders.

Summing it up

Anyone who focuses on just creating a document is missing the point of architecture practice – its not providing its full value if its only a documentation exercise – its the process of creating a design that mitigates risks and meets requirements that is really providing the benefit – documenting is a natural part of that process, but at the end of the day, personally I do not care how big an architecture is, as long as it provides value to its identified stakeholders. I previously wrote a blog 8 reasons not to leave architecture to the end of a project – which could have also been titled 8 reasons not to think of architecture as a documentation exercise. Architects need to understand our standards, and be able to maintain a balance between what is too much and what is too little. Above all, architects must think.

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.