Architecture Concerns

Architecture concerns are often misunderstood, partly because of the use of the word “concern”. This blog aims to provide some clarity around concerns and their use.

What is an architecture concern?

A stakeholder is a person who gets some kind of value from an architecture. A concern is something that a stakeholder wants.  This can be a request/requirement – such as a customer wanting an email service, or a service requiring  a database server, or it can be something more risk based – like customer being concerned with security. We tend to focus on the negative connotations of the word concern; in the Cambridge Dictionary Definition it has two meanings:

  1. To cause worry to someone
  2. To be important to someone or involve someone directly.

Definition 2. is the one that applies to architecture – the reason we talk about concerns is because that is the language used in ISO42010.

Putting it simple:

  • A requirement is a type of concern
  • A feature request is a type of concern
  • A worry is a type of concern
  • A risk is a type of managed concern.

What do you mean by a “risk is a type of managed concern”?

Concerns are addressed within architecture design. A risk happens when we formally accept a concern  that potentially has a negative impact on our goals and requirements.  

An example – Customer may have a requirement (one type of concern) which says they need administrative access to a server. 

If I have a goal to keep the servers secure and ensure their up time – as the architect I may have a concern that granting customer access to the server means that they can break something. My design needs to address the customer requirements and in this case we may have looked at the requirement and determined something that might be a risk. The concern should be taken to the stakeholders in the project (be it project managers/steering committee) and if it is formally accepted as a risk it is formally registered. However we still need to manage the concern.

What part does an Architect play in concerns management?

The architect role is key in concerns management. One of the reasons I speak so much about ISO 42010 is not only that its an internationally excepted way of describing architecture but it makes the relationship between concerns and architecture very clear – all concerns need to be framed within a view of architecture.

This may seem obvious but is sometimes missed – there are concerns – such as customer requirements and non functional security requirements (to name a few types). I’ve seen many cases where architects talk to different stakeholders, read the concerns then just build a technology based solution. The output a technical diagram; at that point they consider the work done.  When you take this approach without documenting how the technical diagram aligns with the concerns you are left with a few questions:

  • How do I know the technical solution meets all the customer and non functional requirements? / How do I know that all the concerns have been managed? Because if its not written down its easy to miss a requirement. Its possible to someone else is managing a concern also.
  • How do I know that we have correctly identified raised and managed all the correct risks from our concerns? Unless we look at each concern one by one ..

In the example above our concern over customer access turned into a risk but regardless of if it is a risk the process for the architect should still be the same because all concerns should be framed in a architecture view.

If a concern is easily met we can just state that – for example if a requirement if for high availability and we can say that “high availability is provided as part of standard design in our SharePoint Product” – that’s perfect. Having this stated it in your architecture design (or in an ArchiMate view) leaves no doubt that we have addressed things.

If we go back to our earlier example of admin access you could see there we had a problem – a conflict of interest that had to be resolved.  Normally that happens in one of several ways

  • Someone Accepts The Concern – A stakeholder should accept the concern – and who accepted it when should be documented in the design.
  • Someone Rejects the Concern – In which case this should also be documented in the same way
  • Something happens to mitigate the concern – This could be a change in the design – in which case you can document what the change is, and again why the change is needed and by whom/what.
Money!

Cost vs Benefit

Its important for an architect to manage and document the management of every concern one by one. Whilst this may seem laborious the reasons are simple – cost and risk. Consider this:

If an architect in a team of 5 project architects is working with 1 concern, its possible he may  be able to instantly say – yes its met by standard design or if its more complex he/she may spend a day validating the said requirement; to do that he may need to read or for example talk to 4 different people. in this case the time consumed may be:

  • 4 hrs reading
  • 4 hrs architect time in meetings
  • 4 hrs of another resources time
  • 1 hr documenting the work.

That’s 13 hrs of work on a single concern. If we manage it that way – then other resources that need to ensure the concerns are met can just look – lets say in our example a project manager is interested, a security manager, and another architect.  This would be another 3 hours if they read the documentation or 6 if they decided to talk to the architect directly – which they could do because they would know the architect managing the concern through looking at the design – in worse case though following the method it would be 19hrs of consumed time for the project to look at the concern.

Lets look at it from an unmanaged perspective. Project would not know who is looking after a concern and would actively have to check in over time. This means that just to check the status the project manager spends 6 hrs of time in a meeting (PM + Architect). If the security manager and another architect also needs to know whats happening we can end up spending  another 18 hrs of meeting time before even doing any work – then the meetings begin – a concern may be managed in one meeting – put into the meeting minutes then several months later on the same project the same question may come up… which is more meeting time. 

A single concern could end up costing hundreds of hours in project time.  multiply that out, and you will see that you end up with huge costs for very little result. Its a very inefficient way of doing things – where you should just have everyone referring back to a single design which clearly connects concerns to the solution.

Prioritizing concerns in a large project

There has to be a methodology behind prioritizing requirements/concerns in projects involving multiple teams. To do this, business takes priority over technology.  When multiple teams are involved a single architect has to coordinate the concerns – its not the job of a project manager to do this – project managers have to ensure the goals of the project are met, and to keep track of status but concerns have to be organised in a way that makes sense to architects, and managed in a fashion that plugs into architecture (reasons are given earlier). If project allocates out concerns then the chain of prioritization can be broken.

For example, on a large project we may have End User Services (EUS) being provided to a customer. the solutions architect pushes the customer concerns for EUS towards the end user services team. the end user services team will then look through those concerns, and some of them will be managed by themselves, and some will need to be allocated to teams behind them – for example, towards the platforms teams.  Its possible that end user services will have some of their own concerns that also need to be allocated towards their dependent teams. 

The concerns that EUS push towards the platforms team should be managed by the platforms team. If the platforms team cannot meet the concerns they should not just say “no”; they should be providing a solution & alternative. If we take this approach then all concerns are clearly managed and clearly owned, and driven from the direction of business towards technology – its important do do it in this direction because we need our architectures to be customer focused.

Having the basic discipline to manage concerns as mentioned above can save thousands of hours on a large project and can lead to much better control of risk and less cost and time overrun.

How do I express concerns?

I generally consider concerns to be a kind of requirement. Requirements can be captured in a number of different ways. I talk about them in various requirements related blogs – and have more blogs planned on this subject. When developing from scratch I often start with User Stories.

Summing it up…

Concerns management requires discipline and competent architects. Architects should have ownership of the management of concerns. The project managers still have a critical role to play in ensuring alignment to goals and schedules, the management of project status which includes having an overview of how concerns have been managed. The project manager doesn’t lead the management of concerns, but they do ensure that the correct parties are managing concerns and delivering results; if we think of this like a jigsaw puzzle, the project managers provide the pieces to the architects and make sure those pieces do not go missing, and may be letting everyone know just how much of our puzzle is complete, but the architect is putting the puzzle together.

Managing architecture concerns saves unnecessary meeting time, ensures that architects deliver good solutions rather than just good technology implementations. Quality goes up, and the changes of missing something, or having chaos in projects through misalignment or misunderstanding, and other cost overheads goes down.

To put it simply. If you are not managing your concerns you have a real risk that whatever solution is being provided to its stakeholders may not be fit for purpose.