Getting The Most Out Of An EA Tool

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

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

Basic Admin

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

Basic Modelling

It was lunchtime. I was getting hungry.

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

Considering Stakeholders

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

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

Appending Basic Information to a Model

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

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

Working With Metrics & Avoiding The Metamodel

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

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

Scripting

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

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

Workflows

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

API Integration

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

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

Summing It Up

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

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

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

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

Working With Deliverables

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

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

What is a deliverable?

The ArchiMate 3.1 Specification says.

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

Figure 1: Projects & Deliverables

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

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

Common Issues In Naming Deliverables

Correctly Scoping The Name

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

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

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

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

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

Correctly Scoping the Element With Specialization

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

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

Figure 4 – Specializing a standard deliverable.

Confusing Deliverables With Requirements Or Goals

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

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

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

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

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

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

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

Focusing On Delivering Documentation

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

Modelling Too Many Things At The Top Level

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

Figure 5: High Level Design Composition View

Summing this Up

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

Working with Projects & Dependencies

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

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

Road Map Level Dependencies.

Figure 1 – Road map dependencies

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

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

Dependencies in the I&M Views

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

Figure 2 – Realizing deliverable’s

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

Real World Deliverables.

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

Figure 3 – Dependencies & deliverable map

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

Figure 4 – Additional Triggering Dependency

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

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

Figure 5 – The navigator view of Project C

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

Focusing on the deliverable

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

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

Using Associations To Denote Dependency

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

Requirements in Architecture

This blog talks about requirements in the context of architecture design – including their importance and some bare minimum needs.

If you have read ISO42010, the ISO standard for architecture description, you will realize how important requirements are. They are how we define the needs of our different stakeholders.

Similarly, if you are using TOGAF, you will see requirements management right in the middle of TOGAF ADM. Generally speaking i tend to think we can manage requirements at different levels, depending on the context of what we need to do, and who we are doing it with.

High Level Requirements with Management

When discussing requirements with senior management I am thinking at a really high level; where we dont want a million requirements with lots of information captured with them. I tend to think in terms of user stories. Those meetings are not normally disciplined meetings where we strictly define “As someone i want to do something to achieve some value” – Although at the end of the meeting i want to have enough information to be able to write those statements – I will typically ask the questions like:

  • Who needs to get value from this?
  • What is it that we need?
  • What value does that bring?

…In taking that approach in a more discursive meeting you have to be very careful – i find its really easy to get into long meetings where you discuss whats needed, but loose track of what the value is that’s brought.

Defining the next level of detail – Capturing requirements

The user stories are great for talking with management, but they are not really enough to be actionable by themselves. We need to refine our requirements into something that is actionable, and clear for anyone working with a design. Its not unusual in a big project to have many high level meetings, and have many stakeholders that need to get value – at this point we need something we can practically work with in design. I need to capture requirements in one place- be it Confluence, Excel, or in a formal modelling or database tool. If its not in one place, its very easy to lose requirements.

There are many things you can ask for but again speaking of minimums to look at as part of an initial architecture definition phase:

  • What is the source of the requirement? Who did it come from? A specific team, person, project or role?
  • What is the destination of the requirement? Is this a requirement coming towards us, or is it a requirement we will need another team to manage? For example if we have a website, the database back end may be run by a completely different team, which we may have the requirement for.
  • What is the actual requirement? The definition of the requirement – it should be as clearly stated as possible and not ambiguous – someone is going to have to validate the requirement has been met. Saying “we need a fast database” is subjective – saying “we need 5000IOPS from the database storage” is a lot better defined – and significantly reduces the risk of miscommunication
  • What is the rationale of the requirement? The reason behind the requirement – It can be simply stated such as “ISO27k Compliance”, “Customer requirement”, “Needed to by the quality team”. Its very often skipped, but is very important because requirements are read by many people from many teams, not all with the same understanding of things. Solutions & Requirements can live for years and its easy to forget why you do something. If you come back to an architecture design with a need to change it later you will be thankful for this – it saves you having to spend countless hours understanding why we do things.
  • What is the priority of the requirement? Commonly I use MoSCoW for this (Must Have, Should Have, Could have, Won’t have). In any given release some things are more important than others.
  • How do I identify requirements? Its worth mentioning that requirement IDs are a good idea to identify right from the start because the exact wording of a requirement is sometimes refined and its easier to speak of specific IDs in general.

Not describing any of the things above will only leave issues later.

Managing requirements once they are defined

