A guide to the Packaged Business Capabilities for the C-Suite

I have made an important observation in my early days as a software engineer, before I became a Partner and the Chief Innovation Manager at Makimo. It basically boils down to this: when writing a program to perform a certain task, one can shape it any way they want to, even if it doesn’t make much sense. That’s why the first few years of learning programming concentrate on reaching designs that can be understood by another programmer.

It’s like a painting of Mona Lisa and Number 1A made by Jackson Pollock. Of course you can explain the essence of both paintings with some smart reasoning, but the former one simply resembles some reality, while the latter one is just confusing.

Today we’re going to talk a lot about resembling reality in software engineering. We’re going to discuss 7 insights for better software investments, but before that, we’ll talk about a few assumptions that these insights are drawn in conclusion from.

The insights are as follows:

1. Do not shelter programmers from reality
2. The necessity of DevOps → BizDevOps transition
3. Differences between Microservices and Packaged Business Capabilities
4. Domain-Driven Design shapes the means of communication
5. Metrics are important, but they are not the whole picture
6. Establish real-world constraints that govern how your business units operate
7. Strict no walling-off policy

I have a secret weapon to help me untangle this topic. Buckle up, dear CTO, CIO or whomever you happen to be, as I’m going to take you straight to the past, to the year 1968.

Conway’s Law

In 1968, Mel Conway made another observation that made waves in the industry. This sociological observation still is cited and discussed today, and the gist of it is the following quote:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Conway, M. (1968). “How do Committees Invent?”

Let’s not just assume it as a principle yet. Why might this observation be valid in the first place?

A popular stereotype is that programmers work alone, but that cannot stray further from the reality. As other engineering disciplines, envisioning, planning and execution of software engineering effort requires a team of specialists working together.

In the software development life-cycle, they are going to introduce new designs and conventions, implement them as code, make sure no errors are introduced into the already functional parts of software, document the changes and release them for public use.

Undoubtedly the creation of a software product is a group design activity.

The more people are involved into creating a software product, the more of a need arises to streamline the communication and to delegate responsibilities for certain parts of the end software product. 

Let’s say that Orders and Promotions are two areas of responsibility our software product needs to meet. An intuitive thing to do would be to create a team structure that reflects these areas – Team Orders and Team Promotions.

The following graph diagram naturally comes out. In this diagram, Team Orders might be responsible for managing order handling in the bigger system, and Team Promotions might be responsible for giving certain customers coupons. There might be other teams, too.

In order to solve these subproblems, each team starts working on a module that handles their part of the end software product.

See now what happens. To make two modules work together, Team Orders starts to negotiate with Team Promotions not the best way to work together in order to make Orders and Promotions work together, but how the Orders module and the Promotions module are going to communicate required data for each other.

This way the two teams pass their own communications structure to the software they make.

The original article used the word homomorphism to describe this similarity, reflecting the one-directional flow of team formation process influencing the probability of arriving at certain architectures with regard to the organization structure.

It’s unusual for the software to be developed in the reverse direction, however there are first voices in the industry raising a point that it potentially could not be impossible to do so, if organizations are open to change the formation procedures of their software teams. Look for “Inverse Conway’s Maneuver”, if you like to see more information on this topic.

Strictly speaking, Conway’s law is a specific type of a homomorphism – a graph homomorphism, operating on a graph representing people, teams and interactions, and later on, modules and connections between them, as presented below:

Before we start building on top of this concept, I’ll put a few more examples to tease the brain:

• One team could produce a monolith application, unless deliberately deciding not to;
• Two teams could produce:
  • Two microservices
  • Core and auxillary modules
  • Back end and front end parts of the product
  • A monolith (if they merge into one team)
• A number N of teams could produce:
  • N microservices
  • M core modules and N-M of “other stuff”

These examples circle back to my initial observation I made in this article, expanding on it slightly. A software product can be shaped in any way, just by delegating responsibilities and building specific teams.

The question remains – is the way people in your company are structured deliberate or accidental? Because design by accident can critically shape your software product out of touch with reality, into Jackson Pollock’s realm of software architecture.

Three assumptions I’m going to use in this article

Let’s go back to the present. Between the times of Conway’s article and today a lot of things happened that can help us avoid chaos. I’ll base my reasoning on three assumptions.

