We need to manage architectural project risk because it is not possible to select 100% suitable architecture at the start of a project. Read another post from the project management series. The post is based on a remarkable book written by Johanna Rothman, Manage It!
We have an infinite number of possibilities for our product architecture. What is architecture in the software development project? We have two main architectural decisions:
- Code structure architecture
- Code runtime architecture
Code structure architecture
This defines how the main components of your application will be organized. For example, your web application could follow MVC architecture, where MVC stands for Model, View, and Controller. The model handles database interactions, the controller is business logic and communication with 3rd party systems, while View holds user interface.
Or you can set Event Sourcing architecture, where everything evolves around events. Events are first stored in the repository and then distributed to event handlers. If somebody mentions that it would be a good thing to use the message queue, that directs you to event sourcing architecture.
Code runtime architecture
These are servers that run your application code. Here, you have a vast number of options, these are just some of them:
- Kubernetes (docker containers)
- AWS EC2 instance
- your own infrastructure
- Linux OS
- Windows OS
- Platform As Service (Heroku)
Lifecycle And Architectural Risk
To lower architectural risk, it is good practice that you can try your application as early as possible. Serial lifecycles are bad for architectural risks, while agile is more suitable. But agile could also be a problem if you do not start with features that would involve end to end flow through your application. Testing those features, you will mitigate architectural risks.
PowerPoint Architecture Fallacy
You probably meet software architectures depicted in PowerPoint with the author claiming that it is possible to test such architecture. You can test architecture only when your application code goes through the processor.
Test your deployed application early and often. Architecture risk is just one of the reasons.