At last, the 6th of my five "P"s!
Why is it 6 of 5? Because I forgot (or did I consciously ignore?!) it. And why did I do that? Because I thoroughly dislike "Process"!
Process I: on a "micro" scale
(by which I mean within programmes, focused on the use of Architecture within Design)
Why? After all, BPM is all the rage, and re-engineering business processes the mantra of the day! Exactly. That's my point! A&D cannot be procedural, there are far to many " if-then-elses", many of which cannot be predicted ahead of time - why else is THE worst question to ask an Architect "have you finished yet?"!
And "but I followed the process!" is a brilliant excuse!
However...
...I do agree adopting a proven "approach and structure" to A&D, in order to facilitate a broadly based (some would say "phase and activity" level) project plan is critical.
But what form of approach? "Waterfall"? "Iterative and Incremental"? "Agile"? "Do and fix"?... - such as recognizing the first phase needs to be "Outline Design" Phase that covers the overarching design of the whole system, followed by a number pseudo-independent "Macro Design" (MD) phases, each focused on a different part (probably parallel MDs) or release (maybe serial MDs) of the solution, for time-sequenced delivery to development and beyond.
Each of these phases do of course need to be sized, but not in a quantity surveyor style "add up the bits" sort of way - it needs the (mature) skills and knowledge of a senior project solution designer to do this; ahead of time (pre-sales budgeting and pricing), and during the project (to explain and negotiate the inevitable changes needed... OK, this is 99.9% of the time actually "overrun!"). And in order to maintain credibility whenever revision is needed - whether externally specified changed requirements, or internally generated design alterations or delays - it's a very good idea for the programme architect being the same person who proposed the solution design in the first place!
No comments:
Post a Comment