How to design a system without requirements.
My five year old likes to build things. When I get home from work, she says, “daddy, let’s build something!” and then pulls out a box of Legos or blocks or something. I usually respond, “sure, what should we build?” And she replies, “I don’t know!” and then she proceeds to start building it. Usually “it” ends up being a spaceship or a house or a three-legged pony, or maybe a three-legged-spaceship-house-pony.
In my last post, I concluded with the statement “at the end of the day, the lesson is this: first define your requirements, then design the system.” But as we all well know, it is a rare day indeed when you actually get defined requirements before you have to begin designing a system. And just like my daughter with and her three-legged-spaceship-house-pony (or is it a bullfrog with three ears and square eyes?), without defined requirements you may end up with a whimsical result, but probably not a very effective one.
Defining requirements
For the purpose of this post, I’m going to classify you into one of three roles: decision maker, architect, or engineer. Each plays a distinct role in building an effective system.
Decision maker. This person is the highest level of authority for the system. Job titles may include CIO, CTO, Chief Executive, or Grand Poobah (well, maybe not that last one). To put it into the vernacular, you’re the man. Often, the decision maker does not have a technical background (even though she may be called the Chief Technology Officer), but this isn’t a problem because the job of the decision maker is to define business requirements. For example, the decision maker doesn’t need to say “we need redundant core switches and a multi-site failover architecture.” Rather, he or she should say, “downtime costs the business $56,000 per minute in lost revenue, and brand damage begins when we are down for more than 10 consecutive minutes more than once per month.”
Architect. This is the person who translates the decision maker’s business requirements into technical requirements. In other words, the architect is bi-lingual, speaking business and tech. The architect interfaces with the decision maker to fully understand the business requirements and then translate them into technical requirements.
Engineer. The engineer uses advanced knowledge of the inner workings of protocols and technologies to create a working system based on a defined set of technical requirements.
As you can see, each role in the list relies upon the output of the role above it. You could extend this list to include implementer and supporter, where the supporter operates the system implemented by the implementer, who implements the system engineered by the engineer, who engineers the system based on the technical requirements translated from the business requirements by the architect, who translates into technical requirements the business requirements defined by the decision maker (phew!).
Finding the missing pieces
When everyone is fulfilling their role properly, the organization runs like a well-oiled machine. But what do you do when there is a missing piece? What is the architect to do when the decision maker fails to define business requirements? What is the engineer to do when asked to engineer a system without any technical requirements? Let’s look at each.
As we already established, the role of the architect is to translate business requirements into technical requirements. But what if no firm business requirements have been defined? The answer is quite simple – make some up, but in the reverse direction. Using your knowledge of the industry, create a list of basic assumptions and define some reasonable technical requirements around those assumptions. Be sure your deliverable clearly states the fact that you had to make some assumptions, and also how you came up with the assumptions. And if you really want to knock their socks off, if you know enough about the business you can reverse-translate your technical requirements into a business impact analysis and show how your architecture will impact the organization.
And what if you are just a lowly engineer being asked to design a system, but haven’t been given any technical requirements? First, welcome to the club. Second, the answer is the same as for the architect – make them up. That’s right, make up your own requirements. Then if your decisions are questioned, you just state that you were not given direction and you came up with something reasonable. This is far better than trying to defend an arbitrary design decision. Just be sure to document your assumptions.
Why does it matter? What does it mean for the future of the enterprise?
Without clear requirements, organizations typically end up violating the First Principle of network design. They often end up with networks that look more like my daughter’s three-sided-fishtank-pony than an elegant, coherent system, resulting in increased costs, decreased security, and a whole lot of headaches.
