97 Things Every Software Architect Should Know – 16/97
It seems to be a never–ending source of surprise and distress to system builders that one data model, one message format, one message transport—in fact, exactly one of any major architectural component, policy or stance—won’t serve all parts of the business equally well. Of course: an enterprise ( “enterprise” is red flag #1) big enough to worry about how many different “Account” tables will impact system building next decade is most likely too big and diverse for one “Account” table to do the job anyway.
In technical domains we can force uniqueness. Very convenient for us. In business domains the inconsistent, multi–faceted, fuzzy, messy world intrudes. Worse yet, business doesn’t even deal with “the world”, it deals with people’s opinions about aspects of situations in parts of the world. One response is to deem the domain to be technical and apply a unique solution by fiat. But reality is that which does not go away when one stops believing in it, and the messiness always returns as the business evolves. Thus are born enterprise data teams, and so forth, who spend all their (very expensive) time trying to tame existential dread through DTD wrangling. Paying customers tend to find the level of responsiveness that comes form this somewhat unsatisfactory.
Why not face up to the reality of a messy world and allow multiple, inconsistent, overlapping representations, services, solutions? As technologists we recoil in horror form this. We imagine terrifying scenarios: inconsistent updates, maintenance overhead, spaghetti–plates of dependencies to manage. But let’s take a hint from the world of data warehousing. The schemata data marts are often (relationally) denormalized, mix imported and calculated values arbitrarily, and present a very different view of the data than the underlying databases. And the sky does not fall because of the non–functional properties of a mart. The ETL process sits at the boundary of two very different worlds, typically transaction versus analytical processing. These have very different rates of update and query, very different throughput, different rates of change of design, perhaps very different volumes. This is the key: sufficiently different non–functional properties of a sub–system create a boundary across which managing inconsistent representations is tractable.
Don’t go duplicating representations, or having multiple transports just for the fun of it, but do always consider the possibility that decomposition of your system by non–functional parameters may reveal opportunities to allow diverse solutions to your customers’ advantage.