I’ve been making some of my earlier work more accessible by publishing it on my website. The latest addition is my very first patterns paper, published in 2006—a collection of Problem Frame Patterns. Problem Frames are an analysis technique invented by Michael Jackson. Jackson’s problem frames build on a recognition of generic problem types, based on structures and relationships between domains, system elements, and shared events.

I wrote these patterns with co-authors Paul Taylor and James Noble (two great collaborators). At that time, we viewed writing problem frames in patterns form as an experiment. We wanted to see if it made sense to use pattern descriptions to characterize the problems solved by software systems.

We succeeded!

Yet we still had questions: Could framing be integrated with other requirements analysis techniques? How might we bridge the gap between problem frames and software design solutions (perhaps that use particular design patterns)?

But the biggest question I had as a new patterns author was this: Would people more readily understand problem frames if they were written as analysis patterns?

We concluded:

“Connections between problem frame concerns and potential design pattern solutions certainly exist. It seems fruitful to view framing as one way of guiding the exploration for potential solutions. However, stronger connections between frame concerns and architectural or design patterns, other than those we have mentioned, don’t appear so obvious. This may be because certain design patterns resolve tensions that are intrinsic to the solution, not the problem. Design patterns as a whole need to be better organized before more connections can become clear.”

Nearly twenty years later, I still believe that design patterns need to be better organized. But I’ve let go of the goal of forming stronger connections between problem descriptions and proposed solutions. Perhaps the gap between the problems and solutions is inevitable. Nonetheless, I find problem framing to be useful. It leads me to ask probing questions in my attempt to better understand the nature of the problem before jumping to design solutions.