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)...

Reflection: Remember this is Business and IT!

I fear I've subliminally focused on IT centric thoughts these last few posts... Which is quite wrong!  Everything I've said applies as equally to Business Architecture as it does IT Architecture:

• "Standard Actors" may be IT, but they have to be grounded in Business Architecture's "Standard Roles", whether they be roles in the business or roles in IT.
   
• A reference IT design might be to do with data distribution; but there is equal need for reference Business Process Models or Entity Relationship Diagrams. And only when the BA's data models and process models are understood, particularly their non-functional characteristics, can IT focused design decisions be made on data placement in the first place!

I know there are some who, while enthusiastically advocating the need for both, describe it as "Enterprise Architecture supporting Business Architecture", implying EA is wholly focused on IT. While there may be a historic truth in that - that EA was a wholly IT centric thing - you have to go back quite a few years to find that narrower view.  Today, EA "is" an integrated blend of IT and Business concerns and considerations.

Making it work ("People"): Teams

"You is not singular - it's plural!"

It's probably pretty obvious by now that Architecture and Design are not things to be tackled on your own, whether it be a need for such a broad range of skills and knowledge, or the value brought by checks and balances of design reviews and architecture conformance -there is such a spread of capabilities in the roles of Architects and Designers that, even if it were sensible to do a design or architecture alone the probability of falling into a hole is horribly high.

But there is a dimension to  "teams" that is very close to my heart...

Mentoring
and the transfer of experience and capabilities from the industries "elders" to their junior colleagues in the work place (as much as the classroom).  Trouble is, it just doesn't happen.

Why?

Because today the pressures to "just do it" are so great, budgets are so tight, and the rate of change scary; that people don't have time to coach and guide - in fact the best of us struggle to just keep up with new "fashions" and marketing messages(*), we seem to spend all our time working out how to exploit the next great idea.

As a consequence, as each generation succeeds the previous one, all we seem to do is constantly repeat the errors of history ... for example, the expertise captured in IBM's early infrastructure design method (distilling the early experiences of distributed systems design in 1993) is still (sadly!) state of the art, and yet is so often ignored (maybe it's simply not known) by today's designers.

Why?

(And this is controversial) because we seem to be the only industry where architects and designers report to the project manager.  In all other industries the project manager ensures the delivery of the design created by the design team.  In our case, it's more "have you (the designer) finished yet?"!  If only authority... and I mean authority in the Design Authority was more widely recognised as the heart of a good solution program!


(*) I refer to our industry as a "fashion" industry, where marketing "fresh new ideas" on how to "do IT" seems to be a constant compelling force.  But how new is new?  How different is the underlying technology of IT?  It's always been about exploiting processors (execution), memory and disks (information) and I/O (communication).  Even "new" design styles such as cloud are not that different from the bureau services I remember from the 1980s...  We should be able to work it out, building from "fashion" to "fashion", rather than it all starting over he moment a new buzz word emerges.

The trouble is, we can't, we're not "allowed" to, there's no time...  And this is the root cause of our failure to successfully pass on our skills to the next generation - put simply the real fashion industry as a whole "knows how to sew a seam".  In other words, the clothing industry as a whole understands the basics of dress making; there is no differentiation between enterprises at that level.  We, though, do not have an industry wide understanding of how to successfully design IT systems - why else are there so many news headlines of yet another failure?

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.

Reflection: is this really how it is?

By now, many of you will be thinking, maybe even saying "yeh, right, in your/my dreams!"  and "Ian's describing a utopia, that cannot exist in this real world!"

Well, funnily enough, it's a rare sight in my world, too.

But that's because my experiences have largely been with dis-functional "Architecture and Design" departments, looking for guidance and help to "make it work"- and all of my "Making it Work" posts are based on practical, first hand experience with these clients, that I have seen work, that have transformed (or at least improved) the effectiveness of the team (or teams).

For example, the "three body" Architecture Governance structure is missing - usually one of the three bodies is not present.

• whether it be the Architecture Board (AB), meaning that the Office of the Chief Architect (OCA) has no "teeth"
• or the OCA is not there, which means the AB has a confused and frustrating relationship with the Program's Design Authority (DA) - basically they do not speak the same language, nor have the same set of issues; 
• or there's no DA, which means the AB and OCA have no-one "in authority" within the program to work with.

