“The Message Is the Application (TMITA)” is an interesting design pattern. I’d like to discuss it’s challenges.
The inspiration for this post comes from reading the masterpiece Righting Software by Juval Lowy. In the book Juval teaches the basics of decomposition and Service-Oriented Architecture (SOA) and design. After teaching the basics Chapter 5 is an example. The example leaps off the deep end and uses TMITA design pattern. I wrote this article because book club discussions about the example made it clear that people were having difficulty following along. The reason I came up with is the complexity of TMITA itself. In this piece I discuss the nature of that complexity.
The gap between messages, rules, and actions creates a cognitive dissonance. It becomes difficult to hold the behavior of the system in your head. This makes debugging difficult. It makes talking to the business and the front-end/application team(s) difficult.
There is a temporal gap as well. The entire system becomes asynchronous. Messages are in queues or in-flight. Gone are the days of inspecting the DB and ascertaining the state of the system. A part of the state is in the messages. In the past the database used to be the gold standard of system state. Now it might actually be misleading.
I’ve used the TMITA design pattern on several systems. TMITA is a natural design pattern when using a workflow engine. Messages come in and pattern matching or rules determine whether there is a matching workflow. If there is a match then the workflow is executed.
I’ve noticed that trying to explain simple use-cases to others can be difficult. Especially if one use-case triggers one or more other use-cases. What gets lost with TMITA is the direct link between the message and the actions taken. We’ve placed pattern matching and rules between the message and the actions. Not to mention queues, buses, and “message-guarantee systems.”
It can be difficult or impossible to inspect a message and know what actions it will trigger. Particularly from looking at the message alone. The pattern matching or rules that matches the message with it’s actions may not be available. For example, you may log the message and it’s contents, but not the rules. By the time you look the rules may have changed. It might even be a security issue to log the message and the rules together. If many workflows share the same actions, it can be difficult to match the logs against the workflows. Learn to love GUIDS and timestamps.
Another issue is in the name itself. The Application. Most developers learn to reason about applications. In SOA we want the system separate and distinct from the clients and the applications. The degree to which the clients and applications are decoupled in TMITA is extreme. As Juval put it, “decoupling is almost stretched to it’s limit.”
Most developers learned to code by building apps. The teams we work on build apps. On the one hand this is it’s own prison, as Monty describes in, “Escaping Appland.” Still it is in the cauldron of application development that we learned to think about code. When “the application is nowhere to be found” how are we to reason about it?
This is not idle wondering. Programming is hard to learn. OOP is hard to learn. Using design patterns is hard to learn. Leading practices are hard to learn. Reasoning about systems instead of apps is hard to learn.
When developing it’s not clear what information will later explain the system’s behavior. How do you know what to log? Messages, rules, runtime context, execution paths? My past TMITA projects have solved this problem by shipping many releases. Each release tries to add the missing information from the last frustrating debugging.
Why am I calling this out? Because if you took the time to learn The-Method then you will use TMITA. As Juval says in the example, “(TMITA) is justified because of required extensibility.” Most organizations will get to the point where this is justified. The question is will the organization be mature enough?
The gaps extend beyond cognitive dissonance. The variety of messages, rules, and actions creates a documentation problem too. We use TMITA because of it’s extensibility. This means that modifying the workflow is often easier than modifying the documentation. The same is true of the patterns and rules. Saying that the system itself is the documentation means your ignoring context. The context of why and what is often more valuable than the how. Documentation serves many purposes. Not the least of which is an independent check on the implementation.
Righting Software is a masterpiece. But if you found the example difficult to visualize, then you understand. TMITA feels like looking at Xml and Json before there were visualizers. It won’t always feel this way but it’s helpful to understand that it does today.
Sidebar: An interesting example. Azure Application Insights is an example of building a modern TMITA system.
From the Azure documentation: https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview
“Application Insights, a feature of Azure Monitor, is an extensible Application Performance Management (APM) service for developers and DevOps professionals. Use it to monitor your live applications. It will automatically detect performance anomalies, and includes powerful analytics tools to help you diagnose issues and to understand what users actually do with your app.”
The Azure Portal has tooling that allows visualizing, querying, and configuring. The system has an SDK allowing developers to extend the system. It’s amazing and well refined. And it still suffers from may of the observations I’ve put forth in this commentary. It’s rare to find anyone that understands Application Insights well.
