Many creative people will tell you that new ideas begin -- often spontaneously -- with a mind's sketch that they then render in some kind of media.
Fair enough -- no news there. We've talked about storyboards, etc before.
But then the heavy lifting begins. How to fill in the details? Where to start?
My advice: Draw it first.
If you can't draw it, you can't build it!
And so the question is begged: What's "it"
And, one more for the PM:
Digression: My nephew reminds me that now we have 3-D printing as a prototype "drawing" tool. Indeed, that's his job: creating 3-D prototypes.
Narrative: (an example)
Bridge stanchion with strain sensor and sensor software
Let's start drawing: Actually, I like drawing with boxes. Here's my model, beginning with the ubiquitous black box (anyone can draw this!):
Of course, at this point there is not much you can do with this 100% opaque object, though we could assign a function to it like, for example: bridge stanchion (hardware) or order entry shopping cart (software)
And so given a function, it needs an interface (blue); some way to address it's functionality and to enable its behavior in a larger system context:
And then we add content (white):
Except, not so fast! We need 'room' for stuff to happen, for the content to have elasticity for the unforeseen. And, so we add a buffer (grey) around the content, but inside the interface, thus completing the model:
- Black: Boundary
- Blue: Interface or API
- Grey: Buffer
- White: functional content
You could call this an architecture-driven approach and you would not be wrong:
1. First, come the boxes:
- Define major functional "boxes"... what each box has to do, starting with the boundary (black): what's in/what's out. This step may take a lot of rearranging of things. Cards, notes, and other stories may be helpful in sorting the 'in' from the 'out'. If you've done affinity mapping, this boundary drill will be familiar.
- Our example: three boxes consisting of (1) bridge stanchion (2) strain sensor (3) sensor software
- Then define the major way into and out of each box (interface, I/F, blue). If the interface is active, then: what does it do? and how do you get it to do it?
- The buffer, grey, captures exceptions or allows for performance variations. In effect, the buffer gives the content, white, some elasticity on its bounds.
- And then there is the actual functional content, to include feature and performance.
2. Second big step: networks of boxes
- Think of the boxes as nodes on a network
- Connect the 'black' boxes in a network. The connectors are the ways the boxes communicate with the system
- Define network protocols for the connectors: how the interfaces actually communicate and pass data and control among themselves. This step may lead to refactoring some of the interface functionality previously defined.
- That gets you a high-level "network-of-boxes" . Note: Some would call the boxes "subsystems", and that's ok. The label doesn't change the architecture or the functionality.
Define all the other details for the 'white box' design. All the code, wiring, and nuts and bolts marterials to build out the box.
- Expect to refactor the network as the white box detail emerges
- Expect to refactor the white box once development begins. See: agile methods
The beauty of this model is that each box can have its own methodology, so long as interfaces (blue) and boundaries (black) are honored among all boxes. In other words, once the boundaries and interfaces are set, they are SET!
The methodology can then be chosen for the white box detail: perhaps Agile for the software and some form of traditional for the hardware. This heterogeneous methodology domain is workable so long as there is honor among methods:
Interfaces and boundaries are sacrosanct!
Estimate the work (yes, estimate: you really can't start off spending other people's money without an estimate); segment and sequence the work; and then build it, deliver it, and you are DONE!
Check out these books I've written in the library at Square Peg Consulting