IT Architecture Aspects

Often when we are validating IT Architecture we talk about the need to cover the aspects of architecture. This blog Briefly introduces them, and their usage.

The aspects are:

  • People
  • Information & Governance
  • Processes & Roles
  • Tools & Technology

When do we need to consider the aspects of architecture?

Always. Wether you are looking at a conceptual architecture, a high level design or a low level design we should consider all the aspects, and may make conscious decisions not to include some of them (this should be documented)

If we do not consider them usually we consider a design to be incomplete. In many companies we often talk about tools and technology, but I have often seen the other aspects missed. A technology solution by itself is rarely enough if we havent made plans on how to operate, and govern it.

Lets break it down into pieces:


Our architectures need to show the people involved in an architecture. This includes the stakeholders, and the people who are operating the solution. A design should be showing that the right people, teams or roles are involved. It should be showing who is doing what.

Not doing this risks that we may not be scale-able, or even worse, may not have the capability to operate a technology design.

Information and Governance

A design should show what information runs through a system – and how we govern it, throughout the information life cycle. Information is a valuable resource and it needs to be governed and protected. We need to understand where it is kept, how it is transmitted, and who is performing what kinds of operations on it.

The structure of the information as part of a system as well as where it is kept can have a key part in the success or failure of a system.

Not considering information and governance can have huge consequences. A lot of people consider GDPR as a first consideration because companies can be fined up to 4% of their annual global turnover (or up to 20 million Euros).

Because GDPR has had so much much attention I wanted to specifically mention it here. It is not enough to have an architecture that is compliant. GDPR is concerned primarily with personal information. Theres a lot of information out there that is not relating to personal information that also needs governance.

Processes and Roles

Within our systems we normally have processes – either manual or automated. Processes tell us in a repeatable what who does what, and when they do it. I talk about processes & roles quite often because they are key to being able to build a scalable organization that mitigates risks.

Not having processes and roles normally has a big hit to operational efficiency and scalability. Organisations can work without having them formally defined but it means that inputs and outputs might be varied, and the ability to take a top level view or have business agility is compromised.

Tools & Technology

Tools & Technology

Understanding which software or hardware are being used together, and how they are being used in order to provide the technical solution.

I don’t feel I need to explain this one too much because I think its the area of IT & architecture that people seem to understand the most.

What About The Organization?

Where I work we have added an extra aspect – the organization. Technically you could cover the Organization as part of people, but working in a large IT Service provider across many industries has meant that we specifically want to emphasize the points around organizational structure; knowing we have agreements between teams, and which teams do what…. Internally we call the IT Aspects, the Five Aspects, so people from my organization may be wondering why i only mentioned four.

Summing It Up…

Its normally fairly obvious when we have an architecture design that is not considering all of the architecture aspects. Its quite easy to come up with a list of risks associated with missing each aspect, beyond the basic examples I give.

When I look at an architecture I don’t explicitly look for a section of a document or any written statement acknowledging that the aspects have been considered – that would be too much. I am looking at the architecture as a whole.

I might see Tools & technology realized in a Visio diagram of a platform, combined with an application co-operation view in archimate, or I might see it in a series of archimate views. The important thing is not specifically how the aspects are considered, the important thing is that they are.

If we consider individual viewpoints for a moment, not all aspects are considered in all viewpoints. A technology layer view may consider tools and technology, but by design doesn’t consider people. People are not the focus of a technology view.

If you present an architecture design for review that hasn’t considered all the architecture aspects, then the chances are its not a complete architecture design, and there are going to be risks, costs, or further design needs that will have to be considered in the future.

Considering the architecture aspects is a good way to see missing parts of your design now – if you are not designing things, sure you may end up with something that works, but the chances are it isn’t efficient.

Agile or die…

When I posted my previous blog on Aligning ArchiMate to BPMN one of the comments I received read “Agile or die, this is the only fact of today business environment” – and this got me to thinking about Agility in EA.

To be honest, lets start by saying I agree with the comment – and that he gave me no reason to believe the person who posted the comment was misunderstanding anything I said.

