Services in ArchiMate

Services are very important parts of the ArchiMate modelling language. This blog shows some ways we can represent and utilize services.

The Difference Between A Service And A Product

Its important to understand the difference between a service and product. I have seen in many places those terms have been interchanged. Product management must have a common understanding to architects, although this doesn’t mean we necessarily need to expose ArchiMate to Product managers. The whole point of ArchiMate is to provide a common modelling language to enable clear communication.

Figure 1

A product is a collection of services and a contract. A product element lives in the business layer. Normally we connect our services to the outside world through the business layer.

Products are composite elements that aggregate or compose any of these elements in archimate:

  • Business Service
  • Application Service
  • Technology Service
  • Business Passive Structure Elements
  • Data Objects
  • Technology Objects

They are pretty clearly defined in Chapter 8 of the ArchiMate Manual.

Services

A business service represents an explicitly defined exposed business behavior.

Although services are also defined in the ArchiMate Manual I don’t think it does them justice.

In point of fact all services are explicitly defined exposed behavior; be it a business service, an application service or a technology service. These services are very important in large organisations. Take a look at this layered view. Its a typical layered view used to show how the Business, Application and Technology fit together for a fictional web hosting service.

Figure 2

It doesn’t show a complete picture – because of course actors and processes in the business layer are likely to connect into the other layers. We do not have to put every element on every view – we use what we need to tell a story. To work more directly with services we can abstract out from the view above:

Figure 3

In figure 3 we are showing only services, and its important to understand the relationships here, and the concepts. You can see A platform service is realized by either Microsoft Azure or an Amazon Web Service. I could have said they were both specializations of a platform service. I prefer to do use the realization because it would have meant drawing specialization relations in the opposite direction which isn’t as intuitive to read.

Abstract Services

In Figure 3 the platform service is abstract. We only want to represent just enough architecture. Azure & Amazon Web Services have commonalities. They use virtual machine managers, and virtual hard disks to realize virtual servers. You can see this in figure 4:

Figure 4

The technology view is showing a number of things. If we had not abstracted to convey this information we would have to create two separate views – One for Microsoft Azure & one for Amazon Web Services. We want to avoid this.

Having that level of abstraction makes it easy to add a new technology service and enables us to be flexible. Lets modify figure 3.

Figure 5

You can see we added Google Cloud and System Centre. Rather than having to create two additional technology views, we need to do nothing, because we have defined the platform service in figure 4.

Over Engineered Products

In big organizations its very easy to get to a point where you are over engineering. In the examples i have shown so far I have been showing a single business service (web hosting service). You can see, that regardless of which platform is used, or which technology, we still only need a single business service, because what we deliver is the same.

In some organizations the product portfolio can be overly complex. For example I have seen limitations in financial models which have lead to breaking things down into products where perhaps they should not be. In Large organizations different services are often provided by different business units which can mean that because of the different units having different levels of responsibility, products might be created in each unit. Something like this can happen:

Figure 6

Because product management processes tend to specify a need for business services we can end up having to unnecessarily create products and business services. This can be a huge cost and complexity overhead. All services need established interfaces, all products have their own team of staff, and services need interfaces defined between each other.

Figure 6 could have existed in an undocumented way. Drawing a view like this makes it clear where complexity exists that does not need to and is one way an EA can show value – reducing unnecessary services and better defining interfaces between the services at the different layers.

Pricing Services

When we have taken away the detail and drawn our services like in figure 5, it becomes significantly more easy to figure how we want to bill things. If we start from figure 5 we might end up representing our pricing components as below

Figure 7 – Adding pricing components.

Defining Interfaces

Back in Figure 2, we showed some interfaces. At a business level our website hosting service is accessible via Email or Web Portal. The Web Portal is realized by a application interface (HTTP Interface) into the website application service. In this case what we are saying is the business service does nothing except expose out the application services.

In the examples I have shown its clear that interfaces should exist for some of the services. that I haven’t detailed in. When I create a layered view I am typically picking and choosing elements, rather than using all connected elements to a service. Other views, such as service realization views, or application cooperation views may show how these interfaces to services exist in more detail.

Functions

