Constructive problem solving 3 steps to building a powerful model
Show me a company with proprietary systems, and I’ll show you a company that’s nervous about changing at least one of them. Consider the legacy system that has become a crucial part of your day to day business—you know the one. It limps along on good days, but god forbid you ever have a real problem, as nobody really knows how certain functions actually work. Its governing structures have melted into a ball of mud, and any change might bring the whole system crashing to a halt.
If your system experts don’t fully understand how to take things apart and fix them, why are you waiting to improve or replace the whole process? Eventually, you’ll hit that fatal moment that sinks your productivity for a week, or worse. But how do you even begin to fix something so tangled? It’s time to build a model!
Consider first your issues, and then imagine how you might make improvements. Dream big, and use the process of modeling to draw out your project’s maximum potential. If you can clearly identify your problem and lay it out logically, you can create a system defined by dynamism and growth. Assemble your team, embrace simplicity, and constantly make changes to the models you build. If you establish a solid foundation, you can solve any problem and add much needed functionality to your existing system.
Step 1: All aboard!
As you begin the process of modeling, take advantage of your human capital. Draw upon your domain and business specialists for their insider knowledge, and include your development and technical cohorts for their expertise in solving the pain points users encounter. Most people don’t interact with other departments unless they have to, which can limit individual perspectives. It’s critical to develop an understanding between your teams, as this will help you discover the best language to use while building your model.
Make teamwork the absolute bedrock of your process, and use proven techniques like event storming to break through isolationist and siloing tendencies. Many people create fiefdoms within their departments to hide the gaps in their knowledge or to bolster a position as sole specialist within the organization. The trick in breaking down these divisions is to celebrate the gaps in your teams’ knowledge as much as you value their expertise. The gaps will show you what doesn’t work universally in your model, as well as offer an opportunity for subject experts to explore new ways to communicate to their counterparts in other groups. In the best case scenario, this illuminates pain points you didn’t even think about. While the process may take significant work, a better product and an engaged team excited by problem solving are excellent tradeoffs.
Every member of the team, right down to the most junior, may have a breakthrough that clarifies an issue, so encourage everyone to share their notes and ideas. Communication in modeling sessions is key to your model’s success, and a system whose language makes sense to all its users will function better and have fewer problems. Take time to remove jargon or terms that distract from the core issue. This is an evolving, adaptive process, and too much focus on tiny details will diminish engagement and cost more time when translating the model into finished products.
Step 2: Simplify everything
Martin Fowler’s frequently repeated observation that “good programmers write code that humans can understand” is a key tenet of effective modeling, and will make problematic segments more obvious as you move into practical use. Instead of pouring too much into the technical details within your model, be explicit in your domain language and show what a function actually achieves. For instance, if you want to include a coupon feature within the model for your point of sale structure, you might write “Buyer moved to checkout → Does Buyer meet the conditions of Promotion X? → YES → Apply Promotion X discount to checkout total.”
I may be driving hard at the importance of simplicity in modeling, but upfront work toward simplification pays massive dividends in clarity and usability. If you have ever been on a subway, tube, U-Bahn, metro, you name it, you have seen an effective, simple domain model in action. Subway maps would be much harder to read if they depicted an accurate overground layout. Although they warp the exact distances between stations, stop names are legible, lines stretch over one another in an orderly manner, and a system that looks like a plate of pasta in reality suddenly takes on a user-friendly elegance.
You can use the same simplicity within your own models. Even if the visual representation of your structure isn’t entirely accurate, it may be more useful as a tool in abstraction. As your model grows in size and complexity, it will start to lose its integrity in unexpected ways. Pieces may bind to each other, and one knot in Function B could tangle up Function Q for no logical reason. However, if you set boundaries around smaller details, you will protect related functions if something fails. The best way to do this is to create new models for each related business case.
Make Simplify Everything your new mantra. Print it on a poster; embroider it on a pillow; say it to yourself regularly during your process. Think about each model you create like you would bubbles in the bath. When a larger bubble pops, it can be incredibly disruptive to the structures around it. When a small bubble pops, its neighbors are still supported and relatively unaffected. Don’t be afraid to start fresh on new models that cover related cases, with the understanding that you can come back to your existing models to make changes.
Step 3: Refresh, renew, repeat
Never let your model ossify. Embrace change and never stop iterating, or you’ll find yourself holding the same ball of mud you had when you started. Even after you’ve moved on to other tasks, revisit your finished models and play with them. The models that are too fragile to touch or change are exactly the models you should go back and adjust. Break things! Make a mess, and then find out why your model broke. Inevitably, you’ll find ways to strengthen existing mechanisms, or you’ll discover exciting new ways to enrich your domain. When we rest, we rust, so don’t wait to get your team together to start modeling!
If you’re ready to learn more, sign up for my modeling webinar below. I have exciting projects in the works, so make sure you bookmark my site and keep an eye out for updates. You won’t want to miss any of this!