During an architecture design project we need to work with each of the requirements, to ensure that they are met – and to show how. Requirements Realization is a whole topic by itself. I spoke about this in my blog Assessing solution requirements – There’s a whole lot more i would like to say on it should I get the time; some of the things i say in that blog are covered in here, but the focus is different. – but the basic things we need to capture are:

  • How the requirement is realized – is it by a specific tool, a specific business process, a specific automation? This is one of those things that are often discussed in meetings, but then sometimes not captured in design – if you ever came back to a project after a year and tried to figure out why someone had made a technology because you want to change something, you may feel pain if this isn’t done. It can lead to huge investigations and many meetings with people which in some cases i have seen thousands of hours being burned. In the absolute worse case you may actually lose this information entirely because people have lost of forgotten.
  • The status of the requirement – different requirements can be in different states – the basic statuses of requirements i would say are – Proposed, In Progress, Implemented, Verified, Deleted, Differed, Rejected.
  • Who’s working with the requirement – on a big project with more than one architect its good to name which architect is being responsible for managing the requirement and ensuring its properly realized (if need be).
  • Activity Log against the requirement – sometimes the whole architecture design process will have a work log and in there you can show what is needed – but sometimes is better to have a log of activities against each requirement – nothing big, just date, whats happened, and who has done it. this way you can keep track of things in a complex project.

Summing it up….

As i said, these are really minimums – I have seen many variations on the above, but have found if you haven’t considered the things I have written about above there is almost certainly going to be an overhead. at some point of time someone will have to run meetings, or investigations to find out what or why something is a certain way, or someone may do something stupid simply because they are not aware of the relevance of a specific piece of architecture. Without properly defining requirements we simply cannot ensure a technical design is fit for purpose.

There are lots of things to consider. but properly managing requirements will radically improve both quality in architecture, and success in project management.

Architecture Principles

This blog quickly runs though some basics on architecture principles & how I use them.

The company I work for, has a specific set of architecture principles. Within our hybrid Infra team, we limited it to 5 principles so it would be easy for all architects to memorise and learn them. Whenever someone comes to me with a design idea, or an architecture to review, or even an architecture concern the first thing I do is in the back of my head, think about architecture principles. Principles are in the motivation layer of an ArchiMate model.

I tend to think of a principle in architecture as being the same as a principle in the real world – its a rule that we strive towards achieving. The ArchiMate manual defines it as a statement of intent or general property that applies to any system in a context.

An example principle

I will use a simple example principle. Lets say our architecture board established a principle “Systems must be available 99.9999% of the time”

When we define a principle, it should be a simple statement like above, but normally there is a need to document further the exact meaning and scope of a principle, as well as its issuing authority.

If it was a principle applied to our unit, or is in scope, in our design documentation we would state it – and we could connect it to a set of requirements like this for example:

We might decide that we will not be able to achieve a principle. having a high resilience is often expensive, and we may have a requirement to keep costs low, or to implement interim solutions quickly. The important thing is we:

  • identified the principle
  • identified how we meet it
  • if we cannot meet it,we identify that we cannot meet it
  • We flag principles we cannot meet
  • We have it agreed with the relevant stakeholder that it is OK to go against the stated principle.

Establishing new requirements

When I drew the view above for the fictional web hosting solution I have sometimes developed in my blogs, i quickly came to thinking of many requirements. I used “…” to represent them above for brevity, but this is another important part of working with principles. Automatically when I started to think about the principle I started to ask myself the question “What do i need to do to achieve it?”.. Suddenly, I started to think about the IT Architecture Aspects and think, I would need to consider people and resourcing, to have resilient processes in place, and so on. Many requirements started to come to mind that I might capture. I may also identify risks when we cannot meet principles.

Had this been a real project i would be validating the principles against the requirements, and I may even define new requirements to meet the needs of the specific principles. I would of course also make sure that in addressing the principles all relevant stakeholders and actors stakeholders were considered.

Of course we do not have to do all our work in ArchiMate, but its a good flexible approach.

Authority

Principles have owners. If a leadership team sets a principle, then I would normally say that that leadership team (or someone they nominate) needs to approve any deviation from that principles

Summing it up

Many times I have worked with architectures and stopped work happening early. because I know our principles by heart, and can state that doing something would be a risk and go against our defined business needs.

Principles are a very good way of representing the intent of an organization, unit or specific stakeholders. They can ensure that all the work architects do head in a commonly defined direction.