Functions are internal behavior units that we do not expose to the outside world. In figure 4 we showed how a technology service was realized. Such a view may have been created by our internal platforms team. The Virtual Machine Manager Function might be very important to talk about to that internal team but would not be something that the sales or product development team need to talk about. If we were to need to relate the virtual machine manager to another team, then we would have created it as a service.

Summing It up…

In future blogs I will be building a lot on the usage of services, because there’s a huge amount that can be done with them. This blog only scratches the surface. Services can be used to reduce complexity and make architecture more light weight and agile. They enable us to focus our architecture efforts. If you are practicing any kind of large scale architecture they are essential.

Using TELOS For Validation & Feasibility Checking

TELOS is one of those handy acronyms we use for validation and checking we haven’t missed anything in architecture. This blog introduces TELOS.

I use TELOS quite a lot when reviewing architecture. One of the reasons why an architecture review with teammates often looks different is because when we ask questions on architecture what tends to happen is some of our lead architects run through TELOS in their heads – and focus in on areas where things need a little bit of attention.

We use it whenever we are looking at investment proposals, or we are presented with architectures or any kind of feasibility study.

Breaking it down.

TELOS is short for:

Some of the questions we ask can technically belong to several areas – such as a question “have you considered software licences for the servers?”. It doesn’t matter if the question is asked as a Technical question or a Economic one – the important thing is that questions are asked. Lets explore this this one part at a time.

Technical

This is things relating to technology. it can include things such as technical requirements, skills, capacity and other things relating to the fitness of the technical solution.

Some typical technical related questions:

  • Do we have the required software?
  • Do we have all the required hardware?
  • Are we reusing existing technology/competency wherever possible?
  • Do we have the skills we need to use the technology or will we need to train or get skills in?
  • Will we need external collaborations/have third party dependencies?
  • Will the solution defined meet initial performance expectations?
  • Will the solution defined meet mid term usage / functionality expectations?

Ive found in the past that its typical to not fully consider your skilling and training costs. I also think that capacity planning is also an area that often requires attention. Many times i have seen a positive problem occur, where a platform is implemented, costs and a return of investment are declared but the actual platform doesnt have the capacity to provide returns that are promised.

Its also important to think lifecycle of the solution and all its components. We need to have an understanding of how long technologies will stay relievent. For example if a software product we are using is several years old and a vendor is known for releasing new things every 2-3 years, will the solution realise its goals before we need to make further changes and incur more costs?

Economic

Relates to economy and includes such things as profitability, revenue tarkets and break even points.

Some typical questions might include:

  • Are all the costs defined?
  • Are all the revenue streams defined?
  • Have efforts been made to provide the most economic design?
  • Will there be an adequate return of investment?
  • How long will it take to show a profit?
  • How expensive is the solution? is it too expensive?
  • Is our pricing competitive?
  • What is the costs of any potential risks we see?

There are lots of mechanisms out there that can be used to help model and design a proper business case. As a minimum when looking at investment proposals I like to see a Business Model Canvas defined, because you can quite clearly see both costs and revenue streams. Of course not all architecture has a goal to provide financial value.

When looking at a promised return of investment we are looking for the reasons that justify things. Its not enough to say a product will return a million euros in the first year – we need to understand why – which raises further economy related questions

  • How big is your target audience?
  • What is the potential revenue for us of everything in the sales pipeline?
  • How often do we win these sales cases?

Legal

Describes things relating to legal.This can include ensuring we adhere to local law, EU Law, or any industry regulation, or contractual obligations.

Typical questions might include:

  • Are we complying to EU laws?
  • Have we ensured we are following all the ISO standards and met other commitments we have promised our customers?
  • Have we considered any industry specific legal requirements?

Some requirements are obvious – such as GDPR because it has such extreme implications and gets a lot of publicity. Other legal requirements are not so obvious. For example we may need to retain financial records for a fix length of time. Its important to ask the different stakeholder of an architecture about any potential legal requirements, so they are not missed.

Operational

Relates to things such process definitions, operational needs, lifecycle and change management

Some typical questions might include

  • Are all of the actors properly defined?
  • What kind of resources or teams in the organisation will be required?
  • Will we need to reorganize processes or teams?
  • Will we need new resources?
  • Have we made agreements with operations to implement our solution?
  • Will there be costs in training?
  • Do we have proper KPIs or automation in place?
  • Will new teams have to be established?
  • Will there be staff resistance to the change?

