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.

Business Continuity Planning (BCP)

Creating a Business Continuity Plan (BCP) requires thought and planning. This blog explores what a BCP is, a high level approach to defining a BCP and how it differs from a Disaster Recover Plan (DRP).

So What’s The Difference Between BCP And DRP?

The obvious answer is that BCP deals with business continuity and Disaster Recovery Plans (DRP) deal with the restoration of systems after a disaster.

Normally DRPs are far more focused on actual technology and steps, where as BCPs have to consider everything surrounding it. The Business Continuity Plan must look at risks to business and likely scenarios we need to manage, where as DRP’s normally are more specific; although they may also be scenario based. Typically the DRP is written by a technical specialist with experience and scope around what happens with specific technologies.

BCPs are important because they consider the needs of the business and not only the technology. Technical subjects, Such as daily backups have a business implication. Performing daily backups implies a Restore Point Objective (RPO) has been set to 24hrs which effectively means that at any point up to 24 hrs of data can be lost. Is that acceptable in a large company? Possibly not. It’s a business decision that sometimes is made by a technical resource with little thought for the fact that loosing a day of business could result in extremely high costs; If one person loses a working day of information the cost may be considered to be 8 hrs of work, but if 100 people lost 8 hrs of information, the cost could be 800 hours.

If you have ever been in the unfortunate position to lose a large system and have to recover from backup due to a series of extremely improbable events you will see some of these issues first hand – It can take months to restore things, causing all manner of financial penalties and chaos. BCP’s should be tested at least once a year – because business and technology change. Even if you only use public cloud services, you still need a BCP in place.

In a large systems failure a simple question can greatly reduced the cost to your business and customers – for example, “What order should we do restores in?”.

Operations might restore in an order that made sense to them, but that’s not necessarily the right order for the customer or the business. Its possible that key critical services & infrastructure for our customers can be grouped together and restored first to minimize impact to them.

The same question could be asked for a product team – in the event of a catastrophe – what do we really need to get things working as a bare minimum? Operations cannot know whats business critical by itself, the BCP guides them.

Customer vs Internal BCP

In an IT services operation its important to remember the customer and supplier are two different business entities. In pretty much every business model the customer doesn’t want to spend money – they want to receive value. As a provider, We want to provide value in the most efficient way we can so we can reduce risk, optimise our costs and improve our profit.

At the heart of a BCP we are managing risk to our business – and the customer must manage risk to theirs. In order to manage risk to business you need an understanding of the business strategy and goals,  A customers BCP is about managing risk to their business and not ours. Properly defining a BCP with a customer can be considered to be consultancy work which may involve connecting to their stakeholders, understanding and modelling their strategy, analysing their working practices, risks, and potential business impact. This requires a level of intimacy with the customer.

Similarly, a service provider does not want to expose customers to all the risks that they need to mitigate; they need to protect the business, and its a level of detail they do not normally need. Typically BCPs are classified as “Internal”, or “Confidential”.

For these reasons above, It’s essential that a service provider doesn’t mix these up.

How do I build a BCP?

People often just pick up a template and fill things in on it – which often gives unpredictable results and isn’t really covering the things that are critical to business. Consider a structured approach:

Risk Analysis (RA)

This is key to building a proper BCP. If we haven’t identified our risk, then how do we know a business continuity plan is providing value, and mitigating key risks to the business? I have seem businesses that have not gone through risk analysis at all, leading to some very high level scenarios, which have no value, because at that level, in an emergency, just making things up would work equally as well. There are formal mechanisms we can use such as SABSA, or if we modelled our business continuity scenarios and processes in BPMN, we could apply something like I suggested in my blog Risk Analyzing BPMN Models.

Thinking about your end to end delivery is a good starting point for doing BCP work and then drawing it as a process.

Requirements are also a good place to start; do not forget those come from all kinds of places – we have customer requirements & wishes, security non functional requirements and may also have goal related or other requirements from our business. Understanding priority requirements and looking at possible risks to meeting them can form a basis for a risk analysis.

