User Stories

Introducing User Stories, an easy mechanism to capture stakeholder needs and requirements.

The Basics of User Stories

There are many forms a user story can take but I introduce a simple one here in the video below.

To sum it up quickly

As <someone> I want to <do something> in order to <achieve value>

Its an easy mechanism we can use to focus users into creating a basic form of requirement.

A practical example

Lets take a look at some basic examples.

  • As a customer CxO I want to outsource my website management in order to reduce risk of unexpected maintenance costs
  • As a customer CxO I want to outsource my website management in order to reduce operational costs
  • As a customer end user I want to have an uninterrupted service experience in order to reduce wasted time
  • As the web service product manager I want to have efficient operations in order to maintain a 30% margin
  • As the web service product manager I want to have a completely automated deployment of my core services in order to be scalable
  • As the web service product manager I want to have a completely automated deployment of my core services in order to reduce the chance of manual error
  • As the web service product manager I want to have a completely automated deployment of my core services in order to have fast deployment times

Above are some typical examples that might come up in a planning session with product management. I could easily go to my stakeholders in separate meetings, and work with them to build a more complete list.

Turning this into ArchiMate

Is fairly easy. Again I showed it in the video but I will demonstrate. I don’t normally insist architects create a view like the one below but it has advantages if you are trying to extract value. Take a look.

I’ve done this quickly. Note I slightly changed the wording for both values and requirements – this is because we have to remember they are elements in a model. This means they need to be able to stand as independently and tell a story by themselves.

Viewing them this way means makes it easier to see which requirements yield the most value, and makes it easier for us to tie things together. We could use these user stories as a motivation view in our work planning.

You can of course also use this very basic motivation view as the basis for a requirements realization.

You could also use the work to group together values.

I will be talking a lot more about requirements of different kinds and approaches to them. Its a big subject – needless to say, User stories offer an easy way to get started capturing the needs of stakeholders.

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.

Planning Work With ArchiMate

Introducing a simple way to do basic architecture work planning using ArchiMate.

In order to keep control of architecture in a complex ever changing work its important to understand the workload. We often have complex projects interconnected, with shifting priorities; architects are asked for many things from stakeholders; to support both our architects and stakeholders I ask for a simple road-map with some supporting views. When a business stakeholder gives new priorities the architect can then easily take an intelligent conversation on what needs to be re-prioritized.

I Abstract away from real work and made up some examples here. So lets cover the Basics; Its far better to ask for basic views using only a subset of architecture elements than to expect fully blown models when you are trying to get a level of consistency and need to balance the levels of complexity with varying levels of competency you invariably face when dealing with a large number of architects.

The Work Package

The key element I want to talk about today is the work package in the implementation and migration layer of Archimate. Work is exactly as in English – its effort that is performed. We define the packages in architecture because it gives us many advantages – In modelling the packages we can accurately represent the effort our teams must take and the impact it has on our architecture over time. 

I tend to align work packages to the SAFe methodology even though we are not strictly using it at the moment – a work package is a unit of work that effectively can take 2 calendar weeks or more, and they should be modular; a package should provide value all by itself – rather than relying on anything else. This is important if we are to ensure we provide continuous value over time.

Work can be product related (implementing a new service within a product for example) or it may be related to a specific project or objective – for example we may have a concern around quality of a service which needs corrective actions for improvement, or we may have an initiative to reach a specific management goal.‚Äč

The Work Road Map

Something I ask all my domain architects to do is a work road map – anything that is going to take more than a week to complete or will tie up one or more resources should appear here.

I ask that the domain architect connects with both Product Manager & Service Manager in order to get a perspective of whats actually going on in terms of work within the specific products and services. 

Each block on the “Road map” (its a road map view in BiZZdesign’s Enterprise Studio) is a work package which has start and end dates. The arrows on this diagram are denoting dependency. We need to understand the dependencies between work packages, and in the example above “My Collaboration Program” is composed of several projects

Having all work modelled on the one road-map with the associated views allow us to ensure there is no duplication of work happening in the organisation and helps us understand our full workload – it should be regularly used with product managers to prioritise what happens next. Of course every work package on an architecture model can be navigated so we can understand all the places it exists.

We could add a number of other elements to the roadmap view – including plateau’s which would give us a stable state to connect architecture to – for now we are talking of the minimum basics.

Motivation View My Collaboration Program

Its important to note that this is a concern – not a risk – anyone can have a concern – it can be like a requirement, or we can express worries in the same way. Building a motivational view like this gives me something I can discuss with the different stakeholders; with a bit of practice you can create these in meetings, capturing concerns and assessments from the stakeholders. None of my motivation views have stakeholders expressed in them, because in our case the stakeholders are made apparent by the repository structure. I could include them in the motivation view.

There’s a school of thought that we should hide negative concerns, and I don’t agree with that – if we hide them, we can never fully address them, and also we may live with a wrong idea on something – for example, I could spend my career thinking that architecture workload for products is unclear and improperly scoped, when a conversation with the right person might simply inform me that I was wrong – there could be processes in place that I just haven’t been aware of, and for that reason, were never included in my architecture.

