Software is eating the world. If your organization neglects its application’s architecture it is risking its existence. The solution is to let architects architect! To learn why, read on.
Writing my book, Microservices Patterns, forced me to dissect the phrase “Microservice Architecture”. This ultimately led me on a trip down memory lane to reflect on topics, such as the definition of architecture and why it matters. As I write chapter 2, my favorite definition of architecture comes from Len Bass and colleagues at the Software Engineering Institute, who played a key role in establishing software architecture as a discipline. They define software architecture as follows:
The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.
This is obviously an abstract definition. But its essence is that an application’s architecture is its decomposition into parts (the elements) and the relationships (the relations) between those parts.
As I describe in my book, the exact meaning of element and relationships depends on your perspective or view.
For example, a developer is typically typically concerned with elements, such as classes, packages, and modules, and the relationships between them, such as inheritance, associations and dependencies.
In contrast, a network engineer typically focusses on elements, such as machines, and relationships, such as networks.
The 4+1 view model of software defines 4 such views with the
+1 being scenarios that animate the views.
An application has two categories of requirements. The first category includes the functional requirements, which define what the application must do. They’re usually in the form of use cases or user stories. Architecture has very little to do with the functional requirements. You can implement functional requirements with almost any architecture, even a big ball of mud.
Architecture is important because it enables an application to satisfy the second category of requirements: its quality of service requirements. These are also known as quality attributes and are the so-called -ilities. The quality of service requirements define the runtime qualities such as scalability and reliability. They also define development time qualities including maintainability, testability, and deployability, which determine development velocity and agility. The architecture you choose for your application determines how well it meets these quality requirements.
Sadly, many organizations neglect architectural requirements unless they map directly to user visible features. For example, a typical product manager relentlessly focusses on features and schedule. As a result, they will often define performance and scalability requirements since those are visible to the customer. But development time qualities are often neglected.
The problem with neglecting development time qualities is that they invariably decline as the application grows. An application can outgrow its architecture. For example, a monolithic architecture might work well for a small application that’s developed by a six person team but it probably won’t well for a large, complex application developed by a large team. Also, technical debt typically accumulates. Given that the application’s development-time qualities determine development velocity and agility, an organization that neglects them will find that it is increasing more difficult to deliver features.
Neglecting development time qualities can very easily turn into a crisis. That’s because software is eating the world. And, the market is becoming increasingly volatile and uncertain. Every organization needs to be a software company that can deliver software rapidly, frequently, and reliably.
This requires a strong focus on the development-time attributes of the architecture. The following graph shows what can happen over time if those attributes are neglected.
As the application grows, and presumably becomes more valuable, the organizational agility and development velocity decline. The gap between actual and desired agility, which grows over time, represents an existential threat to an organization. There is an increasing risk of disruption by a competitor that can rapidly innovate because it has mastered delivering software rapidly, frequently, and reliably.
Consider this insurance industry example. Zego is a fintech startup that offers hourly commercial insurance for gig economy workers. Their CEO told the Financial Times:
We are here to build a global company, up against Axa and Allianz in ten, twenty, or thirty years time…People need proper solutions that those companies, because of their archaic infrastructure, can’t offer.
And, here is a banking example. The Hong Kong Monetary Authority recently licensed 8 new digital-only banks. As a result, HSBC, which is the dominant retail bank, now has 8 new competitors. How quickly can you organization react to these kinds of emerging threats to your business?
The solution is for an organization to manage and prioritize architectural requirements, especially development-time qualities, in the same way as user visible features. It must allocate time and resources to working on the architecture in order to ensure that it meets the needs of the organization. Architects be more than smart, experienced developers who work on the complex, new features. Architects need to be given the opportunity to architect!
Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.
Chris helps clients around the world adopt the microservice architecture through consulting engagements, and training workshops.
Chris teaches comprehensive workshops for architects and developers that will enable your organization use microservices effectively.
Avoid the pitfalls of adopting microservices and learn essential topics, such as service decomposition and design and how to refactor a monolith to microservices.Learn more
Chris offers numerous other resources for learning the microservice architecture.
Want to see an example? Check out Chris Richardson's example applications. See code
Got a specific microservice architecture-related question? For example:
Consider signing up for a two hour, highly focussed, consulting session.
My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!
It covers the key distributed data management patterns including Saga, API Composition, and CQRS.
It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.
The regular price is $395/person but use coupon MECNPWNR to sign up for $120 (valid until May 16th, 2023). There are deeper discounts for buying multiple seats.
Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.
Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,
Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.
Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.
Engage Chris to conduct an architectural assessment.
Note: tagging is work-in-process
anti-patterns · application api · application architecture · architecting · architecture documentation · assemblage · beer · containers · dark energy and dark matter · deployment · design-time coupling · development · devops · docker · eventuate platform · glossary · hexagonal architecture · implementing commands · implementing queries · inter-service communication · kubernetes · loose coupling · microservice architecture · microservice chassis · microservices adoption · microservicesio updates · multi-architecture docker images · observability · pattern · refactoring to microservices · resilience · sagas · security · service api · service collaboration · service design · service discovery · service granularity · service template · software delivery metrics · success triangle · tacos · team topologies · transaction management · transactional messaging