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.
Wednesday, 30 April 2014
4. How formal do we really have to be?
I'd make a small wager that, by now, you're feeling somewhat punch-drunk... this is not the easiest of things to grasp and get your head around... particularly now we've 12 boxlettes!
So what's the essence of all this? How "accurate" and "precise" do you really need to be? Well, if this was some form of safety critical system such as a motorway's roadside information system or maybe a bank's business rests on "getting it right", then probably the model and its views have to be as formal as possible: you don't design and then build a new model of car or a motorway's bridge without proper blueprints.
But there's also plenty of room for informality - sketching ideas for discussion and clarification, often for use with those who are not professional system designers. These sketches cannot be accurate representations of the model in the box (the lay person would not understand them), but they can convey the essence of its design, enabling design options to be discussed in terms of what the system will then be able to do (or not do), without alienating those you're trying to work with.
But I ask one thing of you.
Please, please, please try to hold onto the viewpoint from which you are creating this sketch. So often, the moment we abandon "proper modelling" we also abandon the notion of viewpoints. Please don't - for example:
So what's the essence of all this? How "accurate" and "precise" do you really need to be? Well, if this was some form of safety critical system such as a motorway's roadside information system or maybe a bank's business rests on "getting it right", then probably the model and its views have to be as formal as possible: you don't design and then build a new model of car or a motorway's bridge without proper blueprints.
But there's also plenty of room for informality - sketching ideas for discussion and clarification, often for use with those who are not professional system designers. These sketches cannot be accurate representations of the model in the box (the lay person would not understand them), but they can convey the essence of its design, enabling design options to be discussed in terms of what the system will then be able to do (or not do), without alienating those you're trying to work with.
But I ask one thing of you.
Please, please, please try to hold onto the viewpoint from which you are creating this sketch. So often, the moment we abandon "proper modelling" we also abandon the notion of viewpoints. Please don't - for example:
- If you are discussing the structure of an application, sketch from the "logical/application/functional" viewpoint - don't confuse matters with additional issues of data distribution (technical/operational) or software product packaging (physical/application).
- If you are discussing the performance or security implications of storing business information locally on a laptop, compared to centrally and requiring connectivity to get at it, make sure your sketch from the "logical/technical/operational" viewpoint - does it even need to refer to the application at all?
3. How do we decide from which viewpoint(s) to manipulate the model, and when?
It's all well and good having a rich, insightful set of ways of thinking about a system's design - whether from the PoV of the requirements it will support or the technical underpinnings needed to make it run.
But when I start, by box is empty. There is no "system model". Where to start?
It depends! There are many starting points, depending on the nature of the challenge we face:
In other words, the box allows you to step away from the tyranny(!) of process, in which we've historically been made to follow a rigid sequence of activities "to design the system". Instead, like a real engineer, we can use our own common sense and understanding of the goal (a viable system design) to create a holistic end-to-end model, through whatever viewpoint we need, in order to form the basis of future detailed design, development, deployment, delivery and decommissioning.
FOOTNOTE: It is beyond this blog to discuss the well understood mechanisms and transformations available to the solution designer as they traverse the box's views from boxlette to boxlette. Suffice it to say that these techniques are, in principle, no different from those deployed by other engineering disciplines, whether it be the technique for drawing the 3rd view in BS308, or for optimising the path lengths between devices on a circuit board.
But when I start, by box is empty. There is no "system model". Where to start?
It depends! There are many starting points, depending on the nature of the challenge we face:
- Maybe we need to enhance an existing system, in which case we may need to "reverse engineer" our model, based on what we observe in the real world... in which case the favourite entry point might be "physical/technical/operational": this is the most concrete viewpoint, with hardly any "design information" left out, fully documenting the system's structure in terms of real hardware and software. This allows us document "everything" in a structured way; before we begin to analyse what we've discovered and documented, thereby creating the more abstract (but usually more interesting) views that help us understand how the system works, and eventually what it actually does in business terms.
- Or maybe it's a brand new set of business requirements, currently vaguely understood and constantly changing, that's going to be deployed as a new application into an existing IT environment. In which case we may need to start in TWO places - not only the "logical/requirements/functional" views to tease out exactly what's what, but also the reverse engineering views that will help us understand "the art of the possible".
In other words, the box allows you to step away from the tyranny(!) of process, in which we've historically been made to follow a rigid sequence of activities "to design the system". Instead, like a real engineer, we can use our own common sense and understanding of the goal (a viable system design) to create a holistic end-to-end model, through whatever viewpoint we need, in order to form the basis of future detailed design, development, deployment, delivery and decommissioning.
FOOTNOTE: It is beyond this blog to discuss the well understood mechanisms and transformations available to the solution designer as they traverse the box's views from boxlette to boxlette. Suffice it to say that these techniques are, in principle, no different from those deployed by other engineering disciplines, whether it be the technique for drawing the 3rd view in BS308, or for optimising the path lengths between devices on a circuit board.
2: How do we know what we're aiming at?
"Requirements"!
So far I have not mentioned "requirements" once in this blog; how on earth have I got this far without doing so?!??
In all honesty, I have no idea. And it was probably a mistake. Without "requirements" it's really easy to "do things right" - i.e. ensure the design confirms to some architecture, whether it be that of the enterprise or the vendor, but to "do the right things"? Humph, maybe that's it - my focus on design v architecture diverted me too much...
So... if I have a "system design model" that needs to do the right things, do I have a "requirements model" defining what those things are? Some would say "yes" - based very much on the notion that a model supports a particular viewpoint (see last entry!).
I say no - we need the model necessary to integrate all the viewpoints we need as system designers, and since requirements are just as important as the system design that satisfies them, the model must enable views from the requirements' viewpoint to be envisioned and drawn alongside the eight design viewpoints.
This then means my box must still contain one joined-up model, but now not only "looked at" from my eight design viewpoints, but also from a (or some!) requirements viewpoint(s).
So where do I put these requirements' viewpoints' "holes" in my box?
On top.
The box's vertical dimension is "application above technical" - so it seems equally natural for "requirements to be above application" - i.e. in the same way as "technical" stuff "satisfies the requirements placed on it from above by "application stuff", so the application satisfies the requirements placed on it from above. It's just that until now there's not been that explicit level above application - now there is, the "requirements level" - and all still inside the box. (This of course means the "top four" application level design viewpoints need to "look slightly downwards" from their cut outs into the application level.) And rather than a 2 * 2 * 2 arrangement of boxlettes, it's now 3 * 2 * 2...
What do I see when I look at my model from the requirements' viewpoint? Indeed, is there just one requirements' viewpoint - it would seem rather stingy given there are eight design viewpoints! A quick check of the top of the now taller box tells us there are four requirements "boxlettes", each focused on one of the other two dimensions of functional and operational issues from a logical and physical perspective.
Some would say "yes, there's just one requirements viewpoint (from the middle of the top) with four sets of views", others would say "the four sets of requirements views are sufficiently far apart to be modelled as separate requirements viewpoints". For once, I don't actually have a point of view on this (there's that awful pun again), what I do care about are the views...
...because this has been our Achilles Heel for decades. Whenever a solution designer, or business analyst, or expert user considers "what should this system do?", they automajically focus on the functional stuff - what the application has to do, and the data it has to do things to. When asked something related to the operational aspect, such as "how well does it have to do all this?" (*), the answer comes back "I have no idea, but I'll know when I haven't got what I need!"
And all of this pre-supposes the requirements are being described in business terms (i.e. logically), and not physically by someone leaping to the conclusion that "the answer is Package X!"
In other words, only by recognizing the power of the box's dimensions can we hope to create a system that works functionally and operationally, assuming of course we can understand the relationships between the boxlettes...
(*) "how well" - ensuring the system achieves the right levels of things like performance, availability and security
So far I have not mentioned "requirements" once in this blog; how on earth have I got this far without doing so?!??
In all honesty, I have no idea. And it was probably a mistake. Without "requirements" it's really easy to "do things right" - i.e. ensure the design confirms to some architecture, whether it be that of the enterprise or the vendor, but to "do the right things"? Humph, maybe that's it - my focus on design v architecture diverted me too much...
So... if I have a "system design model" that needs to do the right things, do I have a "requirements model" defining what those things are? Some would say "yes" - based very much on the notion that a model supports a particular viewpoint (see last entry!).
I say no - we need the model necessary to integrate all the viewpoints we need as system designers, and since requirements are just as important as the system design that satisfies them, the model must enable views from the requirements' viewpoint to be envisioned and drawn alongside the eight design viewpoints.
This then means my box must still contain one joined-up model, but now not only "looked at" from my eight design viewpoints, but also from a (or some!) requirements viewpoint(s).
So where do I put these requirements' viewpoints' "holes" in my box?
On top.
The box's vertical dimension is "application above technical" - so it seems equally natural for "requirements to be above application" - i.e. in the same way as "technical" stuff "satisfies the requirements placed on it from above by "application stuff", so the application satisfies the requirements placed on it from above. It's just that until now there's not been that explicit level above application - now there is, the "requirements level" - and all still inside the box. (This of course means the "top four" application level design viewpoints need to "look slightly downwards" from their cut outs into the application level.) And rather than a 2 * 2 * 2 arrangement of boxlettes, it's now 3 * 2 * 2...
What do I see when I look at my model from the requirements' viewpoint? Indeed, is there just one requirements' viewpoint - it would seem rather stingy given there are eight design viewpoints! A quick check of the top of the now taller box tells us there are four requirements "boxlettes", each focused on one of the other two dimensions of functional and operational issues from a logical and physical perspective.
Some would say "yes, there's just one requirements viewpoint (from the middle of the top) with four sets of views", others would say "the four sets of requirements views are sufficiently far apart to be modelled as separate requirements viewpoints". For once, I don't actually have a point of view on this (there's that awful pun again), what I do care about are the views...
...because this has been our Achilles Heel for decades. Whenever a solution designer, or business analyst, or expert user considers "what should this system do?", they automajically focus on the functional stuff - what the application has to do, and the data it has to do things to. When asked something related to the operational aspect, such as "how well does it have to do all this?" (*), the answer comes back "I have no idea, but I'll know when I haven't got what I need!"
And all of this pre-supposes the requirements are being described in business terms (i.e. logically), and not physically by someone leaping to the conclusion that "the answer is Package X!"
In other words, only by recognizing the power of the box's dimensions can we hope to create a system that works functionally and operationally, assuming of course we can understand the relationships between the boxlettes...
(*) "how well" - ensuring the system achieves the right levels of things like performance, availability and security
Sunday, 20 April 2014
1. How do we manipulate the model?
Through the box's holes! That's why in previous posts I never discussed covering them over with a transparent film(*). So imagine having a set of fine tools, like the ones used by a watch maker or jeweller, to manipulate... what? Well, of course it depends on whether you have a "proper" CAD modelling tool or not...
(*) A neat trick when drawing a view of of something (used by many famous artists I am told) is to put a transparent sheet between you and it, then tracing what you see onto the sheet. Camera Obscura work the same way, but with lenses and mirrors to project the image onto a table.
Using a proper CAD tool
(Notice I invariably prefix "tool" with "CAD" - in order to be clear I'm talking about a computer based system modelling program, and not a method centric tool such as a technique or artefact description.)
If like me you have a CAD tool capable of constructing the model "inside the box" and maintaining views of it from all angles, then you can manipulate the model directly - by directly defining and changing its parts as you desire; whether changing their properties or relationships. The tool then maintains all the views you want of the model, from all viewpoints simultaneously, enabling you to see in (pseudo-)real time the effects of your changes - from any viewpoint, not just the one through which you've changed the model.
Or, and maybe more intuitive for many, you can manipulate one of the CAD tool's views (notated in the standard way defined for the viewpoint), relying on the tool to keep the underlying model's parts in sync with the view's symbols that represent them (because on a view it's the parts' symbols your working with, not the parts themselves!); but not just on the view you are editing, all other views on which symbols representing the edited parts appear.
(But how can a CAD tool do this? How does it know "the modelling and drawing rules"? Because it's been programmed with the language and viewpoint notations we've previously been deeply discussing - it "knows" how we think... it's called a metamodel!)
Using Office Productivity Tools
Even though it's anno domini 2014 and CAD has been around since the last century, the vast majority of us still use word processors and presentation editors as our preferred (preferred???) means of documenting our system design models... sorry, views... (or are they even views? I'll come back to this later!)
Please do NOT think that this means we should abandon the thinking models I've been discussing page after page in which I put so much emphasis on distinguishing a model from a view of that model - but I do accept it makes using these ideas so much harder, because it's us and not a CAD tool that has to "look though" the view we are drawing or editing to imagine (i.e. model) the "three dimensional" system model that "must" lie behind the "2D" view. This can be tough.
But maybe not quite so hard if we recognise the difference between "nearby" and "far away" views.
Notably, "nearby". All the views we see through one viewpoint are intimately related; they are "near" each other. For example, some views may document - i.e. draw symbols representing the static structure between some (few types of) parts, while other views convey the dynamic behaviour between those self same parts.
This "nearby" case is so like my old friend BS308, defining how to draw and inter-relate the three orthogonal views of an engineering assembly: having drawn two views (maybe "plan" and "front elevation"), BS308 made it possible (in theory!) to auto-generate the third view ("side elevation") - which is exactly what CAD tools do! In much the same way, because of the underlying modelling rules (i.e. the metamodel), if I draw a dynamic view of my system model with symbols showing data flows or messages between the model's parts, I can "automatically" draw the corresponding structure view, showing symbols of the connective model elements needed to carry that data or those messages.
If I then make another dynamic view of some other behaviour of the same set of parts, I can "automatically" edit the overall structure view to accommodate any new or changed symbols representing the connectors this second set of flows require (unlike a proper CAD tool, most/all office tools can't do this of course, so I have to go back and manually make the edits myself... humph!)
And it's this intimacy between a viewpoint's views that naturally leads to the idea of a model lying behind the viewpoint's set of nearby views - and a quite a different model lying behind another, i.e. far away viewpoint.
Sadly, it's this "far away" isolation between viewpoint specific models that has lead inextricably to different roles being responsible for different (partial system) models, further exacerbating the challenge of ensuring what's in the box is a joined up system design, and not a disjoint set of semi-detached artefacts, grouping nearby views together. And there's a further challenge - because we fail to understand the difference between a symbol on a view representing part of the model, and the part itself these artefacts inevitably take on names such as "The(sic!) Operational Model", when in fact they are "Views of the System Design Model from the Operation Viewpoint".
Bottom line - if you have to work with semi-detached artefacts documenting views of an underlying system design mode, please please please
- Recognise the way these artefacts represent views from far away viewpoints,
and how the inter-relationship between these viewpoints must influence
the broader range of views - whether it be as simple as changing the name
of something that appears in multiple viewpoints, or understanding how altering the dynamic behaviour in one
viewpoint's view changes a static view in another, make sure your change is reflected in all your artefacts
- Lobby for a proper CAD tool!
Friday, 18 April 2014
Enough "looking", let's do some modelling
With so much to talk about "professional communication of system's design" (such as the need for a common language,
using standard and numerous viewpoints to understand the system's design model and so on), I'd almost forgotten about the stuff we're trying to
communicate - the model we're making.
(And, to avoid doubt, I say "the model" in the singular, one model spanning all my eight viewpoints; although I admit now I could fall into my own trap of saying "a model", which I will mean to be the stuff needed in a model to observe it from "a" viewpoint.)
I think there are five critical ideas we need to explore if we are to feel confident in our modelling...
(And, to avoid doubt, I say "the model" in the singular, one model spanning all my eight viewpoints; although I admit now I could fall into my own trap of saying "a model", which I will mean to be the stuff needed in a model to observe it from "a" viewpoint.)
I think there are five critical ideas we need to explore if we are to feel confident in our modelling...
- How do we manipulate the model?
- How do we know what we're aiming at?
- How do we decide from which viewpoint(s) to manipulate the model, and when?
- How formal do we really have to be?
- What happens once we've "finished"?
Thursday, 10 April 2014
Reflection: IEEE 1471 and the answer to everything
At school, in "Engineering Drawing" (an O level at that time), I was introduced to "BS308", an ancient (even then) British Standard defining the notation for engineering drawings and blueprints. Then, I was simply concerned with following the standard - it was a lot later, when I became involved with IBM's methodologists that it dawned on me... BS308 is all about unambiguous communication of complex (graphical) information - "you" interpret what "I" meant in my blueprint of a bridge with confidence.
Then over 30 years later "another" BS308 comes along - this time called IEEE 1471 - a standard for conceiving of and communicating (IT systems) architectures(*) via models, views and viewpoints
I suspect my thoughts in these recent posts don't quite match the precision and comprehensiveness of the standard; I feel I've a rather simplified view of the world. For example I think my point of view (all puns intended) on notation is awry; IEEE 1471 declared it is the view which defines the notation (view type?) and that there are view instances - renderings of the model from a viewpoint drawn/documented according to the view. And I strongly believe in the notion of one model serving multiple viewpoints, rather than a viewpoint being an observation onto multiple models.
Nevertheless, I remain a staunch advocate of 1471... or I should say ISO 42010, recognising a more international adoption of this powerful standard. Oh, and yes, the "42" in 42010 is not random - it is a homage by the standard's leading advocate to "the answer to everything" (wiki the standard's "convener", Johan H Bendz)
(*) another deviation between us - I'd argue the label for the concept is not architecture, but "design"!
Then over 30 years later "another" BS308 comes along - this time called IEEE 1471 - a standard for conceiving of and communicating (IT systems) architectures(*) via models, views and viewpoints
I suspect my thoughts in these recent posts don't quite match the precision and comprehensiveness of the standard; I feel I've a rather simplified view of the world. For example I think my point of view (all puns intended) on notation is awry; IEEE 1471 declared it is the view which defines the notation (view type?) and that there are view instances - renderings of the model from a viewpoint drawn/documented according to the view. And I strongly believe in the notion of one model serving multiple viewpoints, rather than a viewpoint being an observation onto multiple models.
Nevertheless, I remain a staunch advocate of 1471... or I should say ISO 42010, recognising a more international adoption of this powerful standard. Oh, and yes, the "42" in 42010 is not random - it is a homage by the standard's leading advocate to "the answer to everything" (wiki the standard's "convener", Johan H Bendz)
(*) another deviation between us - I'd argue the label for the concept is not architecture, but "design"!
...at what? The sytem's model of course! What's a model (again!)?
We've an empty box with holes in it. These holes represent eight different viewpoints, each uniquely able to help the solution designer focus on a specific aspect of their work - so long as the viewpoint is looking at.. what?
What do we put in the box?
The trite answer is "the full design model of the system we're interested in designing, understanding or communicating". But what does that mean? Oddly, that's a harder question than it might first seem, and one that I took years to get my head around. Because it needs me to introduce another concept - that of "a view", which for almost all my career I failed to understand.
If a viewpoint is the point from which you observe something, then a view is what you see. And what you see you may choose to "document" as a photograph (such as a postcard of a holiday resort, taken from the clifftop), or maybe as a list of all the things in sight (a bill-of-materials of all the things in an engine), or as a series of statements about how "good" what you see is ("this room needs decorating, but the electrical wiring is sound").
(As a point in passing, in our world - as compared to the real world of seaside postcards(!) we take this idea one stage further, by formally specifying the notation we will use to document the view we see from the viewpoint - for example defining the shapes of the symbols we'll use to represent the parts we're looking at, or defining the column headings of the table recording the part's details.)
But... and here's the rub... we have an instinctive tendency to think of the view as being the real thing, and not a view of the real thing. Why? I think it's because, unlike the seaside postcard and the real village it's a picture of, we've never had "the real thing" in front of us. Why? Because our real thing is actually a model of the real thing! (The real thing - the computer system - may even not yet exist!) As a consequence we've only ever been able to create views of it, in things some choose to call "artifacts", others "work products", and maybe even "deliverables". And we reason about these views as being the model... models... of the yet-to-be-created real thing.
I believe we need to take a leaf out of the real engineers' notebook - the leaf marked "Computer Aided Design". Back in 1980 I was creating models of the insides of aero-engines in FORTRAN on my PDP/11 - yes, models: large complex data files documenting the structure of 100's of interconnected parts, read into memory as a "gigantic semantic net" and subjected to "external forces" tht my code analysed using FDM - "finite difference modelling". But at no time could I "see" my model - it was inside the computer as a load of 0's and 1's. Rather, I had to create reports, long tables documenting each part's temperature or some other parameter that I then used to colour-in a picture on graph paper. I knew that the graph paper was only a representation of the FORTRAN model, it was not the model - the only way of changing the colours on the paper was to change the model.
So, having forgotten all about aero-engines and CAD, the stuff in my box had been the artifacts documenting the views I'd choosen to see from some or all of my eight viewpoints, each quite independent of the other - if I chose to change something in one view (an observation from a specific viewpoint), nothing would happen in any of the other views - you would not know there'd been a change if you looked into the box from another viewpoint.
But now my box is full of the CAD model, whose views are all rendered according to formal notations from the box's eight viewpoints.
Now, and this is the magic bit, reach into the cardboard box through one of the viewpoints (that's why they're actually holes!) and change the model. This time, because it's the model you're changing, the change is seen from the other seven viewpoints, and immediately rendered in those viewpoints' views! So if the software engineer changes their mind - a simple change of of a part's name, or an alteration to the model's structure; that change is seen in the views observed by the systems engineer from their viewpoints. Indeed, it's magic!
What do we put in the box?
The trite answer is "the full design model of the system we're interested in designing, understanding or communicating". But what does that mean? Oddly, that's a harder question than it might first seem, and one that I took years to get my head around. Because it needs me to introduce another concept - that of "a view", which for almost all my career I failed to understand.
If a viewpoint is the point from which you observe something, then a view is what you see. And what you see you may choose to "document" as a photograph (such as a postcard of a holiday resort, taken from the clifftop), or maybe as a list of all the things in sight (a bill-of-materials of all the things in an engine), or as a series of statements about how "good" what you see is ("this room needs decorating, but the electrical wiring is sound").
(As a point in passing, in our world - as compared to the real world of seaside postcards(!) we take this idea one stage further, by formally specifying the notation we will use to document the view we see from the viewpoint - for example defining the shapes of the symbols we'll use to represent the parts we're looking at, or defining the column headings of the table recording the part's details.)
But... and here's the rub... we have an instinctive tendency to think of the view as being the real thing, and not a view of the real thing. Why? I think it's because, unlike the seaside postcard and the real village it's a picture of, we've never had "the real thing" in front of us. Why? Because our real thing is actually a model of the real thing! (The real thing - the computer system - may even not yet exist!) As a consequence we've only ever been able to create views of it, in things some choose to call "artifacts", others "work products", and maybe even "deliverables". And we reason about these views as being the model... models... of the yet-to-be-created real thing.
I believe we need to take a leaf out of the real engineers' notebook - the leaf marked "Computer Aided Design". Back in 1980 I was creating models of the insides of aero-engines in FORTRAN on my PDP/11 - yes, models: large complex data files documenting the structure of 100's of interconnected parts, read into memory as a "gigantic semantic net" and subjected to "external forces" tht my code analysed using FDM - "finite difference modelling". But at no time could I "see" my model - it was inside the computer as a load of 0's and 1's. Rather, I had to create reports, long tables documenting each part's temperature or some other parameter that I then used to colour-in a picture on graph paper. I knew that the graph paper was only a representation of the FORTRAN model, it was not the model - the only way of changing the colours on the paper was to change the model.
So, having forgotten all about aero-engines and CAD, the stuff in my box had been the artifacts documenting the views I'd choosen to see from some or all of my eight viewpoints, each quite independent of the other - if I chose to change something in one view (an observation from a specific viewpoint), nothing would happen in any of the other views - you would not know there'd been a change if you looked into the box from another viewpoint.
But now my box is full of the CAD model, whose views are all rendered according to formal notations from the box's eight viewpoints.
Now, and this is the magic bit, reach into the cardboard box through one of the viewpoints (that's why they're actually holes!) and change the model. This time, because it's the model you're changing, the change is seen from the other seven viewpoints, and immediately rendered in those viewpoints' views! So if the software engineer changes their mind - a simple change of of a part's name, or an alteration to the model's structure; that change is seen in the views observed by the systems engineer from their viewpoints. Indeed, it's magic!
Looking through the holes...
Each of the eight "portholes" into the box offer a viewpoint that is tailor made to a particular responsibility in the solution's system design. (I'll talk bout viewpoints and other stuff in a short while)
For example, the front/top/left corner... sorry... hole is looking into the box from the functional/application/logical viewpoint, the most abstract view point we use - and an amazingly powerful way for a software engineer to focus on what matters to them, removing all extraneous information from their mind as they work out the shape and structure of "their application", without worrying (too much!) about it's deployment, implementation technologies and technical services needed to keep it going.
Compare that to the back/bottom/right hole - the operational/technical/physical viewpoint, in which all those "previously ignored" issues have to be grappled with - by the systems engineer, things such as "how will we make sure the data's where it needs to be?" and "where will we run the application - here or there?"
But hold on - surely the software engineer also worries about these things?
YES!
But from different perspectives to that of the systems engineer - they look into the box from the left hand side's four holes - so if they choose to think about how their application will be supported by "infrastructure", they'll use the (bottom/left/front) technical/functional/logical viewpoint as a way of understanding the technical implications and functional requirements placed on the infrastructure by their application and data design - such as specifying the behaviour of the underlying infrastructure needed to supply, backup and maintain their data, or to maintain their application's transaction integrity.
For example, the front/top/left corner... sorry... hole is looking into the box from the functional/application/logical viewpoint, the most abstract view point we use - and an amazingly powerful way for a software engineer to focus on what matters to them, removing all extraneous information from their mind as they work out the shape and structure of "their application", without worrying (too much!) about it's deployment, implementation technologies and technical services needed to keep it going.
Compare that to the back/bottom/right hole - the operational/technical/physical viewpoint, in which all those "previously ignored" issues have to be grappled with - by the systems engineer, things such as "how will we make sure the data's where it needs to be?" and "where will we run the application - here or there?"
But hold on - surely the software engineer also worries about these things?
YES!
But from different perspectives to that of the systems engineer - they look into the box from the left hand side's four holes - so if they choose to think about how their application will be supported by "infrastructure", they'll use the (bottom/left/front) technical/functional/logical viewpoint as a way of understanding the technical implications and functional requirements placed on the infrastructure by their application and data design - such as specifying the behaviour of the underlying infrastructure needed to supply, backup and maintain their data, or to maintain their application's transaction integrity.
Viewpoint overload? No! Think "out of the box"!
Feeling overwhelmed? Too many options? Physical, operational,
infrastructure.... "You've claimed they're not synonyms, but my word I
can easily use them as such!!"
I agree. The distinctions I've been drawing between all these things can be subtle - but these subtleties are critical to ensuring a well designed solution. These last few posts have exposed them to be part of three "orthogonal pairs of viewpoints" that I claim enable solution designers of all persuasions to think about their IT system in a properly shared and mutually understandable way. I hope to justify that claim soon, but also recognise thst they can be hard to get your head around. So first I want to offer you a visual thinking model that should cement the nature of their inter-relationships.
I want you to think "out of the box". Literally from outside of a box, looking in...
So please go find yourself an empty square cardboard box (any size will do, but maybe small enough to put unobtrusively on your desk yet big enough to write on its sides). Also search out a pen, a pair of scissors or maybe a sharp craftsman's knife, and some sticky tape.
For now seal the box up, with nothing inside. It's empty....
Randomly choose "the front", draw a vertical line down the middle, and write "functional" on the left, and "operational" on the right.
Turn to the top, and continue the line front to back, but lightly. Draw another line across the middle, left to right, and write "logical" in front (straddle the front-back line) and "physical" behind (ditto).
Choose a side, and continue the top line down to the bottom, but lightly. Draw another line in the middle, back to front, and write "application" above (straddle the vertical line) and "infrastructure" below (ditto).
Turn back to the front, and continue the side's horizontal line across, lightly, probably through the words you wrote earlier.
If you're a completer-finisher like me you'll have an overwhelming desire to complete all three lines around the box... Go on, do it... You've now got eight "cubelettes" and six words. These eight cubelettes represent eight powerfully different ways of using the three pairs of viewpoints...
... so, using the scissors or knife, cut off the eight corners! Nice, neat triangular holes into the box - what can you see inside? Nothing!!! The box is empty... in fact you can see right through, through the opposite corner's hole, a viewpoint that is as different in every respect from the one you're looking through as could be...
I agree. The distinctions I've been drawing between all these things can be subtle - but these subtleties are critical to ensuring a well designed solution. These last few posts have exposed them to be part of three "orthogonal pairs of viewpoints" that I claim enable solution designers of all persuasions to think about their IT system in a properly shared and mutually understandable way. I hope to justify that claim soon, but also recognise thst they can be hard to get your head around. So first I want to offer you a visual thinking model that should cement the nature of their inter-relationships.
I want you to think "out of the box". Literally from outside of a box, looking in...
So please go find yourself an empty square cardboard box (any size will do, but maybe small enough to put unobtrusively on your desk yet big enough to write on its sides). Also search out a pen, a pair of scissors or maybe a sharp craftsman's knife, and some sticky tape.
For now seal the box up, with nothing inside. It's empty....
Randomly choose "the front", draw a vertical line down the middle, and write "functional" on the left, and "operational" on the right.
Turn to the top, and continue the line front to back, but lightly. Draw another line across the middle, left to right, and write "logical" in front (straddle the front-back line) and "physical" behind (ditto).
Choose a side, and continue the top line down to the bottom, but lightly. Draw another line in the middle, back to front, and write "application" above (straddle the vertical line) and "infrastructure" below (ditto).
Turn back to the front, and continue the side's horizontal line across, lightly, probably through the words you wrote earlier.
If you're a completer-finisher like me you'll have an overwhelming desire to complete all three lines around the box... Go on, do it... You've now got eight "cubelettes" and six words. These eight cubelettes represent eight powerfully different ways of using the three pairs of viewpoints...
... so, using the scissors or knife, cut off the eight corners! Nice, neat triangular holes into the box - what can you see inside? Nothing!!! The box is empty... in fact you can see right through, through the opposite corner's hole, a viewpoint that is as different in every respect from the one you're looking through as could be...
Subscribe to:
Posts (Atom)