Service-oriented architecture. A digital copy of the business

Many IT people, when they hear about SOA, may say knowingly something like, "I know what that is, but we have a microservices architecture."

This is such an important topic that in our course for project managers and strategic consultants we set it apart in the enterprise organizational framework module.

We teach not to confuse IT services with organizational charts and approval-based business processes.

Imagine that your organization has just been born.

There are no job titles or departments yet, no procedures or agreements on how authority is divided, and in general you are all sitting in a small office.

In engineering terms, you can be called a monolith.

As long as there are only a few functions and your processes are as simple as possible, thanks to a manager's good judgment, adding a new responsibility or task to the company is organizationally inexpensive.

You briskly solve problem after problem, and the machine keeps running.

However, the company is still being managed manually.

Your company is growing, and your processes are growing with it.

You no longer fit in a single room; you occupy an entire building.

However, you do not yet have an organizational structure, and without it there can be no service architecture.

Processes have more and more nuances, and the likelihood that each new change will be implemented decreases. You cannot fire

You reprimand Masha for not completing item No. 7 of your contract review instructions, because a dozen important functions depend on it. Masha says to you: "I was at fault, it won't happen again."

Next time, it may well satisfy item No. 7, but it will likely violate item No. 9 and item No.

The authority of departments and individual employees is still mixed together.

You do not yet need as many people as you have functions.

You divided the company in what seemed logical to you, for example by the floors where the departments sit.

This example is intentionally far-fetched.

Of course, you divided the departments into a notional accounting department and a procurement department, for example.

But can you now demand everything from accounting specifically from accounting?

The manager is at work from morning till night, never leaves their laptop or phone, not on vacation or on weekends, just so that "everything works normally."

If it is even possible to measure accounting and procurement, responsibility for that result always belongs to someone else.

In the nice picture, you have an organizational chart for the enterprise.

In fact, you still have a monolith.

A monolith is a state of an organization or program in which every new functional expansion costs more than the previous one.

Each subsequent change requires more and more service actions.

It gets to the point where the number of people grows, but profits do not.

A monolithic IT architecture is exactly the same.

Outwardly, it may look like different programs and services, but in fact everything is so tightly interconnected that adding new functionality always creates more overhead than before.

Of course, your company can somehow function with poorly separated departments, which in IT is called tight coupling.

The problem is that departments are expected to be staffed by superpeople who can solve any problem. These superheroes will work themselves to burnout. The same thing happens in IT under tight coupling.

Each person on the team understands the logic only up to a certain point.

But the further you go, the harder it becomes to understand exactly what needs to be done.

You will need an increasingly brilliant engineer to sort out any problem until they burn out. Something has to be done, right?

The reactions of many managers and engineers in this situation are very similar.

Managers read Harvard Business Review, listen to trendy conferences, and

Gref, and learn about Agile, about teal, or about some super-duper solution that will systematize your business and do all the work for them. "Oh my God, there is some magic pill that will solve everything!"

The system-level solution that can improve a monolithic organizational structure is to split off part of the functionality into a separate block.

But you cannot divide things by intuition, neither in business nor in IT.

Moreover, IT should be divided along exactly the same boundaries as the business.

And now we have reached why understanding the service matters.

A service is not some magical incantation that is supposedly better than a monolith but worse than microservices.

Service architecture is a map of your system functions broken down into business blocks.

A service is defined within the paradigms of the valuable final product or in process output definitions within process management.

The output should make it completely clear and transparent what exactly another company, or another department within your company, is "buying" from this service. For example, let's look at Hubbard's organizational chart.

According to this scheme, the company has a communications unit, and within it there is, in turn, a recruiting and onboarding department.

This department will be responsible for its final product if and only if it has full authority to deliver its core value product. The HR department should work in its own isolated IT system precisely so it can manage the necessary changes independently. It is important that the HR department delivers only what is its core value product to your organization. In the real world, that is employees; in the IT world, it is a digital copy of an employee.

At the same time, the HR department should provide a digital copy of employees in a format for which it can be responsible, while its work should not depend on which solutions other departments use.

They are what allow each department to define its own rules for providing information needed by other departments.

If tomorrow the HR department switches its 1C system to a cloud service, the only thing it needs to do is change the rule in the bus for how to access the employee dossier.

This is part of the HR department's responsibilities, alongside recruiting and onboarding employees.

A digital copy of an employee is still the same employee, just in digital form.

Before making a decision about IT architecture, make sure your technical team is interested in creating a digital copy of your company, not in adopting trendy technologies.

This is a common and understandable situation: IT people like to try something new and trendy that they can add to their portfolio.

To avoid mistakes, first define the company's organizational structure with departments and subdepartments.

If you plan your departments properly from the start, the growth of people, business processes, and software functionality will be synchronized.

The beauty of services is that when they are defined and separated correctly, they do not separate technology from business, but rather put technology at the service of the business.

But in many companies we see that reporting lines are arranged differently: the IT department, without managing the strategy and technology of work and product creation, defines the technology for creating digital copies.

It is not IT that lives by business rules; the other departments live by IT rules.

When services are divided incorrectly, conflicts arise when one task seems like it should be handled in one place, but is partially handled somewhere else too.

Just like incorrect separation of departments leads to conflicts between departments and opaque decision-making.

Or the quality of procurement data somehow becomes the responsibility of a system that is not under that department's control. This is not an easy concept to grasp.

When training managers, we break it down and ask them to create service maps, teach them to model in the context of the organization's business processes, and correctly identify conflicts between services.