Evolutionary Software Development
Evolutionary software development involves breaking down a complex project into small easy-to-manage/understand modules that are iteratively developed and released. It emphasises guided, incremental change across multiple dimensions as a first principle.
Planning Phase
When approaching the architectural and system core design, it is essential to focus on designing around the concept business domain while ensuring there are reasonable ways to adapt to change.
The planning phase is the most critical phase and also the one in which requirements tend to be loosely formulated. It is essential to consult with domain experts and base the design on their input — essentially, Domain Driven Design (DDD).
As a software architect or someone playing the architect role, the first goal should be to create a platform in which the right systems can emerge. When the right platform has been determined, the part(s) of the concept to deliver first can be selected based on business priorities.
Delivery becomes smooth once there is clear understanding of the immediate and near future needs.
Execution Phase
Once the system core and platform has been designed, incremental delivery of the concept to fruition is done in the execution phase. This phase entails design before implementation albeit more narrower and specific as compared to that in the planning phase. The design in this phase usually involves that of more focused supporting systems and incorporation of feedback from earlier delivered versions.
Implementation of the systems can benefit a lot from aspects of Model Driven Engineering (MDE) which when done right, results in software that makes sense from the point of view of a domain expert. The benefit of this is that the cognitive load required to maintain the system is significantly reduced since correct assumptions can be made about the software.
Framework for the right systems to emerge
The driving architectural characteristics of the concept should guide the selection of the best suited architecture. It is not uncommon to use more than one architectural style — the key is to make sure there’s a conscious decision to use the style i.e, its pros and cons as relates to the business domain have been well understood. Below is a diagram illustrating different architectural styles and the “ilities” they excel at.
It is not enough to select a suitable architecture, measures should be put in place to ensure the architectural guiding principles are continually adhered to. This can be accomplished using fitness functions.
Infrastructure Design
For a greenfield project, it is essential to deliberate on the best suited type of general infrastructure — “good operations can often work around the limitations of bad (or incomplete) software, but good software cannot run reliably with bad operations”
Ill-conceived infrastructure decisions often lead to inefficient and unjustifiably expensive operational costs. Furthermore, retrofitting infrastructure to meet regulatory requirements can be a tremendous undertaking.
When making infrastructure decisions, some of the key items to consider include;
Regulatory compliance
Networks and Security
Compute provisioning
Time and cost constraints
Regulatory compliance
The business domain can have regulatory restrictions that dedicate the approach taken for;
Database provisioning. You might have to provision dedicated databases for each country you're in or plan on being operational.
Application deployment strategy. The applications your customers will be using might have location restrictions.
Networks and security. There might be rules governing how and who should be able to access certain systems and the level of auditing required for such access.
Networks and security
How systems are exposed to the open internet is a concern that requires serious consideration — minimising exposure to the open internet helps reduce the attack radius for malicious entities. Identify and classify the various types of workloads involved and devise the network and security layout.
Compute resources
As software is being built or bought to facilitate business operations, it will need to be deployed. Different types of workloads thrive in different types of deployment strategies. Possible options for deployment strategies include;
Serverless
Single service per host
Multiple services per host
Container orchestration
The table below illustrates how each of the deployment strategies above performs.
Conclusion
Evolutionary software development emphasises breaking down a large project into small easy-to-manage portions that are gradually rolled out. This helps highlight the bigger picture while also enabling the delivery of short term goals. Excellent product management skills are essential for success in evolutionary software development. This is due to its iterative nature and the provisions it offers for incorporation of new requirements in the development process which increase the potential for scope creep.