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!

Reflection: politics and people

"People" is my next topic, so it seems apt to reflect on how it is people who make the politics work - only when it's "us" and not "us and them" can the three governance bodies work together.

And a good way of enabling a feeling of "us" is to mix things around - people I mean.

It is already widely accepted that the CAB needs technical and business experts on (the) board alongside the execa.  This usually means the OCA's Chief Architect sitting "at the right hand" of the CAB's chair (together with the more politically oriented CIO), with selected architects joining the board either on a rotational basis, or from time to time when technical topics crop up.

It is very unlikely a CAB Exec will want to join the OCA, but that's definitely NOT true for a DA's designers, many of whom (in my experience) enjoy being co-opted into the OCA (sometimes for extended periods), providing detailed expertise in a critical topic for which the enterprise needs an enterprise wide solution, sometimes in the form of architectural guidance but often as a Reference Design.

And the reverse is also true - architects can be more comfortable with ambiguity and uncertainty, so may be employed in the early days of a programme to untangle and resolve ill thought through requirements, or some out-of-date aspect of the pre-funding transition plan's outline design.

Making it work ("Politics"): doing "Doing things right"

This second value proposition of architecture has quite a different set of primary stakeholders, with very different challenges. But the underlying needs of Governance and sponsorship remain - without these the architecture (now firmly in the "guidance" domain) still sits on the shelf gathering dust.

"Doing things right" is not so much a question of executive decision making, it's more about "conformance" - given a solution delivery programme/project is up and running (thanks to the enterprise exploiting architecture's other value proposition!), the solution designers are expected to design the solution in accordance with the architecture - using the enterprises ABBs and reference designs to ensure their solution fits in with the wider environment.

But what if it doesn't?  Either by design (sorry!) or accident? And how would anyone know?

Conformance
We need a process, or at least  protocol that ensures the design is reviewed, in exactly the same way and at the same times as the project itself is reviewed as part of Project Management. But of course the conformance review is by the enterprise's architects (not PMs!), working in concert with the project's designers.

What happens when it doesn't conform?  Absolutely nothing without architectural sponsorship.  So the CAB is vital here too... But indirectly!

Imagine taking an architecturally detailed disagreement between the architects and designers to a business exec, and asking them to sit in judgement!

No, what is needed is a second body, this time focused on the architectural content, that we might call "The Office of the Chief Architect" (OCA) sponsored by the CAB and which owns the development and exploitation of the architecture.  Only when the OCA and design team agree to disagree ("we need to be live by Christmas" v "you must use the new infrastructure which goes live next year") does the OCA approach the CAB for a resolution - which will inevitably be business value based.and not " down in the weeds"

There remains one last challenge - how to ensure the solution designers (plural) within a programme or project work together in a coherent way, solving the business problem within the enterprise's architectural constraints?

They need a Design Authority.  A body within the programme/project with the authority to oversee, review and approve the design within the context of the solution's requirements, and to negotiate outwards with the OCA during conformance reviews.

The details of how these three governance bodies work together (when "doing things right ")  beyond this blog, but suffice it to say they only need a limited number of relatively simple processes - two associated with "conformance", two with " vitality ", and one with "communication".

Vitality
What's this about  "vitality"?  Basically, it means is the architecture still the right architecture?   What if loads of projects do not conform?  I don't mean vicariously, I mean on purpose?  What's going on?  Probably the architecture is (or has become) inappropriate.  It no longer serves the needs of the enterprise, and must reviewed and revised.

Reflection: who's in charge of the CAB?

Just as so many CABs are IT centric, so their chairmanship is invariably the CIO...  Which is all well and good if the focus is just IT sponsored investments...

...but it so often presents  a real challenge for a business centric EA, when the CIO may be mis-represented as being IT-biased.  So who chairs a Business/IT CAB?

It depends!

It depends on who sponsors the CAB.  If it's the CEO, and they take an active interest in "planning", then it can be Any CxO who has the right breadth of vision across the enterprise and has " the ear" of the CEO; which of course can include the CIO, or a divisional CxO who's business depends (heavily?) on the rest of the enterprise.

Alternatively, the ultimate sponsorship may not rest so high up the enterprise, in which case one looks to the CFO or COO, not only for sponsorship, but also chairmanship.

Making it work ("Politics") - doing "Do the right things"

The essence of real transition planning is not "good architecture".  It's...

Persuading those execs and budget holders who have "private agendas" to recognise the wider advantages of working in concert with the rest of the enterprise.

