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.

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.

Understanding Architecture Value

Value is a key focus area of architecture which is often misunderstood. This blog explores this subject..

Value & Professionalism

It has sometimes amazed me how far architecture can be devalued in an organisation. As an Enterprise Architect, I have not only had to show the value to different business stakeholders, but on occasion I have even had to explain it to architects. The reality is, there are a lot of misconceptions around what architecture is and what architects should do. I started to explore expectations in my blog “What is an IT Architect?” because I wanted to get consistent value from my architects.

Getting our stakeholders to understand value can be a hard nut to crack,. They often have their own ideas of what architecture is which normally revolve around technology. I have found the differentiation between a technical specialist and an architect can sometimes be blurry in the minds of our stakeholders. Communication of the different aspects of architecture in a language that stakeholders can understand is essential.

As architects, It’s very important that we work to ensure we are not perceived to be a painful function by our stakeholders. This happens if architects go from meeting to meeting just criticizing other peoples work. It starts with a mindset.

Stakeholders need to understand that, as architects, we are working with solutions and not problems; we must be encouraging by nature and we must take time to express things in terms of positives and growth where possible. We want to be working with our stakeholders rather than against them. Our role is normally to advise – at the end of the day architects do not usually own the business. If we ask rather than tell, engaging our stakeholders with a positive attitude, we can show our value as architects, the value of architecture, and our stakeholders can become the architecture marketing department.

Showing value enables an Enterprise Architect’s stakeholders to look good. This helps us gain stakeholder commitment and makes life easier for everyone at the same time.

For me personally, the best moments come when someone who is not an architect stands up in front of an organization, shows some of the things that we have done together and passionately shows the value that has come through a project, attributing it to architecture not because they have to, but because they genuinely see the benefits, and want everyone else to.

The Reason I Started To Internally Blog

One of the reasons I started internally blogging in my company was that I could not get enough face to face time with stakeholders to express architecture value. I had to show them value by influencing the people around them.

When management has multiple escalations and start to breach service level agreements, they will often start to search for a root cause. Not having architecture is akin to not planning and not managing risk.

In those cases, where poor planning leads to a risk being realised we do not scream “I told you so”. It’s an opportunity to show how as professionals we can help. In those situations normally people are under a lot of pressure.

There are are a lot of techniques we can apply to help identify issues, and when we have a model repository in place, with a competent architecture team we can not only help with solving architecture issues as they are unfolding but we can also put in the steps to ensure those problems don’t happen again. Having a good architecture concerns management process helps with that.

Planning Work

In order to get a baseline of consistency and understanding the blogging helps a lot. Normally I have meetings where I explain things, as we tackle practical problems but if in a meeting i am introducing a lot of key concepts its easy to overwhelm people with the technical side of architecture.

As an example the first time I introduced mechanisms for work planning with ArchiMate. At the backbone, even though i simplified it, still some people didn’t quite follow. The Planning Work With Archimate blog helped. It gave people a reference they can follow at their own pace. It helped me because I can set a consistent expectation.

I think its the most popular blog I have at the time of writing this blog; its been re-blogged and shared a few times, and received a few comments, which is fantastic.

I think the reason for its success is a lot to do with the fact it has clear value. It offers an easy way to use the ArchiMate modelling language to track and define work; which can be challenging – especially if your architects do not have direct line reporting to you.

Capturing the value from stakeholders

To begin with, I think its a mark of any professional that they think about value regardless of what is being done.. It’s a general life idea – if you think about who you are doing things for, why you are trying and try to anticipate needs, the chances are, your resultant work will be better.

Normally at the beginning of a project I am establishing requirements; I sit down with the team and create a series of user stories.

To my mind if you are having trouble defining fully formed user stories for your work, the chances are you need to talk someone and get a little help in understanding the needs of the stakeholders. Most commonly when I see user stories go wrong its because people have missed the bit at the end that speaks of value. It’s interesting to see how often people cannot directly express the value in the things they do; its common to think because value is implied it doesn’t have to be explicitly defined. The problem there is what is an obvious value for one person is not always obvious for another.

In architecture ISO 42010 they give a good ground list for types of stakeholder to consider in our architectures.

Understanding and taking time to explicitly define the needs of our stakeholders is the first step to building an architecture that maximizes the usage of the architecture and its value to all stakeholders.  When we validate an architecture that we have created with a user story we are validating the creation of value.

Why Doesn’t Architecture Always Bring Value?

Not correctly practicing architecture leads to not getting value from it. If an architect starts the architecture work after a project, or views the creation of architecture as a documentation exercise, its normally lost most of its value.  If an architect only concerns him/herself with producing a couple of technical diagrams, again, its lost a lot of value.

Much of the value in architecture is in its application and the process taken to define it. How we decide what appears in the documentation, all the decisions made around the architecture, as well as the needs of all the stakeholders should be managed & documented as a project progresses for architecture to achieve its intrinsic value. 

A Common Problem With Commitment

Because stakeholders don’t always understand what architecture is or how its practiced, it simply isn’t practiced in some cases.

