Not only is it hard, but the landscape changes frequently. You wouldn't design a system like you designed it pre-mobile, and you wouldn't design a system pre-mobile like you designed it pre-internet, and those are just the big shifts. Cloud is another big shift. A lot of people read how so and so design a system. So and so is successful, so I will design my systems that way. That's rarely ideal. Also, designs can change company to company, depending on what the company structure is, who they serve, etc. Designs can change when a company changes, so hopefully your software can change with it.

Sometimes you inherit a bad system, so how do you fix it while keeping your releases in stride. That's not easy, especially when then original designers aren't there anymore. Speaking of which, what's the best release stride for this company? You might have to adjust design for that too. Was this weird code done on purpose, is it a bug, or were they trying to hack around a mistake somewhere else? Time to roll the dice, because you need to change it. How do you minimize the collateral damage if you are wrong?

You also need to consider your limitations like network and persistence storage. That's a huge part that many haven't even considered yet. How are networks designed today? How is data persistence designed today? What are my options and what are my limitations with this company? What type of reports does this company need? That's a big one. How about failover, what does your system do when the network or database quits? Do you lose any data? Are you sure? How important is it to not lose data? It's not that bad if Facebook loses a post, but it sure is bad if a bank loses half of a transaction.

Programming has a lot of levels that we don't even realize until we hit a new one. Turning good specs into working code is level 1. It takes a hell of a lot of brainpower and abstract thinking to just do that.