Organisation by Business Domain

Organisation Model of a Business Domain

In the business world, there is one subject that comes up regularly: reorganisation. It is either the consequence of a change in leadership, management or the desire to satisfy the consumers of the services provided by the company. But much more rarely, this initiative is initiated to make teamwork really work within the organisation.

In most of the companies where I worked, a more or less hierarchical organisation was in place. They had either functional, matrix, purely hierarchical, horizontal or flat structures, or other combinations of these.

At a time when there is constant talk of reorganisation, what model can we provide to restore agility to the organisation and thus deliver better services?

This article proposes a model for organising a business domain to achieve these goals.

Introduction

This article proposes an organisational model adapted to the provision of services for client organisations. This service delivery is in line with what our customers expect from us: agility, consistency, scalability, resilience.

The model is based on the following findings and assumptions. These findings and assumptions are based on a real-life example of an organisation of about 100 people providing IT services for a group of federated organisations.

Findings

The organisation has a hierarchical organisational model which is found in many organisations. Hierarchical models generate considerable discussion and controversy. Without going into these philosophical discussions, the following points of attention can be noted in this organisation.

Roles

Currently, some services provided by the organisation are provided by groups whose roles are grouped by IT business line: e.g. system administrators are in the infrastructure team, support technicians are in a support group, business analysts in a business analyst group, and so on. This is a kind of matrix organisation in some respects and functional in others. However, as will be seen below, this is not always the case.

The organisation by IT business role type generally leads to a split in the organisation, to silos of functions. It can be seen that a team made up of A roles cannot communicate with a team made up of B roles and vice versa. This is usually due to a lack of understanding of the tasks of these roles and their physical distance from each other and their respective concerns.

This results in the creation of complicated interfaces between role groups. These interfaces therefore make the organisation more cumbersome. See the section on bureaucracy below.

Furthermore, these roles are only formally present in certain organisational units: e.g. the role of business analyst or architect only formally exists in one functional unit.

However, all roles are essential to provide the services of a business domain.

Bureaucracy

As the organisation grows, more interactions between organisational units are required. The network of relationships is therefore more complex to maintain, as there are more human agents in the system.

However, today, given the nature of the company structure, these interactions become bureaucratic: requests between groups, centralised management of requests, centralised management of changes, reporting between teams, etc. All this is done through forms. All of this is done through forms. Instead of favouring human interaction, we prefer a very mechanical process, which is bound to be dysfunctional at the slightest grain of sand in a cog in the process.

I couldn’t stand the paperwork. […] This all system of yours could be on fire, and I couldn’t even turn on a kitchen tap without filling a 27B/6. Bloody paperwork.

Harry Tuttle in Brazil

If rules are needed for the domains to interact smoothly, they should be kept to a minimum.

Command and Control

Decision-making in a group is often attributed solely to the leader. Employees do not have the autonomy to make decisions for which they are competent.

Instead of having a distribution of decisions, all decisions are centralised and usually go to the CEO. Even for a fan request, validation by the CEO is necessary.

Rigidity

The hierarchical structure increases the rigidity of the organisation. As explained above, some organisational units do not have all the roles to carry out their mission.

However, today it is generally not possible for an employee with specific skills to work in another organisational unit for the duration of a project. In this respect, one could conclude that a matrix organisation would solve this problem. As we will see below, this type of organisation is far from ideal, as it prevents the specific knowledge of the business domain from remaining there.

Hierarchical Level

Sometimes there is a confusion between the hierarchical level and the value of the employee. For example, the fact that an expert in a field cannot make a decision on a subject he or she has mastered makes him or her feel inferior and causes frustration and resignation in the long term.

Hypotheses

The hypotheses below are proposed explanations obtained by generalising the findings mentioned above.

• A domain works best if all the roles are permanent and present in each domain. The notion of permanence helps to maintain momentum in the domain. If the members of the domain are only grouped together for the duration of a project, then the momentum disappears when the project is dissolved. This is often what happens with a matrix organisation. Moreover, keeping members in the same team allows the maintenance of services beyond their implementation project.

• A person may have several roles depending on the nature of the role. Depending on the size of the domain and the number of services that the domain provides, one person may have more than one role in the team. For example, the role of support technician may well be the responsibility of all members of the domain: anyone in the team is able to respond to the service user without the user having to go through levels of support. Staff need to be in properly defined roles to make full use of their abilities within the requirements of the organisation.

• Business domains have a different pace from each other. Some business domains are slower to evolve because user needs change little. There are some business domains where the pace of change is slower, as user needs change little, while others have a higher velocity due to their emerging nature.

• Domains are more agile if they are autonomous. An autonomous domain is not a domain that lives in autarky or is independent of the organisation. It must define its interfaces with other domains for proper collaboration. Autonomy lies in being able to leave decisions to the domain’s experts and thus make it more agile. This expert can take all the decisions they want within the framework of their domain: visions, goals, objectives, finance, etc.

• The implementation of a DevOps practice improves cohesion between members of the domain. We have seen above that there is a divide between roles. The DevOps practice allows everyone to have this culture of providing an end-to-end service to the user: those who design a service operate it. Operational concerns are therefore no longer the sole responsibility of the system administrator and design concerns are not left solely to the business analyst, architect or developer.

Proposal

The model presented below is not based on a specific academic model. It follows from the findings and assumptions presented above.

It is also based on my experience of working in different organisations providing similar IT services.

Concept of Domain

The design of the organisation by business domain provides a framework for information system services. A business domain designs and operates the services related to that domain.

In order to define a domain organisation model, it is necessary to define the concept of a domain, and more specifically a business domain.

A business domain represents a set of interconnected activities that operate on a set of shared rules and concepts. It has a vision and is goal-oriented. It can change rapidly. Most importantly, its pace may be different from that of other domains. The scope of the domain extends to the boundaries that separate the activities, rules, and concepts shared within a domain from those outside it. At the boundaries of the domain interfaces are defined.

Within each business domain are all the roles that are necessary for the proper functioning of the domain and the delivery of its services. It is important that these roles are permanent in the team that makes up the business domain, as this ensures that the knowledge remains within the team.

Concept of Guild

The domains include all the roles to accomplish the mission of the domain. However, in order for the entire organisation to be coherent and have integrity, there is a governed inter-domain communication. For this, the roles in each domain are part of a guild. Governance emerges from the roles in each domain and is embodied in the guilds.

A guild represents a community of like-minded people who wish to share their knowledge, tools, practices and experiences.

The guild thus exists as a meta-organisation, with members drawn from the business domains.

Graphical Representation

As an illustration below, three business domains are presented: A, B, and C. These domains include all the roles that are needed to design and operate the services they provide. These roles are permanent: that is, they are not taken from a pool of people to form a project team and then disbanded. The members thus stay together to be as close as possible to the needs of the consumers of the services throughout the life cycle of their services.

Furthermore, the members of these domains are not necessarily employees of the organisation. They may be external to the organisation: self-employed, suppliers, business experts, etc. Nevertheless, they form a sustainable and long-lasting organisation.

The guilds meet regularly to discuss the subjects for which they are responsible. In this way they create cohesion between the business areas.

Through the constitution of these domains and guilds, which are organs that live their autonomy and cause a living ebb and flow, the organisation as a whole comes to life.

The domains and guilds therefore also have their own life cycle: their creation or deletion does not lead to the decline of the whole organisation.

How do you see your organisation’s structure?