10 Common Issues for Architects In Requirements Management

I wanted to share some common issues I see when managing requirements in large projects.

1. The blur between the Architect and Project Manager

Architects build architecture solutions, and if you read standards like ISO42010 its quite clear that designs have to meet the needs of the stakeholders and clearly stake how they do it. This means to design optimal solutions its architects that need to manage requirements. Project managers are there to track, report and guide project state. They naturally have an interest in making sure requirements are met, on time, on budget. Because of that drive I have sometimes seen project managers driving the requirements and their allocation. A good project manager complements an architect, and does not overrun them. The responsibilities between these two roles should be laid out clearly.

2. No project lead architect

In big projects with more than one architect there should always be an architect who is guiding the work of the other architects – to ensure that the different architects and teams are building to a common vision. Depending on the scope of the project that architect might be an enterprise architect or a solutions architect for example. Just because the lead architect is responsible of the solution doesn’t mean the architect cannot use other resources to help with the initial analysis. Large projects should not start without a lead architect coordinating parts, because costly mistakes can occur.

Keeping the vision on track

If you give three children three piles of Lego blocks they can end up building three different things, like a car, a giant chicken and a space ship. All great things that could be built with the same Lego blocks, but if the original idea was to build a house with a garage and car…. then you have problems. The same is true of requirements – three different architects can realize the same requirement in three different ways.

Inefficiency in design

Very often if you are running in large projects there are opportunities for synergies, and to avoid duplication of work in the design, and duplication of components in the resultant design. If one team is designing a platform for database servers, and another team is designing the solution for application servers, there are some opportunities there to reuse common elements to keep costs down.

When working in an organization with silo’s its quite common for separate product or service teams to have separate approaches to things like monitoring. If we are designing and overall cost and profitability are a concern at this point a lead architect should be looking at the feasibility of simplifying the solution. That could include talking to different architects that run the standard services. If 2 services use two different monitoring solutions, you have more complexity & more licensing costs, and need more people to support it. There’s also more things that can possibly go wrong. There’s not always a possibility do optimize down but at the very least those product service architects should be aware that such possible synergies exist.

3. Inconsistent requirements through text analysis.

If requirements are not given and have to created by analyzing text, or speaking to people its important that an architect creates a requirements list. if you do not work from one common set of requirements every paragraph of text is open to interpretation, which can lead to an inconsistent solution. An interpretation of text should be written down and agreed.

4. Unclear requirements

Sometimes requirements are vague or open to interpretation. In this case those requirements need to either be clarified by talking to the source of the requirements, or clearly documented assumptions need to be made, if for some reason there isnt an option to clarify with the source. Assume makes an “ass” out of “u” and “me”.

5. Pick your own requirements

In some projects I have seen an approach where a big requirements list exists that project managers ask the architects to pick the requirements that are relevant to them.

This needs to be done with caution. because several problems can occur. Firstly its possible that some requirements will not be managed unless the project manager is sharp. Secondly in taking this approach you can end up with an inefficient design. A good lead architect will look at all requirements together, and in understanding the principle needs of the solution will design and assign out responsibilities, and as I mentioned already will make sure that we have efficiency in our ways of working.

For example if we are looking at building a secure hosting solution and we have principles around layering security – to ensure this happens it may be that a specific set of requirements are given – and in order to get consistency throughout the whole design extra requirements may also be defined.

6. Not considering requirements hierarchy

Every project is a combination of customer requirements and internal requirements, and there needs to be a structure for requirements management to avoid a lot of conversation overhead, and to ensure we have efficiency in design.

Typically the business and customer are the priority. I like to use BDAT – Business, Data, Application, Technology as a priority. The hierarchy should be clear.

In the past i have seen service architects that are responsible for standard products in an organization say “no” to the business. Sure this can be done, but it comes at a cost, because if we cannot use standard products suddenly the cost of a solution gets a lot higher with customization. It needs to be clear within an organization that service architects are not there to say no – part of their job is to adapt standard services to meet customer needs over time. Architects have areas they are responsible for and they should be providing solutions and not problems.

