We have been inspired by Gartner concept of Composable Business, Data Mesh and Component based Architecture and ended up with what we call Packaged Business Component.

First question we asked our self was how we frame the scope of a component, and decided on that it has to represent something business understand and is a digitalized representation of that.

What’s the language of business? Usually not consistent over the company, same thing might be expressed in different wordings, so what shall we use to try to harmonize?

We decided on using Capabilities as the baseline to establish a common boarder of what we do.

To establish something we first need to agree on a definition, so we borrowed this definition of a Capability from Bizbok:

A business capability, or just a “capability”, defines what a business does. It does not communicate or expose where, why, or how something is done – only what is done.

Bizbok have a more complete description that I have not included but recommend everyone to read.

We now can define a component and a Packaged Business Component:

A Packaged Business Component is a digital representation of a Capability.

To describe a Packaged Business Component, we have something we named a Capability Domain, within this domain some capabilities are selected to be digitalized as a Packaged Business Component (we will explain this more later).

A Packaged Business Component can only be accessed via its interfaces that are:

  • User Interface for human interaction
  • API for synchronous digital interaction
  • Event for asynchronous digital interaction (notification, trigger)

Interfaces a classified by following types:

  • Public/Open for external access outside of the company
  • Partner for partner interaction
  • Internal only accessible within the company

Inside of a Packaged Business Component we have the parts needed for digitalization:

  • Software
  • Data produced and used
  • Processes
  • Manual Tasks (part of processes)

Principles for a Packaged Business Component:

  1. Boarder based on a Capability
  2. As autonomous as possible to increase agility
  3. Consumed only via its interfaces (at least one interface must be implemented)
  4. The inside is private
  5. Have an owner
  6. Have SLA
  7. Is provided as a product including a roadmap
  8. Interfaces have a purpose, and intended consumer group

Why Packaged Business Component?

We have a use case, we build an application, when we have a new use case that can be related to the first application we extend that application.

Overtime we end up with applications that have an unclear purpose or better phrased they are multipurpose applications.

Why is this bad?

It is bad because when we have a new use case we discuss solutions based on which applications need to be changed, to do this, involved people must understand the IT landscape and what each multipurpose application can be used for.

What’s the issue with this?

It is just not easy for new employees to understand what people are talking about when they talk about that application “Jupiter”, needs to be extended with a new table and data from application “Pluto” must be collected via a new API.

If we instead could focus on logical architecture based on capabilities we would have a more understandable dialogs and also more productive dialogs as we separate ourself from the physical implementation aspects when we do a business solution design.

So instead of talking about “Jupiter” and “Pluto” we could have talked about the capabilities that we need to change, and our IT specialists can then analyse what needs to be changed in the current implementation to meet the new demands,

If we also move away from multipurpose applications to Packaged Business Component that has a clear boarder and this boarder is a capability, we end up with an implementation that is in harmony with the logical entities.

This will move us from Application Centric to Business Centric, where we with ease understand what we talk about both from a business and IT perspective.

Application Centric API and Data

API or die is a phrase I have heard people say, to enforce that APIs are created to make integrations more clear, however in an Application Centric world it is hard to secure consistency and clarity as applications are multipurpose and APIs tend to be multi content or specialized for a use case.

In an application centric world, data of same kind is spread out and is sometimes hard to consolidate for analytics.

Data is in the focus and Data Mesh is a moving wave trying to address the issue of multiple owners of the same data based on if it is operational or analytical use cases.

Defining what information a capability is producing and what APIs we can relate to the same capability we have defined the boarder of belonging and by so providing clarity in ownership and purpose of both API and Data.

Capability Domain

When defining our capabilities we ends up in a capability map showing all top level capabilities also usually referred to as Level 1 capabilities.

Each Level 1 capability is decomposed into more specific capabilities in a hierarchical structure, they are often drawn in a compact way showed in the left side of below picture but can be drawn as a tree showed in the right side of below picture.

This hierarchical decomposition of Level 1 Capabilities are what we call a Capability Domain.

Packaged Business Components in the Capability Domain

One aspect of Composable Business is to make business flexible and dynamic to adopt when needed, if we apply this to Packaged Business Component, we should select an appropriate capability in the tree that is not to small, but not too big and can be something an agile team or a few teams can maintain and develop.

It could be that for Payment Capability Domain we select Level 2 Capabilities to be our implementation level and it could look like this.

In this picture I have also drawn interactions to show how the PBC relate to each other, and in this case we have two types of Events that is sent between the PBCs.

Building solutions

Each Packaged Business Component have to expose interfaces needed by other Packaged Business Component (PBC), if a PBC PBC1 needs data for analytical purpose from PBC2 that is producing this data, it is likely that we will have a shared analytical data architecture where PBC2 stores data for analytical purposes and PBC1 can use this data for analytics without moving the data but it is still exposed via an API owned by PBC1 even if it in the physical world is a shared storage platform.

By combining different PBCs we can fast compose solutions for a new use case.

Will this work in reality?

A good question to ask is if this is going to work in reality or if this is just a good thing but not possible to realize.

We will see, but I am convinced that it is worth trying out, but it is difficult and many aspects and challenges have not been addresses in this article, so just scratching the surface.

Leave a Reply

Your email address will not be published. Required fields are marked *