I am often asked what is the difference between a logical design and a physical design. And sometimes, whether it is necessary to separate Business Requirements from Technicasl requirements. Some feel that an attempt to separate these aspects is unnecessary. While I will not let myself get bogged down in obsessive hair splitting of a purely academic or linguistic kind, I believe the ability to make the distinction is crucial to the successful design and implementation of new business requirements. And how many requirements are not “new” and unique, even when it seems to be a modification of existing software.
Take a look at the two pictures of two different trams I was in today, in Hong Kong Both have single seats on the left and double seats on the right. Fit a business requirement for there to be maximum seats without sacrificing reasonable comfort. Three seats per row is the logical design. That it is one on the left, a pathway and two seats on the right, is somewhere between a logical and a physical constraint. (I know, textbooks don’t admit that it may not be a clean cut separation between logical and physical, but hey, we live in the real world, and I am not going to kill my project by spending days just arguing over the theory. The actual material used to make the seats is of course very much purely physical design. Look at the handle bars for the standing passengers. One version has only bars on the left hand side, while the other has them on both sides. That is a physical design choice, for a business requirement that standing passengers should be able to steady themselves. A different design choice could very well have been straps instead of bars, or verticle posts. The reason why we should have some idea between logical and physical choices is to give ourselves a lot more room for creative problem solving.
The humble egg. Two things come to my mind.
One is why we seem to assume it’s a hens egg or a chicken egg when we hear the word “egg”. Without any other context, the chicken in the assumed mother of the “egg”. This contextual meaning is food ( pun intended ) for another post.
Second, is, the arguments we still have on whether the egg is deserving of the same kind of consideration as the hatched fully formed creature, be it chicken or human. It is a very contentious argument and can get very convoluted since the discussion is frequently emotional and both sides tends to dredge up “scientific proofs” as well as moral, ethical and religious literature.
I shall leave you with the questions, and not pontificate on this. I am using this to illustrate the in the realm of work, in business analysis or in project management, you are likely going to meet similar types of issues regarding the definition of things, and the very difficult to define or explain situations, existing or required. An example is when someone can happily describe what he does at work, but finds it difficult to connect them all up into a nice picture.
This is a reason why I am careful not to give new analysts or project managers the impression that “it’s all in the book”.
The idea of a reason, a cause, is dependent on analyzing something over a time.
Take a look at the video clip.
Can you see the ant? (Continued at bottom of video screen…
Question : Why did the ant jump off the mug?
Answer : the mug was hot?
Question : Why did the ant get on top of the mug in the first place?
The question answer sequence can go on almost indefinitely. The further back we trace things, the more possible reasons there will be in a particular link.
The point I am making here is that we need a clear focus on what our objective is, in asking questions. Is it to understand the behavior of ants? Is it to know what actually happened that led to an event? Or maybe the purpose is to design mugs.
Words are merely words. Different people attach different meanings to the same word. At the same time, within the contex of a single conversation, we can use the different words to distinguish between different ideas). This is even necessary, for how will we compare ideas if not to use a different word for each.
Hence, it is important to be careful of the use of words. When you are listening to someone else, check your own thought process, that you are not getting the wrong message by attaching a different meaning to a word, than the speaker.
The emotional attachment, is of course a related but different matter.
This is a relevant discussion when you are performing or learning any task that is centered around defining or analyzing complex matters. Such as in EA (enterprise architecture) or in BA (business analysis).
Simon Seow. First posts in simonseow.com on Monday 29 June 2015.
There is a lot of confusion about the desirable attributes of things and of ideas.
With things, computers, gadgets or software, there is a good reason for wanting to acquire the “latest” or at least a recent version. Manufacturers often drop support for versions deemed too old to support, and you want the benefits of latest features, or simply to be part of the in-crowd. Even with methodologies, with the procedures and steps to accomplish a task, we can have different approaches to tackle the job.
However, when we are talking about ideas and our knowledge of the natural world, then it makes no sense to refer to versions. How many versions of truth are there?
I am prompted to write this because a self-proclaimed EA expert, has launched what he calls “version 2 of Enterprise Architecture (EA)”. This is based on the completely erroneous claim that version 1 was only about technology while the “new” version 2 is about business and technology. At worst, the claim is an absolute lie, and at best a gross misunderstanding of EA (understandable since his title was software architect in a previous role). It is like saying that there is now a second version of the periodic table – the list of all the elements in the world, the stable foundation of all of the material sciences.
The very meaning of EA is a descriptive representation of the entire enterprise viewed as a holistic system, with defined and interconnected parts. This will necessarily include the business parts as well as the technology parts of the organization or enterprise. So, it is like calling a set of four wheels a version 1 car, and the complete car the version 2 car.
A quick look at the book “Finding Out More” by Simon Seow (published in 2000) and the Zachman Framework (ref www.zachman.com) will lead you to the same conclusion.
TOGAF, by the Open Group is iterating through it’s 9th version, and it’s still work-in-progress. So who is right?
Zachman is right, and the Open Group is right. Architecture is architecture. And construction work is construction work. The Zachman Framework is a mechanism for arranging the complete set of elements used to build, maintain and modify enterprises. TOGAF is a methodology that is used to do the building. A methodology must necessarily have versions, because management preferences and technology will change over time, leading to changes in the process of building /making things including enterprises. But the architecture framework, as a reference point, should never change. (except for fine tuning of the words used in terminology or the symbol/notation used). Hence the Zachman framework rows and columns have been consistent over the years.
Engineering work changes. The science behind the engineering work should not change. Unless of course the science used was wrong in the first place, and this likely explains why so many enterprises are drowning in their enterprise architecture efforts.
Simon Seow 17 June 2015