This is probably going to kill me.
But I'm unhappy with the fundamental structure of my book.It is not Lean. It does not flow. It is the architectural equivalent of batch processing and waterfall.
All very rational, deriving (as noted in the book) from established architecture methods. First I do a process model, then a functional model, then a data model, then a systems model.With lots of matrixing and narrative all along the way.
It's batch... do you see? First a big lump of process, then a big lump of data, then a big lump of system - and no value until the very end. Yuck.
I am contemplating a different approach. Start with overall problem statement and industry trends, as before. But before the discussion of process, do a terse architecture section showing ALL the models and defining all the major objects, in no more than 30 pages. That part won't be an easy read and we'll encourage folks without a background in modeling to just skim it.
Then start a more narrative oriented section with the lifecycle/process model, and for each of the major lifecycles, discuss overlaying processes, supporting functions, data structures, and supporting systems, with a heavy focus on patterns and practices. Any one discussion will give the reader all the tools they need to make some progress.
Terrible amount of refactoring and utterly crazy this late in the game. But I am running into a wall with my previous approach.
thoughts?
-Charlie
Recent Comments