Requirements Realization Views

One of the most essential but often overlooked views to have on architecture is requirements realization. This blog explores this subject and one way we can work with them.

I show one way of working with Requirements Realization Views – Its not the only way. Doing this can save huge amounts of time and money by avoiding a need to redo things.

If you have read ISO 42010 the International standard for architecture description, you will know that every architecture view is intended to frame the concerns of its stakeholders.

Architecture isn’t about drawing pictures. Whist defining a view of technology is important, it is more important is understanding the reason why. We learn this in math class as children. The answer to a math question gives you points, but you also get points for showing work.

The Requirements realization view is one way to show how a solution meets the needs of its stakeholders.

I show below some example views and one way of working that can be used with BiZZdesign’s Enterprise Studio. Its the tool I use most often, so I leverage some of its benefits in my workflow. All the things I show can be done with other tools, some tools make this easier than others.

An Example View

Figure 1 – Requirements Realization View

The example above is a basic requirements realization view. Its at a high level – its showing that a product is meeting several requirements. The level of detail we go to depends very much on the benefit it would provide. The view in figure 1 – may serve as a good introduction to anyone wishing to understand the design from the Web Hosting Product. For the purposes of a high level introduction to business stakeholders that might be enough, but how do we know what is above is true?

The next level of detail

Each of the requirements in figure 1 is obviously a collection of other requirements – I might define them in architect, or I might just reference another source. For example – business unit requirements may exist and be managed in a system like Confluence. This might be a more accessible place for stakeholders to manage them if we do not want to go though the trouble of teaching everyone ArchiMate.

The next level of detail in ArchiMate

Personally, I do not always ask for everyone to go to the next level of detail in ArchiMate, because in a complex project with many moving parts it doesn’t always make sense, especially when you have different architects at different levels of maturity, especially when you have several thousands of requirements in a project

That said, there are advantages to mapping your requirements in Archimate. I know one or two architects that do it.

Using Enterprise Studio

Here tools can set you apart. Importing requirements from excel into an architecture model can be fairly easy in some tools. I am using BiZZdesigns Enterprise Studio (BES). – which makes it easy to import and update requirements if I create them using New > Multiple – I can then copy and paste in from excel. I could have done this other ways too and its probably worth the time taken to do that.. You end up with a lot of requirements on a view like this:

Figure 2 – Requirements

You might think in this case that this isn’t very helpful – its just a bunch of numbers – but what i did was import the requirement ID’s as names and I put the actual descriptions in the description or documentation field. In this way when I have many requirements I can make them smaller and more manageable on screen.

To actually see detail of each requirement I can switch on tooltips – so the documentation pops up when I mouse-over the requirement, or I can use labels.

Figure 3 – A requirement labelled.

So why bother?

Once I have the requirements on my canvas i can group them together – to organised them in different ways for different stakeholders. Something like in figure 4:

Figure 4 – Grouping Requirements

When I have done the above in big projects I have sometimes identified requirements that are not managed at all. In the example above you can easily see uncategorized requirements. They are not connected to anything and can easily be forgotten. Just by itself it makes the pain of the exercise worth while. I can also at this point prioritize them and then I normally take these requirements and connect them into a series of implementation and migration views.

Every requirement needs to be realized some how. I can pretty easily either script, or create a property table in Enterprise Studio to see requirements that are not realizing things as an extra level of validation. If we have mapped our requirements into groups, and created views for each group, then we should easily be able to see things that are not realized anyway. Back in figure 4 we did our mapping, and as a result of the mapping for example we may have decided to have 5 realization views:

  • Customer Requirements Realization View
  • Architecture NFR Realization View
  • Security NFR Realization View
  • Business Unit Requirements Realization View
  • Orphaned Requirements Realization View

Mapping Requirements to the Realization

Now with the prep work completed we get to the important part. Our Customer Requirements Realization View might look like something in figure 5.

Figure 5 – Customer Requirements Realization

Lets look closer at figure 5.

The standard web hosting solution

I make use of the grouping element in ArchiMate to represent architecture building blocks. Its enables me to keep things neat – I could have course have hidden this level of detail in another view & just connected in the Web Hosting Product. In this case I felt the services create value. I do not need the detail to know exactly which servers are being used but I can tell that this will be an Azure hosted solution, running on Linux. If you read my blog on services, you should at this point start to see the value of hiding architecture behind the externally facing services.

Standard Services Contract

Some requirements are covered by our standard products and some by our standard agreements. To use the ISO 42010 language again – Its important to see that concerns are all framed within one or more viewpoints. This means even if its obvious to us that something is covered in the standard contract we should state it. What is obvious to me is not necessarily obvious to a coworker.

