We're "system designers"... and unashamedly I'm putting the emphasis on "system" - we concern ourselves with the whole thing, from the full spectrum of functional and operational requirements through to... what?
While it may be clear we need to worry about "all the things upstream" of us - be they business requirements, architectural guidance and constraints, limitations imposed by the operational environment or project related issues (budget, time, people), where do we stop? What is "downstream" of us?
As hinted in the last entry, there is a neat but trite answer of "the five Ds" - detailed design, development, deployment, delivery and decommissioning; with direct contact for us of detailed design (but we ignore the other four at our peril! Have you ever created a system design with a view to decommissioning? Thought so...)
So what's the difference between "system design" and "detailed design"? the clue is in our language...
Our "system design engineering language" is composed of what we consider to be atomic things - components, nodes, actors, use cases, locations and so on. Therefore, the views of our system design model are composed of constructions and interactions between these atomic ideas: a component interacts with an actor, a node is located in a location, a use case has initiating and supporting actors.
Vitally, what we do not do is look inside these atomic parts (actually we do have a tendency to do so to some degree - see footnote!). Whatever it's actual size (small such as "authentication" or large like "customer management"), a component is exactly that - a component.
But components do have insides - they have to if they are to "do" stuff (data manipulation), and "own" stuff (data). While we, as system designers, may decide that a component has a particular interface used to access some particular function offered by the component, we generally do not trouble ourselves about how the component does what it does - it's a black box to us: it's the design of the insides of our "bits" that we hand onto those responsible for detailed design.
This division is not just "custom and practice" (i.e. it's proven to work!), but predicated on a boundary where there is a change in emphasis and often knowledge - rather than our focus on overall "structure and behaviour" of the system; in order for it to be developed and deployed its individual parts (or sub-systems) need to be designed too... and very often with a much higher degree of knowledge about technology, or coding standards, or available resources than we system designers might possess.
I distinguish these two worlds as being our attention to "something of everything" - the whole system model and its views, down to a certain level of detail; and the detailed designer's work on "everything of something" - parts or sub-systems of the whole that need looking inside, to ensure their externally exposed capabilities are realised. In practical terms, this almost inevitably means there is a need for a suite of tools - one, capable of looking at everything in broad outline (the modelling tool I use to capture the insides of my box), and other specialised tools focused on one particular aspect of the detail, whether that be data modelling or deployment modelling. But this is no different from other engineering disciplines, in which a CAD tool is integrated with a Finite Element Modelling tool or a tool focused on Computer Aided Manufacturing (CAM).
Footnote: We can, and do of course "look inside" our atoms - but, typically, only as "lists of content" - just like a real atom, in which we know how many neutrons and protons there are, so we know the functions and data items inside a component. What we choose not to focus on is how these internal parts interact - that's detailed design.
No comments:
Post a Comment