Of course a skilled architect designing solutions and documenting them to an ISO 42010 standard would already be managing stakeholder concerns, and would be able to identify the key concerns easily.

Business Impact Analysis (BIA)

Once we identify risks we need to establish their cost to business.  There may already be guidelines around this; many people like to asses in terms of potential financial loss. In a well defined business there are normally a set of established metrics defined in architecture, and / or a policy around how we measure risk impact. Very basic values can be calculated with a set of assumptions – for example – if we have defined a risk that there will be a loss of customer data we could say the impact hits us in several ways: financial penalties, reputation, potential loss of customers.

If we think a risk will impact multiple customers – such as may happen if we lose a complete platform, you may wish to assess how many customers we might permanently lose, as the missing revenue may impact us in a long term.

 We could make a rough guess on the percentage of customers we might lose, but we could also look at previous examples of similar events – for example how many customers did we loose when we lost our servers during a previous outage? what did it cost? You can use such figures or percentages as a guideline when calculating potential impact.  Think about how you can use the figures you have at your disposal and use those to influence your assumptions. Once you have run through an impact analysis you may actually decide to re-.prioritize your requirements.

Writing the BCP

Once you have done the RA and BIA you have a good starting point to all the key areas you need to cover in a BCP. With or without a template, we have a good idea of the scenarios we need to cover in our BCP. A few things to note:

Normally I try to avoid repeating information I have in other places – i would rather refer to other documents. Doing that however means that you need to ensure the referred documents are accessible to the entire audience of your BCP.  The audience of a BCP is something that needs to be considered carefully. Of course, you have all the security related people but that is the tip of the iceberg. All the players in our BCP process need to be aware of their part in it and need to agree to their part in it.  The owner of the BCP must ensure access to the BCP and all related resources for its audience. At this point we can take a document template and start to build a document that really brings value.

There is another school of thought on where to keep information – when I discussed it with some members of my employers security team, they preferred to copy and paste key material into the BCP template. The value that has is that all the information you have is in a single location – the disadvantage is its another place to maintain which can easily become outdated. 

In some previous jobs I have had to also maintain a print copy in a physical safe. Of course we are supposed to regularly test this so its arguable that the document will be kept up to date… you decide.

I eluded to the fact that there can be a hierarchy of BCP’s; depending on the structure of the business; and there can also be dependencies on disaster recovery plans and on teams and people – its important that as part of the disaster recovery planning excercise you ensure the availability of all of the things you depend on – be it resources, systems, documentation.

Bear in mind that if your services rely on other teams, or other companies they could well be an integral part of your BCP and its important to establish a proper interface and expectation. This becomes a lot easier if you have defined your process using a notation such as BPMN as i mentioned earlier.

Discipline & Testing

Testing should be regularly done – at least one a year – and documented. If its not documented it never happened. Things change.

Losing The Value Of BCP

If its not tested, it loses its value. If its not communicated, it loses its value. if its done as a copy+paste exercise without walking through your processes and thinking though its goals and your business… it loses value.

Like many things in Architecture the value in a BCP is not in the result, but more in the process you take to reach it. Without the risk analysis or an idea on how your business actually works the value is greatly diminished. The question isn’t actually – “Do I have a BCP Document?” the question is “Do I understand the key areas of risk in my business and do i have a solid plan defined and communicated for if something catastrophic happens?”

Should I Be Doing A BCP?

Business Continuity Plans are Rarely a singular document. In a large corporation some scenarios are taken care of at corporate level and then the different levels of the corporation should  have their own – individual service areas, and in the case of Tieto, individual Products/services.

At a corporate level a BCP will usually cover things such as Loss Of Life, and how we should handle things like the media in a catastrophe. Bear in mind also we may rely on other BCPs and should document if its the case.