We talked about costs of training and skilling within Technology, but it doesn’t stop there. If we implement a new system or new processes / ways of working we need to ensure people are aware of them. There could also be formally required training, and needs for the building of a communication plan.

We also need to have mechanisms in place to monitor health of our operations so we can adjust our designs as we need to.

Proper architecture design really helps here. Resistance to change should also be planned for because sometimes one negative person can derail an entire project.

Scheduling

Things relating to resourcing such as timescales, road maps and resource availability planning.

Things relating to resourcing such as timescales, road maps and resource availability planning.

Some typical questions relating to this might be:

  • Given our current expertise are the timescales realistic?
  • Will the project be too resource intensive?
  • Will there be availability issues for key competencies?
  • Are there any timescale pressures that need to be met?
  • Will the solution be built in time to realize its benefits?

We need to be realistic with our timescales, and resource availability has major impacts on this. If resources are not available a plan should re revised because even with the best intentions you will fail. Time commitment for a percentage of time on a project should be time-boxed. if we have one day a week for a project we need to ensure all resources are available on the same day as part of that commitment, or projects will just drag on.

Key milestones or dates should be defined for things such as launches, and sometimes there are business impacts for being late that need to be understood. For example, when technologies are new the opportunity to sell them might be greater at the technology release than a year later.

A plan or road map should exist to ensure that the project / architecture is delivered at the cadence that is needed.

Summing It Up…

Its quite possible that going through this blog you come up with other questions that would need to be answered in a TELOS assessment, and the questions I have presented in this blog are not intended to be comprehensive so much as a starting point for people who want to start to use TELOS in their working practices.

The questions that I have asked in this blog do not necessarily get answered in a single document – although you might chose to have a TELOS section in a high level design. The questions can be answered in many places in our architecture. A road map view might exist to cover scheduling. A Business Model Canvas may cover most of the concerns we have in economy. Its possible we may cover everything in the requirements documentation or with use cases. Sometimes I have built TELOS into requirements templates, and sometimes I have built TELOS assessment templates. Sometimes its enough to just talk it through in conversation.

Knowing TELOS improves our ability to see potential risks or holes in architecture before they happen

.

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:

People

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.

Architecture Concerns

Architecture concerns are often misunderstood, partly because of the use of the word “concern”. This blog aims to provide some clarity around concerns and their use.

What is an architecture concern?

A stakeholder is a person who gets some kind of value from an architecture. A concern is something that a stakeholder wants.  This can be a request/requirement – such as a customer wanting an email service, or a service requiring  a database server, or it can be something more risk based – like customer being concerned with security. We tend to focus on the negative connotations of the word concern; in the Cambridge Dictionary Definition it has two meanings:

  1. To cause worry to someone
  2. To be important to someone or involve someone directly.

Definition 2. is the one that applies to architecture – the reason we talk about concerns is because that is the language used in ISO42010.

Putting it simple:

  • A requirement is a type of concern
  • A feature request is a type of concern
  • A worry is a type of concern
  • A risk is a type of managed concern.

What do you mean by a “risk is a type of managed concern”?

Concerns are addressed within architecture design. A risk happens when we formally accept a concern  that potentially has a negative impact on our goals and requirements.  

An example – Customer may have a requirement (one type of concern) which says they need administrative access to a server. 

If I have a goal to keep the servers secure and ensure their up time – as the architect I may have a concern that granting customer access to the server means that they can break something. My design needs to address the customer requirements and in this case we may have looked at the requirement and determined something that might be a risk. The concern should be taken to the stakeholders in the project (be it project managers/steering committee) and if it is formally accepted as a risk it is formally registered. However we still need to manage the concern.

What part does an Architect play in concerns management?

The architect role is key in concerns management. One of the reasons I speak so much about ISO 42010 is not only that its an internationally excepted way of describing architecture but it makes the relationship between concerns and architecture very clear – all concerns need to be framed within a view of architecture.