All those capable and competent "Architecture and Design" departments have not needed my (or my IBM colleagues) help, so I've seen them rarely.  But they DO exist - there's plenty of evidence in the literature, conferences  and on-line reviews to prove the point.

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.
  

Making it work ("People"): Context (Solution Design, part I)

It's all well and good knowing "what" to do, and "how" to do it, and I've discussed at length the need for us to understand "why".  The previous posts on "Politics" and "Role" pretty much addressed "who", but what about the other two "W"s immortalized in Kipling's "Just So" stories - "when" and "where"?

Let's discuss these first in terms of Solution Design ("when" and "where"), and then in a subsequent entry Architecture:

"When" Solution Design
Design (and Architecture), just like Mark 14:7, should always be with us; from before the first inkling of the need for an IT based solution to a business challenge, to change requests and alterations made to a system many years after its implementation.

But it is vital to recognise the degree of effort - by which I mean the time and money put into the detail, accuracy and completeness of a design will vary enormously from one end of that cyclical timeline to the other:

• In the beginning, probably well before formal funding is available, all that may be needed to verify the viability of something new are sketches and outline, natural language based descriptions of requirements and their corresponding solution(s).
  
  As such, the people most likely to focus on a solution's design at this early stage are the enterprise's architects in the role of designers, instinctively using "their" EA.

 

• Obtaining funding will probably require a more complete design, albeit one that cannot be as detailed or as accurate as will eventually be needed for development - but it must be good enough not only to convince the "upstream" stakeholders of the design's viability and (probably) the manner of it's development /deployment whether via phases, or (sub-)projects, or some other means of chunking a large complex programme.  
  
  Who's most able to fulfill this role?  IMHO, this depends strongly on the final W, "where":  it may be the case that this stage is done "in house", by the enterprise's architects " completing their EA/ABB inspired sketches; but deciding to use an outside agency, maybe with a view to them taking on the subsequent program/project, means it's more likely to be designers, with a more complex relationshop to the enterprise's EA.  Either way, this forms the basis of...

 

• Outline programmetheoject Solution Design is likely to be the heart of any programme's or project's first phase, and as such, it will probably need to keep the "completeness" theme going with the intention of identifying (or confirming) a number of highly cohesive, loosely coupled projects/sub-projects that can "safely proceed" under the design guidance provided by this complete /outline design, while being confident of their pseudo-independence from fellow projects/sub projects.
  
  Almost always, the people for this stage are battle-hardened solution designers - intent on putting (rarely maintaining) their mark on the program.  And my "rarely" indicates an anti- pattern: change the team between proposal and delivery!  So much better to keep the forces of change to the direct solution requirements, and not meddle with the design based on a new broom's wxperiencw.  But, as I have posted before, there's also a strong case for the direct involvement of EAers, and not only if they were the authors of the previous stage

• More detailed project/sub-project Design, focusing in on the (sub-)project's narrower scope, and as a consequence going to a lower level of detail, and a far greater confidence in the design's accuracy and suitability to the (now detailed!) requirements.
  
  Undoubtedly, the person whose bailiwick this is, is the solution designer, ably supported by the architect's reference designs and "wonderfully detailed" ABBs and their preferred implementations!

As a side thought, not directly related to "people" but none-the-less vitaly important is how "deep/detailed/complete" must the design be for each of these contexts?  I have no idea.  Well, of course I do in any given situation - what I cannot do is give you firm/confident indicators - except:

• Early on, things are probably more easily described in "free format" sketches rather than formal views - hence an office automation tool is probably more attractive than a proper CAD tool.  But history tells us this is a dreadful anti-pattern, because "once in PPT/Open Office, always in PPT/Open Office". 
  
  But it is also the case that "things" are far more readily defined than "relationships between things" - as proved by our ability to identify ABBs as candidate building blocks before any structure is formed,and to construct lists of preferred software.  Critically, CAD tools are generally really good at maintaining "thing integrity" while allowing "free format" relationships between things, on sketches such as "Architecture Overview" and "Current IT" diagrams - in other words, use CAD tools from the Get Go!

