Making it work ("People"): Context (Architecture)

The "Who does it when?" of Architecture
Whether it be "upstream" transition planning, or "downstream" ABBs and reference designs, the "when?" of  who does Architecture is rather different than that of Solution Design - fundamentally because Architecture is ongoing "for ever", whereas SD programs and projects have beginnings, middles and ends, often in the stages I described earlier.

So for Architecture "when?" is always "then, now, and later"!   

I'll discuss the direct implications on the lifecycle and useage of the architecture itself when I get to "Process", so for the moment I'll restrict muself to saying Architecture always needs a cyclical refresh, whether annualy or more frequently.

But whatever the reason, rate and nature of change, who changes it?
Architects of course, whenever and whyever the "when"!  

• "Downstream" Architecture guidance and governance
  Whoa, just a minute...!!!  My next topic includes "Persuasion"... and a particularly powerful form of persuation is involvement - for example, in previous posts for downstream Architecture I've discussed the Architects' "curatorship" of "their EA" and how, by engaging the design community directly in the creation of the Architecture, can be a powerful means of gaining commitment from them; whether that engagement be their specification of the ABBs (such as "standard actors") they want to use, or the creation of a specialised reference design based on those ABBs.  Once created, it is almost a given that they will then be happy for the Architects to curate "their" architecture.
  
  Doing it the other way, at least in in my culture, the challenges of "me" getting "you" to use "my" architecture are, well, challenging.

 

• "Upstream"EA ("Transition Planning")
  Here, things are different, where the broader, less "precise" skills of the architect comes to the fore - unless of course the topic is somehow specialised, when the aid of a more technically competent designer is vital.
  
  And of course the stakeholders are different, with skills not necessarily tuned to the challenges of Transition Planning - if the Architect's don't do it, with a hoistic view of the needs of the whole enterprise, then the alternative is almost always to leave it to those with vested interests in specific systems that "they" want to see enhanced or implemented.

 The organisational "who does it where?" of Architecture
Architecture is universally more successful when the people involved are "in house".  Can you imagine the implications of outsourcing it?  Giving an external agency authority over your EA?

Which is exactly what a client of mine once did, outsourcing the whole of their "design and architecture" practice to IBM!  Only when they realised... sorry, only when they experienced the implications did they pursuade IBM to sub-contract back in-house their own previous employees as the overarching architecture function.

The geographic "who does it where?" of Architecture
"In house, on shore".  End of story.  Well, not quite - clearly, some of the " filling in" of detail, such as ABB specifications might be more cheaply managed off-shore... But I'm not convinced.  The "who" doing Architecture have to be in-house, on shore, physically as close to their stakeholders as they can be.