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.

Motivation Layer Modelling – Part 1

I Wanted to share how I approach motivation modelling, as there are many approaches, and I often see important things missing in this area. .

I will be breaking this down into two parts. This first part is focusing on stakeholders, drivers and goals. There are of course many approaches that could be taken but this one is mine; I would love to hear others. I have in fact spoken about simple motivation views in my Planning Work With ArchiMate blog. This blog talks about creating full motivation views rather than the minimal things I wanted to express at the time of writing that previous blog. Bear in mind this example isn’t fully realistic. I made it up.

The Finished view

I will start by presenting a view I created for the CEO of my fictional web hosting service provider. As I mentioned this is only half a model – in the next part I will be talking more about outcomes, principles and requirements..

Figure 1 – Motivation view

When I was drawing this originally I was going to create a motivation view including multiple stakeholders, but just in real life it didn’t work out that way. There’s so much that can be going on it didn’t make sense to start everything on one view. So I created one for the CEO – just as I may well do the same for other stakeholders. I may then go back and create a master view that brings all these views together in a singular view that tells a story.

Stakeholders

I blogged about Stakeholders In Architecture previously; and ensuring we cover as a minimum a set of stakeholders. The reality is that I still sometimes see stakeholders missed – so as a double check, especially in large projects – its a good idea to look at the organization chart. The heads of business and key roles are normally stated there and usually have an interest in our architectures. I also sometimes look at the examples of stakeholders in ISO42010; It mentions users, operators, acquirers, owners, suppliers, developers, builders, and maintainers. I don’t think the writers of ISO42010 meant for this list to be definitive but it has always served as a good starting point. The only issue I had there is it requires a fair amount of thinking to ensure you do not miss stakeholders – for example think about security.

When I state stakeholders I try not to mention names in the elements. because names often change over time and you need a record of how things are at a specific snapshot of time. In the tool we use, Enterprise Studio, we sometimes put labels on the stakeholders to identify specific people in specific views. The advantage there is that the labels are not in the actual object model. For example if a stakeholder was “Owen Richardson – EA” then in 6 months time another architect came in and we renamed the element, all the views that were once Owen Richardson, would now be named with the new architect – which may not be representative of what happened in projects past. Labels stop that from happening.

Its important that the defined stakeholders are resolvable. As in you can identify who they actually are from your model – whether it be by looking them up in the organization structure or by having the actual names of people on the labels.

Relationships

I tend to use influence relationships in my models. I do not do any advanced decision analysis with them. Sometimes I will put positive and negative strength indicators on them. This often confuses people, so sometimes I will leave them off if I think it doesn’t provide value. You can see some examples of how I use influences, and the indicators in figure 1.

Drivers, Assessment & Goals

Drivers are the reasons why someone does something, goals are the things you do to satisfy those motivations. Some drivers are obvious, we normally get the drivers and assessments from talking to our stakeholders. They will normally tell you what they want, and give you reasons – those reasons I treat as assessments. Sometimes they will also give you the goal; or sometimes it may be down to the architect to suggest the goals. In those conversations with the stakeholders I normally create a high level goal then I need to think about how to make it quantifiable, so i go a level down. and have lower level more defined goals influencing the higher level ones. These are important because later on when we start doing implementation architecture and deciding how goals are reached we will be reusing these. Its possible several stakeholders are going to have the same goals; at that point i will sometimes consider creating a higher level motivation view showing just how the stakeholders and goals fit together. You can create as many motivation views as you need to tell the story of how your architecture is motivated.

When creating assessments its very easy to end up with statements like “we need to do ” which could end up as goals or requirements – I try to avoid requirements until later and will sometimes reword elements to avoid confusion. “We need to automate” might be a good example. This could be a driver of a stakeholder, or it may be a goal, or even a requirement. You need to think a little in the context of what you are doing and ask is it really something that drives a stakeholder, or is it something that’s a result of whatever drives them?

Some of my goals in figure 1 influence each other:

Figure 2 – Goals influencing

You will find talking to different stakeholders that in some areas they have a more defined idea of what they are needing. It may also be that you are already thinking about how your goals will be realized when you create your motivation view. In the example we can see our goal isn’t really fully realized until all the goals below it are met. Sometimes you will have this level of detail at the outset – other times this will come up later in design conversations. Motivation views can go through several iterations, as can any architecture view. Its worth mentioning SMART – when it comes to goals (Specific, Measurable, Agreed, Realistic, Time Based). More specific goals in general are more useful when it comes to actually realizing them. The more vague and fuzzy a goal is the more different possible ways there are to make the goal happen, and the less likely that it is that all the goals working together will end up in a desired outcome of your project or architecture.