Customer CRM

Of course I could put as much or as little detail as I need into this view. I am telling a story, which I talk about in my Improving Archimate Modelling Blog. The important thing to remember is that all requirements need to be realized in a view, but again not always the same view. Because we are telling a story we need to be consistent with the level of detail.

Locking Down Requirements

Before starting requirements realization its important to have requirements management under control. Its a separate subject, but you need to ensure that requirements are not significantly changing during a project, or the workload significantly increases.Going through the process of redrafting your realization view will provide benefit and avoid confusion.

Some Common Challenges

I have sometimes seen requirements realization being missed as a step. Sometimes people just create a technical solution, and say “yes” that meets the requirements after a first read through, Then later they realize it doesn’t because they didn’t look to this level of detail and are forced to go through a very expensive exercise of fixing things.

I have also seen things mess up because requirements management is seen as being a project managers job. Yes, those guys are responsible to ensure requirements are met, but not how they are met. I see the job of organizing requirements in a way that makes sense to the solution as being an essential part of an architects job. If you look at the TOGAF ADM for example you will see requirements management at the heart of everything..Its partly a separate conversation but I would also encourage architects to work with project managers to organize requirements in a way that makes sense, because it makes requirements realization a lot easier and reduces risk,

Another common issue if focusing too much on customer requirements. Its really common for organizations to have a customer first approach – but this doesn’t mean we should not consider our own needs. Business requirements are important, as are the architecture and security ones for example. If we do not consider them, issues will occur later – because they are there to mitigate risk. Some non functional requirements will relate to documentation and I can easily create a view for architecture deliverable requirements realization. In projects architects should ensure time is given to manage non customer requirements.

Summing It Up

I cannot stress the importance of doing requirements realization. In this article i focused mostly on doing requirements realization in ArchiMate, but we can actually do it in other ways. I wrote about the challenges of Designing Architecture Through Document Templates before – I personally try to avoid that for the reasons I state in that blog.

Requirements show us “what” needs to be done by “who”, and “when”. Requirements Realization shows us “how”. This is a message I think all architects should take to heart and communicate out to other stakeholders.

Yes, running through thousands of requirements can be boring but taking the time to properly manage and realize them can result in very high quality work. Requirements Realization can be cool.

Documenting An Architecture Model

There are many considerations to make when documenting an architecture model. This blog speaks of some things to think about when documenting elements and relationships.

When I am speaking about documentation I am primarily talking about the documentation fields that are available with different modelling tools for documenting elements and relationships.

On Monday I posted about designing architecture through document templates. Keeping on a theme of documenting things, I wanted to talk about some of the things to consider when documenting within a model. Although I primarily talk about Archimate here, similar considerations must be taken when documenting any kind of relational model.

Elements & Relationships

ISO 42010 talks a lot about elements and relationships, and as I have said before, Archimate extends the concept.  The image above shows two business objects connected by a relationship.  The shapes in ArchiMate are elements – the connecting lines or arrows between them are relationships. 

We have said before that our modelling tools are creating architecture models and not pictures and that is important to understand when it comes to documenting elements. Each element is a building block that may be in many different  views which means when we document an element the focus of the documentation is the element itself and not its connection to other objects. Consider the diagram below:

Part of a very simple Service Realization View

We have an application component MySQL. Within this view we could document the element by saying:

MySQL provides back end services for our Apache application.”

In a word document that would be perfectly fine. In a model this would be bad practice for a few reasons – I have some points to make here:

  • Firstly, If we were to use the MySQL element in another view, such as a realization view for a PHP application service, although the statement above would still be true in the first view it would not be contextually relevant to the PHP realization view. 
  • Secondly – We have already expressed the documentation in a relationship on the view – the arrow between MySQL and Apache – It says MySQL serves Apache.  This relationship documentation would actually be a better place to put our documentation text although, as we said, its not needed.
  • Thirdly – If we find it relevant, to telling the story of the entire picture, we can actually place the documentation as part of the view – although it would be better for the view documentation to provide an overview of what the whole picture is about for the audience, rather than focusing on the minutia that is in each and every documentation element. We can also document each individual folder in a model, as well as applying documentation to the model package itself.

Deciding when you need more elements.

If you consider the example with MySQL again, we could provide a description of what MySQL is such as:

MySQL Server is a relational database management system developed by MySQL AB. As a database server, it is a software product with the primary function of storing and retrieving data as requested by other software applications.

…this is pretty good text because it explains what the element is and it could be reused across multiple views – however there’s another thing to consider. The relationship between MySQL AB and MySQL.  When writing something like that I ask myself is there any value in separating the vendor from the application component. I would say yes, its handy from a vendor management perspective – so on the view I showed above you can clearly see the vendor, and it only takes a few seconds for me to generate a view which would show all the applications that Microsoft are related to.

