The Moment of Conception

It’s that time of year, for those of us whose fiscal year and calendar year align, to start talking about strategic technology asks for next year. To play the portfolio optimization game well we – the architects we – need to produce high level solution designs and close cost and resource estimates for each project or product feature proposal in support of their business cases before they run the gauntlet.

Those proposals usually germinate in a business leader’s mind. To me, the key moment on their path to battling for a bag of money is the moment of conception. That is the moment when the business – the internal customers of IT – have, usually, articulated a business problem, and a goal to address it, and now someone – and it is usually some one, and not a committee – has to conceive of one or more solution alternatives to achieve the goal given the problem.

Conceiving of the solution alternatives requires both expertise in the business domain, as well as experience in solution technologies – Hohpe’s boardroom and boiler room.

Here is an example. Let’s say it’s 1880. We have a smelter on this side of the river, and we discover a copper mine on the far side of the river. Our goal is to maximize our copper production over the next three years. Our problem to solve is getting the ore back across the river to the smelter. Sounds simple enough, right? So what are our solution alternatives?

• We can swim back and forth and bring the ore back in sacks we carry.
• We can swim horses back and forth and bring back the ore in saddle bags.
• We can row our dinghies back and forth with as much ore as they will carry.
• We can build a raft and pole it back and forth with as much ore as it will carry.
• We can build a ferry and bring wagon loads of ore back with it.
• We can build a bridge and drive wagon loads of ore back over it.

Once we have the alternatives laid out, we can mechanically do Fermi estimates of each to inform our selection. We functionally decompose the solutions, make best guess estimates for the details, roll the numbers back up, and compare. So we channel our inner Enrico and start asking questions.

• How much ore will the smelter consume in what timeframe?
• How much ore can we mine in what timeframe?
• How much ore will a sack, saddle bag, dinghy, raft, and wagon hold? How many wagons will fit on a ferry?
• How many swimmers do we have? How many horses? Riders? How many dinghies? Pilots? How many wagons? Drivers?
• How many rafts could we build? How quickly? At what cost? Do we have the expertise?
• How much would it cost to build a ferry? How long would it take? Do we have the expertise?
• How much would it cost to build a bridge? How long would it take? Do we have the expertise?
• What are the risks of swimming, rowing, polling, ferrying and bridging? How many loads – and swimmer and riders and pilots and rowers and polers and wagon drivers and ferry boat captains and stevedores do we expect to lose in what timeframe?
• How much does it cost us to feed humans and animals? How much to maintain the dinghy, raft, wagons, ferry?
• How much does it cost to store ore until it can be brought across the river? What are the risks of storing ore? Do we need a guard? If so how many? What do they cost?

Then we calculate, for each option, how much ore it can deliver, when, and at what cost. And now, finally, we can get down to it: which is the most cost-effective solution option for maximizing our copper production over the next three years?

As architects, we want and need to be as far ‘upstream’ as possible in this process. We are frequently in the best position both to conceptualize alternatives and drive the Fermi estimates. The risk if we are not far enough upstream is that the business conceptualizes a solution without our engagement, based on a vendor’s sales pitch, or the technology they used in their last job, or the technology from a former colleague’s startup, which it can be very difficult if not impossible to unwind.

When we can get to the table, these are the questions I prefer to engage with our business partners around to seed the conceptualization and estimating:

• What are the roles, locations and devices of the users of the new or improved application or new or improved feature, hereafter ‘tool’?
• What is the nature of the expertise of each role? What other tools do they currently use?
• How many users in each role will need to use the tool overall? How many at the same time?
• For each of those user roles, what is it they will be able to accomplish or accomplish better with the tool? (One user role and one accomplishment per line, please.)
• For each of those user role & accomplishment combinations:
  • What tools or processes are ‘upstream’ of their use of the tool for the accomplishment?
  • What triggers their use of the tool?
  • When will they need to use the tool? Business hours? 24x7x365? Once a month?
  • What volume of work will each user in that role need to accomplish with the tool during what time frames?
  • How quickly does the tool itself need to accomplish its actions? Immediately, within 5 seconds? 10 seconds? 30 seconds? 1 minute? 5 minutes? 15 minutes? 1 hour? Overnight?
  • How ‘fresh’ does the data the user needs have to be? Up to the second, up to the minute, up to the hour, up to the day, up to the week, up to the month?
  • How sensitive is the data? (Since I labor in health insurance…) Will the tool include Protected Health Information? Personally Identifying Information?
  • What might he consequences be of an unauthorized user accessing the tool?
  • Is this is a mission critical tool? How quickly does it need to be available after a system outage? After a natural disaster how should we prioritize its recovery?
  • What federal and/or state laws and regulations govern what the user can do, or not do, with the tool?
  • What contractual obligations do we have around the use of the tool?
  • How long do we expect this tool to be in service? One month? One year? Five years? Until it is replaced with something better?
  • How often do we expect new features or improved features in this tool?
  • How do we measure the users success with the tool?

My obvious strategy in this? Elicit the high-level functional and non-functional requirements by asking specific questions. Getting those requirements can be a challenge if you toss a request for them over the silo wall. But there is not any question in my list above that a business partner could not at least take a stab at – and we can get through the list in a thirty minute meeting.

Stay tuned.