O'Reilly logo

97 Things Every Software Architect Should Know by Richard Monson-Haefel

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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
image with no caption

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 ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required