But there are those who do…. There’s a stigma sometimes attached to Enterprise Architecture, and architecture as a whole. It’s sometimes seen as slow, synonymous to waterfall, unable to change, and an overhead in general. I will talk about the value of architecture in a separate blog, but suffice to say, architecture doesn’t have to be that way.

Agility in TOGAF

Its fair to say that TOGAF appears to be, or can be fairly document heavy depending on the choices you make in implementing it. A first point to make about TOGAF would be it is a framework that is intended to be tailored to specific needs, and does fit in well with a waterfall development technique; That said it can also provide a good backbone for something more agile.

Everything TOGAF asks for in terms of deliverables within the framework has its purpose. If you take any of those things away you leave a gap or a risk. It’s a comprehensive framework built by many smart people. As a framework it addresses many concerns from different stakeholders.

To be practical you need to think about how to adjust TOGAF. I have sat in a few meetings where we have discussed those different architecture deliverable’s and how we could adapt a Scaled Agile Framework (SAFe) model to work along side TOGAF, giving the strength of TOGAF and the agility of SAFe. It is possible to do so but it requires careful planning & implementation of processes. Processes that are well defined, with good key performance indicators can be very agile.

Architecture Discipline

I firmly believe that good architecture is a key to success in agile ways of working. Agile doesn’t mean we do not do architecture, but it may mean that we do it differently.

If you look at my blog Planning Work With ArchiMate you will see that its possible to use the ArchiMate language to define small building blocks, and then fit them together – each block expressing its own value and interfaces to the world. Although when we use methodologies like SAFe we need to consider the value of each individual work package, we also need to take a longer term strategic perspective. The approach I took in that blog facilitates agile projects as well as waterfall ones.

Change is a constant and enterprise architecture needs to facilitate it; which is another reason why languages such as ArchiMate and BPMN working together in an architecture repository support this.

I will speak at some point about ISO 42010 (I have a video blog planned), the standard for architecture design; how it fits in nicely with ArchiMate as a standard, and how it enables us to design architecture that supports our goals in a focused fashion. Such standards are essential if you are practicing architecture on a large scale. Each piece on a chess board has its purpose, and rules it must follow – each move must be part of a strategy.

It’s a matter of balance. We only want to do enough architecture to provide value; ISO 42010 provides the groundwork for this – when it describes views and view points – and the ArchiMate Language implements those concepts nicely. It takes skilled leadership with skilled architects in order to get this balance right in practice.

It’s essential we have an architecture strategy, and a good set of architecture practices to facilitate an agile way of working. You can’t be agile unless everyone knows what they are doing, how they are doing it and when they are doing it. Knowing why they are doing it can also be helpful. If you don’t have an architecture discipline then in fact architecture can become significantly less agile. To be agile we need competency and discipline; and we need to have an architecture practice, practice practice…. This doesn’t mean the solution is to do more architecture – more it means that we need to do the right architecture.

Summing it up…

Implementing without architecture design exposes all kinds of risks; it may seem that you implement projects faster, but then what you save in project development time, hits you when you get to an operational phase.

If architecture is not facilitating an agile way of working, then that architecture practice probably has a need to change, not to be abandoned. It’s important to have talented architects to lead us and define process that adapts to change. We need to consider process development and architecture with an agile mindset and should be considering how we can deliver continuous value over time as well as how we can do that efficiently. We need to build a layer of motivation architecture that hooks into our Implementation architecture.

To the guy that said “Agile or die, this is the only fact of today business environment”… I couldn’t agree with you more; but I would like to add trying to adapt to change without clear architecture, leaves you at the mercy of the skills and communication of the individuals, and the bigger an organisation you are, the more risky that becomes. So think of it this way:

Agile Architecture or die.

Aligning ArchiMate to BPMN

ArchiMate is fantastic and connecting different layers of architecture together, and BPMN is fantastic at modelling process – This article demonstrates my approach to marrying the two languages.

Playing To The Strengths

As I mentioned in my article Architecture Languages, Standards, And Frameworks, BPMN strengths lay in creating process detail – and whilst it’s possible to create processes equally as detailed in ArchiMate, generally speaking those processes tend to require more views, and do not look nearly as tidy without a significant amount of effort.

A question I am often asked is which modelling language should be used, and to what level of detail? Both Languages have pros and cons.

