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.

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 🙂

Aligning ArchiMate to BPMN

ArchiMate is fantastic and connecting different layers of architecture together, and BPMN is fantastic at modelling process – This article demonstrates my approach to marrying the two languages.

Playing To The Strengths

As I mentioned in my article Architecture Languages, Standards, And Frameworks, BPMN strengths lay in creating process detail – and whilst it’s possible to create processes equally as detailed in ArchiMate, generally speaking those processes tend to require more views, and do not look nearly as tidy without a significant amount of effort.

A question I am often asked is which modelling language should be used, and to what level of detail? Both Languages have pros and cons.

For that reason I tend to model the process and its connection to the rest of the architecture in ArchiMate and leave the details in the BPMN model.

The order you do this very much depends on the level of understanding you have of the process. Some people prefer to do the detailed process and then fit it into the context of the organisation and others prefer to do the general overview and then detail out the process later. As part of my standard approach to creating high level designs I normally create the ArchiMate process overview before the BPMN one.

The ArchiMate Process Overview

In ArchiMate, my overview generally looks something like this:

Fig 1 – A process overview

I start with the actual process in the middle. I have found many architects can have a challenging time fully defining a process; its easier to understand what you need from a process and what your expected inputs and outputs to process are, and who needs to be involved, than it is to understand all the minutiae. So the key elements here:

  • Business Process – I normally start with one process – with a name suffixed with the word “process”, because its just easier that way to be clear when talking in conversation to other people.
  • Business Actor / Role – I prefer to use roles rather than actors, because it helps with abstraction and re-usability of the process; it’s important to understand the differentiation – actors are assigned to performing roles. Sometimes I might use both or a mixture of two if i have good reason.
  • Business Events – In the ArchiMate specification it says that events denote state change in an organisation – The way I am using events here is to denote the events that cause the process to start running, and the outputs of the process The direction of the trigger relationships tell us which are which.

In the view above (fig. 1) we can see that our process serves the “My Software Service” – its good to put a process into the context of either a service or a function within the overview. Of course I can just take one or several elements from such a view and include them in other views as needed:

Figure 2 – A layered view

In figure 2, you can see a support process as part of a layered view; in this case we are connecting a process also into the application layer, you can see how if we had a process overview of Support Process our understanding if it work be better. We may have included some elements that would appear on a process overview; but not probably not all of them – this is a judgement call – when creating a view, I am telling a story, and I use whichever elements are relevant to that story. Of course the story of a process overview, is “this is the process from end to end, and this is how it all works”. Its views like the one above where we are able to use the process in the context of other architecture in a repository – that make modelling the process in ArchiMate worthwhile.

Creating a BPMN model

Going to the next level of detail, if we did a BPMN view for Figure 1, we may have created a process that could end up looking like this:

Figure 3 – A BPMN process

A couple of key things to note

  • The swim lanes in figure 3, match the roles in Figure 1; of course, if figure 1 had actors, they would be here too; I need to understand easily how the detailed process in BPMN connects not only into the process overview in ArchiMate, but the rest of the model.
  • Its really important to give the process in ArchiMate the same name as the process in BPMN so later its easy to search and find it.
  • We match up the events with same names in BPMN as ArchiMate, It makes sense. I think of them a little like being interfaces into the process.
  • I deliberately didn’t make the BPMN more complex – Its one of those languages that you can get started with easy, and there’s a few things you can do with gateways, and events, and a lot more possibilities than I show on my example. As I have probably said, I am a great believer in keeping it simple – and the 80-20 rule – you can get 80% of the work done in 20% of the time. Of course encourage architects to learn the standards properly and fully utilize them, but the elements i use in figure 3 cover most of my needs – and I would rather not have architects engaged in hour long discussions over what kind of gateway to use, when it is evident from just leaving the gateway empty and seeing it in the context of the view. I have found in the past, after getting comfortable with the basics, most good architects like to explore these modelling languages and will start to figure these things out themselves.

Why Am I Calling It A Process Overview?

So the elements shown in Figure 1 – could be considered to make up a standard process view like is showing in the ArchiMate 3 manual. I consider the process overview to be a specialization of that – because I am asking for specific elements, in a specific configuration – I tend not to want to clutter the view. I also do not limit this kind of model to the business layer – I could just as easily apply exactly the same concept in the application layer, an application process would be triggered by application events, and may serve application functions – Actors & roles would be replaced by other active elements in the application layer – typically the application component.

How Do You Practically Do This With Tools?

Typically I am using BiZZdesign’s Enterprise Studio (BES), which makes it easy, because the model allow me to create models in either ArchiMate or BPMN. I normally connect those view via hyperlinks – both on navigation pages, and in documentation. Enterprise studio also supports cross model relations – so I can link the navigation of one object directly to another and state the type of relationship; so for example, I could create a relationship on my Software Acquisition Process in ArchiMate to show it is refined in my BPMN model; a number of cross model relationship types exist. I could also tweak the meta-model to give me better options, but I haven’t done that.

Enterprise studio has some new compliance functionality – I did a quick video on it (with some notes in another blog) –

If I was using Archi & Visio, I would create a custom property on the element in the Archi Model and link it to the Visio file in a shared space. All of the modelling tools out there support hyperlinking in one way or another. Another option would be to link from the actual views rather than the specific process elements – but I don’t do that.

Summing It Up…

Of course we don’t actually need to do produce both BPMN and Archimate in all cases, but I do like to leverage the benefits of both together.

The approach I have presented today has a few advantages:

  • The ArchiMate view is quick and easy to get started with when you don’t have all your process detail.
  • BPMN is easy for process developers and other people to develop the detail in parallel. This is important if you work in an organization where process is developed separately from architecture.
  • Following some of the rules I presented will make it really easy to understand ArchiMate in the context of the more detailed view – because the inputs and outputs align.
  • Having naming aligned, and hyperlinks in place helps you find things – the alternative to this is to have disconnected processes.

I personally believe that not aligning your BPMN models with your ArchiMate ones, is effectively disconnecting process from architecture. But of course, Let me know what you think.

Enterprise Studio Compliance Color View

A quick introduction to some rather cool functionality recently introduced into BiZZdesign’s Enterprise Studio.

Note – If you are do not see a Quality tab in your interface, it may be either of these issues:

  1. You are running the wrong version of Enterprise Studio. Its possible to have two versions installed at once.
  2. You are running on a model repository that doesn’t have the latest version of the meta-model schema. You can check this. If you create a new model package and have the quality tab but it doesn’t work when using a team server, you need to talk to an administrator.