97 Things Every Software Architect Should Know

Chapter 16. There Can Be More Than One

After many years as an amateur, Keith Braithwaite was first paid to write software in 1996. After that first job, maintaining a compiler built with lex and yacc, he progressed first to modelling microwave propagation for GSM network planning, then seasonal variations in demand for air freight, in C++. A move to consultancy (and Java) introduced him to CORBA and then EJB, and then what was called at the time "e-commerce." He is currently a principal consultant with Zuhlke and manages its Centre of Agile Practice.

—Keith Braithwaite

IT SEEMS TO BE A NEVERENDING 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, multifaceted, 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 ...