ArchiMate isn’t only about drawing views and relational models. Understanding the language fully helps how we shape our architecture.
In a meeting last week there was a fairly lively debate about architecture design. In that meeting we had some people wanting to comment the semantics of the ArchiMate language (the more analytical people). Some people were just wanting to understand the relationships between the applications. Quite a lively conversation ensued, and want to share my thoughts on this.
Architecture Tells A Story
I have spoken about Storytelling in previous blogs. In ArchiMate terms, a view of architecture is created for a purpose for a specific audience – its defined in the viewpoint definition. So its important we address the intentions in the viewpoint definitions.
Following ArchiMate Standards Help Structure Architecture
Using the right elements for the right things is important when it comes to wanting to generate specific views. For example If someone mistakenly stated “ISO42010” as a strategic capability rather than “ISO42010 Compliance” as a requirement, then if I want to automatically generate a view of our strategic capabilities, I am going to have things on there that don’t make sense. If many elements have incorrect definitions or relationships between them then the usage of the model as a whole is greatly diminished.
Understanding the elements and the metamodel fully is key
Understanding and using the full metamodel properly gives so much more than just defining elements and relationships. Services are a fantastic example. Rather than building one massive view of interconnected application or technology components, breaking things down into smaller services gives us opportunity for reuse. This can be done at the business, application and technology level. Building a service is like building a Lego block. You can think of the block as being a service – and the interfaces to that service being the connectors like this:
We can build our services in several layers of course; either stacking services, Business on Application, which sits on Technology – Alternatively our Lego block here could also contain elements from other layers. It could be argued with the example above that the interfaces for directory services or databases shouldn’t be there – because they are part of the internal make up of the building block, but this is one of the key things we need to decide when building architecture – what are the logical blocks that make the most sense for reuse, what is internal, what is external. We are building architecture building blocks. Within our services of course there could also be sub services within these building blocks – so one building block can be made of others. I previously wrote a little on Services In ArchiMate that goes into a little more detail on the subject of Services.
I have already spoken extensively on the benefits of having an architecture model rather than word documents, and an ArchiMate relational model making it possible understand the implication of change, but in understanding how the elements and relationships in the metamodel come together to create a service base thinking we truly start to see some real power.
Putting it all together
At the end of the day, we want to be able to do this:
We start to build standard architecture building blocks, with standard interfaces. connecting into standard services we unlock a myriad of advantages – We can can more efficiently reuse our resources, and we can put our services together in interesting new ways. With Lego the focus isn’t on the blocks – its what you can build with them – the same holds true in architecture.
Summing it up
How we model something and follow the language of ArchiMate is important. We don’t just want to understand the elements, or only have a relational model, we also want to ensure what we are doing is building architecture building blocks that make sense, and make it easy for us to have reuse.
Practicing architecture in this way may mean a learning curve for architects but its key for making efficient use of a companies resources, and maximizing the benefits to business.
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.
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.
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.
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
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.
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.
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.
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.
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.
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:
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
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.
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.
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:
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.
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.:
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.
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.
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.
Benefits of consideration
Risks of not considering
Knowing who your architecture has to provide value to makes sure you design something that meets everyone’s needs
If 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.
Understanding why your stakeholders need to do things helps you ensure the goals we set actually provide value
If 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
Understanding goals helps us determine both our direction, and our criteria for success
Not capturing goals means badly scoped projects, unclear success criteria, which can lead to inefficiency and a loss of traceability and control of spend.
Help us ensure that our requirements are meeting our goals
if we dont check outcomes against our requirements is possible that our requirements do not collectively meet our goals.
Help us ensure that the things that we are doing are meeting the design principles laid out by the relevant authority
Possibly creating designs that violate principles and do not work in the best interest of the company
State the things we need to do in order to achieve our goals
Not 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.
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..
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.
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.
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:
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.
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.
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).
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..
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.
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.
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.
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.
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..
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
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.