We can have a good group of people that want to do architecture but are not given time. In management terms, architecture is often measured in documents, because these are tangible:

Its easy to see architecture as a documentation exercise if you are working with processes that demand specific types of deliverable, because the emphasis is on the resultant documents. If you write a description of a service it makes sense to plan the service, consider risks, agree the service, and capture the reasons for it. You have to give architects time to plan and think. That thinking time should be spent properly – preferably following some kind of methodology where the thought process is documented.

Even with a management commitment of 70% of an architect’s time allocated to be spent doing architecture, there can still be a fundamental gap if our stakeholders do not understand that architecture process is much more important than these documents.

If architects spend a majority of their time just filling in documents for management, technical writing or building presentations, they will not have time to actually follow methodology and design. Every view an architect does is to manage a concern from a specific stakeholder – therefore you can say every view that is not completed represents a risk that a stakeholder hasn’t been fully considered. Time must be given to do baseline architecture and analysis. It improves the quality of the resultant work and more importantly it ensures not only architects provide value, but their designs do.

A good architecture designed by a proficient architect meets the needs of its stakeholders and shows how it does that – it identifies and mitigates risk. On the flip side, a document that is put together without architecture design is likely to lack good quality. In these cases you will normally see failures in operations – either lower productivity where things are not efficient – or in complete failure of process leading to penalties.

Value In Architecture Modelling

I’ve heard it said a few times that architecture is about drawing boxes; even from some architects. It’s not. 

First the obvious. The tools we use are modelling tools not drawing tools. Most people see an ArchiMate diagram in a presentation and miss the true power behind it – because our views all contribute towards a fully relational model we can easily traverse the model using our tools, and more importantly can use it to easily help management understand the impact of change – at the simple level architects can navigate the model – like shown here – for PRTG Network Monitor:

We can expand out those nodes and see all the relationships, to other elements, and then drill down through those.  We can reuse the elements int he model in different ways and generate views. The more information we put into the models, the more value we get out. Each of the elements and relationships can have its own documentation. Seeing a picture sent in mail is nothing like having the interactive model implemented and available to traverse.

The act of modelling with a proficient modeler building a standard view – nearly always raises questions on how things work, and which things should be connected to other things; these questions open up areas that can easily be forgotten, and its better for the architect to think things through in design phase with stakeholders, than to blindly move onto executing a project. The costs can be very high if part way through a project you need to scrap everything an start again, and architecture can help prevent such things happening.

In addition to all of this we can apply metadata to an architecture model – making it possible to represent a myriad of different interests to our stakeholders, if we take time to model, and use the right information sources; and then use our models to inform and enable our business leaders.

Summing Up The Value Of Modelling

I will sum up some of the value of modelling architecture:

  • Consistent communication – everyone get the same views in a repository and common understanding; there’s a reduction in communication overhead.
  • Enabling Scaling – having consistent communication in a common place makes it easier for us to on board new resources, and for many architects to work together in the enterprise.
  • Reduced time to find things – Navigating through a model from element to element enables us to easily find related information quickly.
  • Can abstract many views from the same model. As you develop some views with relationships, you enable automatic generation of other views reusing the same information
  • Reduction of work – If you rename an element in one view it renames it in all views – in the same way the element documentation is automatically reused.
  • Cost savings – having architecture modeled gives us opportunities to easily see and optimize architecture, as well as to identify risk.
  • Better more reusable architecture – modelling forces us to break down complex tasks into reusable components.
  • Reduced complexity – in a model we can focus on only parts of it in different views to make it easier to consume to different stakeholders.
  • A model develops itself – as it starts to mature using algorithms we can find new relationships rather than have to explicitly state them.
  • Better understanding – at the same time as we establish new components, it normally raises new questions around how things fit together and forces us to think. We can also very precisely and easily model and understand the impact changes in the technology, organization or other architecture layers have on our architecture.

The value of ArchiMate

The Archimate full model shows the different layers that make up ArchiMate. Each layer contains different types of elements in the modelling language – for example we have Business Layer business services, Business functions, business processes. 

The ArchiMate language specifies the different types of elements and the ways that they are allowed to connect. You can see that ArchiMate covers everything from the why (motivation layer), to the what (Strategy, Business, Application, Technology, Physical & Implementation). This enables us to represent how all of these things work in conjunction with each other. 

Following the strict rules of the ArchiMate language forces us to think a certain way – to consider our internal working components and how ex expose them out in different layers. It also has the added benefit of enabling us to derive relationships. A simple example – Owen is related to Max, and Max is related to Christopher – and we could represent this on a model with the association relationships. Even if we do not explicitly say it; because we know these relationships exist the modelling software knows that Owen is related to Christopher. More complex derivations exist – which means that as we mature a model,, it starts to provide value beyond what we directly model.

Summing Up The Value Of Archimate

