Here's one for ya':
What, exactly, is a "model?" I'm not talking about this or this . I mean, when BAs are discussing "models" ("logical data models," "process models"), what exactly do they mean?
Is it graphical? How many times have you been referred to a "modeling tool" to create a representation of data?
Is it textual? I've never heard of anybody referring to MS Word as a modeling tool…
Here's an example of the impact of my private quandary:
When somebody is required to deliver a "model" of the data related to a project, do they have any basic idea what that should look like if it were placed in a lineup? Would they panic, not knowing what to deliver? Are they afraid, very afraid???
Surely there must be some consensus somewhere…
I know! I'll look!!
(Sometime later:)
I looked here; I looked there; I looked everywhere. Sigh. No clear, unambiguous consensus.
But I found a couple of clues. First of all is the use of the word "abstract" in so many of the definitions. I think that the use of the word "abstract" is useful. I've noticed something interesting about data: you can't really "see" it. You can see representations of it (like reports, a GUI displaying it, or even a table listing), but you can't really see it, unless of course you elect to try direct examination of the storage media via a scanning electron microscope, which I don't recommend for BA standard practice. It's way too distracting from the goal.
Which leads me to my second observation:
The use of the word "representation" in some of the definitions.
After thinking about it for a bit, it appeared to me that a great definition for the word "model," at least as used by BAs in the performance of their jobs, could be:
"Any visual representation of an abstract concept that is useful for communicating the realities of the project related to the representation."
This definition would prescribe, then, the use of either graphical, textual or both methods for this purpose. But, note also, the use of the word "communicate." This is at the core of the need. If the delivery method is not right for the audience, then the "model" fails the test of the definition.
No matter how cool the picture, if the target audience doesn't grasp the reality of the subject, then it's worthless.
No? Feel free to correct me.
6 Comments
This is so true….I've used both methods, and it completely depends on the audience. My preference is the ERD, but if your target audience is not technical, then the message is not delivered. Even the textual example above talks too much technology. Both representations are excellent means for communicating with your development teams. However, you can only build out both representations after several iterations with your "business sponsor," performing complete process walkthroughs. I document these via use cases, and capture the specific relationships in table with detailed descriptions. I then include this table in my specifications documents – it's easier, then, for the business sponsor to provide sign-off. Just my .02
FWIW: The bottom line is you are attempting to communicate some information. I find it is good to go back to basics sometimes to clarify what I am trying to do. If I may be so bold, I would like to discuss “information.”
Information has five basic properties:
1. semiotics (symbols used to represent the information)
2. syntax (rules for arranging the symbols)
3. semantics (meaning given to the arrangement of the symbols)
4. pragmatics (function; result; outcome of the arranged symbols)
5. apobetics (purpose; plan; or design of the arranged symbols)
Key to understanding the “arranged symbols” (letters, geometric symbols, Morse code, DNA, lines on a blueprint, flowchart symbols) is that the Sender AND the Receiver must understand all five of the above, at a minimum the first three. If someone sees the letters “T-A-G” – how will they interpret those symbols? You say that is easy, they mean…what do they mean? Are they on a garment? Is it a game? Or, if you are German, they are the word for “day.”
So however I build my models, I need to remember the symbols only represent some bits of information. And I need to remember they need to mean something to the person I am trying to communicate with.
I know, very basic, but thanks for indulging me.
Ah, imho, a model is a representation of a system (business, computer, vehicular, whatever) that is isomorphic to the original in all areas considered to be important – data, behaviour, dependencies, timeliness, interoperation, connectivity are examples.
I remember simple press-moulded plastic toy racing cars (e.g. made in china) when I was very young. To me they were a perfect model – just enough isomorphism to the real thing to let my imagination take over.
When I model for the client business (I’m a freelance consultant) I build dataflow models and where appropriate, logical datamodels. And of course, their meaning must be able to be perceived by the intended audience so they can abstract the reality by interpreting the portrayed isomorphism (i.e. model).
Sorry for the ramble but I don’t have my BA hat on today! By the way, have you thought that a case study is a model, too?
Oh and on the subject of case studies – see a pragmatic SSADM one on my site.
And isn’t it true that documents are a poor substitute for a conversation? I like to think that models are tools that support a conversation with the clients and suppliers.
Craig wrote:
“…models are tools that support a conversation…”
Yes!!!
Yes!!!!
And “Yes!!!!!!!!!!” again!!!!!!
So many BAs (and others) get caught up in the mechanics of the work, and lose sight of the core objective: to communicate. Conversations are part of that essential core.
All excellent points!! I thought I was the only one who had these questions / thoughts. OK not the only one, but I was finding it hard to find others.
I have recently been introduced to an SDLC only to discover it is nothing more than a series of templates. The templates are helpful as they can guide the project team through the process and each person knows what they need to deliver. Unfortunately, as mentioned above, this can lead to focusing on the “mechanics of the work” rather than the team understanding what it is trying to achieve.
Our purpose (BAs) is to somehow get all involved to see the same picture and bring to light the issues. The next task becomes to communicate this using any tool/method at our disposal.