12. Require Balance, Demand Strategy

This book has taken us on an intense journey through many aspects of business strategy, digital transformation, strategic learning tools, event-first modeling, reaching domain-driven results, and purposeful architecture with both Monoliths and Microservices.

In this final chapter, we provide a chapter-by-chapter summary of our journey. First, though, we reinforce a key message: There must be balance between business functional requirements and non-functional technical requirements, where the latter must be justified by identifying purpose. This balance is key if the organization is to remain laser-focused on strategic innovation.

Balance and Non-functional Requirements

Software architecture is multidimensional. The section “Right from the Start” in Chapter 10, “Building Monoliths Like You Mean It,” highlights the importance of trade-offs in the face of balancing non-functional requirements, such as performance, scalability, throughput, security, and others. One such trade-off is to balance between performance and scalability without compromising on either of them. Choosing which one of these requirements is more important is essential, because it’s impossible to optimize equally for both. Ultimately, one or the other must have the edge in the realized non-functional requirements.

Thus, selecting between trade-offs is equally important for modular Monoliths and Microservices. Take another look at the non-functional requirements in Chapter 8, “Foundation Architecture.” Consider how the chosen architecture affects the non-functional requirements, and how the non-functional requirements affect the chosen architecture. It’s not difficult to understand why finding balance is so important. Here’s a summary:

Performance: Network latency affects performance. Microservices require a network, if not multiple networks. There are various options for lowering latency by ensuring there are fewer network requests and by making network requests simultaneously.

Scalability: There is a definite advantage to using Microservices when high scalability is necessary, because they can independently scale the resource-intensive parts of the software. Yet, if a Monolith is designed and implemented as a cloud-native system, then it can be deployed as a Function as a Service (FaaS) component, yielding a cloud-scale application.

Resilience, reliability, and fault tolerance: Both Monoliths and Microservices can be designed and implemented with these important qualities. There is less technical overhead in doing so with Monoliths. Use of the Actor Model and other single-process Reactive architectural approaches can increase these qualities in both Monoliths and Microservices.

Complexity: There are several trade-offs between Monoliths and Microservices in terms of complexity, which tend to have opposite consequences.

The non-functional requirements discussed in this section are not exhaustive. For example, we could include a discussion about usability, and how it is interrelated with the requirements we did discuss. Of course, security and privacy, as discussed in Chapter 8, are not optional. Our focus here is on what are generally the most salient among the non-functional consequences brought from choice.

There is no clear winner between modularized Monoliths and Microservices. As always, it is important to understand the circumstantial trade-offs. Modularized Monoliths fit well in the context where performance, reliability, and the least possible complexity are required. Microservices shine when it comes to scalability, availability, reliability, and fault tolerance. Deciding which approach to pursue isn’t a binary selection process. Instead, the options can be balanced to ensure the optimal application of each.

Finding balance is hard, especially in a large system, but tools are available to help us do so [ATAM]. Sometimes, and possibly even more often than not, a blend of modular Monolith and Microservices will give the greatest payoff. Remember, the ultimate goal is to develop strategically significant software that produces breakthrough innovations.

Strategy and Purpose

The overarching theme of this book has been reaching strategic goals by means of strategic thinking and strategic software development. Recall what has been explored in this journey, chapter by chapter.

Business Goals Inform Digital Transformation

Business goals should be differentiating; otherwise, transformation is just another buzzword that is expensive to chase, but too elusive to catch. Here are the big ideas from Chapter 1, “Business Goals and Digital Transformation.”

▪ If pure invention seems nearly impossible, continuous and tenacious improvement is not. Although you will fail if you attempt to leap from A to Z, moving from A to B, and then from B to C, and then . . . is a feasible way to achieve innovations that outstrip imaginary transformation, such as on-premises to cloud migrations. (For a reminder of why this is “imaginary transformation,” see the section “Digital Transformation: What Is the Goal?” in Chapter 1.)