To sum up the value of ArchiMate:

  • Internationally known standard – each element and relationship has a very specific meaning. using this standard i can take a model from a completely different company and understand its meaning.
  • Multiple layers – breaking down into layers such as Business, Application, and technology, enables us to align to many standard methodologies such as TOGAF, and to easily differentiatiate these different concepts.
  • Better architecture structure – Because ArchiMate has strict rules on what can connect to what, and how elements are used it forces us to think in a more service oriented value driven way.
  • Better connected architecture – Essentially with all the layers together we can answer the questions what, why, when, how, who? The layered approach make it very flexible.
  • Better intimacy with stakeholders – Because we define viewpoints for each of the stakeholders we can provide better value for them and get 
  • Aligns to ISO 42010. Archimate as a language was designed to complement ISO 42010 and make it easier to conform to this standard. ISO42010 introduces concepts of elements and relationships – Archimate creates different types of these elements and relationships, that reduces the amount of work we need to describe concepts.

The Value Of ISO 42010

I speak about ISO 42010 quite often because it lays down the things you need for an architecture to be completely documented.

Everything in ISO 42010 has a purpose and everything that we do not do in there could be represented as a risk.

Its great we do Visio diagrams  with infra and we cover some technology, but for these Visio views to be valid we need to understand the decisions that are made related to them. We need to understand the concerns that different people who need the systems we design have, which includes things like risk. We need to understand how it is that the Visio diagrams produced meet the needs of different people. ISO 42010 lays down a structure that could be used for this.

When you run through an architecture and ask how each individual requirement is being met by the architecture you provide, questions and concerns start to arise. Its better for a single architect or a team of architects to sit down and address them and actually think through the design process, than it is for a project team to start booking lots of meetings with different people.  understanding the needs (concerns) of our stakeholders forms the foundation for formal risk analysis – because the risk is basically recognizing where a need might not be met for some reason. Using a managed approach to architecture concerns provides significantly better coverage of your risks.

When we enter projects there’s often a lot of people asking the same questions – who is doing what, how and where? how will the requirements be managed or realized. Its not supposed to be a project managers role to make those decisions – its supposed to come though someone smart sitting down and creating an architecture design.

Applying Discipline to Architecture

Applying discipline to architecture raises many hard to answer questions that need to be managed. If they aren’t captured and answered at design time they will come up later at some point during an escalation. If you don’t apply a method to your architecture, and do it throughout a project things will get missed resulting in project overheads, delays, and costs in both penalties and incidents.

Applying discipline helps us effectively manage change, and it helps to ensure that issues that may cause problems come up sooner rather than later. 

The alternative to this approach of following methodology is to be surprised – this is characterized for example, by getting part way into a project and realizing the active directory you had build needs to be rebuilt – or discovering that one part of the service you provide will just never work with another part, forcing you to look for some kind of bad designed compromise to meet deadlines.

ISO 42010 essentially gives us an international standard on what an architecture description should include – it enables us to build traceable architectures that meet the needs of our stakeholders, and it does so in a very scaleable way, It enables a consistency of understanding and expectation when transferring architecture from point to point. 

Explicit Value In Motivation Modelling

Up until this point its worth noting that most of the value i have spoken about is relating in generic terms to the benefits given, but of course ArchiMate and some other modelling methodologies allow us to represent values within the architecture going well beyond the generic.  ArchiMate has the motivational layer which is there to show the reason why we do things, and has an actual value element – and of course we can easily derive value normally by just looking at our goals, and outcomes.  Take a look at the example:

The example is a motivation view for an architecture concern. As part of our common practice we might connect values to our goals directly in the model. When you follow the flow of the motivation view above from top to bottom – the values become obvious at the point we get to the goal element – so we model them too.

All architecture should provide value, and in this case we explicitly define it for this requirement (Reduced Capital Expenditure, Reduced Maintenance Cost, Modern Future proof solution).

An implementation & migration viewpoint is focused on how we deliver and meet requirements, and not its value – which is one of the key reasons I also state in addition to implementation and migration, motivational modelling is also a good idea. Of course because this is part of a model we are presented with a powerful mechanism for prioritization workloads – when our management wants to run initiatives to reduce costs for example – we could easily auto generate a viewpoint to show which of our work packages contribute to that, and then we can take a discussion with those stakeholders about re-prioritizing workload in a structured fashion and understand how our other values and goals are effected in doing so.

Summing it up…

Architecture and design before doing things are an essential mechanism for avoiding risk and cost. Architecture is a discipline, and unless you take time to do things before during and after a project you never realize its value. Architects must think and be trained; and they must be given time to run through a design process that applies methodology in order to get the value. If we do this, we will literally save millions of euros in penalties, and will have better more focused projects with a significantly higher success rate. Communication overheads will reduce and better communication will be enabled.

To those who think architecture is only drawing pictures – I would say you do not understand what an architect is, or what an architect does, and would recommend you read ISO 42010; For each part of an architecture design ask the question  “does that provide value, and what is the risk if I do not do that?”

To those that leave architecture to the end of a project, I would say, you’ve lost most of the value architecture could have given you already – because you didn’t see the risks coming fully, may have missed some requirements and you likely had a communication overhead. There’s still some value in doing it so others may follow what you went through and why, and of course anything that adds to an architecture model is a good thing. 

Architecture discipline brings architecture value. I would love to hear from you. 

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.