Values

Goals provide value. I like to have a standard set of values that i map onto different architecture models. Values like cost reduction, risk reduction and improved efficiency will come up time and time again when management start new initiatives to improve things. Its good to get ahead of them. if next time my manager asks for a cost reduction i can show him a value, connected to a goal, which is connected to a work package (which would be created in an implementation and migration view), It would be very easy to show how we are already working towards those goals, and then reprioritize work with the management if need be.

Prioritizing goals

Sometimes we may chose to prioritize our goals. Priority may have a significant impact on project planning when we come to do implementation and migration work and when it comes to thinking about how we realize our project. In BES we use MoSCoW prioritization (Must Have, Should Have, Could Have, Won’t Have).

Figure 3 – Our Prioritized goals.

Representing Out Motivation To Stakeholders

ArchiMate is a fantastic way for architects to iterate through a design process; and more important than the actual views we create is the process we are running through of identifying stakeholders and connecting them together with the drivers and goals.

I would always think twice before sharing a motivation view with a senior stakeholder in the organization. They can look complicated and do nothing for the more senior members of the organization, beyond maybe showing that architects are doing something! The value we are bringing is in making sure that all the motivations are considered, so when somebody presents a PowerPoint with our goals on, you can be sure the goals are considered from different directions, and are good.

Validating the motivation views

Its important that the stakeholders feel ownership of the architectures we create; our value comes through ensuring that the needs of all our stakeholders are being managed as part of our architecture. Its important that we get this part of the architecture right, before we go on to look at how to realize these stakeholder desires. Understanding the goals and drivers of all our stakeholders may give cause to reprioritize how we do our developments. Sometimes it takes multiple iterations to get this right, but its important to do, because without understanding the things I show today there is a real risk that a project, or architecture may not be fit for purpose, or we may never be able to show that it achieved the value or goals that were intended. There’s nothing worse than being half way through a project and then realizing a stakeholders needs have not been met and have to redesign things..

Continued in Motivation Layer Modelling – Part 2.

Getting The Most Out Of An EA Tool

At work we use Bizzdesign’s Enterprise Studio (BES). I wanted to talk a little about getting the most out of an EA tool like this, if you want to get to a more advanced level of architecture model maturity.

Yes its true, I like Enterprise Studio, but not because of any affiliation with the company; more because its a powerful tool, and after several years of working with it, I am always finding more. Other tools have some similar capabilities, and strengths and weaknesses. I am talking about a tool I currently use, and a little about some of the things we need in order to reach a more advanced level of architecture maturity.

Basic Admin

Its worth mentioning that with different tools there are different access methods. With BES, at a basic level you can maintain your access to the repository by managing users and groups in HoriZZon (their web access portal). Its also worth mentioning, if you have your own servers you can also build an environment that integrates into your organizations active directory and control things via groups, eliminating the need for much of the manual grunt work around administration, and their licensing mechanisms are fairly integrated. This becomes important as tool usage grows.

Basic Modelling

It was lunchtime. I was getting hungry.

As a tool, one of the reasons we decided to use BES in our organization was that it was easy to jump into, whilst also having a fair level of complexity underneath. Whilst i tend to use it most for modelling in ArchiMate, it also covers some other standards I use, like BPMN. At a real basic level, we have a managed repository, with the ability to check out and check in changes, and maintain a level of version control. This I would expect of any tool that has a number of EAs that need to collaborate. Basic functionality needs to be able to manage elements and the relationships between them, offering functionality to navigate the object model and create new views from that – take a look at Archimate – Looking Beyond Diagrams. The better tools out there enable you to use smart connection mechanisms where you can draw relationships, and then pick the correct relation from a list of possible relations between the two elements you selected. This is especially important when you have junior architects – it saves time if they don’t have to chose from every relationship in the language.

Considering Stakeholders

A BES architecture repository can be exposed out to stakeholders of architecture via a web browser using Horizzon. It’s really important to try and get stakeholders engaged, and to do that sometimes we hide ArchiMate, by changing graphics and simplifying things.

How simple model or represent architecture depends on who our stakeholders are for a particular view. Getting stakeholders connected to what we model is an important first step in getting them to start to see the value of the work we do. Being able to traverse the model gives a level of power by itself. Horizzon gives a lot of power and directly connects to the repository for up to date information, Some tools allow HTML outputs, which is also handy.

