Who Is Responsible for What?

Software systems can be divided architecturally along two broad dimensions. The first is the marketecture, or the "marketing architecture." The second is the tarchitecture , or the "technical architecture." I refer to the traditional software architect or chief technologist as the tarchitect and the product marketing manager, business manager, or program manager responsible for the system as the marketect.

The tarchitecture is the dominant frame of reference when developers think of a system's architecture. For software systems it encompasses subsystems, interfaces, distribution of processing responsibilities among processing elements, threading models, and so forth. As discussed in Chapter 1, in recent years several authors have documented distinct styles or patterns of tarchitecture. These include client/server, pipeline, embedded systems, and blackboards , to name a few. Some descriptions offer examples of where these systems are most appropriately applied.

Marketecture is the business perspective of the system's architecture. It embodies the complete business model, including the licensing and selling models, value propositions , technical details relevant to the customer, data sheets, competitive differentiation, brand elements, the mental model marketing is attempting to create for the customer, and the system's specific business objectives. Marketecture includesas a necessary component for shared collaboration between the marketects, tarchitects, and developersdescriptions of functionality that are commonly included in marketing requirements documents (MRDs), use cases, and so forth. Many times the term whole product is used to mean marketecture.

The $50,000 Boolean Flag

One "heavy client" client/server architecture I helped create had a marketing requirement for "modular" extension of system functionality. Its primary objective was that each module be separately priced and licensed to customers. The business model was that, for each desired option, customers purchase a module for the server that provided the necessary core functionality. Each client would then install a separately licensed plug-in to access this functionality. In this manner, "modules" resided at both the server and client level. One example was the "extended reporting module"a set of reports , views, and related database extract code that a customer could license for an additional fee. In terms of our pricing schedule, modules were sold as separate line items.

Instead of creating a true "module" on the server, we simply built all of the code into the server and enabled/disabled various "modules" with simple Boolean flags. Product management was happy because the group could "install" and "uninstall" the module in a manner consistent with their goals and objectives for the overall business model. Engineering was happy because building one product with Boolean flags is considerably simpler than building two products and dealing with the issues that would inevitably arise regarding the installation, operation, maintenance, and upgrade of multiple components . Internally, this approach became known as the "$50,000 Boolean flag."

The inverse to this approach can also work quite nicely . In this same system, we sold a client-side COM API that was physically created as a separate DLL. This allowed us to create and distribute bug fixes, updates, and so forth, very easily; instead of upgrading a monolithic client (challenging in Microsoft-based architectures), we could simply distribute a new DLL. Marketing didn't sell the API as a separate component, but instead promoted it as an "integrated" part of the client.

Moral? Maintaining a difference between marketecture and tarchitecture gives both teams the flexibility to choose what they think is the best approach to solving a variety of technical and business problems.