A second part to this comes in when we look at the relative weight of requirements. If one requirement has to be met by three separate teams then of course each of those teams have a responsibility to show how they realize the requirement in their design, but the requirement should be managed at a level above – by either the lead architect or someone they delegate, to ensure that the realization of the requirements in design are done in a consistent fashion.

7. Unrealized Requirements

ISO42010 says something to the effect that every architecture concern needs to be framed in one or more architecture viewpoints. Effectively we are saying that every requirement needs to be handled within a design. So the design documentation needs to show exactly what is done to meet every requirement.

8. Forgotten requirements

If you are creating a solution from a request for proposal, its very easy to focus on those requirements, and not think about other requirements from other stakeholders. When building architectures we normally have a number of internal and external stakeholders, and we may be thinking about ITSM tools. When we are properly modelling motivation layers this risk can be reduced.

9. Forgotten principles.

When designing an architecture solution principles need to be applied. Often principles are given by either the organization or the customer, but sometimes when looking at requirements a lead architect will see the themes within the requirements that are given. For a good quality resultant solution it may result in project level principles that are to be considered throughout.

10. Not managing requirements

Requirements need to have a responsible person managing and owning them. in determining how to realize a requirement this is done as part of the requirements realization but also there’s a dialog that is happening between different stakeholders in the requirement. Its very important to keep track of the key decisions that are taken, any assumptions that impact the requirement, as well as the people that have made these decisions. Its something that can be key to understanding why decisions are taken in years to come.

Summing it up

You can probably see that managing requirements properly, especially on large scale projects is not an easy task – and to do it in the best way requires a good interaction between both project managers, and different architecture teams. Having a good requirements management process is not only key to ensuring projects are performed well, but also impacts the overall quality of a resultant architecture in project design.

Good architecture leadership can make or break a project.

Systems user rights in architecture

Last week I was asked for a standard definition of what administrative users are in our company. I wanted to talk a bit about user rights because admin or not admin as a way of thinking is dangerous.

I wanted to share my thoughts on it, and an approach for defining user rights in architecture. I want to start by recommending a read – Modelling Identity In Enterprise Architecture. When it comes to designing role based access control (RBAC) I think this is a good starting point. This blog is thinking more in terms of systems access than designing full RBAC.

Most organizations have a need to adhere to standards such as ISO27k, or even more fully defined security baselines. Its clear that there is a need for segregation of duties, and that security principles should in some way cover the need for least privileged access.

Thinking in terms of administrative usage by itself is dangerous, because its binary – you are asserting that either a user has privilege to administer, or does not. When I started writing this blog that’s all I wanted to point out but in creating the fictitious example below I realized there’s a lot more I could say around my flow of thought.

As with other blogs, the point here is not to design a complete service, more its to explain my approaches. There are a few things I would change if I was going to build a real thing. I would look at my Identity Access Management and fit that in a lot better.

Lets make something up. Our fake example is a backup service.

Backing up a system

In order to fully back up a system it stands to reason you need to have access to everything in it. A non privileged user could not back up files they do not have access to. If we were asking the question should that user be privileged or not, the answer would be yes, that user needs privileges to read all data on that system. In fact all users need privilege’s in a system, the question is normally how much.

Does this mean that user is an admin user?

Here’s where you need to be careful. On a windows or UNIX operating system – assigning admin rights out of the box gives a specific scope of control to a user. people tend to talk in terms of admin rights and non admin rights because of this. if I tell someone they will get admin rights on a windows server they know what they get.

When you do not do architecture, or think about your systems security architecture the exact needs are not designed. I have seen many times in my career people writing code to elevate permissions to admin just because code didn’t work in the current user, and elevating privilege’s solved it. Whilst it made the code work it gave code dangerous levels of access to the systems that could be exploited

