Making IT work ("Process"): managing Architecture

So Architecture needs an approach (not, in my vocabulary, a process!) to Change Management, that has a "what?", a "when?" and a "who?" - when and how do we practically maintain the architecture?

The "What" of Process
First, what do we mean by "the architecture"?  It goes without saying the what can (indeed should!) include all the elements of upstream's transition planning as well as downstream's ABBs, all within a  governance framework covering Business, IS and IT Architectures.

But there's more

1. First and foremost, the architecture needs always to be "THE architecture" - under proper version control, not only at the upstream transition plan and downstream catalogue levels, but at the atomic scale too:  individual transition programme specifications and individual ABBs.  Any project beginning to use the architecture needs to know what's what... at today's date.
    
2. But does this mean the architecture applied to a (long running) program has to be something that is "always changing"?  As a disgruntled programme architect may say:  "They're always moving the goalposts!"?  Well, maybe. Maybe because there's a new piece of legislation being enforced "soon".  But such on-the-fly changes are not, in my experience, often very successful!
   
   It is far more sensible, if at all possible, for the programme to remain conformant to the architecture they began with (maybe last year's architecture), confident that conformance reviews will "understand", and only insist on "this year's model" when they absolutely have to.  Of course this then means there are now two concurrently published, valid architectures.
    
3. How might programmes future proof themselves?  What if there is a new piece of legislation coming in next year?  Or maybe a current technology is planned to be sunset sometime in the future?
   
   The answer lies in the Architects publishing an "early draft" of next year's model - probably linked to an "invitation to comment" from the solution design community.  In other words, there's now three architecture's available for use (assuming a conformance review can approve an ABB from next year's architecture!)
    
4. And the Architect's themselves may have "unpublishable" ABBs and plans (still work-in-progress or with some form of "need to know" confidentiality), which implies maintaining a fourth architecture, kept separately from the previous three!
    

In fact, I've seen clients who co-ordinate FIVE separate versions of their architecture, with the fifth being the architecture prior to the last architecture, provided to support very long running programmes, albeit with specific provisos and lets to ensure continuing maintainability based on the Operations Department's support for "old" product and design standards.

The "when?" of Process
(Ignoring the "now" imperatives that may inevitably cause a revision "today") how often should the the architecture change?  There's no optimum, forces for change versus those hoping for stability have to find some form of compromise, and this can be very sensitive to external influences; maybe an industry has a high rate of change, meaning scheduled revisions need to be more frequent, compared to a more stable industry where change can be less so.

But full "promotion" of the (previously reviewed!) "draft" architecture tends to be an annual affair, with the others shifting to the next position in the "stack".  In addition, it is common to have quarterly partial updates, of those things "particularly troublesome" with the architecture.

The "who?" of Process
Of course, such a structure demands strong tri-partite governance, with standard mechanisms in place to "promote" either partial mid-term updates, or a full "shuffle up" of the four (or five!) architectures.  And now I find myself copying and editing from the "Power" strand:

I firmly believe that authority for Architecture Change Management needs to be vested in each of the three governance bodies - the Architecture Board (AB, from the CEO or other senior CXO), the Office of the Chief Architect (OCA, from the AB) and the Project's Design Authority (DA, from the Project's Sponsors).  Of course, all three bodies need to exist and be fully functional, i.e. respecting each others' needs to keep things as stable as possible (because change is hard) - otherwise their "individual, isolationist" senses of "my way" will make the resolution of issues few and far between.