Making it work ("People"): Context (Solution Design II)

Wow, that was a   l o n g   posting!  Sorry!

My previous post focused on the "when?" of  Solution Design - this one relates to the "where?".  But I do not only mean "in the office", or "Country X" - that sense of "geographic where" is important, but so is the "organizational where":

Organizational Where (Solution Design)
Which organization, or department, or business unit "does" the solution design?  In fact, why should we care?  Put bluntly, "vested interest"!

The forces at play on an enterprise's "internal team" of solution designers are quite, quite different than those of an external agency, be they engaged in a purely "early design" stage, or fully engaged as a Systems' Integrator or Package Implementer.  For example, whose reference designs will the solution be based on?  Those known to the designer, obviously!

• Which means an internal solution design team are more likely to know, understand - even have contributed to the Enterprise's architecture, and therefore far more comfortable with using it as a guide for their solution, and therefore more likely to lead to "architecture conformance"  in balance with the cost/benefit concerns of the wider team, across the full lifecycle of the system (deployment through change to decommissioning)

• On the other hand, an external agency is far less likely to be familiar with the EA - and in fact may face pressures to create a design more in keeping with their own agency's reference materials - the forces at play here being the cost/profit of the engagement. And if the scope of the engagement is no further than deployment, then designing for the full lifecycle is likely to be low on their agenda...

• And then there's the Enterprise's Architects - the forces at play on them are different again - less of a formal "design mindset" and more "big picture stuff", trhey will have a strong desire to follow their own architecture, and "negotiate" the requirements to fit ! :-)

So what can we do to manage these forces so we create the "right" Solution Design?  Invoke the power of Politics!!!!  And specifically that part of politics that ensures the three Architecture Governance bodies are in place, to oversee the design's creation (the program's/project's Design Authority using the EA), its fit to the wider enterprise (the enterprise's "Office of the Chief Architect" in concert with the DA), and conflict resolution (! - the "Architecture Board" in concert with the other two).

Geographic Where (Solution Design)
Where in the world's the best place for Solution Design?

• Instinctively - I say, without hesitation, "locally". Local to the rest of the project team, local to those responsible for specifying requirements, local to those expected to do the detailed design and subsequent deployment.
  
  Why?  Why in this world of outsourcing and off-shoring?  Because Solution Design is hard.  It's iterative, ambiguous (in it's early stages) and it's complex.  It needs face-to-face (and face-to-whiteboard) working ideas and options need to be expressed "tangibly" in "real time", sometimes with passion...
  
  Once, maybe 10 years ago, I was facilitating a design session, attended by expert end users and sponsors as well as my client's designers.  We were "pre-proposal", so things were a bit "foggy", and we were resolving conflicting requirements using the HUGE whiteboard in the Boardroom and Post-Its(r) to represent our model's elements.  As I and my fellow designer's looked on, the two sponsors fort over where a Post-It should go - in the end neither would give in, and the Post-It tore in two. Now THAT'S what I call "local engagement"!

• But it's often inevitable that some (or all) of the Solution Design is performed "remotely", in which case I implore you to ensure some level of "on-shoring" representation is locally available, to act as the human gateway between the real people in the enterprise, and the real people "somewhere else". 
  
  The (small) local team is then responsible for understanding and negotiating the requirements with those outside the design team, and transforming them into formal descriptions for their off-shore colleagues - as well as handling Architecture Reviews - which implies the one-shore team must include some aspect of the Design Authority.