Architecture is all about tradeoffs

H

Software architecture is always about making tradeoffs!

Every choice you'll make will come with preconditions to success as well as side effects.

So does the choice for orienting your architecture around business capabilities.

Tradeoffs of using business capabilities

It takes time

In order to be able to leverage business capabilities, you will first need to learn which capabilities the business has. As every business is positioning itself uniquely in the marketplace these capabilities will also be unique (to some extend) and it may take months to figure that out.

Willingness to align

The delivery team must be willing to embrace business concepts and not just focus on technical details alone. At the same time the business must be willing to share with the delivery team how the organization works, which is also not always a given.

Awareness of language mismatch

Even when this willingness is there, both groups need to be aware that they don't have alignement in jargon and language. They must be actively working to come to a ubiqitous language and mutual understanding.

Organizational maturity

The organization itself needs to be mature and stable enough. In a startup which pivots every year, the capabilities will be shifting all the time and won't be stable enough to build upon.

Need for a discovery process

There is little more wasteful then building the wrong capability in the right way. The organization needs to have a process in place to decide which capability needs to be built next, in alignment with both market needs and organizational priorities.

Technical maturity

Especially the act of packaging capabilities and then composing them again will have profound impact at a technical level. Your delivery team will need sufficient technical maturity to deal with the implications it has on for example the testing strategy, on user experience consistency, on backward compatibility, and so forth...

Relapse into noun thinking is inevitable

We've all been conditioned since high school or college to think in nouns, it is inevitable (even for me) to relapse into noun thinking from time to time. You'll need to be wary of this, accept it, but try to shift your attention back.

It's about the journey not the destination

Please take your time to assess the readiness of both your teams and your organization, not everything needs to be in place to get started, but certain aspects do need to be present.

It's perfectly fine to say you're not ready to adopt business capabilities yet, and first focus on improving the discovery and delivery processes in your organization.

And when you choose to embark on the journey, be prepared to hit some bumps in the road, even knowing you may never reach the final destination (there is always room to improve).

So, blue architecture or red architecture: which will you choose?

About the author

YVES GOELEVEN

I've been a software architect for over 20 years.

My main areas of expertise are large scale distributed systems, progressive web applications, event driven architecture, domain driven design, event sourcing, messaging, and the Microsoft Azure platform.

As I've transitioned into the second half of my career, I made it my personal goal to train the next generation of software architects.

Get in touch

Want to get better at software architecture?

Sign up to my newsletter and get regular advice to improve your architecture skills.

You can unsubscribe at any time by clicking the link in the footer of your emails. I use Mailchimp as my marketing platform. By clicking subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here.