Motivational Views are there to explain why we do things. Above i show a simple motivation view – I have been advocating modelling something similar to above because of simplicity – the basic idea behind the view is to explain the “Why” behind the work packages we have – in an ideal world you can develop a full justification and more complex motivational model but for now –  The basic things we want to have answered:

  • Drivers – in the case above the driver / concern is a customer need. This driver reason behind why everything is happening for the work package. Normally I have one driver that’s motivating the whole view, at the top.
  • Assessments – These are the observations that are forming the rationale behind the work package. In a typical conversation with our stakeholders they will make many assessments on things that we could capture. and connect to our concern. When discussing with stakeholders they normally frame the problem (Driver) and then come up with a whole bunch of things to motivate that. These are effectively assessments.
  • Requirements –  Requirements are the glue that holds everything together in architecture and we could talk about them at length – For now in this simplified mechanism for drawing concerns we create requirements that would mitigate or provide a positive effect on our observations; for example if the observation is that “The media server crashes frequently”, then a good requirement might be: “Media server solution created & implemented to ensure a 99.999% up time”
  • Goals – The requirements together meet one or more goals. Its important that the goals address the needs of the driver.
  • Values – The goals have a positive influence on different values -we could define some standard values at our team level – so we can reuse them. If my boss says “We need to reduce maintenance costs” – we could easily automatically generate a view that shows all the goals that provide this value – and show the work packages with them. When we do that suddenly I can have an informed discussion with my boss – I can say – sure we can do that – but look at the road map – we need to de-prioritize some projects accordingly because of resource constraints – Its a much better discussion to have than answering “yes boss” and then trying to juggle a dozen projects you don’t have time for, get overly stressed and then fail to deliver anything.

I could have added positive or negative influences, I could have made our time restriction a constraint – many things could be done to improve the motivation view, but for the sake of simplicity I normally ask someone to do something basic like above.

Prioritizing The Requirements

Once I have the motivation views in place I normally prioritize the requirements – I am normally using MoSCoW rules (Must have, Should Have, Could Have, Won’t Have). This normally influences package definition – we may decide we address our requirements is several packages – for example, high priority tasks may need to be in a priority project and then you can define secondary projects that can be de-prioritized.

Implementation & Migration View

Once we understand the motivations behind our concerns we can take the requirements from our concerns and realize them within a work package like I have done below for the platform implementation project:

The above view further defines the work package.  The key components are:

  • The Work Package – which everything connects to.
  • The Roles – That are required with the work package – I find it handy to have the association relationships describe how much time is actually required from each resource.
  • The Requirements and Goals – these are from the motivational view – they tie the motivations to the work package.
  • Deliverables – these are things that the work package needs to deliver to be successful.
  • Other Architecture elements – A work package can realize any number of other architecture elements – for example we may create a work package to realize a specific service. 

Business Validation & Other Related Things

I will introduce a couple of basic mechanisms we can use to validate our work packages – none of which should take more than a few hours to create if you have a solidly defined idea of your business case and understand your audience. If you do not understand those things I would say the following practices are even more important. Its very important we do not start work unless we can clearly understand the scope of the work, or the values & benefits it provides.

Below I show a couple of typical requirements or principle that an organization might place upon its businesses; most organizations have some kind of principles we need to be aware of:

  • Products should be returning a revenue of 1MEUR – This doesn’t mean in a year necessarily – but the plan should be in place for when this will happen. 
  • For every EUR we invest we should have a return of 10EUR – Its a basic profitability rule of thumb.
  • We should try and get our product costs covered by pre-selling ideas to customers. Having a customer commit to buying a completed product fully justifies its cost.

User Stories

User stories are a basic form of requirement – they take the form : As <someone> I want to <do something> in order to <achieve some value>.

When you write a series of these with different stakeholders you gain a better understanding of who needs what and why. Take a look at the video:

TELOS

I have already mentioned TELOS in another blog – its an acronym used for feasibility checking. (Technical, Economic, Legal, Operational, Scheduling) Its another thing I could write a lot more about because it is so useful.

Business Model Canvas

When defining a work package for a service or product we may want to consider creating a business model canvas. A reasonable video introduction is below:

We can create a Business Model Canvas that connects directly into BiZZdesign’s Enterprise Studio – its a type of view that can be created in an Archimate model.

Summing It Up…

The mechanisms described here are not complex and do not take much time to implement. For myself, most work packages can be defined and modeled with associated motivation views inside of an hour – the modeling is not the hard part – the more difficult part is clearly deciding what your goals are, who you need, if your business case is strong, and requirements. modelling these individual elements forces an architect and their stakeholders to clearly think about every element.

We could talk in terms of risk here – if you cannot create a business canvas, for a service I could question the fundamental business case. If you cannot identify stakeholders a risk around the understanding of cost and basic feasibility could be raised.  With resources being limited and the need to deliver value being ever greater following the methods I describe above give you a good way to describe work and its implications and give a good foundation that can be used to continually manage a complex workload and ensure that the workload is prioritized in a way that you are getting the correct value at the correct time.