Lesson number one in any effort that involves developing or configuring software is determining not just what in the heck you are trying to accomplish but why. What determines the mechanics, why determines the design. This lesson becomes all the more critical at the scale of Enterprise IT, where this task can be rather difficult to get right. Such projects are often challenged with daunting complexity, both from a technical and political perspective. As a consequence, it’s very easy to get lost in the mechanics of what, while the underlying why is lost. Examples are common: delivered systems that just don’t work, needlessly complex processes, new systems which manage to carry forth baggage from old systems, and usability frustrations that make normal humans want to put their fists right through computer hardware. For each of these examples, all too often there’s an architect who will emphatically explain “We have a requirement for that.”
The requirements “gathering” process is much maligned – chiefly because requirements can’t be gathered like shells from the beach. And it doesn’t really help that most humans have trouble identifying a good requirement from a Pan Galactic Gargle Blaster. It’s not because they are exceptionally dim-witted, but rather that the requirements process requires extracting information from other humans. And each of these human information sources typically share a rather myopic view of what they are asked about grounded in the context of the current system and its technology. To find the absolute truth requires talking to quite a few humans and piecing together the right details… carefully. It is not easy. You can’t just plant all your ultimate business questions in front of Deep Thought and expect to receive orderly, numerical answers. And you certainly won’t have seven-and-a-half million years to think it over.
Enter the various methodologies, which attempt to standardize the process into something that can be consistently executed by people who aren’t comfortable regularly realigning warp cores. Since many of the methodologies arose from either systems engineering or software development, both the process and vocabulary can often be rather unfriendly when used. Death by acronyms is not uncommon when people start arguing about RTM’s, BUC’s, and SUC’s. Not to mention many of these exhibit a consulting bias simply due to the amount of self-justifying documents or “artifacts” they demand to concretely demonstrate value. Not happy with Bob the consultant’s last expense bill? But just look at all those artifacts! And this is where the less experienced architect will often go awry, spending too much time and effort to get the artifacts looking just right, but missing the point that if no one else can use them effectively they might as well not exist.
An example I like to pick on because it’s a pet peeve of mine: Use Case UML Diagrams. They have their use… for example when you are trapped on the moon with three Java developers. Outside of that I don’t think they are particularly useful in communicating with human beings. Yet, you’ll be surprised as to how some people spend Herculean efforts to get their Use Case diagram just so, like it was the analyst equivalent of the Sistine Chapel. Stop wasting your time like that.
Now there are a lot of methodologies, and frequently people will ask which is best, which has the most hit points, or what has been magically ordained as the “right” way. The answer is none of them and all of them. The methodologies and the documentation they stipulate are nothing more than a consistent means of communication. Honestly, whatever you come up with that can uphold a similar consistency of communication will be good enough, provided:
- There is an immutable record be it a spreadsheet, napkin, or writing in the sky and
- Other people you don’t know can understand it.
But it’s not just requirements. The problem with requirements is that by themselves, they cannot tell you why. They tell you what. And if you don’t understand the why, boy, are you in for it. How to save the world then? Try to remember to use the 5-Why Combo indiscriminately.
What’s the 5-Why Combo? Well, you have to act like some kind of demented owl. Instead of asking Who? All the time, you ask Why? Some will undoubtedly presume you are nonetheless demented, but you will eventually find the truth… but be aware the truth is a minimum of 5 Why’s away at all times. Once you begin to master the approach you will find that some may begin to fear the owl, or people you’ve never heard of want to invite the owl to their meeting because they know something good will happen.
Let’s demonstrate:
Q: What other attributes to we need on this form?
Configuration Manager: We need three tiered drop-downs with these 57 codes in this spreadsheet, that need to show the both the code and this textual description of the code in another attribute.
Owl: Why?
Configuration Manager: It’s on every product that goes through the current system.
[Note: Here is where many architects just go “OK!” and furiously scribble it into their Use Case Diagram. And two years later when the unwieldy parade of 57 codes drives people to jump off bridges they state “We had a Requirement for that.”]
Owl: Why?
Configuration Manager: It’s in our process documentation. See here. Page 7, Section 4 and Table 5. Last revised this year.
Owl: Why?
Configuration Manager: It’s always been that way, as far as I can remember.
Standards Officer: It’s in the process because it was determined years ago those codes are necessary for planning to pass certain critical information to manufacturing for measurement purposes.
Owl: Why?
Planning Manager: All my people transfer this coding to the ERP system as part of their effort.
Owl: Why?
Planner: I really don’t know. I just copy the code over.
[I don’t know is usually a sign you are close to the truth. This is where the owl must press on.]
Manufacturing Personnel: Yes, we’ve been receiving these codes for quite some time. Initially they were used for some metrics about 5-6 years ago, but they proved to be unreliable so we switched to a different method. We just more or less ignore it as it doesn’t slow us down much.
And there you go – what would have otherwise been a rather complicated set of requirements turned out to be nothing at all. Thanks to the owl and the 5-Why Combo… this happens much more often than you think. The end lesson here is this: Beware of the tendency to focus on requirements in of themselves rather the underlying business objectives of efficiency, effectiveness, and ultimately usability. Gathering requirements and not asking why is a sure-fire way of creating a new system that is indistinguishable from the previous one. And what’s that value in that?