1. Conway’s Law works. An organization will produce a design whose structure is a copy of the organization’s communication structure. I’ll use this homomorphism as true without asking for formal proof.
2. Current team structures (small, 3-15 people Agile teams) are probably good enough to produce meaningful chunks of software. The choice of the word “probably” is deliberate here – from my perspective, this structure is still the default choice for many organizations and often they are deployed without much thought, following something akin to a mantra, while actual consideration is either lost in materials from ‘80s and ‘90s or not yet vocal enough to enter the mainstream discussion.
3. Domain-Driven Design is probably a good enough set of techniques to model reality in a satisfying manner for business purposes. There’s a caveat and a benefit to this assumption, both of which I’m going to describe later.

For the second and third assumptions, currently I have no way of confirming them in a rigorous fashion. It’s more of my intuition, check back in a few years if I have some newer commentary on that.

A guide to building healthy Packaged Business Capabilities

Here are the promised insights. We now have enough background to explain some of the current trends and make a few new observations that might help your business in building better tech.

1. Do not shelter programmers from reality

Here’s the Domain-Driven Design caveat I’ve mentioned.

There are many ways to shape parts and modules of your software product. But only a few designs out of all the possibilities will resemble something that will look recognizable to you (like the Mona Lisa painting). That’s because without close connection to the business in the designing process teams of programmers are going to carve up the software in the way it makes the most sense to them, without considering the constraints imposed by the reality on you:

• how market determines your business units’ operation;
• possible future expectations and directions of change to your business units;
• what is too rigid to change or doesn’t matter much;

In Makimo I prefer our teams to contribute their consultancy skills to clients as well as delivery skills. The end result is staggering – the software that actually does what everybody wants it to do! That’s why I believe we are a BizDevOps oriented vendor, as we don’t shy from research & development works, UX consulting or other kinds of consulting in addition to our main line of software development services. I can definitely say this approach works, and since long it is one of the tenets of our company. To understand and then choose wisely.

2. The necessity of DevOps → BizDevOps progression

Using Conway’s law, we can use it to draw out further consequences of the former point.

• DevOps might produce deliberate architecture detached from the business reality – they might miss the point on the business requirements passed to them or focus too much on the achievable and measurable (see point 5).
• BizDevOps should produce deliberate architecture in line with the business reality, as they have a tight feedback loop with people experienced in the business side of operating the software.

That change might need to come from the top down. For example, if you are a Chief Information Officer and have the whole IT staff under your command, take proactive measures so that your IT people work not only on the software being developed, but are to see the effects of their applications on the rest of the company.

That’s only one suggestion of a possible feedback loop for your staff, there are many more – starting with you reaching out to other C-Levels to hear their part of the story.

Avoid siloing your people.

3. Difference between Microservices and Packaged Business Capabilities

Again, Using the Conway’s law and the previous insights, I believe that many microservices designs are failed attempts to produce Packaged Business Capabilities by the development teams who have no idea about the reality of your business.

To introduce the terms:

• Packaged Business Capability (PBC) is, according to Gartner, “software component that represents a well-defined business capability, recognizable as such by a business user”.
• Microservice is a technical term that describes a “thing that does something, and can be installed on a server or deployed to the cloud”.

A Packaged Business Capability can be a single microservice, or a few microservices working together to enclose a single business area, unit or function.

Ideally you’d have a single PBC for a single business unit it represents – or a business function, starting from the core ones. That way, the structure of your company influences the design, the design becomes a deliberate design, and that produces thought-out PBCs and common microservices that provide common data for most or all PBCs.

If your teams are not aware of business realities, they might try to create a PBC, but fail to encapsulate the whole unit/function inside, forcing people to work around it in order to do their job. The worst decision here would be to take another team to develop the missing parts. You basically are guaranteed to end up with a design that has some microservices with boundaries that make no sense.

Let’s formulate it in a table:

	Deliberate	Accidental
Microservice	Infrastructure for PBCs, shared services for multiple PBCs	Deployable software units with unclear boundaries and/or technical-only purposes
Packaged Business Capability	Design encapsulates business units/functions	Risk of building a byzantine system with confusing properties
Who produces that	BizDevOps	DevOps without access to business knowledge and experience