▪ Software goes wrong when lack of knowledge and necessary shortcuts aren’t recognized and then addressed by knowledge acquisition and corrective refactorings. A Big Ball of Mud becomes the destination, where everything becomes slow, and getting out of the hardened mud is difficult after spending a long time encased in it.

▪ Operating under the effects of Conway’s Law is an inescapable fact of life. Communication is the key to knowledge acquisition, and organization structure can either help or hinder this process. Organizing teams around areas of expertise with the right people and clear communication is the best way to innovate with success. Of course, we’re not recommending the creation of silos, but rather creating teams within specialized areas of a system that include cross-team communication and overall shared goals.

▪ Minds can be on autopilot, or they can be engaged in exploratory and deep thought. Rethinking multidimensionally and critically is a good way to challenge the status quo, with the goal of transitioning from a position of ordinary to a fresh strategic vantage point.

▪ Monoliths are damaging when poorly designed, and Microservices are disastrous when misappropriated. An architecture is good for its intended purpose. Purposeful architecture is the best architecture.

▪ #Agile is what teams make of it. If it is kept lightweight and focused on satisfying the customer, it will take teams in the direction of success. If it becomes heavyweight and ceremonial, those using it are by definition doing #agile rather than being #agile. Doing #agile will hinder success.

▪ A software system that has become deeply mired in debt, and possibly reached maximum entropy, took years or even decades to reach that point. Succeeding under such conditions depends more on attitude than on distributed architectures. Positive attitude is developed through confidence; confidence is achieved by smart choices and continuous improvement.

Use Strategic Learning Tools

A strategy is the what aspect of business creation, leading to new initiatives that are intentionally unique and produce a combination of profit sources. Make culture a tool. Learning to learn for strategic advantage is the essence of Chapter 2, “Essential Strategic Learning Tools.”

▪ Decisions are necessary. Deciding when to make decisions is as important as the target decision. Make decisions at the last responsible moment. Being wrong so that you can eventually be right is the purpose of experimentation.

▪ Failure is not fatal when building an agile, failure-tolerant culture that fosters willingness to experiment. Providing people with the psychological safety needed to experiment and fail will only increase business success and competitive advantage. It makes teams stand up to Conway’s Law.

▪ Design modules first and push long-term deployment decisions as far out as possible.

▪ Innovating toward strategic, competitive advantage is hard. Achieving this aim requires focusing on software design based on business capabilities and tackling business challenges. Don’t allow poor architecture and design to derail business innovation.

Event-Driven Lightweight Modeling

In software development, some fundamental concepts underlie the way that components work well together. Modeling software rapidly while collaboratively applying the fundamental concepts of components is a powerful approach that accelerates knowledge acquisition and success. Put these tools from Chapter 3, “Events-First Experimentation and Discovery,” to work.

▪ Software modeling is a big part of making sense of the complexities of business. The models produced are used to relate everyday business procedures and processes to software components.

▪ Model with events first, but include commands, policies, entities, and other elements where they benefit learning. This is a low-tech tool for experimentation that leads to understanding innovation within high technology.

▪ Although intended for in-person collaboration, EventStorming can be simulated online with remote teams using a virtual modeling surface.

▪ Using EventStorming big-picture modeling is an exercise in discovering the overall flow of the system under exploration. It’s an initial step toward dynamic and rapid learning.

Driving Business Innovation

Every business has a specialized sphere of knowledge, which is gained through preexisting expertise and the activities of collective and shared learning. Once this knowledge is reflected in software products, it has influence on consumers. In actuality, businesses have multiple, if not many, spheres of knowledge, and the chapters in Part II dive into ways to take advantage of the core parts.

▪ When it comes to business software strategy, understanding where to invest the most and where to invest the least is critical to success.

▪ Software reaches across the breadth and depth of an entire business. The entire domain or sphere of knowledge of all software in a large enterprise is voluminous. Use the concepts of domains and subdomains to understand the problem space and strategic decision making.

