Part III: Events-First Architecture

Executive Summary

This part of the book introduces the software architecture styles and mechanics that lead to highly versatile and adaptable applications and services. It does take on a more technical slant, but the illustrative diagrams and explanations should be palatable for many who do not regularly practice software development. At a minimum, it is recommended that executives and other senior management have a fundamental understanding of making good software architecture decisions, which help practitioners avoid the bad ones. Armed with this knowledge, feel free to converse with software architects and developers, and inquire about the choices they’ve made. Challenge them about these decisions, which must stand up to the test of time and relentless change.

Chapter 8: Foundation Architecture

Every software architecture must start somewhere, and this chapter provides the building blocks to begin such an effort. As expected, some foundational principles must be set and followed to make a software architecture flexible enough to host any number of decisions made early, mid-term, and late in the software development life cycle.

▪ You must understand which software architecture styles and decisions are commonly used, and which ones fit more narrowly defined system-building situations.

▪ Using the Ports and Adapters style can establish the most flexible architecture possible, and leave openings for early and late decisions as needed. Further, consider four options that can be used inside the Ports and Adapters style, depending on the specific context being constructed.

▪ Consider using modularization to address contextual divisions for both Monoliths and Microservices, and for hybrids of both.

▪ Gain a primary understanding of REST, a widely used Web style of browser-to-server communication, while discovering that REST is much more versatile than most developers think.

▪ Grasp the critical nature of supporting architectural requirements that are not driven by user feature–based functionality: security, privacy, performance, scalability, resilience, and complexity.

Chapter 9: Message- and Event-Driven Architectures

There are numerous reasons to use message-based and event-driven architectures. Depending on familiar request–response introduces multiple points of failure, including ones that are notorious for causing cascading outages. The nature of distributed systems that operate over networks, as well as in cloud and multi-cloud environments, calls for tolerating latency, whose scale is unpredictable at any given time. It would be better for systems and subsystems to embrace latency, by designing architectures that deal gracefully with it. That is exactly what messaging infrastructure supports, and messaging is the way the events are generally offered for consumption. This approach all but erases concerns over network latency, and makes it possible to deliver more responsive systems because the message-based foundation underpins and supports elastic and resilient subsystems and their internal runtime components.

▪ A common use case in a large system is for multiple business capabilities to share in a step-by-step workflow, taking it from start to finish. For example, when an applicant requests an insurance policy, (1) their application must be validated for correct and full data. Next, (2) a risk assessment must be performed on the application. If the risks are acceptable, (3) a premium rate must be calculated. At that point, (4) a quote is generated, and (5) the applicant is given the opportunity to accept it. If the offer is accepted, then (6) the policy is underwritten.

▪ All of the steps must be managed by the system, and this chapter explains two options that can be used to do so: choreography and orchestration.

▪ Choreography is a process in which the decision to fulfill a given workflow step is left up to the individual subsystems. Each contextual subsystem must understand the stimulus, such as an event notification, that signals that a given step must happen next. Choreography is best reserved for simpler process workflows with few required steps.

▪ Orchestration is a process in which a central control mechanism guides the workflows steps by commanding each one to take place when and as directed. Orchestration is most useful when a process includes several or many complex steps, such as the policy underwriting workflow.

▪ Doing the simplest thing that could possibly work is generally the best choice. One such thing is to feed events to interested subsystems through a Web-based request–response procedure. This technique uses event logs stored in disk files similar to Web server static content (e.g., HTML pages and images), which are served to clients one log at a time upon request. It’s based on the scale and performance of the Web. The fact that the server might not be available from time to time is generally not problematic. Clients already assume latency exists between things that have happened on the server subsystem and one or more steps required in reaction on the client subsystem to bring them into harmony.

▪ An architectural technique is introduced as a means to track all data changes in a subsystem, such that audit trails of the changes are maintained over the subsystem’s life cycle. This approach is generally most useful when government or industry regulations demand proof of which data changed and when that change happened.

▪ Sometimes it’s helpful to treat the data that changes on user command differently than the data that the same user views to make decisions about which data changes should be commanded. This is the case when the shape and content of the data that users view is a richer aggregation of information than the more limited data that changes on command. This architecture technique creates a division between the two kinds of data, so that each side can be custom optimized for how it is used.

There is no need to be a software architect to appreciate the simplistic power packed into the architecture guidance offered in the chapters in Part III. Every executive and other senior managers who invest in software innovation as a competitive differentiator must be conversant with the architectural decisions being made on their behalf. Part III provides a highly approachable treatment of this topic for executives and software professionals alike.