To conclude, start building microservices that reflect the business units’ goals in your company and PBCs naturally follow.

4. Domain-Driven Design shapes the means of communication

I’ve stated that there’s a benefit to using Domain-Driven Design as a reality modeling method, too. The set of techniques described here result in clear definitions of how communication between modules should be structured – with interfaces and (business) domain events.

That’s part of Packaged Business Capabilities as well – both focus on providing Application Programming Interfaces to access their data and functions, and on event channels to be notified of something happening in other parts of your business.

Think of APIs and event channels as how websites and text messages shaped the data access and communication in the past.

Why is that a benefit? Because if all teams respect the same rules in their approach to communication between modules, there is less risk that with time, the software becomes unmaintainable. Clear rules also structure their expectations and negotiation processes between teams.

For you that means that you can focus more on the team formation processes and less on coordinating the means of communication between them.

It also means that you can use APIs to start composing PBCs in novel, unexpected ways, by building integrations on top of them. With that you can gain a technical edge over the competition. Read the story about the importance of APIs in Packaged Business Capabilities that I’ve written some time ago for more on that topic.

5. Metrics are important, but they are not the whole picture

I remember a quote from Peter Senge’s The Fifth Discipline:

You Can Only Measure 3% of What Matters

The way I usually envision KPIs or other measurables is that they can validate whether the business unit is maintaining certain levels (of quality, speed, financials etc). If they don’t, that’s a marker for me that I should investigate what is happening.

The same KPIs that would be given to a software team designing part of your software product would become a mantra and the final product would put too much focus on the measurable KPIs and too small on the lesser defined “reality” that everyone in the unit is used to handling on a daily basis.

So don’t try too much to “help” your software teams by setting clear and measurable goals to deliver. Better to expose them to what actually feels like to be in a specific business unit, to ambiguity, unpredictability and all other unclear things as well. A lot of software I’ve been working on was exposed to varying levels of uncertainty in the development process. Usually that comes in plus for the software, as the developers learn to build the right abstractions handling these uncertainties, making the end product better suited to its environment.

6. Establish real-world constraints that govern how your business units operate

In the Cynefin framework there is a body of methods that operate on real world constraints. Just for a quick introduction, there are many types of constraints:

• Governing/Enabling Constraints
• Internal/External Constraints
• Connecting/Containing Constraints
• Rigid/Flexible/Permeable Constraints
• Dark Constraints

To use and discover them in software design is a blessing, because it enables a much richer understanding of the environment of a business unit.

For example, the Promotions unit is constantly looking for other types of promotions that would actually drive sales up – that’s a constraint that should shape the design of the Promotions Packaged Business Capability, with two goals in mind:

1. being able to quickly implement new promotion rules;
2. being able to quickly test and compare different promotion rules;

As you can see, just one statement about the reality of the business unit can give us a glimpse into an enabling constraint that determines the end shape of the software product.

Discovering constraints other than money and time is an important part of software engineering.

7. Strict no walling-off policy

The points above assume everybody wants the best for the company. Now let’s play the devil’s advocate.

In order to become impossible to fire in IT, one can:

1. make the design as convoluted as they can;
2. make it to the production;
3. prevent any changes threatening them to the production.

So if you ever happen to see any signs of a team of developers rising walls or communication breakdowns, you should act fast and swiftly. Because of what Conway’s Law tells us, communication structures influence software design to a great extent and you are going to see the same walls in the code – sometimes grinding the software’s evolution to a halt.

Conclusion. Let reality shape the teams

In the introduction I’ve written that the first few years of learning programming concentrates on reaching designs that can be understood by another programmer. What I haven’t said there is that the rest of the career concentrates on reaching designs that can be understood by anyone.

As the Mona Lisa painting can be appreciated by people and art critics alike, a deliberately-chosen architecture will be enjoyed by both business and developers.

And to let in this reality to your development teams, focus on:

• bringing businesspeople, designers, users, and programmers together to reflect reality on all stages of your product design;
• building microservices that reflect the business units’ goals in your company; Packaged Business Capabilities will follow naturally;
• being aware that software team structures should reflect the deliberate design of your system – if teams are arranged according to HR organizational structure, you are prone to arrive at accidental design!

Happy designing!