The "whole problem" is simply a process. Processes in the real world are composed of 1-* sub-processes, and ultimately distill down into transformations (input -> transformation -> output).
You don't need to understand every low-level process to make a start.
You raise two interesting points though. Yes, revisiting an architecture is required when you've not solved a similar problem before. Consider though that in this community 99.9% of the time others have solved your problem before. You could reinvent the wheel (which is arrogant), or you could do some research to see which architecture has been successful for others.
Sure, that means doing some work before writing code which seems decidedly unpopular these days. It's a free world.
You also say that it's a lot of hard work. Yes. Nothing worth doing is easy.
[Edit] There's a really good book (there always is) that describes complexity and problem solving better than any other I've found. http://www.amazon.com/dp/0787967653
You don't need to understand every low-level process to make a start.
You raise two interesting points though. Yes, revisiting an architecture is required when you've not solved a similar problem before. Consider though that in this community 99.9% of the time others have solved your problem before. You could reinvent the wheel (which is arrogant), or you could do some research to see which architecture has been successful for others.
Sure, that means doing some work before writing code which seems decidedly unpopular these days. It's a free world.
You also say that it's a lot of hard work. Yes. Nothing worth doing is easy.
[Edit] There's a really good book (there always is) that describes complexity and problem solving better than any other I've found. http://www.amazon.com/dp/0787967653