Let's discuss these first in terms of Solution Design ("when" and "where"), and then in a subsequent entry Architecture:
"When" Solution Design
Design (and Architecture), just like Mark 14:7, should always be with us; from before the first inkling of the need for an IT based solution to a business challenge, to change requests and alterations made to a system many years after its implementation.
But it is vital to recognise the degree of effort - by which I mean the time and money put into the detail, accuracy and completeness of a design will vary enormously from one end of that cyclical timeline to the other:
- In the beginning, probably well before formal funding is available, all that may be needed to verify the viability of something new are sketches and outline, natural language based descriptions of requirements and their corresponding solution(s).
As such, the people most likely to focus on a solution's design at this early stage are the enterprise's architects in the role of designers, instinctively using "their" EA.
- Obtaining funding will probably require a more complete design, albeit one that cannot be as detailed or as accurate as will eventually be needed for development - but it must be good enough not only to convince the "upstream" stakeholders of the design's viability and (probably) the manner of it's development /deployment whether via phases, or (sub-)projects, or some other means of chunking a large complex programme.
Who's most able to fulfill this role? IMHO, this depends strongly on the final W, "where": it may be the case that this stage is done "in house", by the enterprise's architects " completing their EA/ABB inspired sketches; but deciding to use an outside agency, maybe with a view to them taking on the subsequent program/project, means it's more likely to be designers, with a more complex relationshop to the enterprise's EA. Either way, this forms the basis of...
- Outline programmetheoject Solution Design is likely to be the heart of any programme's or project's first phase, and as such, it will probably need to keep the "completeness" theme going with the intention of identifying (or confirming) a number of highly cohesive, loosely coupled projects/sub-projects that can "safely proceed" under the design guidance provided by this complete /outline design, while being confident of their pseudo-independence from fellow projects/sub projects.
Almost always, the people for this stage are battle-hardened solution designers - intent on putting (rarely maintaining) their mark on the program. And my "rarely" indicates an anti- pattern: change the team between proposal and delivery! So much better to keep the forces of change to the direct solution requirements, and not meddle with the design based on a new broom's wxperiencw. But, as I have posted before, there's also a strong case for the direct involvement of EAers, and not only if they were the authors of the previous stage
- More detailed project/sub-project Design, focusing in on the (sub-)project's narrower scope, and as a consequence going to a lower level of detail, and a far greater confidence in the design's accuracy and suitability to the (now detailed!) requirements.
Undoubtedly, the person whose bailiwick this is, is the solution designer, ably supported by the architect's reference designs and "wonderfully detailed" ABBs and their preferred implementations!
As a side thought, not directly related to "people" but none-the-less vitaly important is how "deep/detailed/complete" must the design be for each of these contexts? I have no idea. Well, of course I do in any given situation - what I cannot do is give you firm/confident indicators - except:
- Early on, things are probably more easily described in "free format" sketches rather than formal views - hence an office automation tool is probably more attractive than a proper CAD tool. But history tells us this is a dreadful anti-pattern, because "once in PPT/Open Office, always in PPT/Open Office".
But it is also the case that "things" are far more readily defined than "relationships between things" - as proved by our ability to identify ABBs as candidate building blocks before any structure is formed,and to construct lists of preferred software. Critically, CAD tools are generally really good at maintaining "thing integrity" while allowing "free format" relationships between things, on sketches such as "Architecture Overview" and "Current IT" diagrams - in other words, use CAD tools from the Get Go!
- Towards the end, there is a limit beyond which we do not go: the insides of our model's elements. A node or component is - must be respected as - a black box - it'a atomic. We do not look inside, nor do any internal design work - that is the bailiwick of the detailed design professional. probably far more versed in technology limitations and exploitations that fits them better to this work - in other words, use CAD tools that focus on "something of everything" (limited depth but full scope/breadth), not specialist tools that do "everything of something" (deep depth on a narrow scope, be that "requirements", or "s/w design")!
OK - those of you who've followed me from (near) the beginning will know that's not true - we DO look inside nodes and components (and other model elements), because we list the key things in the insides - methods and data items "inside"(*) a component, or DUs "inside" a node. What we do not do is describe how a method is accessed via an interface to manipulate data items, responding via a (different?) interface back to the requester.
(*) it's a little inaccurate to describe DUs as being "inside" a node or Methods "inside" a component - rather, a component or node "is" the aggregation of its parts, rather than being something greater than the sum if its parts.
"Where" Solution Design
The subject of my next post!
No comments:
Post a Comment