Pivot-able Architecture

What is software architecture;

“Software architecture refers to the high level structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.” – Wikipedia.

Why should we care;

“Software architecture is about making fundamental structural choices which are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of software.” – Wikipedia

Most often when coming to design an architecture for a software solution, the business case is still very speculative. Meaning that the solution which will best serve the target audiences, is still unknown. At the same time the, once implemented, the architectural design of the software is costly to change.

How then, would one go about designing a software architecture in an uncertain domain, which would most likely demand some changes once the solution has reached the audiences and its utility starts to refine?

One logical path to address this situation, would require the software architect to clearly define the value proposition built into the software solution. Knowing that, will create a sub-set of assumptions relating to the solution, which will be relatively fixed and endure through the life-time of the solution and its various versions.

When a solution is design with the business case in mind first, it can more easily be compartmentalized. Creating a fragmented design will enable the solution to pivot through the first set of iterations in the market. Where some segments of the solution will be abandoned over time, while the others become an integral part of the solution going forward.

This design might be viewed as a patchy or ad hoc evolution of the solution, the main difference here however, is that this strategy has a direction and a purpose. The core of the patching is design with the value proposition in mind, and the additional components all come together to support and enhance it. 

Some concepts of architectural design transcend any specific solution and can provide a guide in uncharted territories. A consideration of a smart client vs. a heavy server logic can be decided using a few basic points of information on the solution and overall business space. Choosing web vs. mobile or cloud vs. on-prem can be done fairly early in the process as each of these decisions have clear advantages. Other architectural decisions regarding logging mechanisms, unit test and code-review policies are solution agnostics and can be put in place based on the best practices relating to the development team.

Once the easy scientific decisions are made, a solution architect is then faced with the artistic (perhaps even instinctive) aspect of the craft. Required to make educated guesses on the best tools and structure to serve a solution which has not been built and has not been reviewed by the intended users. This it where a Pivot-able approach for a software solution architectural design should come into place. In this approach the architect would identify a sub-set of characteristics of the proposed solution which are most likely to endure over-time (e.g. servicing the elderly, shopping-cart, full functionality offline, AI supported, etc…). These are the foundations of the architectural design. If the business case is defined well enough in advance, and the pivoting of the business is not likely to breach these parameters, the architect can then put in place these foundations and feel comfortable with making tools and structure decisions around them.

Next is the trial and error phase, these components should be cheap and patchy. Some will stick, and some will be abandoned on introduction to the market. The agile, quick and iterative development methodology really becomes valuable at the phase. When building and designing these ad hoc features, it is best to keep a clean divide between them and the core structure of the solution. Almost defensively assuming these components will fail to penetrate the market and would have to be severed and discarded.

Over time the component which have “made the cut” will become more integral to the solution, merged into the foundation and become foundation for additional layers of new features and components. As the business evolve reaching new audiences and the continuing demand for innovation forces the solution to grow, there will be a point in time when a new solution would have to be rebuilt and redesigned from scratch. For the lifetime of the solutions however, the more flexible it is in its early days, the longer it would last before a complete reconstruction is required.