Addressing a City’s Challenges

The Met’s Digital Policing Strategy is a fine response to the challenges of a large, cosmopolitan city in the not so new millennium.  You can access the strategy via the link below but here are a few highlights.

  • Use technology to widen and deepen engagement with citizens, making use of digital channels and generating open data to improve transparency.
  • Really leverage data to develop a better understanding of citizens, communities and the factors impacting on their safety (and their perceptions of safety).
  • Integrate with partner processes and systems to improve the efficiency and effectiveness of collaboration and, hence, improve end-to-end service delivery.
  • Equip staff (particularly those on the front line) with ability enhancing technology so that they really can do more without increasing the risks to their safety or health.
  • Industrialise the gathering, classification and retention of digital evidence allowing this valuable content to provide actionable intelligence.
  • Consolidate incident, case, capability and asset data so that staff can access the service’s acquired knowledge more easily and operate more effectively.
  • The best services are customer centric and similarly modern policing needs to be citizen centric; utilising technology to provide a single person view.

Digital Policing at the Met

 

A User Experience Journey

It started as a task to understand how Android works and see what user experience (UX) opportunities it offered.  Soon realised I’d have to learn Java which was going to turn my short exercise into a longer trial – ho hum.

We’ll, it turns out that the designers of Eclipse really do understand UX.  My background in Prolog, Basic, C and Pascal meant I had the fundamentals for Java, but context help provided in the Eclipse IDE made me very productive, very quickly.  Mmm… I could learn from Eclipse.

Rather than producing my n’tieth “hello world”, I wanted to develop something that needed mobility and would benefit from a tablet form factor.  Through circumstance and coincidence, I opted for volleyball stats.  At the time, the established software for collecting stats needed three pairs of analysts; one pair for each team and a backup pair.  Surely, my Android app and me could do better than that.

Volleyball AttackVolleyball, in its indoor incarnation, is played by two opposing teams of 6 players who try to ground the ball in the opponent’s 9m square court.  In the way is a net raised to 2.24m for women and 2.43m for men.  Each team can touch the ball three times before it has to cross the net so teams typically use specialists players to prepare (touches 1 & 2) for the best possible attack (touch 3).  The average rally takes 5 seconds which typically involves a serve from one team followed by three touches by their opponents.  This means our analysts have just over a second to record details of each “touch”.

The established software also needed users to learn a set of codes so learning curve was extensive.  I would produce a solution that was easy to learn and easy to use.  I talked to some of my club’s coaches about stats and to one of the national programme analysts.  As well as playing, I watched games and visioned actually recording stats myself.  The concept was hatched.

I’d use the tablet’s touch interface to echo each player’s touch of the ball, indicating whether their contact was positive, negative or neutral.  No complex codes.  To make it easier for analysts, I’d also provide a visual layout of the court so that their actions could mirror the ball’s flight during a point.  Finally, given that we’d be building up such a detailed picture of the game, we could feed this back to the analysts – they’d have their own live scoreboard.

Fast forward through the coding, unit testing and system testing to a test, on my laptop, at an actual game.  I knew that volleyball was quick but I was a little taken aback.  Moving the mouse and clicking in the right place were a struggle but hopefully the directness of a touch interface would be easier.  The bigger challenge was watching the game and re-orienting to the app, multiple times in a few seconds.  I had to accept that it probably needed a spotter (to watch the game) and a recorder (to capture what the spotter told them). Disappointing; but 2 down from 6 wasn’t bad.

The next milestone was testing with an actual tablet.  Much easier to work with than a laptop and mouse but still a challenge.  I did ponder restricting the app to only produce stats for one team but rejected this change as it didn’t take account of skill improvement over time and would deny those with faster brains and fingers.  I did, however, allow for analysts to collect for both teams or just one – their choice.

So, maybe two analysts, maybe four but easier to learn and a richer more informative environment.  Added some utilities (eg sharing) and did a little hardening so good for beta.

Why is it an example of good UX?

  • Stats SoftwareRich, informative environment (eg scoreboard) helps memorability.
  • Information is grouped logically and some is presented visually (eg substitutions). This helps learning.
  • Visuals and positioning (eg court layout) are used extensively for communication and control so the app is easy to use.

 