• Towards the end, there is a limit beyond which we do not go:  the insides of our model's elements.  A node or component is - must be respected as - a black box - it'a atomic.  We do not look inside, nor do any internal design work - that is the bailiwick of the detailed design professional. probably far more versed in technology limitations and exploitations that fits them better to this work - in other words, use CAD tools that focus on "something of everything" (limited depth but full scope/breadth), not specialist tools that do "everything of something" (deep depth on a narrow scope, be that "requirements", or "s/w design")!

OK - those of you who've followed me from (near) the beginning will know that's not true - we DO look inside nodes and components (and other model elements), because we list the key things in the insides - methods and data items "inside"(*) a component, or DUs "inside" a node.  What we do not do is describe how a method is accessed via an interface to manipulate data items, responding via a (different?) interface back to the requester.

(*) it's a little inaccurate to describe DUs as being "inside" a node or Methods "inside" a component - rather, a component or node "is" the aggregation of its parts, rather than being something greater than the sum if its parts.

"Where" Solution Design
The subject of my next post!

Reflection: roles and careers

Clearly how "good" one is in a job using the capabilities defined in the job's role(s) determines one's professional and therefore career position, but - and this is key - it can also determine one's profession.

Sometimes, the career profile of a role/job shows a steady, balanced progression, across many capabilities both hard (technical) and soft (people) and it is therefore quite reasonable to enter that profession "early" and look forward to a smooth(!) journey up the ranks.

I think Project Management has this profile - while senior project execs clearly need superbly honed interpersonal skills, they are "more of the same" being demonstrated daily by their team.  And their technical(*) skills show similar profiles.

(*) remember "technical" is not the same as "technological": the ability to create and use a Gantt chart is just as technical as creating and using a component structure view.

Is architecture the same?  I'm not sure... I don't think so.  Why?  Because of one factor: knowledge.  By which I mean the underlying knowledge of the industry (business architecture) and/or application (IS) and infrastructure technologies (IT) upon which an architect applies their technical and people skills.

Sometimes this knowledge has to be bang up to date, but (and this may be debatable!), may be more focused on " first principles", learnt many years ago when technologies were quite different - or so many think!

Either way, there feels like there needs to be a pre-req role to that of the architect - as a technical specialist, such as "Business Analyst" or "Detailed Designer" roles which have a high " knowledge index", enabling the practitioner to cut their teeth on the detail, before switching to a role that takes them away from this "everything of something" world to the world of architecture's "something of everything".

All of which begs three further points:

1. It is likely IT and Business Architects enter the profession later than their peers in other professions such as Project Management and Consulting, probably simultaneoulsy switching from another more technology focused job.
2. There is no fundamental reason why a technical specialist would want to switch to architecture - in fact it's probably the case that many (if not most?) people in technology-centric roles/jobs remain in them for their full careers - why not?
3. It is perfectly possible to enter the architect profession early, so long as provision is made for "knowledge", maybe via assignments into other roles: the key is not to confuse an architectural "technically content rich" role with the softer-skilled consulting profession!

Making it work ("People"): what's in a role?

Role is different from job.

• The notion of "role" is to organize sets of skills and abilities into coherent and valuable descriptions of an individual's capability.
• A "job" describes what that individual is expected to do - sometimes disconnected from the role they are capable of satisfying!
• A "job title" is an attempt to characterize the combination of "jobs" one person can do, at a certain level of maturity or seniority.

Joking apart (was I joking?), clearly the role has to be capable of doing the job, and indeed may define what's needed for many different jobs - whether these job's form part of a job title. And of course a job may require the incumbent to fulfill several different roles.

Confuse the three, and you have a nightmare.  Particularly if your professional qualification is unfortunately "job title based"!

For example, while at the moment I am generally lumping "Architect" and Designer" together (hitherto fore, without distinguishing these as labels for role, job or job title!  In this entry, I mean...), the role of architect demands different skills to that of designer - something I highlighted in an earlier posting where I discussed how an architect may be more comfortable with the job of "lead designer" early in a project than a designer (oh boy - similar names for role and job!!), given the job's higher levels of ambiguity and uncertainty.

These distinctions of roles within our "profession" is critical if we are to succeed - each role may be honed to fit a particular standard job, but each and every one is built on a single core set of "hard" and "soft" skills that every architect and designer must have.  Here is not the place to go into detail, but a few key capabilities in that core can be listed as "the ability to..."

• Speak several languages, from Consultant to Cobol
• Predict the winner of next years Superbowl/FA Cup final
• Know when "yes of course!" means "I've no idea!"
• Keep your head when everyone else has lost theirs.

