First Principles for Solution Design
JohnArwe 120000CAW7 Visits (1740)
Since 90% of the output of any system is a function of its structure (something I learned in System Dynamics at MIT "a few" years ago -- don't take the 90% value too prescriptively, SD is about the shape of the output more than exact values), it's important to have a solid list, and it's important to evolve it over time. As the audience most concerned with the outputs of our solution development system, you seem like a logical group to critique my list, and especially to fill an any blanks. You'll see that this list is at a very high level of abstraction -- that's intentional. It keeps people focused on the desired result ("what"), rather than the route taken to that result ("how")... if you keep the techies focused on the 'what', a lot of the 'how' debates fall by the wayside. I'll poke in more detail at some specific points in the future, but for now let's concentrate on things at this level.
Clients want solutions...
It's a list I put together for my own use; it has no official status in the development process, but I do use it internally in an informal educational sense. It's possible some things are missing; it's possible some things here are no longer especially important, and I should drop them. You might observe what is missing too: no mention of 'how'; no specific technologies (I'm a pragmatist - fit the tool to the job, after learning the tool's limits).