I’ve heard from product managers sometimes in different service organizations that they shouldn’t be responsible for BCPs – its a customer thing. The reality is, if you have a business that you value, you need to be able to protect it, which is why the BCP exists. There may be exceptions but at the end of the day product teams and operations are running parts of the business too – often together – We should not forget the architecture side of this – we are defining a solution that needs to cover our aspects – That looks at risk relating to  People, Processes & Roles, Tools & Technology, Organization, and Information.  Product managers have P&L responsibilities – so naturally the continuation of business should be of interest to both.

Summing it up

If you have a business, how important is it to you that it continues? If its important at all, then why not spend a little bit of time protecting it, and rather than blindly running through a paper exercise, really think about what you need to do to protect it. Maybe take in some key resources to work together and take a structured approach. It may be that your BCP exercise yields unexpected results, and improvements to your architectures.

Understanding Architecture Value

Value is a key focus area of architecture which is often misunderstood. This blog explores this subject..

Value & Professionalism

It has sometimes amazed me how far architecture can be devalued in an organisation. As an Enterprise Architect, I have not only had to show the value to different business stakeholders, but on occasion I have even had to explain it to architects. The reality is, there are a lot of misconceptions around what architecture is and what architects should do. I started to explore expectations in my blog “What is an IT Architect?” because I wanted to get consistent value from my architects.

Getting our stakeholders to understand value can be a hard nut to crack,. They often have their own ideas of what architecture is which normally revolve around technology. I have found the differentiation between a technical specialist and an architect can sometimes be blurry in the minds of our stakeholders. Communication of the different aspects of architecture in a language that stakeholders can understand is essential.

As architects, It’s very important that we work to ensure we are not perceived to be a painful function by our stakeholders. This happens if architects go from meeting to meeting just criticizing other peoples work. It starts with a mindset.

Stakeholders need to understand that, as architects, we are working with solutions and not problems; we must be encouraging by nature and we must take time to express things in terms of positives and growth where possible. We want to be working with our stakeholders rather than against them. Our role is normally to advise – at the end of the day architects do not usually own the business. If we ask rather than tell, engaging our stakeholders with a positive attitude, we can show our value as architects, the value of architecture, and our stakeholders can become the architecture marketing department.

Showing value enables an Enterprise Architect’s stakeholders to look good. This helps us gain stakeholder commitment and makes life easier for everyone at the same time.

For me personally, the best moments come when someone who is not an architect stands up in front of an organization, shows some of the things that we have done together and passionately shows the value that has come through a project, attributing it to architecture not because they have to, but because they genuinely see the benefits, and want everyone else to.

The Reason I Started To Internally Blog

One of the reasons I started internally blogging in my company was that I could not get enough face to face time with stakeholders to express architecture value. I had to show them value by influencing the people around them.

When management has multiple escalations and start to breach service level agreements, they will often start to search for a root cause. Not having architecture is akin to not planning and not managing risk.

In those cases, where poor planning leads to a risk being realised we do not scream “I told you so”. It’s an opportunity to show how as professionals we can help. In those situations normally people are under a lot of pressure.

There are are a lot of techniques we can apply to help identify issues, and when we have a model repository in place, with a competent architecture team we can not only help with solving architecture issues as they are unfolding but we can also put in the steps to ensure those problems don’t happen again. Having a good architecture concerns management process helps with that.

Planning Work

In order to get a baseline of consistency and understanding the blogging helps a lot. Normally I have meetings where I explain things, as we tackle practical problems but if in a meeting i am introducing a lot of key concepts its easy to overwhelm people with the technical side of architecture.

As an example the first time I introduced mechanisms for work planning with ArchiMate. At the backbone, even though i simplified it, still some people didn’t quite follow. The Planning Work With Archimate blog helped. It gave people a reference they can follow at their own pace. It helped me because I can set a consistent expectation.

I think its the most popular blog I have at the time of writing this blog; its been re-blogged and shared a few times, and received a few comments, which is fantastic.

I think the reason for its success is a lot to do with the fact it has clear value. It offers an easy way to use the ArchiMate modelling language to track and define work; which can be challenging – especially if your architects do not have direct line reporting to you.