When people use the term elevated privilege’s they do not necessarily mean administrative access, they mean they require more than they would have had otherwise.

Using Admin Users For Elevated privilege

In general I would say using admin users for anything is a bad idea – because if you share admin credentials around you are increasing the probability those credentials can be compromised – and you are also making it hard to trace who actually made changes to a system

Giving users admin rights would be a better approach when it comes to identifying change, but still this is generally considered not good enough; A common security principle that you will see in many standards is “only provide needed rights” – so if an account does become compromised the damage is limited.

In the case of our backup example, admin rights may be too much. to perform a backup, I need read access to a system; in specific cases I may need to also be able to write to specific areas, for things like logging.

Designing Backup Scenarios

When designing a system I should be thinking about specific use cases. This example is a simplified one just for demonstration purposes at the top level, if i was providing a backup service, I may have thought of four basic user stories:

  • As a backup technical specialist i want to back up all the files from my server in order to prevent data loss
  • As a backup technical specialist i want to be able to restore individual back to a system in order to recover from a data loss
  • As a backup technical specialist i want to be able to test my backups in order to ensure they work
  • As a quality controller i need to see that backups, restores and tests are happening correctly to ensure the quality of my service

I am not providing a full set of use cases, because we would need to cover things such as restore time and point objectives, and would need to deal with complexities such as single file restore vs entire system snapshots, and I want to try and keep this blog short!

A quick service realization

Off the back of those 4 use cases I drew my first attempt at a service realization. It looks like this:

Figure 1 – A service realization

A full service realization would cover more around the process; our motivation models and user stories would develop this view further, but our focus here is to look at users and their interactions. There are a couple of thoughts that went into the design of figure 1.

  1. From the use cases its clear that there were two business roles i was working with, each needing different levels of access.
  2. In doing this design I know my security principles & control needs, so in the back of my head i am already designing for them. sometimes we may do this in several iterations – especially when i start to do my requirements realizations. It is way faster to develop things if you are familiar with the standards and controls you need to adhere to.
  3. I deliberately separated out logs from actual server data to meet some security principles.
  4. As a principle I already think what is the flow of information and the minimum level of access I need

User vs System Permission

Its important to understand the differences here. In our example our backup technical specialist would need to be able to backup, restore and test. He is a single user, and would probably be authenticated for access to a backup system portal with his own credentials. I didn’t model it here but he would probably be given roles in a backup application which would enable him to run different application processes. Its standard role based access control.

At a systems level things are more complex, and should be designed to be secure.

From looking at the access relations on figure 1 I can quite clearly see where I need to apply different levels of permissions. in our case we have 3 business processes – they are core processes, which make perfect sense to be accessing the systems with their own permission. From the service realization I could easily cut it into pieces to have a sensible scheme for permissions – it might look like in figure 2:

Figure 2 – Breaking down into users

Our view here is telling us

  • Our restore user needs to read backup storage, and read write to our server data & restore logs
  • Our backup user needs to be able to write to backup storage, write backup logs, and read server
  • Our test user needs to be able to read and write test server data, read the backup storage and write test server logs
  • Our backup log reader user needs to be able to read backup logs, restore logs, and test server logs.

Figure 2 – is really just figure 1 organized into different users.

So what’s missing?

I didn’t show that I had specific reasons for creating the user access the way I have done. My thoughts would be lost if I didn’t document them some how. I could easily extend figure 2 to show this. Take a look at figure 3:

Figure 3 – Requirements Realization

Figure 3 tells a story as to why we organized things this way, and like any architecture it is iterative. We would have arrived at our requirements when motivation modelling – we could also choose to show our principle on this requirements realization view in figure 3. I speak about motivation modelling in other blogs. Whatever makes sense to tell our story. Bear in mind we can also document any element and any relationship between elements. on the view i chose to label the relations in some places, but additional information could be stored in the documentation for the relations. Understanding why something is related to something else is something that’s easy to document in most modelling tools.