Appending Basic Information to a Model

We can easily import information into a model a whole bunch of different ways – starting with the basic updating and creation of elements and relations. You can within BES you can use new multiple and easily just copy and paste things from excel for quick addition or updating of elements and their metadata

Its possible to apply a level of automation to that. We can create connections to Excel workbooks, SQL, ServiceNow, and automatically refresh parts of the model package or update them, and we can do mapping from different data sources into the model These are things that take a bit of knowledge and getting used to – but on the most part, you don’t need to be a developer. Basic information can be pulled into the model quite easily if you think a little about how you are formatting it as part of the project that you are working on.

Working With Metrics & Avoiding The Metamodel

I have a love/hate relationship with the meta-model editor, and as a policy where I work we don’t edit it. Some tools work with meta-models easier than others, and working with the meta-model editor that BES has provided lead to some fairly painful mistakes. Its a very flexible and powerful thing, which with a bit of experience can be used, but I don’t often find I need to customize it. In older versions of the tool every time the tool needed upgrading, the meta-model would need redoing – but a lot of new features have come along that make it significantly easier now. As a rule though I tell people not to touch it because when you don’t know what you are doing you can break things in spectacular ways.

When I want to append information to an element these days, mostly I add metrics to the element that needs to contain information. From there its easy to create colour displays or play with labeling to your hearts desire. There are some restrictions in this technique.

Scripting

BES has a really powerful scripting language that sits behind it; you can use it to do all manner of things including creating views, tables of information, modifying the model or colouring the existing model. You can create custom scripts to keep metrics up to date.

The more information you get into the repository the more value it brings. Its good to be able to traverse the portfolio in a number of different ways and represent different things on the same model..

Workflows

Something really cool is workflows – I haven’t used these as much as I would like. Being able to create a workflow in BPMN and then apply it to a model package so we can have approval workflows for example is very cool. We can also use this for getting stakeholders to update specific properties, so we can update our information from the browser without even having to open a modelling tool

API Integration

Here the possibilities start to get a bit insane. I was thinking the other day about building a C# app to pull architecture concerns out of Jira and automatically create/update views in BES. But you could do so many things. What about building your org charts from scanning your active directory? Or pulling a project roadmap directly from a tool like SharePoint? What if we can model our financials? Currently the BES API supports data enrichment; between the API, scripting and other methods I mention today, an imaginative developer can achieve can achieve a lot of cool things.

Creating these integrations have benefits in a number of directions – when you start to expose different information sources, you can not only build models that are correct and business relevant. Doing this sort of work also teaches us a lot about the data consistency and hygiene of our various information sources

Summing It Up

When you start to get to the point where all your different organization sources are being pulled into a repository we can start to connect and traverse them in exciting and interesting ways.

If you are working in an organization that does everything in Excel, PowerPoint and Word, and doesn’t leverage the benefits of technologies like Power BI, I would stop and look at your Enterprise Architecture. Chances are you are spending a lot of time in meetings, and are spending a lot of time looking for the right people and information, rather than focusing on business. Automation doesn’t make people redundant – it enables them to stop doing trivial work so they can focus on things that are important.

It takes time, money, and some developers to truly leverage the best value out of a Tool like BES. The problem I have always seen is a struggle to put together a business case for it. We can save a huge amount of man hours and communication overhead, but calculating how much is hard before you have taken the time to make the connections and make your organization more traceable through its EA.

Tools like BES are pretty expensive to own. We can also spend a significant amount of time and money customizing them. I would suggest that the value of such a tool is unlocked by how you use it – Its worth spending some time in training. The tool is nothing without a good EA behind it, with a bit of imagination, and a little bit of time and money from committed stakeholders. Do that, and you won’t be thinking about your tool spend, because you will be using your tool to unlock your existing information sources and reusing them in creating new views in exciting new ways, rather than just manually modelling things from unmanaged stale data sources like PowerPoint.

Working With Deliverables

Following my previous blog on Working With Projects & Dependencies I wanted to say a little on working with deliverable’s and avoiding some pitfalls.

I wrote this blog to address some trends I am now seeing with new architects modelling implementation and migration architecture for the first time because its really important to get this right. This is aimed at beginners.

What is a deliverable?

The ArchiMate 3.1 Specification says.

A deliverable represents a precisely-defined result of a work package.

Figure 1: Projects & Deliverables

So simply put, when we do work in a work package, we expect a result. Work packages realize deliverables & in my last blog I showed how I manage link dependencies from one work package to another by accessing (reading) the deliverable that is realized by another project.