Capturing the value from stakeholders

To begin with, I think its a mark of any professional that they think about value regardless of what is being done.. It’s a general life idea – if you think about who you are doing things for, why you are trying and try to anticipate needs, the chances are, your resultant work will be better.

Normally at the beginning of a project I am establishing requirements; I sit down with the team and create a series of user stories.

To my mind if you are having trouble defining fully formed user stories for your work, the chances are you need to talk someone and get a little help in understanding the needs of the stakeholders. Most commonly when I see user stories go wrong its because people have missed the bit at the end that speaks of value. It’s interesting to see how often people cannot directly express the value in the things they do; its common to think because value is implied it doesn’t have to be explicitly defined. The problem there is what is an obvious value for one person is not always obvious for another.

In architecture ISO 42010 they give a good ground list for types of stakeholder to consider in our architectures.

Understanding and taking time to explicitly define the needs of our stakeholders is the first step to building an architecture that maximizes the usage of the architecture and its value to all stakeholders.  When we validate an architecture that we have created with a user story we are validating the creation of value.

Why Doesn’t Architecture Always Bring Value?

Not correctly practicing architecture leads to not getting value from it. If an architect starts the architecture work after a project, or views the creation of architecture as a documentation exercise, its normally lost most of its value.  If an architect only concerns him/herself with producing a couple of technical diagrams, again, its lost a lot of value.

Much of the value in architecture is in its application and the process taken to define it. How we decide what appears in the documentation, all the decisions made around the architecture, as well as the needs of all the stakeholders should be managed & documented as a project progresses for architecture to achieve its intrinsic value. 

A Common Problem With Commitment

Because stakeholders don’t always understand what architecture is or how its practiced, it simply isn’t practiced in some cases.

We can have a good group of people that want to do architecture but are not given time. In management terms, architecture is often measured in documents, because these are tangible:

Its easy to see architecture as a documentation exercise if you are working with processes that demand specific types of deliverable, because the emphasis is on the resultant documents. If you write a description of a service it makes sense to plan the service, consider risks, agree the service, and capture the reasons for it. You have to give architects time to plan and think. That thinking time should be spent properly – preferably following some kind of methodology where the thought process is documented.

Even with a management commitment of 70% of an architect’s time allocated to be spent doing architecture, there can still be a fundamental gap if our stakeholders do not understand that architecture process is much more important than these documents.

If architects spend a majority of their time just filling in documents for management, technical writing or building presentations, they will not have time to actually follow methodology and design. Every view an architect does is to manage a concern from a specific stakeholder – therefore you can say every view that is not completed represents a risk that a stakeholder hasn’t been fully considered. Time must be given to do baseline architecture and analysis. It improves the quality of the resultant work and more importantly it ensures not only architects provide value, but their designs do.

A good architecture designed by a proficient architect meets the needs of its stakeholders and shows how it does that – it identifies and mitigates risk. On the flip side, a document that is put together without architecture design is likely to lack good quality. In these cases you will normally see failures in operations – either lower productivity where things are not efficient – or in complete failure of process leading to penalties.

Value In Architecture Modelling

I’ve heard it said a few times that architecture is about drawing boxes; even from some architects. It’s not. 

First the obvious. The tools we use are modelling tools not drawing tools. Most people see an ArchiMate diagram in a presentation and miss the true power behind it – because our views all contribute towards a fully relational model we can easily traverse the model using our tools, and more importantly can use it to easily help management understand the impact of change – at the simple level architects can navigate the model – like shown here – for PRTG Network Monitor:

We can expand out those nodes and see all the relationships, to other elements, and then drill down through those.  We can reuse the elements int he model in different ways and generate views. The more information we put into the models, the more value we get out. Each of the elements and relationships can have its own documentation. Seeing a picture sent in mail is nothing like having the interactive model implemented and available to traverse.