Clearly intended to be a light hearted list, but undoubtedly with grains of truth for the roles' soft skills.  the core role's "hard skills" fall into two categories, both of which are needed by all roles: those associated with Architecture, and those of Design - yes, a designer needs to understand and be able to contribute to architecture work, and ditto an architect and design.

Additional capabilities are then needed depending on specialism - on a general level, an enterprise architect speaks the same language as a solution designer, but uses it is very different ways.  More specifically, a designer (or architect) may specialize (performance, security, systems management, data), or remain more generally focused on a level (business, application, infrastructure).

These mixes of capabilities define the skills needed in the jobs of a Chief Architect through to those of a junior data modeller - which prompts another thought: roles and careers...

People - who's that then?

You!

And you're brilliant.

In my opinion, you have to be, to be a good architect(*) - I believe the role of architect, be that specialised to IT, Business, Solution, Performance, Enterprise or whatever, is one of the hardest roles - if not the hardest in the industry.

(*) remember I am using "Architect to cover both "Architect" and "Solution Designer".

Of course I would say that wouldn't I... but think about it:

How different could our two sets of stakeholders be?!  Commercially driven Business execs to the left; deeply technical, technologically savvy detailed design specialists to the right - each expecting us to speak "their language" as we understand and help them solve their widely differing challenges - while we try to be effective and efficient between ourselves in our various roles endeavouring to communicate our architectures and designs clearly and unambiguously. 

How complex is our subject?  Could it be any more complex?!

• You need the technical skills to explain (formally or informally) some of the most challenging types of architecture and design I know: the challenge of IT systems is that so much is virtual and intangible - can you see software?  And we can only imagine data flows - the airflow through an aero-engine's compressor, combustion chamber and turbine is far more tangible.. seen and heard!
   
• How many dimensions do we need to get our heads around?  As far as I can tell, this blog is over 19,000 words long - and I'm not finished yet; and I'm only scratching the surface of...

• Enterprise and solution/system level thinking, for both architecture and design,
• The Architecture/Design of Business as much as IT (and their complex interlock),
• The cube's multiple thinking model viewpoints,
• The non-functional ("goodness") needs of a system, as well as its functional behaviour ("stuff done", whether done well or not).
   
• And to cap it all, the highest levels of inter-personal soft skills, which I suspect can often be more challenging for us - certainly on many occassions more important than our technical expertise!

In other words, you are amazing!  Which is why the qualifications available today as an IS architect are so "Professional", and why architects tend to be older... sorry, more experienced than some other roles within our industry.

But one critical thing is still missing - "you" is not singular - it's plural!!
 

Which means I have  three "People" topics to discuss...

• The role(s) of Architects
•  The context(s) of our work
• Working in Teams
  

Yes there are!

Or should that be "yes there is!"?

Either way, I am delighted to have had a good (private email) response to my question, matching the tone and enthusiasm of my two " public" commentators.  And a potential expansion of my reader base via a few offers of publicity is an added bonus!

So on with "People"...

Is there anybody out there? (*)

Having reached "people", something has struck me - is anyone reading this?

I get great pleasure in writing this blog, but I'm really not sure its ended up being the right medium.  If there are only a few of you, I think I'd rather email these thoughts directly.

So

If you know me, you'll have my email id - a quick " carry on!" would be appreciated; if you don't have my email id, bite the bullet and post a simple comment!   Please!

(*) Apologies to Pink Floyd

Reflection: politics and engagements

My good friend Harjinder makes some excellent points in his comment to my post on politics and people, not least of which is he points out the challenges of a supplier "doing the right things right" (ie architecture) when engaged by an enterprise to design and deliver a new or enhanced IT based business system.

Almost all of this blog has ignored this dynamic; assuming the context was "the enterprise" and its architects.  Adding in the "supplier" dimension adds a whole new challenge when the enterprise's architecture governance processes are broken or missing (which is the underlying cause of the symptoms Harjinder documents).

And there's a further complication even if there is good architecture on the client enterprise - whose reference designs will the supplier want to use?  Their own (which they know well and can be confident in), or those of the client which may include "foreign" building blocks?   A particular challenge if the supplier is focused on development and deployment,  and not subsequent delivery and change!