Its not the only way we can work with this, but its a way that works.

Common Issues In Naming Deliverables

Correctly Scoping The Name

Each element in an architecture model is reusable and may be used in many views. This means you need to be specific to the context you are modelling in. For example lets say we name our deliverable “High Level Design Documentation”. It is a fairly generic name that would be an object that many architects may want to use. When we are thinking of using specific elements in specific contexts we need to get this level of abstraction right. If we are documenting an element named “High Level Design Documentation” then we can only document things that are specific to all high level designs (HLDs). if we needed to say something specific about a project, we would need to name it in a way that’s identifiable as a project specific element; Its far better to name it “Project A – High Level Design Documentation” in such a case.

I spoke about this in my blog Documenting An Architecture Model.

How we scope the element is dependent on how we will use it. In the case of “High Level Design Documentation” – If every project has exactly the same requirement to deliver exactly the same type of document its tempting to just reuse the same element on each project. That’s a really bad thing if you are trying to dependency Map because then every work package would have a relationship to the same element and you would have no way of differentiating between the different deliverables. Figure 2 is an example:

Figure 2: Using same High Level Design Documentation element (A bad idea)
Figure 3: Navigating High Level Design Documentation

The view looks easily understandable but it is bad in the when we look at this in the model. In figure 3 we can see the relationships for the High Level Design Documentation Element. There’s no way of telling that project A can run completely independent of project C, because project C accesses high level design documentation, and there is no difference between the element realized by project A to the one realized by project B or C.

Correctly Scoping the Element With Specialization

So if we want to show we have a standard high level design and maybe have the documentation of that element reflect the standard, what do we do? The solution to this problem is simple. we use a specialization.

Figure 4 shows several deliverable’s being a specialization of a standard deliverable.

Figure 4 – Specializing a standard deliverable.

Confusing Deliverables With Requirements Or Goals

I have seen sometimes people define deliverable like requirements – where people are thinking about what a project needs to do, rather than what a project needs to deliver. You can think of a set of defined deliverable as a checklist of things that a project should produce. In general I don’t go crazy with this idea. If you saw my blog on High Level Design you could see a design can be composed from many documents, and If I did decide a HLD was a deliverable I wouldn’t model each document, unless I have a very special reason to do so.

In fact if a high level design is part of our standard project documentation – I may not model them specifically at all (See Just Enough Architecture). Some examples of deliverables:

  • Project Standard Documentation
  • Fully Configured Production environment for Project X
  • Updated InfoSec Policy
  • A Deployment Process
  • ISO27k Audit Policy Pass

Looking at the deliverable above you can see a deliverable can be almost anything. I nearly didn’t include ISO27k Audit Policy Pass. The reason being that although it may be a deliverable, its easy to confuse it with a requirement. Deliverable’s are effectively an outcome of the work done to realize a requirement, or goal.

In the documentation for the elements above I might specify further what we need to achieve that deliverable. For example I might elaborate on “Fully Configured Production Environment For Project X” by saying something like:

Production environment implemented and documentation of its acceptance provided by operations and the all the stakeholders shown in the view “Project X Stakeholders”

We don’t need to write a book, but we do need to be precise; specific and measurable.

Focusing On Delivering Documentation

Ok, there are times when documentation is key to the progression of other projects and dependencies, and documentation can definitely be a deliverable. Don’t get lost in doing architecture there – our goal at the end of the day is to have projects deliver value, not to only document. One of my own managers favorite sayings is “Build the hospital, don’t only design it”. The message being is we can spend a long time trying to design a perfect thing, but unless we have a practical implementation for it, its useless. For that reason when looking at any implementation and migration architecture in my own company, we always look to see if there is a deliverable that goes beyond documentation. I think this is good general advice, but I mention this especially for my own architects…

Modelling Too Many Things At The Top Level

In figure 4 we showed Standard high Level Design Documentation as a common deliverable. Standard high level designs may be composed of several documents, and unless there is a very specific need we do not want to model project specific instances of all of them. It would be better to create a view showing the composition of a high level design like in figure 5.

Figure 5: High Level Design Composition View

Summing this Up

This blog was really targeted to address some issues I am seeing right now from some people that are new to modelling completely, and I may have repeated things that I have said in other blogs, but I hope other people find this useful. Having a well defined set of deliverables really helps set expectations.

Working with Projects & Dependencies

