In Step 3, I touched on how legacy choices might significantly impact the design of enterprise components.  Now we need to incorporate the broader needs of the business into our design which will likely reverse some of the simplifications applied in the last step.  Establishing a sound basis for changing our simplified design is as much mandate as requirement.  We need to make our decisions with reasonably comprehensive knowledge of the entire business domain.  Of course achieving this requires balancing our need o conduct research and analysis with the limited time to do so before the domain changes again.  With fresh eyes we need to discover (or rediscover) the enterprise.  We need to venture forth, leaving our cubicle, going beyond the comforting borders of the IT department, and mingle with the business in action  Questioning everything and assuming nothing.


When gathering information about the domain you should;


  • Leave the laptop behind; I, like many, can type faster than I can write with a pen.  Non-the-less, I abandon the laptop for a pad of paper when I am researching an enterprise.   The laptop has a way of coming between me and those I speak with.  The clicking of the keys always breaks the otherwise natural rhythm of conversation and keeping eye contact becomes, at best, difficult.  I would like to believe a slate or tablet pc is a middle ground but I haven’t had the privilege yet.
  • Use Interview not Interrogation techniques; There are few populations as affected by television as software developers. The vast majority of developers turned business analyst I have worked with seem to have taken their interviewing style from police dramas or investigative news shows.  You should avoid direct positive confrontations.  Instead of saying “don’t you usually look to minimize over burdening people in the schedule?” consider, “ are all people scheduled the same way? if so how do you manage to balance things, if not what differs one person from another?”  Avoid developing a theme for the people your speaking with, instead look for themes they present to you.
  • Avoid System terms; as users of tour echnology become more and more comfortable with how technology works they tend to translate their thoughts into our language.  They mean well but don’t let them.  Finding out that someone clicks a button and updates a record in the database simply doesn’t help us at this point.  We need to know why they are acting on the entity or thing whose attributes are persisted in the database. What are they trying to accomplish?
  • Lead gently and Listen intently; we need to provoke thoughtful consideration of the business tasks and how context, workflow, and constraints affect them.  This is verbal geometry.  Our theorems require proofs.  If someone says they receive some information to process, ask where it comes from, does it always come from the same source, is it always the same format?  Find the pattern in content, schedule, etc ...

It has been said that all arguments are good.  You either prove you are right or you are proven wrong and provided the opportunity to correct your own misunderstanding.  While we should striver to avoid the negative aspects of arguing, we must challenge our customer and ourselves. As architects we bring technical understanding to the resolution of business issues as often as we bring business understanding as guidance to the technical solutions.  Constantly seeking to define the implicit activities of the domain in explicit terms so that we may validate their accuracy and completeness helps us map our understanding of the domain and identify it’s impact on how and where we apply technology.