My approach to solution design

My professional life is in IT. I’m not the developer or the solution architect but I’m the intermediate between the users and the people that realize IT solutions. 

When I talk to my customers I need to avoid technology but focus on what they are doing, and why. Doing so I identify potential of automation. I isolate the tasks that are some dumb that a computer can do it better. 

The way I approach my work, all seems very playful and intuitive but what I do is based on a mix of methods and standards. You’ll never hear me say: You must. It’s a proven way for me to do my job. 

Over the years I have done jobs from small to large and from simple to complex and what is clear to me is that if I follow this approach, the outcome is always a logical consequence.

Please try this at home. Shape your own style, use my “things” when it fits you. You will experience that working via a proven methodology always leads to good output.

Study and describe the process

Writing use cases is considered difficult by technologists

A use case is a process description, used to find the best balance between the various activities and the help of (computer) tooling. It is most likely >99% related to IT but still, it describes the process that makes use of tools or applications.

Something goes in. It passes a black box or a range of black boxes, and something comes out.

What happens in the black box has a main flow (that is described in plain language). Make sure to avoid technology. This process can also have sub-flows or alternate flows. 

Also the requirements engineer or business analyst describes:

  • 1 primary actor; the person or agent that triggers the process.
  • secondary actors; people/ stakeholders that have an interest in the output or additional actors in the process.

Writing use cases is the domain of a business analyst or requirements engineer. Developers are the worst business analysts because of their technology focus.

A use case describes the agreement between a supplier (solution designer) and a process owner. If the process owner doesn’t understand the message, it is a lousy use case.  

The process captured in one use case

Sometimes that’s just enough. When your mother makes her weekly French fries on Saturday, there is absolutely no need to describe the process in detail. Mama is smart enough to peel only those potatoes that are in the right shape. She knows how to slice those peeled potatoes, and knows by intuition or tricks when the oil is at the right temperature. By observing the color she knows when the fries are done and perfectly crispy. and she knows that she needs to throw away the residue like peel and sand in the green container. 

But what to do when you need to bake fries on an industrial level?

Using industrial machines, a process automated to the max enables a 24/7 approach. Machines don’t need light, don’t need a break every two hours, and perform with ultimate concentration.

When it’s dumb enough you can use a computer to control the job. 

To do that you need to break up the process into smaller parts (finer granularity) and you need to be very specific. A computer doesn’t have the common sense that a mother has. Computing is calculating. That’s why you need to make the tasks quantifiable. A computer can compare values. 

Select and wash potatoes


  • A batch of unsorted/ muddy potatoes is loaded into the input reservoir

Main flow

  • Potatoes are hosed with water.
  • Wait 5 minutes
  • Disperse potatoes into the conveyer belt.
  • Shake and align 
  • Hose again while rotating potatoes
  • Execute press test, identify squishy potatoes
  • Dispose squishy potatoes
  • Measure potatoes via laser
  • Isolate too small potatoes
  • Selected potatoes are grounded/ peeled

Sub flows/ alternate flows

  • Squishy potatoes are blown away by air pressure gun and dropped on the conveyer belt for squishy potatoes
  •  Small potatoes are blown away by air gun and dropped on the conveyer belt for small potatoes
  • The washing process is set to hold because of too much clean potatoes in the slicing reservoir


  • Matching potatoes are cleaned, peeled, and added to the input reservoir of the slicing machine.
  • Squishy potatoes are dumped into the “rotten potato” container
  • Too small but firm potatoes are peeled and added to the mash potato machine
  • A stack of potato peel.

Slice potatoes

The postcondition of a previous step is the precondition for the next step. That’s why it’s called a process chain


  • Matching potatoes are cleaned, peeled, and added to the input reservoir of the slicing machine.

Main flow

  • Potatoes are placed in length orientation 
  • Potatoes are pushed from the latter side though the knives
  • Chips are shaken to get separated

Sub flows/ alternate flows

  • The slicing process is scaled down to 50%
  • The slicing process is scaled down to hold.
  • When the load of the slicing input reservoir exceeds 200 kilos, the washing process is stopped


  • Potatoes are sliced into chips and added to the fryer reservoir.

Bake French fries


  • Potatoes are sliced into chips and added to the fryer reservoir.

Main flow

  • Potatoes are portioned
  • Potatoes are fried in oil, heated to 160 degrees Celcius, for 2 minutes
  • Potatoes are sieved and shaken to get loose
  • Potatoes are spread over the cooling rack. 

Sub flows/ alternate flows

  • Potatoes are kept on hold on the cooling rack until demand
  • When the demand batch exceeds 5 kilos, hold the first frying stage
  • When the fryer reservoir exceeds 25 kilos, the slicing procedure is downscaled to 50% speed.
  • When the fryer reservoir exceeds 40 kilos, the slicing process is set to hold.
  • Sales are monitored to inform the procurement proces.


  • Chips are fried and added to the package reservoir

Pack, sell, and present French fries


  • Chips are fried and added to the package reservoir

Main flow

  • French fries are baked, slightly salted, and boxed. 
  • French fries are baked, slightly salted, boxed with added ketchup
  • French fries are baked, slightly salted, boxed with added mayonnaise
  • French fries are baked, slightly salted, boxed with added vinegar

Sub flows/ alternate flows

  • Fries are paid for.
  • Fries are packed as “Fries ToGo”.
  • Decide to give them away to the neighborhood kids 
  • Fries that have been laying too long and got stale, losing their crispiness are disposed of as pigs’ food. 


  • French fries are paid and handed over to the buyer to be eaten on the spot.
  • French fries are paid for and handed over to the buyer in a bag “ToGo”.
  • French fries are given away for free and handed over to the kid to be eaten on the spot.

Focus on the tools and resources at the same time

What happens next with these use cases?

The business analyst will make an overview of the functional components. While describing the functional aspects this is also the starting point of discussing the infrastructure with the architect (what platform) or the application impact with the lead developer. 

For the architect and the lead developer, these functional “thingies” are the interface to technical design and documentation.

It's teamwork, and it requires a variety of disciplines.

A use case described baking fries at mama level

A use case diagram

In a use case diagram, often no distinction is made between the representation of a human actor and a tool, a machine, or a resource. Some purists think that you should also draw a computer system like a man. I have a hard time with that because I’m looking for those things that are so stupid that you can outsource them to a computer.

The human being then comes into its own better because of his/her capacity for nuance, ethics, fantasy, and most important: common sense.

Use case diagram ; industrial level

The use cases are displayed as ellipses. The boundaries of the process are shown with a rectangle.

The model is also hierarchical. Every use case can be opened by clicking it and then the next level detail of the use case is displayed. 

There is no limit in refinement or granularity. 

The stick figures represent human users

The square icon with the two bars represent the non human actors in the process.