Incremental Software Architecture

Chapter 12Design Substantiation

Nothing proves more conclusively that an end-state architecture is indeed performing as expected than its sound implementation. If the design proposition were still an architecture blueprint, the task would be then to implement segments of the overall architecture to substantiate the founding planning and assumptions.

At this crucial junction in the incremental software architecture process, the charter is clear: Prove it by implementing it.

However, if the end-state architecture has been delivered, deployed, and now operates in production, then the task is different. Here, the mission would be to discover troubling segments of the end-state architecture, ascertain the root cause issues, and apply proper remedies. In some cases, though, it would be wise to retire a troubling system or an application if the efforts to avert a shutdown outweigh the benefits of rescue. This also goes for a failing environment, in which systems, applications, middleware, or network infrastructures do not meet business or technical requirements.

Either of these scenarios calls for action. In the former, when a software construction is about to take place to verify an architecture, a design substantiation effort must be pursued. For such an endeavor, continue though the sections that follow to learn about process of design substantiation. If the aim is to find troubling architecture segments or to save failing implementations, simply refer to Chapters 13–15. These chapters ...