Architecture is Not: A Proof of Concept

I recently heard the sound of rushing water in the wall of my kitchen. I was aware there was a problem. I didn’t really understand the problem. I simply knew something was not right. What do you suppose I did first? Did I go out and buy a pipe wrench as my first act? Did I dial the guy who installed the kitchen cabinets and demand a demo of new soft-close drawer technology? Did I call my appliance guy to show me the new Subzero fridge line? No. The first thing I did was go into the crawl space to discern what in the hell was happening. It appeared to be a burst pipe. I traced it to the nearest water shut-off valve and turned it off. I made a quick analysis, localized the problem in my kitchen infrastructure to be a pipe and not a cabinet or a refrigerator, and took a course of action to temporarily fix the problem. Now I needed a long term solution.

So I called the plumber, the expert. I didn’t ask him to show me all the tankless water heaters he sells, I asked him to fix the problem that I had diagnosed. “Hey, I figured out that I have this problem and I need a long term fix for it. What do you think?” Some new piping and soldering and I was soon in business.

Why do we have folks in our companies today that insist the first thing that should be done to address a business or technical problem is to get a demo set up of all the latest gee-whiz tech? There isn’t an attempt to identify, localize and describe the problem. There isn’t an attempt to draft any real set of requirements for how the company would like to see the problem addressed. The gut instinct seems to be to call up the vendors and get a proof of concept set up for that new BPM tooling or cloud middleware component. Think the new Sharepoint is the cat’s meow? Let’s get a PoC set up in a Microsoft Tech Center stat! What problem are we solving with it? Well, you know, we don’t communicate well or something. But look! Sharepoint has webparts!

An architecture for a solution requires understanding the problem at hand well enough that solving it can be described in terms that everyone understands. The architect speaks in terms of capabilities, not products, needed to address a problem that is well understood. But the understanding must come first. What pain is being experienced? By whom? Over what? How can we conceptually define an architecture that addresses this pain? How do we prioritize solving the pain(s)? What are the impacts of implementing this solution? Who will benefit? In what manner will they benefit (more speed, less speed, fewer defects, greater revenue…)? What will we need, conceptually, to solve this problem? Is this a data problem? A throughput problem? A people problem? A process problem? How much are we willing to spend, ballpark, to solve it? Is there any value-add to solving this problem?

These questions, and many more, are the sorts of things we should be thinking about eons before we go to a vendor and ask them to show us how cool their foobar doohickey is. It helps us target our thinking. It helps us ensure that what we’re doing (getting ready to spend the company’s money) is something that makes sense, matters, solves the problem. It allows us to put a team on the problem and not circle endlessly in headless Webex sessions looking at tools that may or may not have anything to do with the issue at hand.  It allows companies to avoid possessing vast inventories of tools that it doesn’t really need.

I’m not against a PoC as a learning mechanism. In fact it is often necessary when sophisticated solutions are being considered at a certain point in the solution lifecycle. I’m against it as a substitute for asking the right questions up front, understanding the problem and proposing an architecture to address that problem. A Proof of Concept is not an Architecture.