This blog runs through some basic dependency mapping that we are doing within my team, and the approach I sometimes take to manage project deliverable’s in a large scale project environment.

There are many different approaches that can be taken to do this, but i will show how i am doing things now.

Road Map Level Dependencies.

Figure 1 – Road map dependencies

You can see basic dependency mapping that we did in BiZZdesign Enterprise Studio (BES). We have three projects; they are work packages in ArchiMate that are pinned to a timeline.The arrows between them are triggering relationships; Project A triggers project B, which then triggers project C. These relationships are causal. In BES creating a “Roadmap view” enables us to easily shift these things around.

The warning triangle is shown because project C is starting before project B is over. When we are doing agile project development each work package should have well defined deliverable’s and is well scoped with goals which are sufficiently defined so we can measure the success of a project.

Dependencies in the I&M Views

In Planning Work In Archimate I introduced an Implementation & Migration view – which shows a work package with a dependency, Within this view you can see the work package and deliverable’s.

Figure 2 – Realizing deliverable’s

In a larger scale, different architects may be modelling these packages with managers, and we will typically have those views for each project. This is good for individual projects but doesn’t work if we want to understand dependencies across the top level for all projects. The view above may also include dependencies on other deliverable’s. Its important that we get project managers to sign off on these views and document that somewhere, because as projects get more complex, its easier to have discussions on roadmaps with leadership teams where the different project owners have committed.

Real World Deliverables.

So in the real world the triggering relationships between work packages like shown in figure 1 are often not enough. Projects sometimes have several deliverable’s delivered within a project timeline, or other projects outside our project scope need them. Sometimes projects start early or are run at the same time because management will apply pressure to “start now” (also known as “jumping the gun”). Take a look at Figure 3:

Figure 3 – Dependencies & deliverable map

When talking to different project teams about deliverable’s they will state dependencies on other deliverable’s in other projects. when drawing those together I use accessing relationships – for example project C within the view above reads Deliverable B. In taking the deliverable centric discussion if we are looking we have discovered a new dependency shown here in bold. Project E should not start until after Project B.

Figure 4 – Additional Triggering Dependency

To my mind, the best scenario is when work packages have dependencies between each other. Project C or Project E should not start until project B is completed. Work packages should have resources allocated so they can start, and continue to the end focusing on a clearly defined goal, and once that is achieved, move on to the next thing. Its well known in scientific circles that people cannot multi task. The triggering relation is a causal one, perfect for expressing one thing starting after another. Realistically though, I don’t always get my own way, so triggering one project after another doesn’t always work for me in the real world!!

The reason my deliverable dependencies are denoted by accessing relationship is that work packages can exhibit behavior, but deliverable’s are passive structural elements; so we cannot use triggering relationships.

Figure 5 – The navigator view of Project C

When running through this exercise of mapping with different project teams we can build much more realistic road maps, avoiding chaos when knowing the exact impact when a project is either delayed or stopped. We often draw the final road maps without the dependencies – and its quite often when projects are running their own individual lives that nobody keeps track of a dependency & deliverable map. In having this we can help inform our stakeholders and help them make better decisions when prioritizing projects. If we just look at the navigator in figure 5 you can see for project C that the dependencies for the project are easily visible; they are accessed. The deliverable’s are very visible, they are realized. Project to project dependencies are shown and easily understandable Note, there are some extra objects on that package where I have used project C in other blogs.

Focusing on the deliverable

In figure 1, I showed a dependency relationship with warnings. Sometimes that cannot be avoided for reasons outside of our control. I recently removed all the dependency relationships from a road map just because they made it too messy and complicated.

In cases where the project structures look messy I will sometimes create a road map with deliverable’s only on it, so i can see delivery dates rather than the projects themselves.. Most management do not need exposure to a view like in figure 4 – but its essential for project managers to understand these dependencies between projects, because without understanding dependencies project plans are likely to be unrealistic. there’s nothing worse than a project getting half way through and then discovering they will be delayed because another team hasn’t delivered something important. In an ideal world strict project discipline and work packages are defined to deliver single agile work packages. As things get larger scale things often get more complex, and this blog demonstrates a technique I have actually used in order to dig into some of those complexities..

Using Associations To Denote Dependency

I would like to say thanks to Eero Hosiaisluoma for pointing out two things. First I had inadvertently reversed the directions of my access relationships in the original article. Second was pointing out that in Archimate 3.1 we can also denote direction on an association relation, which we could use instead of the accesses relations. Where I work our standard is ArchiMate 3.0; so I didn’t even think to mention this.