I would probably allow the definition above to be used in many cases – because even though it talks of the relationship between MySQL and MySQL AB, I think its OK because that relationship between product and vendor is very unlikely to change. If we were talking about a relationship that was more dynamic in nature I would probably redraft the definition.

How much should we document?

I would consider documenting all elements, and most relationships when fully modelling something, as well as documenting the view as well, to tell the story of the view and a little of the views intentions to its stakeholders.  The thing to remember here is not everyone knows what you do and what is obvious to you may not always be obvious to all readers of your view, or why relationships exist.  A colleague of mine who works with architecture in the defense industry was telling me he asks that all elements and relationships are documented as a rule of thumb for exactly that reason.

Its important that we get our balance right – we do not document for the sake of it but the view is providing the audience a story and all the elements and relationships within it form part of that story (I talk about this a little in my blog Improving Archimate Model Quality). Because Archimate provides some correspondence itself I will normally read out all the relationships on a model to myself. For example – “Owen is assigned to the role of Enterprise Architect”. I then ask myself does that say enough. Do I need to tell the audience why? If the answer is no, then I probably will not put any documentation in that relationship – because the relationship type (assignment) says enough by itself.

Asking For Help

I like to peer review views that I create, and get another architect to tell me the story of what my view says – a fully documented view I will also ask questions on just to see if its intuitive enough to enable the architect to answer.

Within my architecture domain I encourage all my architects to spar this with me, and in some cases i will give a view to a non architect too, just to see if they can figure things out.

Effective communication is key – if you are finding it hard to find the balance, sharing in a peer review can be a good way forward.

Improving ArchiMate Model Quality

I get models and diagrams presented to me in many different forms and levels of quality. In this blog I want to look at talk at improving ArchiMate Model Quality by telling a story with your Archimate views, and covering some other basics.

Telling A Story

When I produce a new diagram I will tell a story with it – I will walk through the diagram and try to put it in a number of sentences, and I will think about the value that the view is trying to express to its stakeholders. I will show a fictional example of a motivational view that looks similar to what a junior architect may produce:

Figure 1. A diagram produced in a training

What it effectively says:

“We have a requirement for data protection, identity management, and ease of access. We are driven by a need for security services for Microsoft cloud. This has a positive effect on our goal to have end user identity and access.”

It doesn’t really tell me much – I had to look at the documentation for the elements hoping in particular to find if the requirements had rationales, and impacts defined. I was a little lost to what the author had to say.  I normally start by looking at the drivers. Security service for Microsoft cloud didn’t make sense, as it is not a reason to do something. In strict terms I would question the value of this view. If I didn’t actually know a little of the subject matter may be really confused. 

Finding Some Value In Confusing ArchiMate Views

The diagram above was easy to put into story because of its layout – it was easy to follow the flow of the thinking because the arrows went in a single direction from point to point, even though the actual story was a little confusing from an strict ArchiMate perspective. In some cases where relationships flow in many directions its hard to tell the story. As a disciplined architect its easy to get a little confused when you get a diagram of the quality i have shown – because its arguable that those requirements should be goals, etc…  The usage of the elements is wrong. To get clarity we need to forget the strict definition of the elements a little. If you look at it below, a non-architect may actually find this easier to understand.

Figure 2

I could have taken the influencing relationships off the diagram; and start to think about reworking it. Sometimes when I get models from less experienced architects in my head I am doing exactly as above – trying to understand the thought behind the structure – it normally helps me get some kind of value. I of course do the same thing with the relationships as with the blocks. I am abstracting away from the modelling language So the diagrams above provide some value but not much – if we had strictly understood the usage of each element type and each relationship the diagram would look significantly different – and would fit into a larger architecture in a way that makes sense.

It wouldn’t make sense to reuse the elements in this because they are ambiguous and incorrectly typed – so the value to the overall architecture is greatly diminished – although we cannot make things better unless we have a starting point – and I would be positive towards the architect because this is a starting point for improvement and we can now start a discussion around the things that either the architect or the stakeholders find important.

Looking at a better view

With motivational layer diagrams I normally start by looking for the drivers – the reason why, add a few assessments – and work from there.

Lets look at another view:

Figure 3

CWAD Is Consumer Workspace Architecture Domain – a team I used to run. The story this tells:

A CWAD architect, domain lead, product manager  and service delivery manager are assigned to do CWAD road mapping. this project will deliver a product level road map, concern and motivation views, and work package implementation and migration views. This project needs to ensure that each service work package is mapped onto a product level road map, is properly scoped, and that rational and related concerns are clearly identified;this will all give us improved trace-ability into CWAD workloads.

