On my last project as an architect, I found myself drifting into an architecture strategy of keeping everything as simple as possible. In choosing a database I would look at our projected usage, multiply the number by ten and evaluate which database would be the simplest given our requirements. Given the size of an external library is it better to import it as a black box or to write the functionality as a single file module? The project being in Go made a few of the choices easier because Go does not offer many higher level features. Instead of worrying about class hierarchies you just write the functionality you need.
Keeping it stupid means choosing an architecture that anyone would understand at first look. Other people should always assume that they could have come up with the architecture when they read it. There shouldn’t be any surprises or ‘cool’ technology choices. There is a blog post out there about how a startup or software team can afford to pick one risky technology before going bust. In KIS architecture you never pick a risky technology.
In the 2018 Software Engineer’s toolbox are dozens of technologies that are both proven and incredibly powerful. We have access to many of the common tools as managed services in the cloud making things even easier. Save yourself the trouble, keep your architecture stupid until its proven that it needs to be more complicated.