The act of modelling with a proficient modeler building a standard view – nearly always raises questions on how things work, and which things should be connected to other things; these questions open up areas that can easily be forgotten, and its better for the architect to think things through in design phase with stakeholders, than to blindly move onto executing a project. The costs can be very high if part way through a project you need to scrap everything an start again, and architecture can help prevent such things happening.

In addition to all of this we can apply metadata to an architecture model – making it possible to represent a myriad of different interests to our stakeholders, if we take time to model, and use the right information sources; and then use our models to inform and enable our business leaders.

Summing Up The Value Of Modelling

I will sum up some of the value of modelling architecture:

  • Consistent communication – everyone get the same views in a repository and common understanding; there’s a reduction in communication overhead.
  • Enabling Scaling – having consistent communication in a common place makes it easier for us to on board new resources, and for many architects to work together in the enterprise.
  • Reduced time to find things – Navigating through a model from element to element enables us to easily find related information quickly.
  • Can abstract many views from the same model. As you develop some views with relationships, you enable automatic generation of other views reusing the same information
  • Reduction of work – If you rename an element in one view it renames it in all views – in the same way the element documentation is automatically reused.
  • Cost savings – having architecture modeled gives us opportunities to easily see and optimize architecture, as well as to identify risk.
  • Better more reusable architecture – modelling forces us to break down complex tasks into reusable components.
  • Reduced complexity – in a model we can focus on only parts of it in different views to make it easier to consume to different stakeholders.
  • A model develops itself – as it starts to mature using algorithms we can find new relationships rather than have to explicitly state them.
  • Better understanding – at the same time as we establish new components, it normally raises new questions around how things fit together and forces us to think. We can also very precisely and easily model and understand the impact changes in the technology, organization or other architecture layers have on our architecture.

The value of ArchiMate

The Archimate full model shows the different layers that make up ArchiMate. Each layer contains different types of elements in the modelling language – for example we have Business Layer business services, Business functions, business processes. 

The ArchiMate language specifies the different types of elements and the ways that they are allowed to connect. You can see that ArchiMate covers everything from the why (motivation layer), to the what (Strategy, Business, Application, Technology, Physical & Implementation). This enables us to represent how all of these things work in conjunction with each other. 

Following the strict rules of the ArchiMate language forces us to think a certain way – to consider our internal working components and how ex expose them out in different layers. It also has the added benefit of enabling us to derive relationships. A simple example – Owen is related to Max, and Max is related to Christopher – and we could represent this on a model with the association relationships. Even if we do not explicitly say it; because we know these relationships exist the modelling software knows that Owen is related to Christopher. More complex derivations exist – which means that as we mature a model,, it starts to provide value beyond what we directly model.

Summing Up The Value Of Archimate

To sum up the value of ArchiMate:

  • Internationally known standard – each element and relationship has a very specific meaning. using this standard i can take a model from a completely different company and understand its meaning.
  • Multiple layers – breaking down into layers such as Business, Application, and technology, enables us to align to many standard methodologies such as TOGAF, and to easily differentiatiate these different concepts.
  • Better architecture structure – Because ArchiMate has strict rules on what can connect to what, and how elements are used it forces us to think in a more service oriented value driven way.
  • Better connected architecture – Essentially with all the layers together we can answer the questions what, why, when, how, who? The layered approach make it very flexible.
  • Better intimacy with stakeholders – Because we define viewpoints for each of the stakeholders we can provide better value for them and get 
  • Aligns to ISO 42010. Archimate as a language was designed to complement ISO 42010 and make it easier to conform to this standard. ISO42010 introduces concepts of elements and relationships – Archimate creates different types of these elements and relationships, that reduces the amount of work we need to describe concepts.

The Value Of ISO 42010

I speak about ISO 42010 quite often because it lays down the things you need for an architecture to be completely documented.

Everything in ISO 42010 has a purpose and everything that we do not do in there could be represented as a risk.

Its great we do Visio diagrams  with infra and we cover some technology, but for these Visio views to be valid we need to understand the decisions that are made related to them. We need to understand the concerns that different people who need the systems we design have, which includes things like risk. We need to understand how it is that the Visio diagrams produced meet the needs of different people. ISO 42010 lays down a structure that could be used for this.

