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.