Human Cognition & Experience Design

To improve people’s experience of technology, we need to understand the point where people “touch” technology – the user interface.  To understand the user interface, we need to understand how people think and communicate.  This is human cognition.

Cognition covers the processes and structures (eg images & words) of mental operation and can be thought of (see what I did there) in terms of the following elements:

  • Memory – the way we store useful information
  • Vision – the key perceptual system through which we learn about the world around us
  • Attention – the way we direct our perceptual systems when dealing with several sources of information
  • Language – the way we refine the information we hold
  • Skills – our ability to interact with our environment

We’ll look at each of these in turn.

Memory
Neural PathwaysOur experiences (captured as memories) form the basis of our capacity to plan, make sense of what’s going on and imagine alternative actions.  Given the mass of information with which our digital world bombards us, recalling a specific piece of information can be difficult.  The way we improve access to specific items is by coding them and the more codes we allocate to an item, the greater the likelihood of retrieval (document tagging takes this approach).  Our challenge is that retrieval can be unreliable (there are insufficient cues to allow retrieval), affected by interference (the information available through processing does not match stored information), over-stimulated (there are too many entries with similar cues) and can decay.

Memory is affected by the situation and context in which it is constructed.   If we’re unfortunate enough to witness a car accident, we’ll often remember the most minute details – flashbulb memory.  We also have strong recollections of details that are associated with major events in our lives – episodic memory.

Vision
Shanghai TowerVision shows us what things look like, how they’re structured and where they are. When a scene is viewed, the eyes rapidly move from one element to another in a jerky fashion.  These movements are called saccades and at their end, the eyes rest and fixate on one point.  Saccadic movement gives structure and texture helping us to derive greater meaning.  The Gibsonian principle (JJ Gibson, 1979) covers such texture and is the theory behind the narrowing gaps between lines approaching roundabouts that prompt us to slow down.

Gestalt discovered that we perceive the whole before we perceive the parts.  This explains why we will generally read mis-spellings such as “cimena” correctly without realising.

Attention
Hazard WarningAttention is the way we direct our perceptual system to selectively focus on particular items of information in the face of several sources.  Arousal describes an ad-hoc event that stimulates the allocation of our cognitive resources – looking at someone when they call our name.  Studies have found that we experience difficulties when performing multiple activities; we’re overloading a particular cognitive resource (eg listening to two conversations at once).  If, however, we can use different cognitive resources for the competing activities, we’re more likely to cope; consider listening to the radio and emailing colleagues as we commute to work.

Language
Hello around the WorldLanguage is not only a means of expressing thought (communication) but also influences our perception of the world.  According to Sapir-Whorf, our experience of the world is enriched by the variety of the language used to describe it – Eskimos have a richer experience of snow than that of us in the West – you can ask Kate Bush why.

Let’s deconstruct language to understand it’s cognitive significance.  Semantics refer to the contextual meaning of words, rather than the dictionary meaning.  Semantically, “dead” has a different meaning when prefixing “good”.  The order in which words are applied (their syntax) can be significant.  Consider the following two sentences, each containing the same words, but in differing order; “imagine there’s no heaven” vs “there’s no heaven, imagine”.  Pragmatics reflect the influence of situation.  The words “What’s the problem?” from a nurse to a patient carry a very different meaning when they are from a driver who’s just taken your parking space.

Skills
Everyday tasks such as holding a conversation, playing chess and dancing are abilities that we learn and develop over time.  Cognitive skills (such as playing chess) rely on the use of declarative knowledge (knowledge of “what” is required).  Sensory-motor skills (like dancing) require procedural knowledge (knowledge of “how” to do something).

Developing procedural knowledge involves practice; repetition tunes our neural network.  When we practice, we organise clumps of information to support the task and then execute in sequences of clumps.  Knowledge of results goes a long way to helping develop skills.  Feedback can be intrinsic (spiking a volleyball gives immediate kinaesthetic feedback) or extrinsic (we’ll know how well we threw a dart if it hits the bullseye).