When you run through an architecture and ask how each individual requirement is being met by the architecture you provide, questions and concerns start to arise. Its better for a single architect or a team of architects to sit down and address them and actually think through the design process, than it is for a project team to start booking lots of meetings with different people.  understanding the needs (concerns) of our stakeholders forms the foundation for formal risk analysis – because the risk is basically recognizing where a need might not be met for some reason. Using a managed approach to architecture concerns provides significantly better coverage of your risks.

When we enter projects there’s often a lot of people asking the same questions – who is doing what, how and where? how will the requirements be managed or realized. Its not supposed to be a project managers role to make those decisions – its supposed to come though someone smart sitting down and creating an architecture design.

Applying Discipline to Architecture

Applying discipline to architecture raises many hard to answer questions that need to be managed. If they aren’t captured and answered at design time they will come up later at some point during an escalation. If you don’t apply a method to your architecture, and do it throughout a project things will get missed resulting in project overheads, delays, and costs in both penalties and incidents.

Applying discipline helps us effectively manage change, and it helps to ensure that issues that may cause problems come up sooner rather than later. 

The alternative to this approach of following methodology is to be surprised – this is characterized for example, by getting part way into a project and realizing the active directory you had build needs to be rebuilt – or discovering that one part of the service you provide will just never work with another part, forcing you to look for some kind of bad designed compromise to meet deadlines.

ISO 42010 essentially gives us an international standard on what an architecture description should include – it enables us to build traceable architectures that meet the needs of our stakeholders, and it does so in a very scaleable way, It enables a consistency of understanding and expectation when transferring architecture from point to point. 

Explicit Value In Motivation Modelling

Up until this point its worth noting that most of the value i have spoken about is relating in generic terms to the benefits given, but of course ArchiMate and some other modelling methodologies allow us to represent values within the architecture going well beyond the generic.  ArchiMate has the motivational layer which is there to show the reason why we do things, and has an actual value element – and of course we can easily derive value normally by just looking at our goals, and outcomes.  Take a look at the example:

The example is a motivation view for an architecture concern. As part of our common practice we might connect values to our goals directly in the model. When you follow the flow of the motivation view above from top to bottom – the values become obvious at the point we get to the goal element – so we model them too.

All architecture should provide value, and in this case we explicitly define it for this requirement (Reduced Capital Expenditure, Reduced Maintenance Cost, Modern Future proof solution).

An implementation & migration viewpoint is focused on how we deliver and meet requirements, and not its value – which is one of the key reasons I also state in addition to implementation and migration, motivational modelling is also a good idea. Of course because this is part of a model we are presented with a powerful mechanism for prioritization workloads – when our management wants to run initiatives to reduce costs for example – we could easily auto generate a viewpoint to show which of our work packages contribute to that, and then we can take a discussion with those stakeholders about re-prioritizing workload in a structured fashion and understand how our other values and goals are effected in doing so.

Summing it up…

Architecture and design before doing things are an essential mechanism for avoiding risk and cost. Architecture is a discipline, and unless you take time to do things before during and after a project you never realize its value. Architects must think and be trained; and they must be given time to run through a design process that applies methodology in order to get the value. If we do this, we will literally save millions of euros in penalties, and will have better more focused projects with a significantly higher success rate. Communication overheads will reduce and better communication will be enabled.

To those who think architecture is only drawing pictures – I would say you do not understand what an architect is, or what an architect does, and would recommend you read ISO 42010; For each part of an architecture design ask the question  “does that provide value, and what is the risk if I do not do that?”

To those that leave architecture to the end of a project, I would say, you’ve lost most of the value architecture could have given you already – because you didn’t see the risks coming fully, may have missed some requirements and you likely had a communication overhead. There’s still some value in doing it so others may follow what you went through and why, and of course anything that adds to an architecture model is a good thing. 

Architecture discipline brings architecture value. I would love to hear from you.