Regardless of what specific business requirements there may be, requirements that deliver value need to arise from sound business, code, application, UI/UX, and infrastructure architectures, and that task must exist within the primary constraints of scope, cost, and time. The soundness of any design is predicated on the architecture it's based upon. Whether it's one line of code, an application module, the UI/UX, the infrastructure, or a business requirement, each must do its part to mitigate risk, support quality, and deliver value.
A software's design and architecture is always under test whenever that software is run. Every project, at one time or another, has had failed tests. Just as good code starts as bad, or at least workable, code, successful projects don't hit their stride out of the gate. There are always bumps along the way. The question is whether that bumpy ride can get smoother, when that smoother ride will begin if it can begin at all, and finally, what the additional costs will be. When your software is evaluated, whether through use or retrospective, the question of whether success can be achieved at all, and the degree of success achieved, is founded on certain design and architecture pillars the software sits upon.
It's often lamented that what software developers are called-upon to do is difficult. I posit that why such difficulty exists is that on one hand we're asked to model reality via software composed of interfaces, logic, and algorithms, and on the other hand, there's a dearth of people with sufficient understanding of how a business reality is supposed to work, or, much less, how it actually works.
Before we can confront how the existing system works, we must confront what the existing system is. The existing, like beauty, is often interpreted in the eye of the beholder. At a basic level, the existing system is composed of three basic components: software, processes, and infrastructure with the goal of supplanting the existing system with new software, processes, and infrastructure. The scenario is exactly what it sounds like, replacing a system's powerplant while keeping the system running. Distilled down to one word, that word is risk.
Risk management requires a blueprint, a plan that defines the software's design and architecture. The blueprint also serves as a guide to the boundaries within which your software's designed to operate. Staying within the boundaries carries at least some risk and straying beyond those boundaries is even riskier. Not knowing where those boundaries are is the riskiest behavior.
All risk, great or small, must be managed. In my experience, risk mitigation through successful system design and architecture consists of these architectural pillars:
- Business: All business requirements, knowledge, and SMEs. Also any legal, compliance, and regulatory matters. The Business defines and owns the scope, cost, and time constraints. The business is the primary customer and the arbiter of value and quality. At the same time, the business is accountable for creating value. In other words, the business is responsible for and accountable to itself.
- Code: The standards and practices that are brought to bear on the code. The raw materials themselves must be of good quality, both as to content and proportion. If those raw materials are reasonably expected to combine to produce a quality product that yields positive value, all that goes into developing and improving those raw materials must be of comparable quality. It's obvious: quality yields quality. You can have 99 quality steps in a 100-step process. If the last step doesn't meet the moment, the work product is in danger of becoming spoiled.
- Application: Includes the components, libraries, and integrations that comprise the application. The application is what the code evolves into. An application can only be as good as its underlying code, which can only deliver value to the extent that the business can articulate and define the criteria by which success is measured. Business > Code > Application is the primary critical value supply chain.
- UI/UX: Some may consider the user interface and user experience to be part of the Application pillar, but how users and other applications will be able to interface with the application is just as important as the application itself. The underlying requirements, the code and the application need to be suited to the task. UI/UX in this context includes the API taxonomy as well as the graphical user interfaces, whether they be mobile-, tablet-, or laptop-oriented.
- Infrastructure: If the application is part of a cloud migration, which IaaS, PaaS, and SaaS features will be used? How will security and access be controlled? How will distributed denial of service (DDoS) attacks be defended against? How will scalability, high availability, and reliability be managed? How will disaster recovery be managed? Often, enterprises proactively fend off such events through redundancy (high availability).
These pillars exist within an over-arching contex, what I've referred to in the past as the “business and administration of software development.” How we write, build, test, and deploy software and how we enforce standards and ensue quality - all of that could safely be generally referred to as what modern DevOps represents.
The core of DevOps is about creating positive value streams that are the by-product of our software development work. The five pillars enumerated above provide a means to catagorizing software develoment concerns against the backdrop of business requirements. The intersection of where design, architecture, and the business meet is where the software takes form.
Any healthy software project must be of sufficient quality subject to the three primary budget constraints of scope, time, and cost. I've written in these pages before that in any project, we must choose the two we wish to directly control, leaving the third to be a function of the two we chose - we don't have direct control over the third constraint. For example. if we want a broad scope in the shortest amount of time possible, we're ceding control over costs. Which constraints to prioritize derives from a system's design and architecture.
Having no direct control of costs puts a whole new perspective on risk tolerance. When costs can't be controlled, the constraints that need to be controlled directly are scope and time. If the solution is needed quickly at a minimal cost, scope will need to be pared back. This is often manifested in terms of a minimally viable product (MVP). Figure 1 illustrates a risk mitigation through architecture model for software development:
To mitigate risk, it's better to be slow and steady than fast and erratic. It's far better to aim small and miss small than to aim big and miss big. The basic rule is: If we're going to undertake work, while we accept the fact there will be unknowns, we'll nevertheless endeavor to understand as much as we can about what we're delivering. That understanding can be enhanced by categorizing decisions within a design and architectural context that takes account of business and technical concerns, which, taken together, creates conflict. Those conflicts must be resolved before work proceeds.
None of the five suggested architectural pillars exist in a silo, independent of the others. They must all be coordinated in such a way that they can all productively enhance quality. Quality is enhanced when the coordinated effort is subject to a constrained approach that is, in turn, subject to budgetary matters of time, scope, and cost. If any one pillar falls short, quality is impaired, which results in diminished value. And no one wants that.