Note I added some users as application data objects there. From a systems perspective all a user is, is data. different applications use that data to authenticate using there own application process mechanism. I did this because i want to refer to these standard users and their standard permissions in the final part of this story:

Figure 4 – considering technology and locale

I knew already when I was creating figure 3 that rules around information segregation would also need to be considered at a server level and that this would likely mean that the user structures I was creating at an application level would have to be split so i could ensure that compromising a single country does not compromise my entire solution. Figure 4 shows that each country we are operating in needs a data center in order to ensure that backups do not leave the host country. In our case we have allowed log files to leave the country so we can centralize our log management but we have a clear idea of the major data flows.

Summing it up

Designing this way is going to help when it comes to doing things like ensuring we have GDPR compliance, and making sure we follow security principles. At this point I may also chose to do either a basic risk analysis or maybe model some threat scenarios to look at different ways this design may be compromised. That’s a story for another day.

Architecture building blocks and ArchiMate

ArchiMate isn’t only about drawing views and relational models. Understanding the language fully helps how we shape our architecture.

In a meeting last week there was a fairly lively debate about architecture design. In that meeting we had some people wanting to comment the semantics of the ArchiMate language (the more analytical people). Some people were just wanting to understand the relationships between the applications. Quite a lively conversation ensued, and want to share my thoughts on this.

Architecture Tells A Story

I have spoken about Storytelling in previous blogs. In ArchiMate terms, a view of architecture is created for a purpose for a specific audience – its defined in the viewpoint definition. So its important we address the intentions in the viewpoint definitions.

Following ArchiMate Standards Help Structure Architecture

Using the right elements for the right things is important when it comes to wanting to generate specific views. For example If someone mistakenly stated “ISO42010” as a strategic capability rather than “ISO42010 Compliance” as a requirement, then if I want to automatically generate a view of our strategic capabilities, I am going to have things on there that don’t make sense. If many elements have incorrect definitions or relationships between them then the usage of the model as a whole is greatly diminished.

Understanding the elements and the metamodel fully is key

Understanding and using the full metamodel properly gives so much more than just defining elements and relationships. Services are a fantastic example. Rather than building one massive view of interconnected application or technology components, breaking things down into smaller services gives us opportunity for reuse. This can be done at the business, application and technology level. Building a service is like building a Lego block. You can think of the block as being a service – and the interfaces to that service being the connectors like this:

Figure 1 – Lego Web Service

We can build our services in several layers of course; either stacking services, Business on Application, which sits on Technology – Alternatively our Lego block here could also contain elements from other layers. It could be argued with the example above that the interfaces for directory services or databases shouldn’t be there – because they are part of the internal make up of the building block, but this is one of the key things we need to decide when building architecture – what are the logical blocks that make the most sense for reuse, what is internal, what is external. We are building architecture building blocks. Within our services of course there could also be sub services within these building blocks – so one building block can be made of others. I previously wrote a little on Services In ArchiMate that goes into a little more detail on the subject of Services.

I have already spoken extensively on the benefits of having an architecture model rather than word documents, and an ArchiMate relational model making it possible understand the implication of change, but in understanding how the elements and relationships in the metamodel come together to create a service base thinking we truly start to see some real power.

Putting it all together

At the end of the day, we want to be able to do this:

Figure 2: Building blocks

We start to build standard architecture building blocks, with standard interfaces. connecting into standard services we unlock a myriad of advantages – We can can more efficiently reuse our resources, and we can put our services together in interesting new ways. With Lego the focus isn’t on the blocks – its what you can build with them – the same holds true in architecture.

Summing it up

How we model something and follow the language of ArchiMate is important. We don’t just want to understand the elements, or only have a relational model, we also want to ensure what we are doing is building architecture building blocks that make sense, and make it easy for us to have reuse.

Practicing architecture in this way may mean a learning curve for architects but its key for making efficient use of a companies resources, and maximizing the benefits to business.

