Structure is required for transformation.
Like castles are built and renovated on stable structures, digital businesses require stable points of construction and evolution.
But many existing IT systems lack them.
And a major difference for a digital platform is the speed at which changes must be delivered, creating the need to drive a continuously moving target.
This article shares why a business platform needs a Structure, and how Quality Engineering can provide structure through 3 concrete architecture practices.
Follow the QE Unit for more Quality Engineering from the community.
Why Business Platforms require Structure
A business platform is a product that either delivers or enables other products or services through connectivity with a network of consumers and producers.
Platforms have the common trait of delivering business capabilities through open services and connectors to ease transactions between businesses.
Legacy organizations can have tremendous power in terms of market presence, customers portfolio or past expertise—but it won’t matter if they fail to structure a platform.
In the twenty-first century, the supply chain is no longer the central aggregator of business value. What a company owns matters less than what it can connect.
—Alex Moazed, Platform Business Model – Definition | What is it? | Explanation, Applicoinc.
When an organization is not structured, everyone wants to talk to everyone, it’s hard to know who to talk to, and even simple things become hard.
The same happens with digital platforms that depend on software.
Platforms can only exist on top of structured services with clearly identified capabilities that become reusable within the network of users.
It means that business platforms are not born, but structured around a:
- Business platform vision to make choices
- Organization of business capabilities
- Architectural alignment with the vision.
Let’s see how these elements contribute to Quality at Speed software.
How Quality Engineering provides Structure
Quality Engineering is the paradigm constraining the entire software lifecycle to continuous value delivery to its users through MAMOS.
The domain of Architecture is precisely the one organizing software components that brings to life digital business platforms.
Quality Engineering provides Structure through Architecture with:
- Blueprint defining the business platform vision
- Urbanization of business capabilities
- Domain-Driven Design of business services.
Blueprint providing a platform vision
Organizations have to close the gap between business and IT to speak the same language and clarify they are pushing for common objectives.
Gaps due to silos, backgrounds and interactions required to align the stakeholders on a shared vision providing a common frame of reference.
A Quality Engineering Blueprint is a shared vision of the business platform clarifying the key domains, areas, and points of interactions between ecosystems.
Concretely, it is a set of common documents and schemes that has been co-constructed between business & technology stakeholders.
The most valuable part is the common schemas known and understood by all actors within the organization—they must be cherished and regularly shared at the north star.
It usually results from a collaborative effort of a few weeks to:
- Collect business needs across the organization
- Regroup and filter needs in major business evolution themes
- Evaluate possible business & technology scenarios
- Consolidate the big picture of retained scenarios
- Envision and define the business platform vision
- Detailed trajectory with associated resources and main milestones.
This exercise used to be done every 3 to 5 years depending on the organization maturity, sector or organizational change like the arrival of a new CIO or CTO.
The acceleration of the ecosystem pushes to perform a full Blueprint at least every 3 years, refresh every year, and implement a continuous architecture governance.
While a Blueprint provides the vision of the big picture, a more detailed perspective is required for the concrete implementation of software components.
Urbanization of business capabilities
The good urbanization of a city reflects in the capability to sustain an increasing population, to evolve with low rework, and to minimize disruptions.
Urbanization seems like a quite useful practice for business platforms requiring a continuous reinvention with new services, more users, and high-quality operations.
Some people consider urbanization as “old-school” or “useless”.
I don’t agree.
It is precisely with urbanization that a company can provide a set of coherent, stable and modular services through a proper organization of business capabilities and software assets.
Organizations missing that practice end up with complex systems to evolve whatever the technology or architectures.
Urbanization consists in animating the following elements:
- 4 architecture layers: process, functional, application, technical
- An target and trajectory for each architecture layers
- Architecture principles to stick for decisions and implementation.
Principles support the urbanization process like single ownership within a block (e.g. of a function or application) or the one of “high cohesion, low coupling”.
Urbanization maximizes its value when performed with a continuous collaboration between architects and product teams, ensuring an operational alignment.
Even if some organizations claim to have no “architects”, the important point is to ensure urbanization is done by competent individuals with the vision, not by a job title.
There’s a complementary practice that helps the urbanization exercise to be aligned on the business platform capabilities.
Domain-Driven Design of business services
How we look at things influences how we manage it.
Blueprint focuses on the mid to long-term evolution of the big picture, while urbanization on the entire set of architectural layers, perimeter and modules to deliver.
Domain-Driven Design brings the missing perspective to identify the business services to provide within the multiple business domains.
Its application consist in clarifying the following elements:
- Bounded-context to draw platform and application perimeter
- Services & business events to identify platform connectors
- Domain entities, aggregates, and value objects of business domains
- Technical elements like repositories or factories for implementation.
Its value is to apply the “high cohesion, low coupling” principle to isolate business complexity into specific business platforms and services.
The practice can be performed during the Blueprint exercise to help identify the platforms, but also on a day-to-day basis for the concrete implementation of services.
And it’s a practice contributing to more than architecture; the identified domain can result in an organizational alignment, resources allocation, and staffing prioritization.
Teams able to combine Domain-Driven Design with a Blueprint and an Urbanization are setting the correct structure to thrive with Quality at Speed software.
Using Structure to thrive with Quality Engineering
Organizations with the Structure of Quality Engineering make better decisions to progressively build their business platform.
Their ultimate measure of success is the speed at which they are able to deliver offerings meeting users expectations to generate new revenue streams.
More concretely, the shared vision of the business platform target and trajectory streamline decision-making across stakeholders and software teams.
As a result, Quality at Speed decisions are taken aligned on the business needs and capabilities leveraging a powerfully aligned architectural vision.
These teams are not able to predict the future, but they are able to build a progressive business platform based on rapid iterations with minimal commitment and rework.
The progressivity of QE enables to deliver value early on, while being ready to more mature practices like event-driven architecture, data mesh, or evolve to feature-teams.
Their cumulative iterations enable them to capture market opportunities faster than their competitors, allowing them to remain competitive in the digital ecosystem.
These teams thrive with Quality Engineering.
References
Alex Moazed, Platform Business Model – Definition | What is it? | Explanation, Applicoinc.
Éric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional.
Vaughn Vernon, Implementing Domain-Driven Design, Addison-Wesley Professional.
Vlad Khononov, Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy 1st Edition, O’Reilly Media.
IS Urbanization, GreenIT.
Murat Erder, Pierre Pureur, Eoin Woods, Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps. Addison-Wesley.
Platform (Digital Business), Gartner Glossary.
Stefan Hofer, Henning Schwentner, Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software. Addison-Wesley.