This may seem obvious but is sometimes missed – there are concerns – such as customer requirements and non functional security requirements (to name a few types). I’ve seen many cases where architects talk to different stakeholders, read the concerns then just build a technology based solution. The output a technical diagram; at that point they consider the work done.  When you take this approach without documenting how the technical diagram aligns with the concerns you are left with a few questions:

  • How do I know the technical solution meets all the customer and non functional requirements? / How do I know that all the concerns have been managed? Because if its not written down its easy to miss a requirement. Its possible to someone else is managing a concern also.
  • How do I know that we have correctly identified raised and managed all the correct risks from our concerns? Unless we look at each concern one by one ..

In the example above our concern over customer access turned into a risk but regardless of if it is a risk the process for the architect should still be the same because all concerns should be framed in a architecture view.

If a concern is easily met we can just state that – for example if a requirement if for high availability and we can say that “high availability is provided as part of standard design in our SharePoint Product” – that’s perfect. Having this stated it in your architecture design (or in an ArchiMate view) leaves no doubt that we have addressed things.

If we go back to our earlier example of admin access you could see there we had a problem – a conflict of interest that had to be resolved.  Normally that happens in one of several ways

  • Someone Accepts The Concern – A stakeholder should accept the concern – and who accepted it when should be documented in the design.
  • Someone Rejects the Concern – In which case this should also be documented in the same way
  • Something happens to mitigate the concern – This could be a change in the design – in which case you can document what the change is, and again why the change is needed and by whom/what.
Money!

Cost vs Benefit

Its important for an architect to manage and document the management of every concern one by one. Whilst this may seem laborious the reasons are simple – cost and risk. Consider this:

If an architect in a team of 5 project architects is working with 1 concern, its possible he may  be able to instantly say – yes its met by standard design or if its more complex he/she may spend a day validating the said requirement; to do that he may need to read or for example talk to 4 different people. in this case the time consumed may be:

  • 4 hrs reading
  • 4 hrs architect time in meetings
  • 4 hrs of another resources time
  • 1 hr documenting the work.

That’s 13 hrs of work on a single concern. If we manage it that way – then other resources that need to ensure the concerns are met can just look – lets say in our example a project manager is interested, a security manager, and another architect.  This would be another 3 hours if they read the documentation or 6 if they decided to talk to the architect directly – which they could do because they would know the architect managing the concern through looking at the design – in worse case though following the method it would be 19hrs of consumed time for the project to look at the concern.

Lets look at it from an unmanaged perspective. Project would not know who is looking after a concern and would actively have to check in over time. This means that just to check the status the project manager spends 6 hrs of time in a meeting (PM + Architect). If the security manager and another architect also needs to know whats happening we can end up spending  another 18 hrs of meeting time before even doing any work – then the meetings begin – a concern may be managed in one meeting – put into the meeting minutes then several months later on the same project the same question may come up… which is more meeting time. 

A single concern could end up costing hundreds of hours in project time.  multiply that out, and you will see that you end up with huge costs for very little result. Its a very inefficient way of doing things – where you should just have everyone referring back to a single design which clearly connects concerns to the solution.

Prioritizing concerns in a large project

There has to be a methodology behind prioritizing requirements/concerns in projects involving multiple teams. To do this, business takes priority over technology.  When multiple teams are involved a single architect has to coordinate the concerns – its not the job of a project manager to do this – project managers have to ensure the goals of the project are met, and to keep track of status but concerns have to be organised in a way that makes sense to architects, and managed in a fashion that plugs into architecture (reasons are given earlier). If project allocates out concerns then the chain of prioritization can be broken.

For example, on a large project we may have End User Services (EUS) being provided to a customer. the solutions architect pushes the customer concerns for EUS towards the end user services team. the end user services team will then look through those concerns, and some of them will be managed by themselves, and some will need to be allocated to teams behind them – for example, towards the platforms teams.  Its possible that end user services will have some of their own concerns that also need to be allocated towards their dependent teams. 

The concerns that EUS push towards the platforms team should be managed by the platforms team. If the platforms team cannot meet the concerns they should not just say “no”; they should be providing a solution & alternative. If we take this approach then all concerns are clearly managed and clearly owned, and driven from the direction of business towards technology – its important do do it in this direction because we need our architectures to be customer focused.

Having the basic discipline to manage concerns as mentioned above can save thousands of hours on a large project and can lead to much better control of risk and less cost and time overrun.

