Whenever I read articles about microservices most of the times I hear people talking about “servers”, “protocols”, “devops” and so on. I never found an article that put the human factors at the center.
The trigger of this short article is my current consultancy activity with at a customer that is special in my heart: Brüel & Kjær is the first company I worked for when I came to Denmark in 2003.
Beside the fact of meeting old colleagues dear to me that I haven’t seen since 10 years ago (and that make me feel so welcome like in the old days!), what impress me is their efficiency. The IT department is pretty small 22 people, with very specialized and differentiated skillsets, serving over 1200 users.
There are few things that makes work with them a real pleasure:
- Everybody knows everybody
- Strong personal ownership of the tasks
- Collaboration between every person is paramount
- The manager knows everything is important for her/him to know
You could argue that it is so easy to make a similar structures with small departments, and this is also a point that people make when comparing small and big lands (Denmark vs Italy, to talk about a comparison that I know very well).
When scaling up in numbers, you reach a limit where you need some intermediate layer to glue together the bottom to the top. But does it have to be like this for everything? How can a small IT department manage infrastructure and projects for more than 1.200 employees?
That’s why the first time I heard the moniker “microservices” I thought that somebody finally had reached the conclusion that IT doesn’t need to be a independent mastodon all the times, efficiency can be achieved with clever split of responsibilities and assignments merged with the business.
Company’s structures of this century i most of the cases still reflect the structure needed in the last century, where all the administrative work was performed with pen & paper. Moreover, it was a clear distinction between company administration, suppliers, sales, marketing, customer, products and services. Every entity had their own life-cycle, because the work couldn’t be structured in any other way. So when IT became a real thing, the most natural way to introduce IT in a company was to establish the “IT Department”.
In today’s companies the IT is the business, and it can be also the product, the supplier and the customer and everything else! You cannot disconnect the IT entity from the business entities, your company would survive only few weeks (or hours) before you shut it down.
This means that:
- Business people need to understand IT
- IT people need to understand business
I believe that before we talk about “microservices”, we should first talk about how the company structure can support this specific IT system design approach. Let’s call this preparation step “microcompanies”.
MICROSERVICE: system design discipline that deals with the way we break down the design and organization of IT systems
MICROCOMPANIES: organization design discipline that deals with the way we break down and design the organization of companies.
I would describe microcompanies as a structure between “flatarchies” and “holacracies” (see this series of articles on Forbes by Jacob Morgan for a quick overview).
One of the tools that can make the transition from silos/monolithic company to microcompanies is a Rapid Application Development (RAD) tool like APEX. And these are the main reasons:
- Business people need to be in the loop of the development of new digital tools that will be used by themselves. A RAD tool allow power users to make simple application or mock-ups for the developers that will expand the functionalities of the application
- Developers can deliver new tools for the business at very fast pace, allowing also the management of big projects in small, predictable and meaningful sprints (Agile), with immediate deliverables.
In my opinion, if we pack together microcompanies, microservices and RAD tools, is eventually possible to design a business structure where each business unit has these characteristics:
- Authonomous: every person in the unit knows what they are doing from both business and IT perspective.
- Borderless: the busness unis can communicate with the rest of the company trough well defined channels (microservices, web services, etc.).
- Agile: any need in term of tool and processes is quickly satisfied within the unit itself using the RAD tools, or another business unit, in case extra information is needed, as the communication process is well known to all the units (see previous point)
There is still a lot to say about microcompanies and RAD tools, but it might exceed the purpose of this article. I just wanted to stimulate the conversation on this subject. I also wanted to make the point that business structures (and the IT is part of them) have not so much to do with dogmas, rule of the thumbs, server, but more with people and communication.
If the idea of microcompanies got your attention, I suggest to read this very interesting and inspiring article by Marc Wagner, which I feel that somehow points to the same direction. And I would also really appreciate if somebody can comment my article or give me references to other similar articles related to a subject that I find very actual and challenging.