For that reason I tend to model the process and its connection to the rest of the architecture in ArchiMate and leave the details in the BPMN model.

The order you do this very much depends on the level of understanding you have of the process. Some people prefer to do the detailed process and then fit it into the context of the organisation and others prefer to do the general overview and then detail out the process later. As part of my standard approach to creating high level designs I normally create the ArchiMate process overview before the BPMN one.

The ArchiMate Process Overview

In ArchiMate, my overview generally looks something like this:

Fig 1 – A process overview

I start with the actual process in the middle. I have found many architects can have a challenging time fully defining a process; its easier to understand what you need from a process and what your expected inputs and outputs to process are, and who needs to be involved, than it is to understand all the minutiae. So the key elements here:

  • Business Process – I normally start with one process – with a name suffixed with the word “process”, because its just easier that way to be clear when talking in conversation to other people.
  • Business Actor / Role – I prefer to use roles rather than actors, because it helps with abstraction and re-usability of the process; it’s important to understand the differentiation – actors are assigned to performing roles. Sometimes I might use both or a mixture of two if i have good reason.
  • Business Events – In the ArchiMate specification it says that events denote state change in an organisation – The way I am using events here is to denote the events that cause the process to start running, and the outputs of the process The direction of the trigger relationships tell us which are which.

In the view above (fig. 1) we can see that our process serves the “My Software Service” – its good to put a process into the context of either a service or a function within the overview. Of course I can just take one or several elements from such a view and include them in other views as needed:

Figure 2 – A layered view

In figure 2, you can see a support process as part of a layered view; in this case we are connecting a process also into the application layer, you can see how if we had a process overview of Support Process our understanding if it work be better. We may have included some elements that would appear on a process overview; but not probably not all of them – this is a judgement call – when creating a view, I am telling a story, and I use whichever elements are relevant to that story. Of course the story of a process overview, is “this is the process from end to end, and this is how it all works”. Its views like the one above where we are able to use the process in the context of other architecture in a repository – that make modelling the process in ArchiMate worthwhile.

Creating a BPMN model

Going to the next level of detail, if we did a BPMN view for Figure 1, we may have created a process that could end up looking like this:

Figure 3 – A BPMN process

A couple of key things to note

  • The swim lanes in figure 3, match the roles in Figure 1; of course, if figure 1 had actors, they would be here too; I need to understand easily how the detailed process in BPMN connects not only into the process overview in ArchiMate, but the rest of the model.
  • Its really important to give the process in ArchiMate the same name as the process in BPMN so later its easy to search and find it.
  • We match up the events with same names in BPMN as ArchiMate, It makes sense. I think of them a little like being interfaces into the process.
  • I deliberately didn’t make the BPMN more complex – Its one of those languages that you can get started with easy, and there’s a few things you can do with gateways, and events, and a lot more possibilities than I show on my example. As I have probably said, I am a great believer in keeping it simple – and the 80-20 rule – you can get 80% of the work done in 20% of the time. Of course encourage architects to learn the standards properly and fully utilize them, but the elements i use in figure 3 cover most of my needs – and I would rather not have architects engaged in hour long discussions over what kind of gateway to use, when it is evident from just leaving the gateway empty and seeing it in the context of the view. I have found in the past, after getting comfortable with the basics, most good architects like to explore these modelling languages and will start to figure these things out themselves.

Why Am I Calling It A Process Overview?

So the elements shown in Figure 1 – could be considered to make up a standard process view like is showing in the ArchiMate 3 manual. I consider the process overview to be a specialization of that – because I am asking for specific elements, in a specific configuration – I tend not to want to clutter the view. I also do not limit this kind of model to the business layer – I could just as easily apply exactly the same concept in the application layer, an application process would be triggered by application events, and may serve application functions – Actors & roles would be replaced by other active elements in the application layer – typically the application component.

How Do You Practically Do This With Tools?

Typically I am using BiZZdesign’s Enterprise Studio (BES), which makes it easy, because the model allow me to create models in either ArchiMate or BPMN. I normally connect those view via hyperlinks – both on navigation pages, and in documentation. Enterprise studio also supports cross model relations – so I can link the navigation of one object directly to another and state the type of relationship; so for example, I could create a relationship on my Software Acquisition Process in ArchiMate to show it is refined in my BPMN model; a number of cross model relationship types exist. I could also tweak the meta-model to give me better options, but I haven’t done that.