How do I express concerns?

I generally consider concerns to be a kind of requirement. Requirements can be captured in a number of different ways. I talk about them in various requirements related blogs – and have more blogs planned on this subject. When developing from scratch I often start with User Stories.

Summing it up…

Concerns management requires discipline and competent architects. Architects should have ownership of the management of concerns. The project managers still have a critical role to play in ensuring alignment to goals and schedules, the management of project status which includes having an overview of how concerns have been managed. The project manager doesn’t lead the management of concerns, but they do ensure that the correct parties are managing concerns and delivering results; if we think of this like a jigsaw puzzle, the project managers provide the pieces to the architects and make sure those pieces do not go missing, and may be letting everyone know just how much of our puzzle is complete, but the architect is putting the puzzle together.

Managing architecture concerns saves unnecessary meeting time, ensures that architects deliver good solutions rather than just good technology implementations. Quality goes up, and the changes of missing something, or having chaos in projects through misalignment or misunderstanding, and other cost overheads goes down.

To put it simply. If you are not managing your concerns you have a real risk that whatever solution is being provided to its stakeholders may not be fit for purpose.

BPMN Basics – A Quick Start

This blog is a basic getting started for people that need to quickly produce BPMN process diagrams with a minimum for fuss and time commitment.

Introducing BPMN

BPMN – Business Process Modelling Notation is a notation that is maintained by the Object Management Group. I would recommend checking out their website and fully implementing BPMN.

For those that do not have time this blog is my quick start that I can give to people in order to have processes modelled in BPMN with as short a learn time as is possible.

Take a look at the diagram below it has everything we need to get started:

Fig 1 – An example BPMN Diagram

BPMN Elements

Below are the elements we need to get started with BPMN:

Events

Events are things that happen. In the Example “Once Per Week” is an event – Events trigger the start of the process but also the end of the process. Any event can start a process.

Fig 2 – Events

These are the circles. The green circle is a start event. BPMN doesn’t specify the color of the elements, but green is a default scheme with the tool I use and the color is an easy differentiator. Example events include

  • User requires software
  • Once Per day
  • An Email Requesting A Service

The Red circle is an end event. Note the red circle has a thicker line. End events define the conclusion. Examples might include:

  • Software is delivered
  • Process Completed Successfully

There are other types of events within the specification but normally having start and end events is enough for most modelling I ask people to do at a basic level.

You can have several events both going into a process or out of it. For Example if we have a approval process we might want to have one end event for Acceptance, one for Rejecting.

Gateways

On the Example BPMN model there are two gateways.

Fig 3 – Gateways

Again, there are more elements in the actual language, but with these two you can represent most things. Normally with a gateway we put a question in there, and label the decisions choices on the relationship. You can see an example of this in figure 4.

Figure 4 – Gateways, Tasks, And Sub Processes

Parallel gateways are demonstrated in figure 1. I like to use them because it makes it visually easy to see when process tasks both split and merge.

Tasks & Sub Processes

In Figure 4 you can see examples of tasks and sub processes. A Task (in the example “Approve the Purchase”) is exactly what you would expect.

A sub process is normally a complete process within our process – used to reduce complexity. in the example above “Order Process” would lead to a whole BPMN diagram which describes that process.

Tying It Together

Relationship wise all the arrows I use in Basic BPMN are Sequence Flow arrows. Remember these diagrams are showing flow, from a start event towards an end event. If we need to flow backwards we need to be careful to make sure the flow does not get caught in a loop. This is done by making the flow arrow flow backwards conditionally using a gateway.

Back in Figure 1 I showed a full BPMN diagram. The last thing to talk about are the swim lanes, which represent the roles of the people that are either making decisions or executing tasks or processes. In Figure 1 we had two roles in the swim lanes – Author and Target Audience. Any thing in the respective swim lane is executed by those roles.

The colors used in the example are the default ones used with BiZZdesign’s Enterprise Studio. I do not change them because I think they demonstrate clearly the different element types.

Summing it Up

This article really showed the bare minimums, and I will use it to quickly introduce people to BPMN when I need things done fast and do not have training time.

BPMN is an easy modelling language to get started and communicate with. Take a look at Risk Analysis BPMN models where I take the next steps with BPMN.