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.

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.

Agile or die…

When I posted my previous blog on Aligning ArchiMate to BPMN one of the comments I received read “Agile or die, this is the only fact of today business environment” – and this got me to thinking about Agility in EA.

To be honest, lets start by saying I agree with the comment – and that he gave me no reason to believe the person who posted the comment was misunderstanding anything I said.

But there are those who do…. There’s a stigma sometimes attached to Enterprise Architecture, and architecture as a whole. It’s sometimes seen as slow, synonymous to waterfall, unable to change, and an overhead in general. I will talk about the value of architecture in a separate blog, but suffice to say, architecture doesn’t have to be that way.

Agility in TOGAF

Its fair to say that TOGAF appears to be, or can be fairly document heavy depending on the choices you make in implementing it. A first point to make about TOGAF would be it is a framework that is intended to be tailored to specific needs, and does fit in well with a waterfall development technique; That said it can also provide a good backbone for something more agile.

Everything TOGAF asks for in terms of deliverables within the framework has its purpose. If you take any of those things away you leave a gap or a risk. It’s a comprehensive framework built by many smart people. As a framework it addresses many concerns from different stakeholders.

To be practical you need to think about how to adjust TOGAF. I have sat in a few meetings where we have discussed those different architecture deliverable’s and how we could adapt a Scaled Agile Framework (SAFe) model to work along side TOGAF, giving the strength of TOGAF and the agility of SAFe. It is possible to do so but it requires careful planning & implementation of processes. Processes that are well defined, with good key performance indicators can be very agile.

Architecture Discipline

I firmly believe that good architecture is a key to success in agile ways of working. Agile doesn’t mean we do not do architecture, but it may mean that we do it differently.

If you look at my blog Planning Work With ArchiMate you will see that its possible to use the ArchiMate language to define small building blocks, and then fit them together – each block expressing its own value and interfaces to the world. Although when we use methodologies like SAFe we need to consider the value of each individual work package, we also need to take a longer term strategic perspective. The approach I took in that blog facilitates agile projects as well as waterfall ones.

Change is a constant and enterprise architecture needs to facilitate it; which is another reason why languages such as ArchiMate and BPMN working together in an architecture repository support this.

I will speak at some point about ISO 42010 (I have a video blog planned), the standard for architecture design; how it fits in nicely with ArchiMate as a standard, and how it enables us to design architecture that supports our goals in a focused fashion. Such standards are essential if you are practicing architecture on a large scale. Each piece on a chess board has its purpose, and rules it must follow – each move must be part of a strategy.

It’s a matter of balance. We only want to do enough architecture to provide value; ISO 42010 provides the groundwork for this – when it describes views and view points – and the ArchiMate Language implements those concepts nicely. It takes skilled leadership with skilled architects in order to get this balance right in practice.

It’s essential we have an architecture strategy, and a good set of architecture practices to facilitate an agile way of working. You can’t be agile unless everyone knows what they are doing, how they are doing it and when they are doing it. Knowing why they are doing it can also be helpful. If you don’t have an architecture discipline then in fact architecture can become significantly less agile. To be agile we need competency and discipline; and we need to have an architecture practice, practice practice…. This doesn’t mean the solution is to do more architecture – more it means that we need to do the right architecture.

Summing it up…

Implementing without architecture design exposes all kinds of risks; it may seem that you implement projects faster, but then what you save in project development time, hits you when you get to an operational phase.

If architecture is not facilitating an agile way of working, then that architecture practice probably has a need to change, not to be abandoned. It’s important to have talented architects to lead us and define process that adapts to change. We need to consider process development and architecture with an agile mindset and should be considering how we can deliver continuous value over time as well as how we can do that efficiently. We need to build a layer of motivation architecture that hooks into our Implementation architecture.

To the guy that said “Agile or die, this is the only fact of today business environment”… I couldn’t agree with you more; but I would like to add trying to adapt to change without clear architecture, leaves you at the mercy of the skills and communication of the individuals, and the bigger an organisation you are, the more risky that becomes. So think of it this way:

Agile Architecture or die.