Don’t Show Me ArchiMate, Show Me PowerPoint

Showing people ArchiMate views to leadership is not always a good idea. Today i wanted to talk a little about presentation of architecture in PowerPoint!

I am probably going to shock a few people who know me with the title of this blog, because I use ArchiMate all the time especially when I am talking to architects – they all need exposure to it, and as a common modelling language between architects its very useful to avoid miscommunication, but sometimes when I am in a presentation with senior management and I see an ArchiMate view, it sometimes hurts.

In one of my recent blogs I created a motivation view; this is from part 1 of Motivation Layer Modelling:

Figure 1 – A motivation view

Its a good view – it follows the ArchiMate rules, and it provides a lot of value when you work with stakeholders to define it – but as I mentioned previously, I probably wouldn’t share this with a stakeholder, because not everyone loves ArchiMate, and it looks complex; it switches some people off.

About Leadership

There are many types of leaders out there – I have been in a few leadership teams where they do psychological tests, and use a number of techniques to determine things like how analytical you are, how competitive you are, or how dynamic. Even the most analytical of leadership are likely not to have the time or motivation to learn a language like ArchiMate.

Just as analytical thinking brings benefits to the table, other approaches do as well. The view in figure 1 – may be really attractive to an architect who understands the relations and notation – it may even be very exciting; but to a business leader, even an analytical one, if you present ideas in such a complex form, issues will arise, and your message can be lost in the complexity.

To some, ArchiMate is just drawing pictures. I spoke about the value of ArchiMate and the value of modelling in my blog Understanding Architecture Value because I felt at the time that a lot of the people I was talking to didn’t understand the value of the work I was doing, and in retrospect, the reason wasn’t because of the work – it was because of how i was presenting it at the time.

A PowerPoint presentation has the value of communicating things to an audience, and an architecture model brings its own values. ArchiMate modelling is a better tool for designing, and ensuring solutions are water tight, with different relations and elements and is good for communicating between architects who design solutions. Depending you your stakeholders, PowerPoint is often a better visual tool for communicating concepts. A leadership team typically doesn’t want to get into the small details of a solution – but needs to maintain an overview of a lot of moving parts, and trust its architects to do their jobs.

About Presentation

I spoke to a colleague in a large establishment about this at one point – he told me a story about an architecture he did for one part of the organization, which he thought was really good and could be reused in another part of the organization. He presented it and to his surprise the audience hated it. He went away, and several months later, changed the colors and the logo on the view and presented it again. People loved it – he had made no changes to the actual content. How we present things is sometimes as important as what we present.

Our architecture story

Our architecture views are telling a story. We can tell that story in different ways. If we look back to the view in figure 1 – we have stakeholders, drivers, and goals. and one easy way of presenting a motivation view is to focus on those parts; they all address questions. There was a reason I split the last two motivation blogs the way I did. Stakeholders, Drivers & Goals focus on the stakeholder needs – where as when we start to talk about requirements, principles, and outcomes we are very much thinking about how we will achieve those goals. Just as we do this in the motivation layer, we could take a similar approach with any part of the model. We think about the different element types and their connection and then figure out how they relate as part of the story they can tell to whoever we are presenting to. We need to consider our audience and the questions we are answering – because we want the story we are telling to resonate with them. There are many books out there on presentation skills, but if you can tell a simple story that your audience can relate to, you are more likely to be able to tell your architecture. EA is very much about people.

Doing the modelling in ArchiMate and following an architecture process gives us value, and ensured we hadn’t missed anything in our thinking. Sometimes I might want to keep a view like figure 1 at the back of my slide deck for support if complex questions come up, but for presentation I want something better focused, and maybe even more simplistic to grab the attention of the viewers

Stakeholders