The story was easy to tell for a few reasons.

  • the arrows clearly go down the page and flow the same way
  • The different layers (business, implementation and motivation) are clearly grouped together
  • The elements are well named and typed.
  • The author is clearly telling a story in the views design – including everything that the reader needs to understand the scope of a project.

When I am trying to read a view in general I start with the business layer, or strategy layer and then work down following the arrows.  Within each of the layers I look for the external elements and work inwards – so I will look for external behavior elements (services) and other external active structures (such as interfaces) – and will work from there. A good diagram will highlight those elements.  In the diagram above its easy to see because the business layer active elements are at top – and flow downwards towards the other elements.

Ordering Elements

When creating diagrams I try to follow the order of things in the ArchiMate core model – if i have strategy elements they are on top – the Business, Application, Technology, Physical, Implementation & migration, going down the page with motivation elements on the right hand side because it connects to all layers. Sometimes it doesn’t make sense to do it that way, but as a rule of thumb, you end up with nice consistent models. Having relationships crossing over each other will sometimes push me to changing the order of things; ultimately we try to tell a nice clean story that makes sense. You have probably seen the Archimate Full Framework which has a nice diagram of the layers – I don’t publish it here because that image is under copyright.

It can be tricky to do take that approach on occasions, and you can be forced to do things very differently – This particularly happens to me whenever I do things with implementation and migration because you can be realizing elements in multiple layers, or with requirements realization views that have motivation elements everywhere. I still try to group layers together but its equally important to stop a spaghetti view with relationships crossing everywhere. Another reason that following the flow of layers in the full framework is a good idea is because of the way some of the standard viewpoints fit together – for example Service realization goes from Business to Application – Technology usage sits beneath it connecting application to technology. 

People in the western world find it much easier following diagrams that go from top to bottom – or left to right.  There are of course times that you cannot avoid to have arrows in different directions. Sometimes diagrams have to be complex. As a rule of thumb if a view has more than 30 elements i think about breaking it out into a separate view.

Some other miscellany

Some general things I do to keep things tidy and consistent: 

  • Avoid relationships crossing each other on the canvas – sometimes this will end up as a jigsaw puzzle and its not always possible. But mostly it is.
  • Don’t use diagonals – I use right angled connections.
  • Resize boxes to highlight importance – on a service realization view – I will make the service big. 
  • Resize boxes to make the line connections simpler. See figure 3 – i made the work package larger in order to avoid having to bend my lines.  the association relationships now go straight down. 

Summing it up…

These are more guidelines than rules. There are times where its not practical to follow all of the formatting suggestions i have put forward today, and that’s OK. The most important thing to remember here is that every view you are creating is telling a stakeholder a story. We need to do that in a way that makes sense, so we have a little creative licence. 

Don’t be shy about getting your views peer reviewed by friends – or asking them to tell your story – it will help you improve your game. Ant view is better than no view.

The more we model and review – the better we get – there’s no one way to do things – but practice will improve your game.

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. 

Assessing Solution Requirements

In this blog I talk about requirements, and the process of choosing anything as an architect. It could be a hardware solution, like a suitable laptop, or a software decision like choosing between Teams and Slack. 

A really important thing to note here, its that its much more important to think about the methodology behind what I present here than the tools I use.

Choosing The Right Solution

As a rule of thumb, it’s always a good idea to assess 2-3 different technologies before choosing one. Its good to know if your primary option fails for whatever reason, there’s a secondary solution. We want to avoid vendor lock-in ; if there is only a single vendor we should risk assess them – which is a whole other subject unto itself.

Decisions should be made based upon the requirements of our different stakeholders to ensure that the solution is fit for purpose. Its tempting to look at software and think about the feature set that the software gives. Some people choose one piece of software over another because it has better features. This is normally a bad approach; you may end up paying for a solution that’s expensive that will never be fully utilized. The same approach equally applies to hardware and software.

When considering replacement technologies or upgrades you should also revert back to the requirements.

An Example With Disk Capacity

For example – If we are looking to order new disk capacity – a vendor may offer us a new model of disk capacity which is 5% faster. It may look at a good idea on the surface, but that’s not necessarily the case. If we do not require faster disk capacity, then in fact there may be a cost overhead. Let’s consider TELOS for a moment (Technology, Economy, Legal, Operational, Scheduling). We may realize that to implement new hardware means potential incompatibility and a risk to operational efficiency. It may also mean we need people to support or train with the new technology; its one more technology type to manage. 

