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.

Process: on a "Macro" Scale (Architecture)

Process II:  on a Macro Scale 
(by which I mean within the Enterprise's, focused on the creation and maintenance of Architecture for Upstream Transition planning, and Downstream Design guidance and governance)

A good Architecture Team knows that the Architecture is not static.  It needs constant refinement and evolution, to ensure it's the right Architecture for the enterprise.  But what do I mean by "constant"?  technology and industries are changing all the time - does the Architecture need to match these forces "in real time"?  Maybe sometimes, and only when absolutely necessary - imagine what life would be like if your favourite catalogue dropped through your letter box every week or day, with some of your favourite building blocks no longer available, replaced (or not!) by "similar options" - chaos!

No, what is needed is a regular scheduled cycle of review and revision, with changes imposed or elected not only by these external forces, but internal ones too:

• "75% of the project's reviewed in the last year/ 3 months did not conform to this part of the EA".  So where is the fault?  It's probably not the case that 75% of the Architecture's users were being self-centred:  it's more likely the EA was at fault, somehow no longer suiting the enterprise's (or industries!) current direction/approach/business imperatives.
   

• "There's a game-changing technology/legislation/new type of competitor emerging, we need to accommodate it in our Transition Plans!" It's no good sticking with a plan when the context changes!
   

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?

Making IT work ("Process"): managing Design

But what form of approach?  "Waterfall"? "Iterative and Incremental"?  "Agile"?  "Do and fix"?...

My experience tells me none of these, in isolation.  And all of them have value.  But, overall, I'd plumb for a basic approach that blends "Waterfall" with "Iterative and Incremental".

• Part Waterfall, because I need to have a general sense of "Requirements" ahead of "a broadly based start to Design", feeding into more focuses activities leading to a hand off to "Detailed Design"
   
• Part "Iterative and Incremental" because only when I've done some design can I begin to clarify Requirements(*) and begin to work out what I can and cannot deliver - as well as those I have to!
   

(*)  Maybe the best I ever heard from a sponsor was "I don't know what I want, but I'll know when I haven't got it!", closely followed by "how big does it have to be to justify the business case?"

As such, I'd recognize the first phase, immediately following the project's kick-off meeting, as being the "Outline Design" Phase, covering the overarching design of the whole system and during which the "big hitting requirements are flushed out, clarified and agreed.  And, hopefully, this phase confirms the outline design included in the project's proposal!  Under no circumstances would I start with a "Requirements Analysis" Phase! (Do not ask - just remember "analysis paralysis"! (#))

(#)  We do NOT do, in our role as architects, "Requirements Specification".  This is the bailiwick of Business Analysts and others focused on those things that drive the solution "from the outside in" - as architects we need to be very careful in ensuring we look at those requirements "from the inside out".

"Outline Design" gives me the big picture that acts as the backdrop - the reference and co-ordination base point - for more specific "Macro Design" (MD) phases, each focused on a different part of the solution, revisiting requirements at a more accurate and detailed level and revising the design (and revising maybe re-negotiating those requirements too!)

Therefore, and while there is only one Outline Design phase in a project, multiple, pseudo-independent (^) Macro Design phases typically run in parallel (or maybe staggered), delivering the design for "their sub-system" back into the overall design model for hand-off to Detailed Design.

(^)  "Pseudo-independant:  able to work largely independently (because we got the "cohesion/coipling splits right in Outline Design) but towards a common goal, as guided by the overall outline design.


Or maybe Macro Design phases are focused on separate releases of the solution, i.e. they are then more likely to be running in a more serial manner for time-sequenced delivery to Detailed Design, Development and beyond.

Other specialised approaches may be adopted within certain aspects of the design activities, such as

• "Agile" for the Functional Aspect (assuming the operational aspect can tolerate the inevitable lack of focus on Non-functional requirements!)
   
• "Do and fix" for the Operational Aspect when determining the configuration of servers in a novel environment with no performance data to hand (and maybe with changing application performance characteristics. 

Sizing
Each and every one of these phases within a project do of course need to be sized, but not in a quantity surveyor style "add up the bits" sort of way - it needs the (mature) skills and knowledge of a senior project solution designer to do this; ahead of time (pre-sales budgeting and pricing), and during the project (to explain and negotiate the inevitable changes needed... OK, this is 99.9% of the time actually "overrun!").

And in order to maintain credibility whenever revision is needed - whether externally specified changed requirements, or internally generated design alterations or delays - it's a very good idea for the programme architect being the same person who proposed the solution design in the first place!

Process: on a "Micro" scale (Design)

At last, the 6th of my five "P"s!

Why is it 6 of 5?  Because I forgot (or did I consciously ignore?!) it.  And why did I do that? Because I thoroughly dislike "Process"!

Process I: on a "micro" scale
(by which I mean within programmes, focused on the use of Architecture within Design)

Why?  After all, BPM is all the rage, and re-engineering business processes the mantra of the day!  Exactly.  That's my point!  A&D cannot be procedural, there are far to many " if-then-elses", many of which cannot be predicted ahead of time - why else is THE worst question to ask an Architect "have you finished yet?"!

And "but I followed the process!" is a brilliant excuse!

However...

...I do agree adopting a proven "approach and structure" to A&D, in order to facilitate a broadly based (some would say "phase and activity" level) project plan is critical.

But what form of approach?  "Waterfall"? "Iterative and Incremental"?  "Agile"?  "Do and fix"?...    - such as recognizing the first phase needs to be "Outline Design" Phase that covers the overarching design of the whole system, followed by a number pseudo-independent "Macro Design" (MD) phases, each focused on a different part (probably parallel MDs) or release (maybe serial MDs) of the solution, for time-sequenced delivery to development and beyond.

Each of these phases do of course need to be sized, but not in a quantity surveyor style "add up the bits" sort of way - it needs the (mature) skills and knowledge of a senior project solution designer to do this; ahead of time (pre-sales budgeting and pricing), and during the project (to explain and negotiate the inevitable changes needed... OK, this is 99.9% of the time actually "overrun!").  And in order to maintain credibility whenever revision is needed - whether externally specified changed requirements, or internally generated design alterations or delays - it's a very good idea for the programme architect being the same person who proposed the solution design in the first place!

Reflection: sponsorship and reach/range

Sponsorship:  a "plus"
On one (and only one) occasion outside of IBM, I came across an OCA that was sponsored (and monitored!) by the Organization's CEO.  Suffice it to say that organization did not need my help!

Reach and range: a "minus"
On another occasion, I found an otherwise well formed architecture governance structure attempting to operate within the bounds of an Enterprise's Business Unit, clear on their "range" of authority (the scope of things they have an interest in) which happened to be focused on architectural downstream governance of solution design. As such, things worked pretty well for Business and IS Architectures - because the OCA's "reach" (their spread of influence) was within their Business Unit and therefore  adequate (except for anything "shared", which was a nightmare); but sadly they failed to properly influence the IT Architecture of their systems' Infrastructure Designs, given the "IT department's" enterprise wide control (i.e. "reach") and, therefore, enterprise wide authority.

Making IT work ("Power"): must be vested in Governance

I firmly believe that power 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 authority (= power!) - otherwise their "individual, isolationist" senses of Passion and Power will fail to Persuade, and agreements on the resolution of issues will be few and far between.

Making IT work ("Persuasion"): Involvement!

As it happens, the two best examples I've come across of experiential persuasion are "external" and "internal" - both of which I've referred to before:

• The external community - and a torn PostIt(r) note!
  During an outline solution design workshop, I invited the two Business Sponsors' representatives (originally there only as observers of process) to comment on a tricky design choice.  After some hesitation and vague comments, I gave the nearest of them the problematic DU (as a PostIt Note) and asked him to put it on his preferred node (and yes, I used this language (*)).  He was immediately contradicted by his fellow "sponsor", who re-placed it nearer the user.  Whereupon they both tried to grab the PostIt, tore it in two, and put half in each place!  Subsequently, both reps' sponsors joined the Architecture Board...
  
  (In the end it was resolved by "future proofing" the placement to accommodate anticipated requirements of a later phase.  (*) And I do not subscribe to the (once true) view that our sponsors and other non-architect "clients" shy away from technical language when dealing with A&D - they don't do so for the languages of other professions)

• The internal community - "I wrote this!"
  Simply put - Solution Designers creating, and Architects curating the Architecture.  Only when I believe in something will I exploit it - and how better to achieve this level of confidence that to have written it in the first place?  "These are the roles our solution designs will recognize as standard supported roles"  (and, yes, these ABBs are indeed part of the business architecture!)

Power, Persuasion, Passion

I've decided to address these three "P"s together - they are, I believe, strongly inter-related.  If does mean, however, this is another long post!

At their core, these three P's fascinate me.  What is is that drives People within the Political context of their working lives to care about Architecture (up and downstream) and Design, when so much of it is "just plain hard work"?  And, intimately intertwined with this on a very personal level, why am I writing this blog?

Passion
Because I and we believe in it - we are Passionate about it.  We are so sure that the arguments I and others put forward for A&D make it so "obviously" critical to any project's success, whether that project is delivering an IT system, or some other sort of system - from building a ship, to building an organization - that we cannot imagine how others would see it any other way.

Put otherwise, and in a cautionary manner - passion is dangerous!  If left unchecked and allowed free rein it can isolate and alienate those who believe in A&D from those who do not get it - such as I've observed before about Execs and others, some of whom think it's there to hinder rather than help:  imagine how our "blind passion" for A&D may affect them:  "you're here to stop me!" or similar.

Passion needs to be controlled and focused positively as a "contagious" rather than "isolationist" thing.

But how?  The answer lies in this post's name:  "Persuasion" and "Power"

Persuasion
Clearly, we hope our passion is infectious; we are able, simply through impassioned logical reasoning that others will "get it" and "believe"!  Of course this rarely happens (at least in my experience!), and we need to adopt other tactics - we need to Persuade them in a passionate way!

I've found, on almost all occasions, that someone is more likely to be persuaded of A&D's value by  practical experience rather than (just) academic theory.  But - and this is critically important - that practice needs to be of the theory.

Maybe one of my most disliked words is another P: "pragmatic"; not because of it's dictionary definition ("dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations"), but because it is constantly invoked as a mantra for doing it the easy or politically expedient way.  And even when it is properly applied, it still fails to address the need for "professional improvement", never addressing the underlying basic problems A&D are designed (sorry!) to overcome.

Power
But what if "they" still don't "get it" (no Passion), or can't (you'll say refuse to!) be Persuaded?  Then I guess, as a last resort, we need the Power to enforce the Architecture (on designers!) and/or Design (on the project team and its sponsors)...