Lets create some simple slides for presenting the view in figure 1.Lets assume we have been given a short time to create a presentation which we may have to present in a meeting. Its different to prepare presentations that may be part of an information pack. In that view there is only one stakeholder. On a presentation I may chose to just present this in the context of other stakeholders in other views (if there are any, or if the presentation is only about things in figure 1 – focus on our CEO; iI think carefully as I may want to make the audience aware of the different stakeholders and that this view is part of something bigger. These are the people we are providing value to, and a good starting point in a presentation. At this point its worth mentioning I am not going to talk about how to present things in PowerPoint – I limited myself to only having 10 minutes to prepare this PowerPoint, and used a PowerPoint stock theme – at work I would use the company deck. On the view i am presenting, I only have a single stakeholder so I create a single slide that’s basic – just to make sure i don’t forget about this important topic: I could include a bit of information about our CEO, and if there are several I would introduce the stakeholders at a high level on a single slide. I lacked imagination so just stuck the CEO photo in, and use it as an anchor in the presentation for talking about him. I am setting up the basis of my story.

Figure 1 – Our Stakeholder

Drivers

Once we have set the stage with our stakeholders, in our figure 1 view, we are flowing to drivers. Drivers are the primary stakeholders that have needs. In our tools its really easy to just select all elements of a single type and copy them into a piece of smart art. Once I did that I tweaked the text a little to make more full sentences, because in the object model we sometimes skip a word or two to make the element boxes smaller when drawing, but i am trying to connect to our audience: The importance is in the message, and I didn’t put anything in there to detract from demonstrating our understanding of our stakeholder needs. The colors i am using are fairly strong, in the real world you may not want use softer colors, or create a little more space, but for a quick presentation this would do.

Assessments

Looking at our motivation in figure 1 there are a number of assessments that really support our reasoning behind why we have our goals. Depending on the size and complexity of our presentation, i could break these out into a separate slide but sometimes its better not to. In this case i am thinking these are talking points i could run through when we speak about our goals. So I copy and paste them into the presenter notes for the next slide.

There’s a balance to be had. if i put too much text on the slide, the focus of the audience may shift from listening to the presenter, to reading. You want the slide to be focusing the message of the audience, not taking away from it.

Goals

In our figure 1 view we showed goals in two levels – the higher level goals connecting to the more specific goals. Depending on who we are presenting to, we may only wish to show the high level goals. Again i keep it simple. not too much text. In every slide i am asking myself the question is this answering the question of my audience.

Values

Its important we express out value and when I did those three slides above I considered 3 different approaches to representing them.

  • I could have put them in the notes for the goals with the assessments – A skilled presenter can tell the story of the challenges being met by the goals and the value our goals bring, beyond just stating bullet points
  • I could have them on their own slide. It felt to me a bit much to do this, as value seemed like more of an integrated topic than something that stands by itself
  • I could put them on the project goals slide above. If i had a little more time I may have done that.

Summing it up…

You may or may not like the slides I produced above – Visually I just picked a random default theme in PowerPoint. End to end it took me 10 minutes to go from having an ArchiMate view to having a few standard slides that can be used to tell a story. We are telling a story. We introduced the charactors, set up the challenge, then said how we would meet the challenge.

I chose the example i did today because right at the moment i see a lot of people presenting motivation architecture, and it is an easy example. Of course, for a full presentation you may want to be presenting a lot more, from multiple views, but the concept is still the same.. you can think through elements and relationships, think about the questions you need to answer and visualize your ArchiMate in many different ways, indeed some tools let you customize the visual representations of your views so they don’t look like ArchiMate at all..

ArchiMate is used to communicate architecture, and in the architects community is a fantastic way to convey a message, but the point of this blog was to show that ArchiMate is not the beginning and end of architecture presentation.

As an EA my job is not focused on technology – really its about the people, and whether the more analytical of us like it or not – PowerPoint is a standard way to communicate in some circles, and being able to effectively look at our model, and think about which elements we need to convey in the context of a story, then abstract away from the technicalities of our modelling language is an important skill.

Motivation Layer Modelling – Part 2

Following on from my last blog on motivation modelling lets look at Requirements, principles, and outcomes.

A Quick Recap

In my last blog we looked at Stakeholders drivers, assessments, values, goals and how they fit together to ensure we are meeting the needs of our stakeholders. We ended up with this view:

Figure 1 – The Complete Top Half of our motivation layer from last time

Once we focus on who we are achieving goals for we need to start to think a bit about how we achieve these goals. To keep the screen a bit clear i will create a separate view today and just start with the goals from our last example. Take a quick look at figure 2

Figure 2 – the goals portion we start with.

Putting in the first requirements

So we know our goals. the first thing i do is look at what would we need to do to realize each goal. its requirements that realize goals. In my case i drop them onto the canvas but don’t yet connect the relationships up – the reason being is because i will connect outcomes to the goals, and I haven’t done those yet.

Figure 3 – Adding the first requirements

This is really a first step. I cover requirements in other blogs. i will need to understand and document things before i am finished with the views but at the moment i just get them down, and can polish them before we complete the view. When I did my previous blog I lay out my timeline expectations in goals – for example Cloud offering must be in place by Q2.

Although I could also specify this as a requirement I didn’t when i quickly modelled this – because as a goal I know when we define the project and the roadmaps it will we represented out there. Of course I will define my motivation views in several iterations. After quickly putting requirements on the canvas I ask myself are they well defined enough that I can easily measure success. I immediately saw that “Fast training of technical resources on cloud tech” is a bad requirement – because fast is a subjective measurement – its better to say “Training of technical resources on cloud tech by end of Q1”. I only put timeline requirements in place here if they are essential.

When doing this work and creating requirements am also at the back of my mind thinking Plan, Do Check Act (PDCA). Planning something doesn’t give us value unless we actually implement it. Checking, and Acting would be an integral part of the architecture design. Also I don’t ever forget that architecture design needs to also cover the different IT Aspects – even though I have technical requirements on this view, whenever i talk about architecture design i mean we should cover all the IT Aspects. The Check & Act portions of this I would expect to be covered in the actual design.

Timing so far

Up until this point its taken me about 45 minutes to create those requirements. I am writing this blog at the same time. I would possibly engage a colleague or specialist to validate what i have written here, but its high enough level at the moment i don’t feel the need to. Stakeholders and technical resources will validate this over multiple iterations.

Outcomes

Figure 4 – realizing an outcome

Now I have laid out my first requirements I put in some outcomes. These are useful for validating that our requirements are actually doing what it is I need to achieve the goal, and also help for logically grouping things. I start to take a look at the requirements and what they really produce, and if they align to the goals, . take a look at figure 4. The requirements i have realize an outcome Cloud hosting product created. BUT there’s something there that bugs me. My requirement and outcome talk about the product being in place but still in my mind i was being bugged by the fact that the requirements do not capture the Q2 objective, and the outcomes haven’t captured it either. At this point just for my own peace of mind I create a constraint, even though we have covered our constraint in the goal definitions. This makes me feel a bit better because i know that I am being double safe. I have seen in some cases project managers focus on goals, and architects focus on requirements realization. By adding the constraint I minimize the risk of this important constraint getting missed.

Figure 5 shows how I filled out the outcomes now for the first goal:

Figure 5 – Requirements and outcomes done for our first goal

It made sense to me to split out design and implementation – because i know later on practically these may be run in separate project by different teams, and because I am always thinking Plan > Do > Check > Act in my head. My thinking here is that if you have an architecture process you are going to have to ensure as part of that process your delivered architectures have had some kind of benefits validated a time after things are delivered (which is where we Check if what we have done is ok, and Act upon that.. If you aren’t doing this – think about the implications. That could be a whole separate blog.

I would go through and figure out the different outcomes that each of my requirement’s are achieving and then checking my outcomes against the goals – looking for gaps. If the outcomes are not achieving everything we have as a goal, in our requiremetns we have missed something important.

Principles

I blogged on principles before. in the interests of full disclosure i am normally thinking principles in my head when i come up with requirements – and the next step i take here i normally actually do as part of the previous step. When you know your companies architecture principles its easier. Lets pick up some fictional principles.:

Figure 6 – Principles

At a company level, architecture board level, or even a project level there are principles that may need to be applied. Requirements normally realize them. We drop them onto our motivation view and start to connect them with the requirements we have in place.

Figure 7 – Attaching Principles

I am left with the principles that are not currently considered by the current requirements and goals. At this point I need to either modify the requirements i have, or add some new ones. In figure 8 you can see where I have started to add some requirements to ensure our requirements fulfill our principles. There are cases where when we may chose to not follow a principle. If that’s the case this should be documented in the design – you may even want to flag this as a risk.

Figure 8 – New requirements connected

Breaking things down

You can see that motivation views can get fairly complex. Each of them tells a story and its ok to break up things into multiple views – and connect them together via a single view at the top level. An overview is important because we have to understand the motivation in its entirety – even if the overview is only a collection of links to other views. The way I have broken things down between the first and second part of this blog could be a good logical break point, or you may chose to have one view per stakeholder, or whatever other logical split that makes sense.. The first part of the blog focused on the stakeholders and what we need and why – and this part is focusing on the things we need to do in order to realize those goals. The motivation view i have presented in this blog is typical of the kind of thing you can expect to see when engaging high level stakeholders for the first time.

Benefits vs Risks

I wanted to say a little something about why we model these different elements together for those people skeptical on taking such an approach with motivation views.

ElementBenefits of considerationRisks of not considering
StakeholderKnowing who your architecture has to provide value to makes sure you design something that meets everyone’s needsIf you miss a stakeholder its possible your architecture wont be fit for purpose or people may end up customizing things to suit the needs of people or teams you didn’t consider.
DriversUnderstanding why your stakeholders need to do things helps you ensure the goals we set actually provide valueIf you do not capture the reasons people do things, later you may have trouble understanding why choices have been made. There is a real risk that the goals that are set will not make sense and you will miss opportunities to understand synergies between your stakeholders
GoalsUnderstanding goals helps us determine both our direction, and our criteria for successNot capturing goals means badly scoped projects, unclear success criteria, which can lead to inefficiency and a loss of traceability and control of spend.
OutcomesHelp us ensure that our requirements are meeting our goalsif we dont check outcomes against our requirements is possible that our requirements do not collectively meet our goals.
PrinciplesHelp us ensure that the things that we are doing are meeting the design principles laid out by the relevant authorityPossibly creating designs that violate principles and do not work in the best interest of the company
RequirementsState the things we need to do in order to achieve our goalsNot having designed requirements may lead to designs that are not fit for purpose, due to missing essential requirements or needs.

Summing it up

Before we are finished with everything its of course important that we document our elements, so those that come after us understand what it is we say and why. This is particularly important with requirements. You can see that when i was creating this view i made some changes as i went, because i was always thinking of the readers of the views that will come later, and how these views will be used. Again, this blog wasn’t trying to fully demonstrate how i would implement a cloud hosting product, but should have given you some insight in how i think when i create these views.

Understanding What, Why, When, How and Who are an essential part of an architects job, and motivational layer model in the structured way i described help us ensure we do not do the wrong things when it comes to realizing architecture design.

I’ve spoken many times about how architecture design isnt just a set of servers connected to boxes – and ISO42010 tells us that all concerns of our stakeholders need to be framed in one or more architecture views. Having a good motivation view, or set of motivation views is the first step towards ensuring we do not have architecture solutions without problems defined.

Sure its possible to define all these things separately, spread across many documents (such as a project directive word file, a requirements excel, etc… Doing it that way can lead to a lot of unseen gaps, or risks in design. If its painful to design a motivation layer view for whatever reason, you should stop and think if you really know what it is your architecture needs to do, and if there are possibly some holes in your design. Thanks for listening.