I see step 4 as interwoven with other steps. The implementation ideally takes into consideration the domain and while implementing, potentials for flexibility are potentially revealed, to be taken advantage of, "without programming ourselves into a corner". Implementation also is of course related to maintenance. Maintenance already needs to be taken into account. How easy is it to adapt the system we are building later?
This all happens while we are at the implementation stage and impacts all other aspects of the whole thing. It is a grunt work, but we need elite grunts, who see more than just the minimal requirements.
I’ve been going on about this in another thread in a separate post. That’s where modularity comes in. From code I write to teams (or multiple teams back in the day). I always enforce micro services. Not always separately deployable micro service, they could be separate packages with namespace/public/private accessibility.
Even if you do have not so good developers, they can ramp up quickly on one specific isolated service and you can contain the blast radius.
This isn’t a new idea. This was the entire “API mandate” that Bezos had in 2002. s3 alone is made up of 200+ micro services