Enterprise studio has some new compliance functionality – I did a quick video on it (with some notes in another blog) –

If I was using Archi & Visio, I would create a custom property on the element in the Archi Model and link it to the Visio file in a shared space. All of the modelling tools out there support hyperlinking in one way or another. Another option would be to link from the actual views rather than the specific process elements – but I don’t do that.

Summing It Up…

Of course we don’t actually need to do produce both BPMN and Archimate in all cases, but I do like to leverage the benefits of both together.

The approach I have presented today has a few advantages:

  • The ArchiMate view is quick and easy to get started with when you don’t have all your process detail.
  • BPMN is easy for process developers and other people to develop the detail in parallel. This is important if you work in an organization where process is developed separately from architecture.
  • Following some of the rules I presented will make it really easy to understand ArchiMate in the context of the more detailed view – because the inputs and outputs align.
  • Having naming aligned, and hyperlinks in place helps you find things – the alternative to this is to have disconnected processes.

I personally believe that not aligning your BPMN models with your ArchiMate ones, is effectively disconnecting process from architecture. But of course, Let me know what you think.

What Is An IT Architect?

In this blog I discuss what an IT architect is, and the common expectations that I normally have on all architects – Regardless of whether they are Business Architects, Infrastructure Architects, Enterprise Architects or otherwise.

There are many definitions of what an architect is if you google the term “architect definition” – but all of them have some common threads between them. The reason we re-use the terms that we have from the physical world is designing information technology systems require the same levels of discipline and structure. In traditional architecture you need to plan before you build because rebuilding is a costly exercise; and this holds true of IT architecture, even though the nature of IT architecture is changing and we now see trends towards more agile thinking. Agile methodologies don’t mean that we forgo the design processes, it means we work with smaller units of work and a slightly different focus – they still need scoping, goals, to provide clear value, a design, and plan for execution.

Today I am discussing the general traits for all architects – Its true that specific architecture roles have specific definitions and needs – Infrastructure architects, for example, need a basic grounding on technical concepts that relate to their roles – We should be careful not to blur the roles of architect with those of technical specialist; a good architect can capture requirements from different stakeholders, and leverage their expertise – technical specialists are stakeholders in the architecture, and architects can leverage that experience. Another important differentiation between the roles is focus – technical specialists are often good at creating technical designs but do not focus on other aspects of architecture – i.e. they capture tools and technology, but do not think of processes & roles, information flows, governance & People.

Some other common things I see in the definition of an architect:

  • Architects design structures. It doesn’t matter if we are talking about physical structures or information structures – we start with a skeleton or a concept and we build upon it.
  • Architects oversee the building of structures. In many places its stated that architects build things – which can be easily misunderstood. If you look at an architect on a building site, hes not there laying bricks. although he may take an interest in the work that is happening – he may check the quality and make sure his requirements are met – Its the architect that has specified the type of brick and ultimately where it goes. In the execution phase of a project an architect is there to ensure that everything goes according to plan. The building industry has many regulations that need to be followed, many risks, and methodologies and redesigning part way through a project is expensive – just as it is in the IT world.
  • Architects design and plan. They need to be able to turn a fluffy vision into something more concrete that meets many sets of requirements – from legal, from the customer, from their own best practices, they need to understand risk and cost, and they need to be able to communicate these things in industry standard ways with different stakeholders. They interact heavily with managers to realize their visions, and need to be able to clearly manage risks and requirements, as well as apply methodology in order to help identify risks in areas we may not think of. For example, in IT, we might teach architects to know about the TELOS acronym when looking at requirements – assessing Technology, Economy, Legal, Operational, Scheduling. If you think through those words when you are assessing an architecture you can easily start to spot things that may be missed otherwise.

We need to train our architects to think, and to practically utilize methodology, and follow standards such as ISO 42010, the standard for architecture description.

To me, Tom Graves said it well – “Things work better when they work together on purpose” – and to my mind fundamentally architects are there to facilitate this.