May 3, 2016Doug Hadden
Marketecture is one of the most creative endeavours for product marketers. That’s because it’s not about the actual product architecture. It’s about trying to explain product capabilities in a way that is easily understood. And, to provide some visceral notion of value.
“Modular” design has been considered an important aspect for all enterprise software for decades. The truth be known: vendors tended to present “marketectures” as much more modular than reality. Like simple blocks. Yet, these are anything but.
The problem is that traditional software, like ERP, is monolithic in design. The “modules” are large to very large. This meant that buyers needed to be certain that all required functionality was included in the modules. A single function in a different module meant buying that module. This has created some confusion because it is generally assumed modules among vendors are very similar. But, the definition of what is a module differs among vendors. And, it becomes rather more confusing when the product architecture, like in the FreeBalance Accountability Suite, is not monolithic.
The FreeBalance Accountability Suite uses very small business objects that we call “Government Entities” (because we don’t make software for businesses). These “GEs” are assembled for any piece of functionality. Many GEs can be assembled to create modules of the size and scope of legacy systems. Some GEs can be assembled to create functionality that is much smaller than traditional modules. All of these GEs are unified to enable centralized metadata and workflow management (that provides significant advantages). So, modules within modules within modules can be provided. In other words, FreeBalance customers are not concerned about modules because the assembled set of functionality meets needs. And, FreeBalance customers pay for this functionality, not the entire “module.”