In addition to this – we should of course be tracking decisions, in a work log or other system. We might also consider having release management on versions of our requirements and the approvals of them.

Modelling Device & Requirement Mapping

A practical example. I needed to choose a new laptop. Not knowing what to get I did an exercise in ArchiMate. I started by modelling the top choices I had narrowed down to (I created a Technology View). Of course, if we were deciding software items we could just as easily use application components in another view.

Laptop Device Elements

From there I needed to decide my requirements. I am using BiZZdesign’s Enterprise Architect and multi-added some items (it took 2 minutes). I followed this by using a property table to assign priorities to my requirements. The resultant requirements ended up looking like shown below. It’s a Motivation View, using a MoSCoW color filter:

Requirements View

You can see above the priorities in had on my requirements. Normally in doing requirements I am thinking about TELOS; we could also consider ensuring we capture requirements from all the different stakeholder types named in ISO 42010. Note, in my laptop decision I was doing quick and dirty modelling.

Realizing The Requirements

Once I had the requirements it was a matter of deciding which devices met the requirements. I could have put both the devices & requirements in a requirements realization view; Instead I used another cool Enterprise Studio feature – I created a cross reference table using these options:

Cross reference table definition

From here it created a table and I could just click on the table cells to generate realization relationships between the requirements and the devices.

Cross Reference Table

Visualizing this – it was easy to see the best option there was the EliteBook. I could have easily from this point generated a ArchiMate view if I wanted to using the auto-generate functions in enterprise studio but I just didn’t need it. I could have also saved this table as a Enterprise Studio Viewpoint and reused it later so I didn’t have to re-select the options again. Note – Viewpoints in this case refers the the Enterprise Studio functionality. In my agony to make the right choice I did in fact produce one last motivation view:

Motivation View

The whole exercise took 30 minutes.  There are distinct advantages to modelling your requirements; when it comes to making sure nothing is missed in requirements realization and tying requirements into other bits of architecture. We can of course document the requirement, its rationale, and influence.

Working With Larger Projects

When working as part of a larger project you might have to periodically sync requirements, or compromise on how you work with them – I could for example in a requirements realization view show a single element such as “Citrix Hardware Requirements”  and then in the documentation of the element just link to a confluence page where a team of people not using my modelling tool can manage them. 

We can also document the relationships; in relationship documentation you could express who had actually agreed or confirmed the requirement can be realized alongside any justification or documentation you have.

Capturing Requirements In A Collaborative Tool

We can capture requirements using any collaboration tool – be it something like OneNote or Confluence. Of course its good if the tool you use allows versioning; regardless of the actual tool you need to consider the following:

  • State who the requirements are for.
  • We clearly identify who is responsible , which product it pertains to, and other people that have been involved in identifying these requirements in a header block.
  • Sometimes I break requirements down following TELOS – to ensure whoever fills in the template considers things around Technology, Economy, Legal, Operational, Scheduling.

Minimum Needs For Requirements

Normally the actual requirements table as a minimum need has:

  • Who – is the source of the requirement
  • Service/area – gives an indication as to the general area/category of the requirement
  • The requirement – should be clearly defined and easy to validate (no fuzzy vague wording)
  • The rationale should explain why the requirement exists
  • Priority Follows MoSCoW (Must Have, Should Have, Could have, Won’t Have)
  • We have compliance columns for each option we assess.

The levels of compliance normally has the status, and the name of the person who has responsibility for meeting our requirement – for example, if we have a requirement for the network team someone in the network team needs to agree that they can fulfill requirements.The compliance statuses i normally include with the name:

  • Full – means that the device/service/software fully meets the requirement. 
  • Partial – Means the device partially meets the requirement. In this case we would also include words in this table cell to explain why it is only partially compliant.
  • Non Compliant – Is obvious – again the reason for non compliance should be stated
  • Undetermined – Means we have asked but just don’t have an answer yet.

Summing It Up…

Its important to capture requirements and then to assess different technologies against those requirements rather than to look at the feature set a tool or application gives us. If it looks like a solution has a feature we didn’t realize we wanted, this is a change in scope for our solution and we should reassess our business case.

In a world where technology is ever changing its essential that we document the decisions we make or we can loose those reasoning over time, or in bigger projects end up jumping from meeting to meeting essentially discussing the same thing. This is a cost overhead in time and is a risk in terms of miscommunication or the possibility that things get lost.  Its possible to have meetings discuss requirements and keep things together within meeting minutes but architects should be looking to understand these things consistently and to group information together, in a way that in a years time when we look at answering the question “why did we buy this, and can we replace it?” we have something we can go back to.

Please feel free to comment 🙂