In Categories of Human Learning, Fitts identifies three stages of skill acquisition.  In the Cognitive Phase there is intense concentration and focus, aiding learning.  During the Associative Phase, parts of the skill are tried out with the appropriate actions and elements being assembled into an easy to remember packages.  During the Autonomous Phase, the skill has become second nature, requiring little conscious intervention.  Under pressure, however, autonomous skills may break down, reverting back to the Cognitive Phase.

So…

  • If our initial interactions with particular technology are rich, enjoyable experiences we will better remember how to use the technology.
  • Our ability to understand and learn how to use particular technology is improved if the information it conveys is sensibly grouped.
  • The more irrelevant distractions we encounter using technology, the more difficult we’ll find it to use, regardless of our experience skill level.
  • Simple patterns and symbols can communicate information to us quickly making the technology easy to use.
  • We can better absorb a mass of information if the technology communicates with us via different senses and methods.
  • Technology that utilises our cognitive skills will be easier to learn if it helps us to organise and remember information.
  • Technology that uses our sensory & motor skills will be easier to use if it provides opportunities for us to practice without worry.

Just Enough Automation

Automation seems to go through three stages of maturity.  At stage one, we identify something as being a real pain, cumbersome, a hassle, error-prone.  In response, we decide to throw technology at it (stage two) but often too much technology; so the result is inflexible and unsophisticated.  Stage three brings enlightenment; we scale back technology but still take pain out of the job without relinquishing control to the dreaded automaton.