As just "a document", a transition plan is nothing more than a linked set (or sets of transition programmes, each with an estimated cost (based on an outline solution design) and benefit, sitting on a shelf somewhere...

So how to convince an exec from one division that their pet project is less critical to the enterprise than one from another division?

Governance.

Is a big topic in today's corporate climate - but usually governance of financial and legal behaviour.  But we're dealing with Architectural Governance, and we should be able to exploit the current focus... if we tackle it right - via a Corporate Architecture Board (whether central, federated, hierarchical or in some other form is a  question deeper than this blog) provides the executive decision making to underpin the EA inspired  "joined up" plan because of it's...

Sponsorship...

And here's the trick - if the CAB is composed of senior sponsoring execs and content-rich architectural advisors, the CAB (or whatever you chose to call it), provides the authority to direct, arbitrate and decide on the execution of the plan.

Why?  Because without sponsorship (and decent operational funding), EA will always loose to a tough battling exec (who will drive "I know what we need to do to get past the 'paper plan' and achieve our personal goals") who will always overcome the otherwise impotent-but-right EAer (whether they're called The Chief Architect or not). So sponsorship has to be...

...of the right kind

The biggest challenge of all.  So many (could it be 99%?) of these CABs are wholely staffed by execs and architects from the IT department, because historically EA has been all about IT.  This might be OK for infrastructure centric transition planning - it's "in the family".  But of course the enterprise's divisions have business centric plans that exploited IT, in ways that suit them... which immediately gives them the upper hand with an IT CAB when they say "what do you know about my business?", and therefore dismiss the IT centric attempts at governance.

Which is why an earlier post on Business Architecture is so vital. There, I discussed how critical it is for EA to embrace BA; but not just as a driver for IT (as discussed there), but as a source of business sponsorship, and therefore presence on the CAB.

Only when the CAB exerts business centric pressure can architecture's influence on enterprise transition planning.

Politics - why bother? No-one listens!

No harm in starting with the most complex "P"!!!

For architecture(*) to have an impact, it needs to influence other disciplines - like project management it has no intrinsic value (yes, unless someone acts on it, it's just so much paper sitting on a shelf...); but unlike PM, people don't get it.

(*) from now on, please read " architecture" as "architecture and design"

"Do without PM?  You're joking!"
"Exploit architecture?  What good is that?"

But who are these people who should know better?  Put otherwise, who are our Stakeholders?  Who should be "buying" the products of our expertise?

There are TWO very different groups, with very different agendas that we need to intercept and often change, in spite of their often more narrowly and selfishly focused, politically (career centric!) inspired perspectives.

And in order to succeed, we need to recognise the need to "sell" in their language; we need to articulate our Value Propositions, i.e. the value they should expect from us; not (as we so often do!) the "features of architecture", expecting them to work out for themselves why this is a good thing - history tells us they never have, and they are unlikely to change.

So who are these two groups of stakeholders, and what are our value propositions to them?  I refer the honourable reader to an earlier post, way back in March called "Architecture also drives change", which discusses

"Upstream EA", guiding executives and senior planners to "do the right things"
"Downstream EA", governing development and deployment, to "do things right"

OK, so much for theory - how can this work in practice? We've not been to good at it in the past... The secret is to recognise that it is indeed the theory which drives successful implementation, but only if supported via sponsorship and governance...

...of both "doing the right things" and "doing things right"...

The Soft Stuff - that's really hard

Enough of the "content", at long last I can focus on the really interesting stuff (to me that is!) - how to make all this content work in the real world of politics, people, power, persuasion, passion... and process; the "human context" of Architecture and Design.

Why is it interesting?  Because years of experience tells me these "soft skill" oriented topics are really really hard to put into practice; people so often talk a good game, but then fail for any number of reasons (that almost always boil down to one) to see it through.

Maybe it's because we Architects tend to be" Logical Thinkers"; and yet so often have to deal with "Tough Battler" executives and managers?  Even more challenging if there's a "Friendly Helper" in the room!

I think I'll take these 5, sorry, 6 "P"s in the order I list them - they're all intertwined anyway.

But before I do, this is not the first time"soft skills" have featured in this blog - previous posts have discussed the power of language (P for "people" - "the power of tribes") and the distinction between "creator" and "curator" (P for "persuasion" - "I'll use what I make"), as well as a significant discussion on architecture's value propositions (P for "politics" - "why should I bother listening to you?").

Reflection: reality v the physical world

Aren't these the same thing?  Isn't the physical world reality?

In the same spirit as non-engineers are happy to interchange "stress" and "strain", then yes they are.   But we're not lay people - we are IT System designers, who recognise a more precise way of observing the world...

• Reality is related to abstraction - how "realistic" is the model you are constructing in order to understand and communicate your ideas about the IT System?  Put otherwise, how much information are you modelling?  More "content" = more "real".
  
  We've already seen this in action - the functional dimension of my box captures less information than the operational dimension - it is more abstract because it ignores (or you may wish to think of it as simplifying) great swathes of detail associated with place - which is no bad thing when you are focused on the cohesion, coupling and encapsulation of your "lumps of function and data".  But on the other side of the box, all of this extra stuff is modelled, because we are now looking deeper into more realistic views of the system's model: operational modelling is more realistic than functional modelling.
  
  Critically, it vital to realise that "the real world" can be modelled either logically (as specifications of what the model elements are required to do) or, with equal validity, physically...

• Because  thinking about the physical world means thinking about actual things, whatever the level of abstraction - in other words, 
• • Physical things can be equally associated with the functional or operational sides of my box; for example, a functional physical thing might be a software package from vendor "TBO" composed of modules A, B and C; whereas an operational physical thing would be a located PC model XYZ from manufacturer ABC running parts A and B of that package.
    
  • Physical things may be at (or span) the application and/or infrastructure levels (a specific version of a vendor's FTP package is infrastructural).
  
  In all events, modelling physical things means making decisions on (or observing previous decisions on) the implementation of a logical specification.  E.g. choosing a broadly based, fully integrated software package TPO for all back office functions is a functional physical decision, or choosing a PC model XYZ from vendor ABC to implement the "Regional Application Server" located node is an operational physical decision. 

Sadly, it is one of the most common mistakes I see made by systems designers - freely interchanging the two concepts of "physical" with "realistic", usually only using the qualifier "physical" to distinguish any and all the views they may create that are not "functional" - if it's not a component view then it must be physical...  As a common mistake it can be extremely disruptive, in two distinct ways

1. Because it represents a switch of thought across two dimensions of my box - a functional systems designer working with logical functional views would expect an operational system designer to create more realistic-physical operational views... and one thing I've learnt as an engineer is "change one thing at a time"!
   
2. Because it completely dismisses (jumps over) the logical operational view (more realistic, not yet physical), which is THE view used to balance and optimise placement decisions, firstly of logical located (application) DUs and secondly the operational functionality needed in the infrastructure to support these placement decisions.

So, in a nutshell, relating these two notions to my box:

• "Reality" is the right side - OM is more "real" than CM, whether thinking logically or physically; application or infrastructure
  
• "Physicality" is the back plane, addressing both functional and operational implementations of logical specifications, at both application and infrastructure levels.

Reflection: it's not just components

The last few entries have focused on components and their DUs (located or not) and the need to recognise the 4th and 5th shortcoming of the Lego analogy for ABBs .   But these are not the only model elements that have "located equivalents" - model elements that are "somewhere"; ABB types such as

• Nodes
  To all intents and purposes, nodes represent the solution's "computing platforms" - but not just its computers; any hardware (probably plus systems software and middleware) that supports "the solution " - printers, routers, terminals, even patch panels and other passive devices.  All these things need to be located (or are locatable) somewhere.
  
  Nodes (and their ABBs) come in two flavours, which means so do Located Nodes:
  
  (1) Application Nodes, composed of usually standard collections of co-located (or locatable!) Located  DUs - application configurations of DUs that work together (in one place), such as those that make up a "Sales Server" Node ABB, which may be deployed into a regional office (which we might call it the Regional Sales Server" Located Node), call centre, or data centre. 
  
  (2) Technical Nodes, composed of standard configurations of systems software and hardware   (and which therefore form part of the system's infrastructure), probably specified by "Operations" as their recommended supported configuration that they expect Systems Designers to used as the basis for their Located Technical Nodes.  For example, Operations may specify an "Application Server" Node ABB, providing the infrastructural specification for a "Regional Application Server" Located Technical Node that provides the necessary services to underpin the "Regional Sales Server" Located application node.
  
  In both cases, the functional specification will be the same (or very similar) across all located nodes (although it may be that not all functionality is exploited in all locations) - differences will most likely be in the non-functional characteristics, such as the transaction volumes on each of the "Regional Sales" Located Nodes being different from that on the "Data Centre Sales" Located Node.

• Actors and Users
  Our system's logical actors and physical users (collectively referred to as external agents) need not be limited to accessing the system from one place, nor in using just one means of access from each place.  Therefore, the functional viewpoint's abstracted view of a "location-less external agent" (which may be based on an Actor ABB or User Implementation of that ABB) must be modelled as one or more located external agents in order to understand and create the more realistic Operational views - sometimes to such a degree that, for a given functional actor or user, one located external agent may transpire to be human (because the system's boundary is a keyboard/Video/Mouse), while another is designed as an external IT system (because the system's boundary is based on HTTP/HTML traffic) - but both based on the same (now ambiguous) specification of the functional external agent.

Placement

OK, so what's the difference between "a sense of place" and "placement"?

A great question, and one we did not know to ask until only a few years ago.  It all comes down to...

...multiplicity

We don't necessarily place a Deployment Unit (DU) just once, in one place.  There may be more than one "instance"(*) of a DU on an operational view - it is placed multiple times.  In fact, experience tells us that if at least some DUs do not appear several times, then the design is at best incomplete, and at worst poor or unworkable.

(*) More accurately, we have more than one "representative instance", since it may be that there are many instances of each place were the DU is deployed.

For example...

• The Data DU associated with a Home Shopping application's "Catalogue" component might be "The Catalogue". Naturally, given its reach (out to the home shopper) and range (all home shoppers), one might decide to deploy it onto (one) central server.  But does this decision ensure good performance or availability for all users?  What if the customer wants to build an order, but their internet connection is down?  The answer may be to keep a copy of the catalogue on each and every customer's workstation.
  
• It may be appropriate to run the "Catalogue" component's Execution DU on several internet servers for some home shoppers (such as those working in a Call Centre, taking orders by phone as a proxy for the real customer) - because communication is sufficiently reliable, available and secure.  But for others - such as each real customer working on their own device, it may be better to run the same code locally; for the same reasons as they have a local copy of the catalogue.

In the first case, we have two instances of the catalogue (master and copy) in two different representative places (possibly called "Regional Data Centre" and "Home"); and the second two (identical?) instances of the catalogue's execution  could be in places "Call Centre" and "Home".

Of course both design decisions can introduce significant and often costly infrastructure design challenges, which in turn means the business benefits of such placement centric design decisions need to be sound.

Other things being equal, then, the functional DU, representing an aspect of a component, has a single specification - if it's a Data DU then we may wish to know its size (records or Gb) and volatility (some measure of frequency of change); whereas for an Execution DU we should be interested in transaction rates or concurrent users.  But these single specifications are abstractions, approximations to the real world - maybe a decision is made to update the copy of the operational DDU less frequently than it changes: so there are now two specifications for the same DU...

In other words, the operational DU is different from the functional DU - both have a sense of place, but only the operational DU has placement - it is somewhere and hence more "real world".  But what to call it?  If we were to call the places in which it is deployed "Locations", then a natural name would be "Located DU", and there's usually (in anything other than the simplest designs) more than one Located DU for each DU.

So the fifth and final shortcoming of the LEGO analogy is...

...IT System ABB based model elements can be in more than one place, but a Lego ABB cannot.

Reflection: do we have to use Components?

No!

It's just that I've been brought up on "Component Modelling" (after the fashion of UML), with the strong belief that the CM approach makes application development and delivery so much more straight forward when the "lumps" are bounded, broadly independent, and focused on doing one or a few things well (encapsulated, loosely coupled and cohesive).

In other words, a component "owns" it's data and functionality, and uses its interfaces (or services!) to get the data and/or functions it does not have from other components (via their interfaces); thereby co-operating with other components in the application to deliver business value.

But we do not have to model in this way.

There was a time when Data Modelling and Functional Decomposition were popular analysis and development techniques for application development - and for the OMer such an approach means the "deployable functional parts" of an IT system are immediately obvious - using matrices and other mechanisms to explore what function needs which data, thereby lending themselves far more naturally to OM.

So in these non-component based cases, the various sorts of "functional lump" can be directly placed in the "operational viewpoint" without any manipulation - a data entity can be placed (and distributed) without confusion, as a Data Deployment Unit (DDU); as can an application (maybe with some negotiation between functional and operational designers if a client-server approach is adopted) as a EDU. Not only this, but also  the functional viewpoint's data/function (CRUD!) matrices directly inform our needs for communication between DUs, and therefore the connectivity needs of the system.  Sounds like OM nirvana!

A Sense of Place

"Where things are" or "where things will be" *is* Operational Modelling - do we put the system's data close to the user, where performance and availability will be good, or do we put it somewhere central, making security and systems management easier?  Once these business driven(!) decisions are made, then (and only then) can the system's infrastructure be designed - for example ensuring distributed data is up to date, or backup and recovery software is implemented.

(Yes, I know I am being idealistic - when was the last time you could choose where to put operational data in order to ensure the right levels of business performance?!)

(This linkage between solving business requirements (by appropriate placement of the application and its data) and the consequential infrastructure systems design is also present in the functional viewpoint, hence the horizontal application/infrastructure split across both left and right hand-sides of my box.)

And it's this sense of place that's the 4th issue with LEGO.  In the analogy, we'd be constructing models from Lego bricks - and of course each brick has to be somewhere.  The whole brick in the same place (unless you decide saw a 4 * 2 in half!).  But things are different with IT Systems...

...because in IT system's design we might think we place components (that may be based on ABBs),  but in fact we do NOT place them "whole"(*) - we make separate placement decisions for the things from which these components are composed:

• Where to store (or where is) the data that each component owns?  Maybe all of it is in one central or distributed database, for all of the system's components?
• Where will (or where are) the components' functions run?  Some might run centrally, others on the user's workstation?   Or might some components be configured as a client-server configuration?
• Where will be (or are) the components' runtime executables stored?  (Their .exe's. .dll's, and so on).  All in one file on the same machine as they run, or as separate files on a file server somewhere else?

All three of these places may of course be different places; and, to cap it all, all may be somewhere completely different from the place where the user accesses the component.  So OM has to model all four places, in order for us to understand the implications of "distribution" - how will the infrastructure connect the execution of a component with its data?  What will the operational characteristics of that distribution be - good enough for the user's required response time, throughput, or security and availability?

So operationally an ABB is not a monolithic thing after all - it may be a cohesive, encapsulated and loosely coupled atomic building block when looked at through one of the functional viewpoints - after all, this togetherness of the four elements is the major abstraction of the functional side of my box; but the moment we bring back in to our thinking the major "real world" issue of place, we need to expose the component's insides - not only does that need Operational Modelling, it also needs us to modify our LEGO analogy for the fourth time, to allow the "atomic ABBs" to be split up into their constituent parts.

Footnote: 
What do we call these "constituent parts" of our components?  What "are" they?  Whatever they are, we need to explicitly model them so that they can appear on Operational Views.  And to model these "units of deployment"  they probably need a (collective) name...  How about "Deployment Unit"?  We'd then be able to model Data Deployment Units (DDUs), Execution Deployment Units (EDUs), Installation Deployment Units (IDUs) and Presentation Deployment Units (PDUs)!

(*) this does not stop many people, often very experienced system designers, claiming they do place components into the "real world".  It's only when you quiz them, hard, that it transpires they mean they place an aspect of the component. Most often, I discover they mean the components' EDUs, but sometimes it's where their IDUs will be...

Operational Modelling - and the last two shortcomings of Lego ABBs

I really want to move on, from the basics of Architecture Thinking to the five Ps (politics, people, power, persuasion, passion); the real "secret sauce" of success in the world of IT System's design, but there's just one loose end to tidy up - the last two (of five) shortcomings of LEGO(r) as an analogy of Architecture Building Blocks.

Both lie full square in the realm of system design, and their use in the "real world" of Operational Modelling (OM).  In fact, I've already hinted at the underlying cause of both when I briefly discussed OM in relation to "infrastructure" - basically it's the difference between "the bottom layer" of my box (infrastructure) and its "right hand side" (OM) that's key to both shortcomings...

...a sense of place,
...and placement.

5. What happens once we've "finished"?

We're "system designers"... and unashamedly I'm putting the emphasis on "system" - we concern ourselves with the whole thing, from the full spectrum of functional and operational requirements through to... what?

While it may be clear we need to worry about "all the things upstream" of us - be they business requirements, architectural guidance and constraints, limitations imposed by the operational environment or project related issues (budget, time, people), where do we stop?  What is "downstream" of us?

As hinted in the last entry, there is a neat but trite answer of "the five Ds" - detailed design, development, deployment, delivery and decommissioning; with direct contact for us of detailed design (but we ignore the other four at our peril!  Have you ever created a system design with a view to decommissioning?  Thought so...)

So what's the difference between "system design" and "detailed design"?  the clue is in our language...

Our "system design engineering language" is composed of what we consider to be atomic things - components, nodes, actors, use cases, locations and so on.  Therefore, the views of our system design model are composed of constructions and interactions between these atomic ideas:  a component interacts with an actor, a node is located in a location, a use case has initiating and supporting actors.

Vitally, what we do not do is look inside these atomic parts (actually we do have a tendency to do so to some degree - see footnote!).  Whatever it's actual size (small such as "authentication" or large like "customer management"), a component is exactly that - a component.

But components do have insides - they have to if they are to "do" stuff (data manipulation), and "own" stuff (data).  While we, as system designers, may decide that a component has a particular interface used to access some particular function offered by the component, we generally do not trouble ourselves about how the component does what it does - it's a black box to us: it's the design of the insides of our "bits" that we hand onto those responsible for detailed design.

This division is not just "custom and practice" (i.e. it's proven to work!), but predicated on a boundary where there is a change in emphasis and often knowledge - rather than our focus on overall "structure and behaviour" of the system; in order for it to be developed and deployed its individual parts (or sub-systems) need to be designed too... and very often with a much higher degree of knowledge about technology, or coding standards, or available resources than we system designers might possess.

I distinguish these two worlds as being our attention to "something of everything" - the whole system model and its views, down to a certain level of detail; and the detailed designer's work on "everything of something" - parts or sub-systems of the whole that need looking inside, to ensure their externally exposed capabilities are realised.  In practical terms, this almost inevitably means there is a need for a suite of tools - one, capable of looking at everything in broad outline (the modelling tool I use to capture the insides of my box), and other specialised tools focused on one particular aspect of the detail, whether that be data modelling or deployment modelling.  But this is no different from other engineering disciplines, in which a CAD tool is integrated with a Finite Element Modelling tool or a tool focused on Computer Aided Manufacturing (CAM).

Footnote:  We can, and do of course "look inside" our atoms - but, typically, only as "lists of content" - just like a real atom, in which we know how many neutrons and protons there are, so we know the functions and data items inside a component. What we choose not to focus on is how these internal parts interact - that's detailed design.

4. How formal do we really have to be?

I'd make a small wager that, by now, you're feeling somewhat punch-drunk...  this is not the easiest of things to grasp and get your head around...  particularly now we've 12 boxlettes!

So what's the essence of all this?  How "accurate" and "precise" do you really need to be?  Well, if this was some form of safety critical system such as a motorway's roadside information system or maybe a bank's business rests on "getting it right", then probably the model and its views have to be as formal as possible:  you don't design and then build a new model of car or a motorway's bridge without proper blueprints.

But there's also plenty of room for informality - sketching ideas for discussion and clarification, often for use with those who are not professional system designers.  These sketches cannot be accurate representations of the model in the box (the lay person would not understand them), but they can convey the essence of its design, enabling design options to be discussed in terms of what the system will then be able to do (or not do), without alienating those you're trying to work with.

But I ask one thing of you.

Please, please, please try to hold onto the viewpoint from which you are creating this sketch.  So often, the moment we abandon "proper modelling" we also abandon the notion of viewpoints.  Please don't - for example:  

• If you are discussing the structure of an application, sketch from the "logical/application/functional" viewpoint - don't confuse matters with additional issues of data distribution (technical/operational) or software product packaging (physical/application).
• If you are discussing the performance or security implications of storing business information locally on a laptop, compared to centrally and requiring connectivity to get at it, make sure your sketch from the "logical/technical/operational" viewpoint - does it even need to refer to the application at all?

This challenge is not helped at all by the fact that, so often, the standard work products we have available for such sketching (might it, perchance, be called the "Solution Design Overview Diagram"?) make no reference whatsoever to the purpose of the sketch, other than "free-format communication"...

3. How do we decide from which viewpoint(s) to manipulate the model, and when?

It's all well and good having a rich, insightful set of ways of thinking about a system's design - whether from the PoV of the requirements it will support or the technical underpinnings needed to make it run.

But when I start, by box is empty.  There is no "system model".  Where to start?

It depends!  There are many starting points, depending on the nature of the challenge we face:

1. Maybe we need to enhance an existing system, in which case we may need to "reverse engineer" our model, based on what we observe in the real world... in which case the favourite entry point might be "physical/technical/operational":  this is the most concrete viewpoint, with hardly any "design information" left out, fully documenting the system's structure in terms of real hardware and software.  This allows us document "everything" in a structured way; before we begin to analyse what we've discovered and documented, thereby creating the more abstract (but usually more interesting) views that help us understand how the system works, and eventually what it actually does in business terms.
2. Or maybe it's a brand new set of business requirements, currently vaguely understood and constantly changing, that's going to be deployed as a new application into an existing IT environment.  In which case we may need to start in TWO places - not only the "logical/requirements/functional" views to tease out exactly what's what, but also the reverse engineering views that will help us understand "the art of the possible".

But, and here's the power of the box at it's most obvious - as these starting-point's views emerge, IMHO it's vital to check what things look like through the other viewpoints... for example in #2 above "if this were to be a requirement, what's the implication on the existing infrastructure?  Let's look at the "logical/technical/operational" views!".  And all this then has an obvious consequence - not only might it be necessary to change the model seen through the original requirements viewpoint, it's almost certainly going to be necessary to change the model through the other viewpoints too... and at the same time!

In other words, the box allows you to step away from the tyranny(!) of process, in which we've historically been made to follow a rigid sequence of activities "to design the system".  Instead, like a real engineer, we can use our own common sense and understanding of the goal (a viable system design) to create a holistic end-to-end model, through whatever viewpoint we need, in order to form the basis of future detailed design, development, deployment, delivery and decommissioning.

FOOTNOTE:  It is beyond this blog to discuss the well understood mechanisms and transformations available to the solution designer as they traverse the box's views from boxlette to boxlette.  Suffice it to say that these techniques are, in principle, no different from those deployed by other engineering disciplines, whether it be the technique for drawing the 3rd view in BS308, or for optimising the path lengths between devices on a circuit board.

2: How do we know what we're aiming at?

"Requirements"!

So far I have not mentioned "requirements" once in this blog; how on earth have I got this far without doing so?!??

In all honesty, I have no idea.  And it was probably a mistake.  Without "requirements" it's really easy to "do things right" - i.e. ensure the design confirms to some architecture, whether it be that of the enterprise or the vendor, but to "do the right things"?  Humph, maybe that's it - my focus on design v architecture diverted me too much...

So... if I have a "system design model" that needs to do the right things, do I have a "requirements model" defining what those things are?  Some would say "yes" - based very much on the notion that a model supports a particular viewpoint (see last entry!).

I say no - we need the model necessary to integrate all the viewpoints we need as system designers, and since requirements are just as important as the system design that satisfies them, the model must enable views from the requirements' viewpoint to be envisioned and drawn alongside the eight design viewpoints.

This then means my box must still contain one joined-up model, but now not only "looked at" from my eight design viewpoints, but also from a (or some!) requirements viewpoint(s).

So where do I put these requirements' viewpoints' "holes" in my box?

On top.

The box's vertical dimension is "application above technical" - so it seems equally natural for "requirements to be above application" - i.e. in the same way as "technical" stuff "satisfies the requirements placed on it from above by "application stuff", so the application satisfies the requirements placed on it from above. It's just that until now there's not been that explicit level above application - now there is, the "requirements level" - and all still inside the box.  (This of course means the "top four" application level design viewpoints need to "look slightly downwards" from their cut outs into the application level.)  And rather than a 2 * 2 * 2 arrangement of boxlettes, it's now 3 * 2 * 2...

What do I see when I look at my model from the requirements' viewpoint?  Indeed, is there just one requirements' viewpoint - it would seem rather stingy given there are eight design viewpoints!  A quick check of the top of the now taller box tells us there are four requirements "boxlettes", each focused on one of the other two dimensions of functional and operational issues from a logical and physical perspective.

Some would say "yes, there's just one requirements viewpoint (from the middle of the top) with four sets of views", others would say "the four sets of requirements views are sufficiently far apart to be modelled as separate requirements viewpoints".  For once, I don't actually have a point of view on this (there's that awful pun again), what I do care about are the views...

...because this has been our Achilles Heel for decades.   Whenever a solution designer, or business analyst, or expert user considers "what should this system do?", they automajically focus on the functional stuff - what the application has to do, and the data it has to do things to.  When asked something related to the operational aspect, such as "how well does it have to do all this?" (*), the answer comes back "I have no idea, but I'll know when I haven't got what I need!"

And all of this pre-supposes the requirements are being described in business terms (i.e. logically), and not physically by someone leaping to the conclusion that "the answer is Package X!"

In other words, only by recognizing the power of the box's dimensions can we hope to create a system that works functionally and operationally, assuming of course we can understand the relationships between the boxlettes...

(*) "how well" - ensuring the system achieves the right levels of things like performance, availability and security

1. How do we manipulate the model?

Through the box's holes! That's why in previous posts I never discussed covering them over with a transparent film(*). So imagine having a set of fine tools, like the ones used by a watch maker or jeweller, to manipulate... what?  Well, of course it depends on whether you have a "proper" CAD modelling tool or not...

(*) A neat trick when drawing a view of of something (used by many famous artists I am told) is to put a transparent sheet between you and it, then tracing what you see onto the sheet. Camera Obscura work the same way, but with lenses and mirrors to project the image onto a table.

Using a proper CAD tool 
(Notice I invariably prefix "tool" with "CAD" - in order to be clear I'm talking about a computer based system modelling program, and not a method centric tool such as a technique or artefact description.)

If like me you have a CAD tool capable of constructing the model "inside the box" and maintaining views of it from all angles, then you can manipulate the model directly - by directly defining and changing its parts as you desire; whether changing their properties or relationships.  The tool then maintains all the views you want of the model, from all viewpoints simultaneously, enabling you to see in (pseudo-)real time the effects of your changes - from any viewpoint, not just the one through which you've changed the model.

Or, and maybe more intuitive for many, you can manipulate one of the CAD tool's views (notated in the standard way defined for the viewpoint), relying on the tool to keep the underlying model's parts in sync with the view's symbols that represent them (because on a view it's the parts' symbols your working with, not the parts themselves!); but not just on the view you are editing, all other views on which symbols representing the edited parts appear.

(But how can a CAD tool do this?   How does it know "the modelling and drawing rules"?  Because it's been programmed with the language and viewpoint notations we've previously been deeply discussing - it "knows" how we think... it's called a metamodel!)

Using Office Productivity Tools
Even though it's anno domini 2014 and CAD has been around since the last century, the vast majority of us still use word processors and presentation editors as our preferred (preferred???) means of documenting our system design models... sorry, views...  (or are they even views?  I'll come back to this later!)

Please do NOT think that this means we should abandon the thinking models I've been discussing page after page in which I put so much emphasis on distinguishing a model from a view of that model - but I do accept it makes using these ideas so much harder, because it's us and not a CAD tool that has to "look though" the view we are drawing or editing to imagine (i.e. model) the "three dimensional" system model that "must"  lie behind the "2D" view.  This can be tough.

But maybe not quite so hard if we recognise the difference between "nearby" and "far away" views.

Notably, "nearby".  All the views we see through one viewpoint are intimately related;  they are "near" each other.  For example, some views may document - i.e. draw symbols representing the static structure between some (few types of) parts, while other views convey the dynamic behaviour between those self same parts.

This "nearby" case is so like my old friend BS308, defining how to draw and inter-relate the three orthogonal views of an engineering assembly: having drawn two views (maybe "plan" and "front elevation"), BS308 made it possible (in theory!) to auto-generate the third view ("side elevation") - which is exactly what CAD tools do!  In much the same way, because of the underlying modelling rules (i.e. the metamodel), if I draw a dynamic view of my system model with symbols showing data flows or messages between the model's parts, I can "automatically" draw the corresponding structure view, showing symbols of the connective model elements needed to carry that data or those messages.

If I then make another dynamic view of some other behaviour of the same set of parts, I can "automatically" edit the overall structure view to accommodate any new or changed symbols representing the connectors this second set of flows require (unlike a proper CAD tool, most/all office tools can't do this of course, so I have to go back and manually make the edits myself... humph!)

And it's this intimacy between a viewpoint's views that naturally leads to the idea of a model lying behind the viewpoint's set of nearby views - and a quite a different model lying behind another, i.e. far away viewpoint. 

Sadly, it's this "far away" isolation between viewpoint specific models that has lead inextricably to different roles being responsible for different (partial system) models, further exacerbating the challenge of ensuring what's in the box is a joined up system design, and not a disjoint set of semi-detached artefacts, grouping nearby views together.  And there's a further challenge - because we fail to understand the difference between a symbol on a view representing part of the model, and the part itself these artefacts inevitably take on names such as "The(sic!) Operational Model", when in fact they are "Views of the System Design Model from the Operation Viewpoint".

Bottom line - if you have to work with semi-detached artefacts documenting views of an underlying system design mode, please please please

1. Recognise the way these artefacts represent views from far away viewpoints, and how the inter-relationship between these viewpoints must influence the broader range of views - whether it be as simple as changing the name of something that appears in multiple viewpoints, or understanding how altering the dynamic behaviour in one viewpoint's view changes a static view in another, make sure your change is reflected in all your artefacts
    
2. Lobby for a proper CAD tool!