▪ Separate the context of communication within a specific, focused sphere of knowledge into a Bounded Context. Develop a language around the salient features of the communication, and maintain its consistency of meaning inside the boundary.

▪ Understand the specific core, supporting, and generic subdomains within a system. Know where to invest in core differentiation, where to provide supporting models, and where commercially available solutions would work best.

▪ Use Context Maps to recognize and improve inter-team relationships and for selecting the appropriate integrations patterns.

Events-First Architecture

Not every architecture style and pattern will suit any set of arbitrary business, technical, scale, performance, or throughput constraints. The specific set of constraints will drive a purposeful architecture. These are important takeaways from the chapters in Part III.

▪ Problems are likely to be encountered when there are fundamental differences between the external devices and other mechanisms used to interact with a software service or application. Use the Ports and Adapters architecture to separate the technology from the outside world into consumable stimuli offered to a service or application.

▪ A message-driven architecture emphasizes sending and receiving messages as playing a prominent role throughout the system. The benefits realized from this architecture include loose coupling of software components and services as well as reduced dependencies on expected outcomes within an arbitrary time dictated by technology. Events are inherently messages, so a message-driven architecture supports an event-driven architecture.

▪ REST is an architecture style and pattern that supports request–response actions. In consequence, REST can be useful even in an event-driven architecture. The requests are made using verb-based methods. Requests can be used by a consumer to register for events to be published by a system by means of REST-over-HTTP.

▪ Within the domain model of an event-driven architecture that uses a domain-driven approach, powerful tactical tools can be employed to manage the complexity of the business domain: Entities, Value Objects, Aggregates, Domain Services, and functional behavior.

▪ Use process choreography and orchestration, where fitting, to manage long-running system-wide workflows. For simpler long-running business software processes that require limited individual steps, choreography is suitable. For more complex processes with a fair number of processing steps, orchestration works best.

▪ Use Event Sourcing when maintaining an audit log of all past occurrences in a service or application is a business concern. Employ Command Query Responsibility Segregation (CQRS) when queries are complex and the organization can realize advantages from tuning the answers before the queries are executed.

▪ Managing security and privacy are certainly not the least important among the many architectural decisions. In fact, in recent years these issues have been pushed to the forefront of information technology concerns.

Monoliths as a First-Order Concern

Architecting and designing Monoliths to be both useful and manageable over the long haul is not a pipe dream. For most companies, developing Monoliths for use over the long term makes a lot of sense. Even if the organization decides to use at least some Microservices, starting with a modular Monolith makes it possible to reach decisions at the last responsible moment. Using the following advice compiled from Chapter 10, “Building Monoliths Like You Mean It,” can help teams focus on all-important software delivery rather than getting sidetracked by architecture decisions that they might not have ever needed.

▪ Effectively architecting and designing Monoliths from the start can be accomplished using straightforward steps.

▪ Seek business capabilities to implement in a Monolith, because the business capabilities of a company are natural places for division between various models. These decisions will be driven by business experts and technical stakeholders who engage in specific capability-centric conversations.

▪ Even after a Monolith becomes the unfortunate home of a Big Ball of Mud, an organization can use specific measures, as thoroughly explained in Chapter 10, to form a modular Monolith.

▪ After traveling the bumpy road to form a modular Monolith from a Big Ball of Mud, it might be that remaining with the Monolith makes the most sense.

Purposeful Microservices from a Monolith

If there are good reasons to separate some Bounded Contexts from a Monolith into autonomous Microservices, that transition will be most straightforward when the organization starts working from a modular Monolith. If that’s not a luxury afforded to you, and the leap from a Big Ball of Mud into Microservices is necessary, you can follow some steps to make this shift happen more easily. When there is a purpose to using Microservices, by following the guidance from Chapter 11, “Monolith to Microservices Like a Boss,” you’ll be kicking [amorphous] and taking names.

