Links

Beyond Software Architecture

Preface

Many excellent books have been written on software architecture. These books, which, among other things, define, classify, and describe software architectures, define notations for representing and communicating architectural choices, and provide guidance on making good architectural decisions, have enduring value. Unfortunately, while these books may help you build a successful architecture, they fall short of the goal of helping you create a winning solution. To create a winning solution, you need to move beyond subsystems and interfaces, beyond Model-View-Controller, and beyond creating third normal form relational databases. You need to move beyond software architecture and move towards understanding and embracing the business issues that must be resolved in order to create a winning solution.

An example of one such business issue concerns technical support. It is almost inevitable that one of your customers is going to have a problem with your software. When they contact you for assistance, choices you've made long ago in such areas as log file design or how you intend to support upgrades will determine how well you can meet their needs. Beyond Software Architecture helps you move beyond software architecture and towards creating winning solutions by discussing a wide range of business issues and their inter-relationship with architectural choices. Understanding and managing this inter-relationship is the key factor, for moving beyond software architecture does not mean throwing it out!

Beyond Software Architecture presents a unique perspective that is motivated and informed from my experiences in creating everything from single-user programs costing less than $50, software systems used in academic research, utilities used to diagnose and fix problems associated with internally developed systems, and distributed, enterprise-class platforms costing multiple millions of dollars. Along the way, I've played a wide variety of roles. I've been an individual contributor, a direct manager, and a senior member of the corporate executive staff. At various times I've either worked in or lead engineering, product marketing/product management, quality assurance, technical publications, and first and second line support organizations. I've managed teams and projects across multiple cities and continents.

The common thread that ties all of this software together is that all of it was created to provide value to some person. Research software, for example, serves the needs of the researchers who are trying to understand some phenomena. Business software, on the other hand, is designed to serve the needs of a well-defined set of users in a sustainably profitable manner.

This book represents the insights I have learned about creating winning software solutions in the context of a business. I focus on the business context, because this represents the bulk of my experience, and because in many ways creating sustainable software solutions-meeting customer needs over a long period of time, through multiple releases-is among the most challenging and enjoyable endeavors I've ever faced.

Although I will often refer to software architecture, and discuss things that are technical in nature, my discussions won't be focused on such things as the best ways to diagram or document your architecture or the deeper design principles associated with creating robust, distributed, component based systems. These discussions tend to be more academic than practical.

Instead of focusing on academic choices, Beyond Software Architecture helps you create and sustain truly winning solutions by focusing on the practical, nuts-and-bolts choices that must be made by the development team in a wide variety of areas. I have found that focusing on practical matters reduces the often artificial barriers that can exist between developers and the business/marketing people with whom they work. These barriers prevent both sides from creating winning solutions. I cringe when engineers profess to only taking a "technology" point of view, without due consideration for "business" issues, or when marketers make demands to "get me this feature", without due consideration of the underlying technical ramifications of the same.

What is especially troubling is that these arguments seem to be made in support of the idea that technical issues can be somehow separated from business issues, or that business issues can be somehow separated from technical issues. At best this is simplistically wrong; at worst it can be a recipe for disaster. Developers are routinely asked to endure the hardships of design extremes, such as a low-memory footprint, in order to reduce total system cost. Entire companies are started to compete in existing markets because investors are convinced that one or more technological breakthroughs will provide the competitive advantage necessary for success. Not surprisingly, investors are even more eager to invest when the technological breakthrough is accompanied by a similar breakthrough in the business model being offered to customers.

As you will find out, managing the inter-relationship between technology and business will be a recurring theme throughout this book. Handle only the former and you might have an elegant system. Handle only the latter and you'll have a paper solution that excites lots of people, and may even get you funding, but doesn't deliver any sustained value. Handle both and you'll have a winning solution. While creating elegant systems can sometimes be fun, and designing sophisticated new business models can be exciting, both pale in comparison to the deep satisfaction that comes from creating and sustaining winning solutions.