There is a popular notion that requirements stability is difficult to acheive, because customers don't know what they want. Ignoring for the moment that requirements instability is the root cause of Death March project and let's pretend requirements stability is in fact hard to come by.
If you a project without requirements stability, the architecture of the underlying systems become paramount, since the components of the system are guaranteed to change.
What is software architecture?
Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.
This means that the underlying architecture must
- Be based on a reference design, so the structure has alreay been shown to work
- The transaction model must be separated from the data model and the display model
- There must be strict, some would say ruthless, separation of concerns, for example
- Data warehouse paradigm, where the data for the transactions and the resulting display and interaction is completely isolated
- A federated architecture, where systems are integrated through a data bus or some other form os isolation
- The referential integrity of the data must be ruthlessly maintained and enforced
With these the result of low requirements fidelity is the ball of mud or shanty town architecture. The Ball or Mud paradigm is
A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
This means there is
- Throw away code - we'll fix this now and worry about the outcomes later
- Piecemeal code that is installed to fix the current problems, only to create future problems.
- Keep it working - we're on a deadline, we need to get this fixed and move on.
And of course the biggest lie of all for any non-trivial system
Our architecture emerges as the requirements become known
This approach is the basis of Shanty Town or Ball of Mud architecture of the modern hacked together systems we've all come in contact with.