▪ As with any complex software development undertaking, developing the right mental perspective is quite important before embarking on a journey to develop an architecture. Yet, when pursuing distributed systems with a Microservices architecture, some challenges will stand out quite starkly. Performance, scalability, reliability and fault tolerance, and other complexities must be well understood.

▪ From team dynamics and technical perspectives, the choice of which Bounded Contexts to extract from a Monolith, even a well-modularized one, is not arbitrary. The best candidates are based on factors such as rate of change; a general need for autonomy, including independent deployments; performance; and scalability.

▪ Even when working from a modular Monolith, at the early stages the team should extract one coarse-grained contextual module (Bounded Context) at a time into a Microservice. Look for quick wins. After gaining experience and confidence, the team might be able to evolve more than one Bounded Context into a Microservice. If it encounters problems when doing so, the team can fall back to moving one Bounded Context to a Microservice at a time.

▪ Extracting Microservices from a Big Ball of Mud is very challenging, but the team can use some measures to render this a success. Move with caution and seek opportunities that lead to achievable wins.

Balance Is Unbiased, Innovation Is Essential

Software architecture is multidimensional, and its evolution requires reaching a clear understanding of the current trade-offs. In the face of balancing non-functional requirements, such as performance, scalability, throughput, security, and others, it is essential to understand the trade-offs and make unbiased decisions. If you want uncompromising value delivery, heed these lessons.

▪ Imagining that Microservices automatically deliver higher performance is wrong. The only way to understand the trade-offs is to measure. In-process method invocations are faster than network operations.

▪ Performance and scalability can be achieved in different ways, and Microservices aren’t always a clear winner in that regard.

▪ Using “transformation” as an excuse for pursuing Microservices and/or a cloud-native system is not innovative or differentiating. Following this course of action must provide an advantage. Many companies have already adopted Microservices and cloud-native systems when it was not necessary, and have paid a heavy price for those bad decisions, both financially and operationally.

▪ Business goals must be sought for differentiating value. This does not negate making other strategic or tactical moves, such as moving to the cloud or using Microservices. Ultimately, those decisions should help the business to achieve differentiating value, not hinder it.

▪ Being wrong so that you can eventually be right is the purpose of experimentation. Knowledge workers must feel safe and be safe while seeking to acquire knowledge.

▪ Practice deep thinking and critical thinking when asking “Why?” and “Why not?” Experiment toward reaching strategic business goals. Apply strategic thinking and continuous improvement that leads to distinguishing software systems.

Conclusion

In 2011, Forbes published an article titled “Now Every Company Is a Software Company” [Forbes-ECSC]. That article asserts:

The era of separating traditional industries and technology industries is over—and those who fail to adapt right now will soon find themselves obsolete.

Now, at least 10 years after those words were written, many companies have adopted that point of view. Many more companies have not. There are still other companies that are somewhere in between.

Does that mean companies that have not achieved a good amount of progress toward digital transformation are now obsolete? Look for the startup that could well displace that company within a few years. One problem with huge companies is that they can’t move quickly. Another problem is that they can’t detect their own slow death, because they can’t understand that a $20,000,000 loss in a quarter occurred because consumers are moving to the bright, young, agile competition. The company might literally not even be aware of that new startup, or know of only one out of five serious challengers.

The answer to this dilemma is not for large companies to go on a scavenger hunt, looking for all the new startups that could eat their lunch—that is, unless buying their lunch (acquisition) is the only way to prevent this fate. Allowing and actually enabling nimble startups to innovate over your company with the idea of future acquisition is not a great strategy. Those companies could be second in line or off the offering price by a few billion dollars. Unicorns happen.

Don’t trade the opportunity to turn a current core software system into the next generation of SaaS or PaaS in your industry. We, the authors, truly hope to have provided both incentive and inspiration to start your journey, or to keep innovating along the path that has already begun.

References

[ATAM] https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513908

[Forbes-ECSC] https://www.forbes.com/sites/techonomy/2011/11/30/now-every-company-is-a-software-company/?sh=7cfd5ec2f3b1

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.238.82.77