Paddle ShiftThese three stages appear in the refinement of vehicle gearing systems.  Manual gearboxes are cumbersome and a pain in traffic (stage #1).  Automatic gearboxes take all the pain away but also take away the control (stage #2) – it’s a bit rubbish if the car kicks down on the motorway when all you want to do is slowly accelerate.  The next shift (excuse the pun) in transmission systems (sensonic, steptronic, tiptronic) allows drivers to decide when to change gears but removes the whole clutch nonsense.   Great for Lewis and his F1 buddies but do we really need all that paddle activity?  We thought we’d reached stage #3 but in reality, we’re back at stage #1.  Today, I think we’ve got the balance  right, true stage #3.  The car decides when to change gears (no clutch, no paddles) but we can shift down or shift up if we want to do something particular.  When the car senses that we’ve finished “active driving”, it quietly assumes control of the gearing decisions again.  Automation has taken away the tiresome bits but we can assume the right level of control when we want.

The official report of flight AF447, lost en route from Rio to Paris, illustrates another pitfall. I will tread carefully here given the tragic loss of life and I will be clear that I cannot summarise in a few lines what aviation experts needed over 224 pages to capture.  The report concluded that the accident resulted from a…

“Temporary inconsistency between the measured airspeeds, likely following the obstruction of the Pitot probes by ice crystals that led in particular to autopilot disconnection and a reconfiguration to alternate law.”

… followed by a number of incorrect pilot actions.  Alternate Law refers to the situation where fly-by-wire Airbus craft reconfigure to remove the normal protections that prevent pilots from performing actions that would endanger the craft.

Pilots are trained to safely fly their craft during Normal Law and Alternate Law.  In the 4 minutes and 23 seconds between autopilot disconnect and impact, the three flight crew had to assimilate conflicting information provided by flight information systems, assume control and handle the emergency with a craft that was responding in an atypical (but trained for) manner.  One could compare this to one’s taxi driver saying “Don’t know why the car is accelerating and the steering isn’t working properly, you drive… and don’t hit that wall that we’re fast approaching.”

Robot AIOur lesson here concerns the ability of humans to effectively take control. With my new paddle shift gearbox, the situation is one in which I decide when to take control having been steering, accelerating and actively sensing road conditions. If I’ve been completely disengaged from driving and the vehicle forces me to take control, my ability to do so safely may be limited.

So; what is Just Enough Automation when the challenge is autonomous vehicles?

What’s Wrong with UK Healthcare?

According to the June 2016 Britain Thinks survey (commissioned by the BMA), 37% were dissatisfied with the running of the NHS (up from 21% the year before) and 53% expected it to get worse.  In contrast, the 2014 report from US research foundation the Commonwealth Fund, found England’s NHS to be the world’s second cheapest major healthcare system while scoring top in six out of nine measures (effective care, safe care, coordinated care, patient centred care, cost related problems, efficiency). The report (Mirror, Mirror on the Wall) compared healthcare provision across eleven of the leading, western nations in a study of healthcare outcomes.  The NHS clearly isn’t failing but there’s no room for complacency.

Consider Leon’s experience when he was suffering from chest pains and shortness of breath.

MonitoringFirstly, Leon called NHS 111.  The call handling agent was unable to do much more than take details (1st explanation) and referred to a clinical colleague.  The out-of-hours clinician that called Leon back (booked by the 111 agent) carried out a triage covering the same ground (2nd explanation) as had been covered on the original call.  Concerned, the out-of-hours clinician referred Leon back to 111 who made a booking into an extended hours hub (a product of the 2015 GP Access Fund).  After a one hour wait, Leon was able to see a doctor at [coincidentally] his home practice.  The extended hours clinician did (it’s assumed) have access to Leon’s medical history but no access to the 111 details so Leon’s explanations had to be repeated (3rd explanation).  The extended hours clinician referred Leon to MIU for chest x-rays.  This referral was rather chaotic involving an instruction to go to the MIU connected to A&E and a printed encounter summary.  On Leon’s arrival at hospital, the nurse insisted on admittance to A&E (and not the MIU) but was not able to gain sufficient details from the encounter summary so Leon was forced to explain his condition again (4th explanation).  The x-ray was booked and a number of other tests (blood, ECG) carried out by rather harried staff in an ad-hoc fashion.  After a five hour episode of care, Leon was sent home with no clear diagnosis of what had happened but an assurance that he was OK.  Two hospital nurses, two GPs, one hospital doctor, an x-ray technician, one healthcare assistant (who took Leon’s blood) and the laboratory (who mislaid the test results for a time) combined across four care settings (111, out-of-hours, extended hours, hospital) to provide Leon’s care.

All-in-all, a rather disjointed experience with almost no sharing of data between the different care providers.  Assertions of the importance of Caldicott principles seem rather hollow when necessary data either isn’t exchanged at all or is printed out and manually handled.

So, what’s wrong with UK healthcare?

Leon’s experience (he was suspected of having a spontaneous pneumothorax) highlights a number of issues.  Firstly, those managing Leon’s encounters seemed to share almost no data, meaning that time was wasted with the situation having to be repeatedly explained (four times in Leon’s case).  Secondly, communication to Leon through the episode was limited, it was left to him to actively seek updates and clarify next steps.  Thirdly, the different care settings appeared as completely different organisations with call backs and re-registration rather than operating in concert to manage Leon’s situation as a single episode of care.

If we look across the world, Japan (not included in the Mirror, Mirror… report) spends more on healthcare, providing for a more elderly population but has a far lower rate of obesity.  Japan appears able to deliver significantly more provision at little additional cost but it is note-worthy that the level of obesity (a significant risk factor for type two diabetes) is very low by world standards.  This is relevant to UK healthcare where there were 2.7m people living with diabetes in 2013 and (according to the 2015 NHS England Annual Report) one in five primary school children are clinically obese.  If we add lifestyle demand (such as alcohol related hospital admissions) we must take the view that demand for healthcare is as important an element in solving the UK’s healthcare woes as is a reconfiguration of the way in which healthcare provision is organised.  Interestingly, “Mirror, Mirror on the Wall” placed the UK last in the Health Lives category.

Given a healthcare system that, by some objective measures, performs reasonably well; what can we do to address its pressing challenges?  Firstly, citizens (not just patients) need to be supported to manage their own social, mental and physical health.  We need to support people in living healthy lives and to intelligently seek out the right medical care when necessary.  Secondly, we need healthcare providers to work effectively together regardless of internal, organisational boundaries.  This needs patient information to be shared across care settings and for treatment to be organised across provider borders, driven by patient need.

References

Commonwealth Fund, Mirror, Mirror…

Consultants & Architects

Having had an unplanned stay in hospital (I wouldn’t recommend pneumonia), I’ve been reflecting on the experience. Maybe I’m a bit strange but I can’t help but look at it through a consultancy lense; maybe interesting, maybe sad.

The paramedics were a bit like a sales team, always there when you call and full of reassuring words. Beneath the relationship management, there’s a real focus on qualifying out (you’re OK, you don’t need our help) or quickly getting you to hospital. The wards, with their skilled doctors and nurses, were like development teams, varied and core to delivery. From the intensity of acute care to the relatively sedate pace of a regular ward, patients perceive that it all happens in the wards. Finally, the consultants were like architects, focused on understanding the patient and determining what programme of treatment they really need. Their skill is getting behind the symptoms, understanding the underlying challenges and defining a course of treatment that will really work to bring about improvement.

After being deposited in casualty, consultants were the first medics that I saw. Initially, they directed the team on which examinations to conduct in order to figure out what was wrong with me and what interventions would best tackle my problems. Once things had calmed down, they spent more time talking to me, understanding how the treatments impacted and keeping me informed on what would happen.

During my time on the wards, the consultants were still overseeing my care. They would pop back, keeping me updated and making necessary adjustments to the plan.

TrainingThe big surprise for me has been since leaving hospital. I’ve been handed over to a new consultant but she has full access to my details as well as the treatments established. There are tests planned to ensure that the treatment has worked but much of my time with the consultant has been focused on explaining what’s happened, reviewing progress to date and advising me on how best to assure short and long term recovery. The advice has been really useful; I know where I need to play it safe and where I should push to accelerate progress. Though the planned tests will be an objective assessment of success, I feel that I know what they’ll show because the consultant has alerted me to the signs and I’m alive to how I can manage things to get the outcomes that I want.

I wanted to thank about a hundred people for my care but the consultants stand out as shaping my treatment and really helping me to drive my recovery.

Now, back to architecture.

Agile should mean Faster AND Better

If your digital project is late and its users are unhappy, it’s not agile.   Well, it could be tagged as agile by some (it’s got sprints, t-shirt sizing & stand-ups) but this is really rather pointless box ticking.  Today, resources need to be consumed purposefully and efficiently, and the drive for digital needs assured, “good enough” delivery.

I’m not suggesting that we throw out the agile baby with the tar-pit bath water here, most definitely not.  What I am saying is that we must shape our projects so that they deliver to order and, for digital, this covers faster.  Agile development is a valuable part of this faster, better delivery but there are some essential architectural underpinnings if we want success; fast, efficient, on time and on the money.

We (those tasked with facilitating change) need to understand what the enterprise wants to achieve and how.  More customers, more sales, more revenue per customer… they’re all good, we just need to know.  If there’s no documented strategy, objectives and KPIs can probably be found in the annual report but the “how” (critical success factors) may well not be expressed.  If you can engage chiefs or senior managers and find out how they want to achieve their objectives (I want to drive up customer numbers on the freebie service and then convert them to premium) this is great for building valuable relationships and strengthening buy-in.  I can imagine some of my agile colleagues developing hives at the thought of all the time wasted on this documentation but they’re wrong.  No engagement, no buy-in, no delivery; it’s that simple.  There’s a positive side to this too.  The resulting motivation model can be used to define scope (it doesn’t deliver a CSF or KPI so drop it) and priority (without this, that KPI can’t be measured so it’s a “Should”) so we’re lean.  It also helps to minimise change (we could change the user stories but it won’t improve support for that CSF) so we’re lean.

I’ve written before about the value of business object modelling (Things) to quality but it’s also great for speed & agility.  Things are easy to understand so they’re quick to attract buy-in.   Once we’ve defined them, we just need to build them.  The actions defined for each Thing are first-cut functions, the characteristics are first cut screens. A lot of time is typically wasted during iterative projects trying to nail these two sets of decisions and the result is often lots of screens/forms/pages that are variations on a theme, hence more work to do and a more complicated and more confusing user experience.  Definitely not lean.

The next tool in my cargo pants is a Capability model.  I’m a bit of a latecomer to this one but I’m finding these models really useful and tight.  We’re developing generic and sector capability models so we can provide a start for ten here.  Capabilities are easy to document, the technique is model driven (and uncomplicated) and they’re readily consumable.  Although process models are important downstream, the semantics and notations (even simplified BPMN) are an unnecessary complication at pre-project stage.  Capabilities are excellent for getting to a shared view of operations and models can be heat-mapped to give different perspectives.  Change is easily reflected and progress is rapid; so we’re agile.

The final tool in my small pocket is the Roadmap.  It’s great being bold and running off down a path but you can spend an awful lot of time running round in circles if you don’t know where you’re going.  Wasteful, not lean.  Many of you will have been on a project with a big elephant called Technical Debt slumbering in the corner.  You’ve made progress, there’s a beta to launch and everyone’s happy.  Who cares that it will fall over frequently and cost a fortune to strengthen.  It’s a beta, right?  I get the need for speed and agree there’s a need to hold back costs until we know there’s demand.  Roadmaps just mean that informed decisions can be made and the majority of technical debt avoided; so we’re lean.

Like “fail fast” and “good enough”, “slow start, fast finish” feels a little uncomfortable to begin with but it’s the right way to go.  So keep your user stories, burn-down charts and scrums; just add in motivation, things, capability and road-mapping if you really want to go digital.

Building Spacious Systems…

Even though I sold it some years ago, I still reminisce about my old Kentish Town flat so what was great about it?  Well, firstly it was spacious.  Downstairs was completely open plan so given that I didn’t overfill it with furniture, there was a real feeling that you could definitely swing the proverbial…  Secondly, it was bathed in light as the back windows were wide, floor to ceiling affairs that opened the flat to the world (don’t worry, I had curtains).  The final great feature was not inside the flat but outside.  Access to my first and second floor “maisonette” was via a secure doorway, stairs (with a lift for the lazy) and a balcony/terrace which again opened the flat to the world as well as encouraging neighbourliness.  Once through the security gate and main door, things were fairly open and security wasn’t in your face.  I thought the developers were a bit rubbish so how did they build such a great place?

KTWhen building homes, for the majority of people, there are some fundamental principles.  Before we get to deciding between Smeg and Miele, creation of space (whatever the external constraints) and maximising natural light will always be desirable. Similarly, flexible, non-oppressive security will be another winner.  The same is true in building good technology; in parallel with reflecting specific requirements, there’s a set of principles to which almost all systems should adhere.  It should be easy to move around into areas that suit our inclination without constantly meeting obstructions.   We should also be able to benefit from natural illumination wherever we are… re-phrased, our way should be enlightened with knowledge as we go.  Finally, while security becomes ever critical as more of our lives are lived online, we don’t want that security to be so oppressive that our use of the technology is impaired.

I’d venture to say that if we applied just these three principles, our tech would be much, much better.  Easy navigation and having the right context (relevant information) can both be established by the adoption of a technique that I think is really, really strong.  Object modelling, user conceptual modelling and business entity modelling are all monikers for a technique that identifies, defines and then embeds the things with which we interact.  I’m not talking about normalised entities or implementation classes but the real things, be they physical or conceptual, that are all around us.  In a financial situation, I have an account that I use to purchase goods from particular merchants (Account,  Purchase Transaction,  Product, Merchant).  In a travel situation, I walk to my local station to catch a train that will take me to the shops (Station, Journey, Train Service, Location).

The beauty of these things, is that once identified, we can define them in a natural way and this definition can be shared with the technologists allowing them to implement equally naturally.  I’ve mentioned account, I’ve said that I want to be able to credit money to and debit money from my account; and I’ve called out the different characteristics of my account (balance, transaction history, facilities, regular debits, etc).  I’ve also said that I want to be alerted if there are any strange debits.  Given that I’ve gone to this trouble, I want it to be really obvious, when I’m using the technology, how I get to my account and really easy to access and do the things I’ve said.  So, as I’m making a purchase, for example, it would be really cool if I could see my balance after the transaction and what my overdraft limit is.

Behind the scenes, these things are used extensively.  As well as determining the structure of user interaction (accessible spaces, illumination), these things provide information definitions that can be normalised to generate data models and they outline the default set of services for our service architecture.  This is particularly helpful in agile development as we have a single model that can be used throughout our project without the need for repeated translation.  Translation is not a bad thing but the more translations we have, the more effort we expend and the more likely we are to make a mistake.

“… and what about security”, you ask.  Does Object Modelling help with creating unobtrusive security?  My location may not be a big secret but my changing locations over a period of time may well be personal and sensitive.  Therefore, in deciding how to control access to information, context is key.  Object Modelling supports the design of unobtrusive security by identifying the different contexts, the characteristics mentioned above.  If access to information is linked to these characteristics, access control can be simple and flexible.

Object Modelling can help us to build spacious systems with lots of light and flexible, unobtrusive security.  It’s a key technique in our approach to accelerating technology enabled change.

A History of Architecture

I’ve got to that age when one reflects on one’s career; the troubled projects, late nights, cancelled holidays, “go live” celebrations and [it’s work, honestly] client entertaining.  Not quite rock-n-roll but a rich tapestry of consultancy and what strikes me, repeatedly, is how things change, but yet remain the same.

For my undergraduate thesis, I looked at three small businesses (we now call them SMEs), developing a picture of their business objectives, critical success factors and key performance indicators (motivation modelling) in order to understand what they wanted to be able to do (capability modelling) and what technology facilities (architecture building blocks) they needed.  Since then, I’ve done analysis, development, management, selling (shh!) and lots of other stuff but I’m back doing architecture again.  Like Viggo Mortensen’s character, I just can’t escape my past.

What we now call enterprise architecture was once an aspect of business analysis and before that was strategic planning.  So if things really have remained the same, what can we learn from our architecture forebears?  Our architecture is relatively young so let’s look at traditional architecture.

Physical architecture typically involves a professional team being commissioned by their client to plan, design and supervise the building of structures.  The formative academic study of architecture in the UK (University College, 1841) shaped architecture as a fusion of art and science, I think this mostly holds for our architecture. We have clients (internal or external), we undertake commissions (contractual or not) and we plan, design & supervise.  Do we, however, see art and science in our architecture?  The importance of communicating ideas in a digestible and attractive way certainly needs artistic flare and the development of pleasant user experience needs artistic understanding and creativity.  The need to understand people and their inter-relationships is critical to success so humanities come in to play, too.  Maybe architects are the polymaths of the information world.  To balance this accolade,  maybe I should question whether we’re professional but let’s make that rhetorical.

One area of difference is the reach of architectural projects.  Physical architecture is comfortably project based and, even when developing the head offices of corporate giants, has a specific area of impact.  Our architecture, dealing with information rather than concrete and steel, has a much more enterprise impact and hence has an existence and mandate beyond the project.  This is important as it does require an elevation for the practitioners of our architecture and it requires us to supervise for a longer period of time.  Further, physical structures have a clear purpose (to get across the river safely, to comfortably house 1000 staff) so benefits realisation is clearer and sooner.  As long as the bridge is inspected safe and cars can cross the river on it, the purpose has been achieved; Norman and Richard can be given a pat on the back and can cash their cheques.  With our information structures, the basic achievement of purpose cannot be so clearly signed off and the full realisation of benefit may need a while to confirm.  Our Zaha cannot be congratulated quite so readily.

Burj

Final, let’s consider context.  Byzantine,  Renaissance and other, older architectures are reflections of prevailing, cultural norms.  Modern architectures can be said to be establishing styles and setting trends that other aspects of society later adopt; notable in this regard is Bauhaus.   Corporately,  the move from evolved to architected enterprises (though early stage) emulates this lifecycle of physical architecture.

So…

  • Architecture needs a wide variety of skills; arts, humanities & science
  • Architecture is about change so buying in architecture is completely valid
  • Information architecture does not have physical form on which rules of certainty can be employed so we must accept a degree of ambiguity
  • The change from evolved to architected happened in the physical world and is rightly happening in the digital world

Our history is indeed shadowing that of our cousins in physical architecture; things do remain the same.