Things I learned while doing 24/7 eldercare

I’d been sort-of looking after my elderly mother for some years now – the whole of the past decade, probably, though more and more so over the years. Earlier this year it had reached the point where I couldn’t really go away even overnight, let alone for longer – which kinda limited what I could do here, as you may perhaps have noticed. But that’s okay: family comes first.

Yet suddenly that ramped up real hard. Back in early August, she had a bad fall in the middle of the night: broke her hip, ended up in hospital for a couple of months. For a while was even touch-and-go as to whether the shock had been too much, but she pulled through after a few worrying days. Okay, she’s had bad falls before, and she’s tough – even in her mid-90s she’d still been going to the gym every week – but it’s clear that this one has taken a serious toll. So since she came home a month ago, for me it’s been full-time eldercare, pretty much 24/7, all day, every day, and all night, every night.

Which is hard work. Very hard work.

But which in turn has provided me with some very first-hand experiences which seem relevant to enterprise-architectures. In no particular order, these include:

— Service-providers in healthcare do all mean well, but the healthcare system as a whole doesn’t join up well as a whole system. Carers drop by in the morning and evening to do the bits I shouldn’t, such as dressing, undressing and bathing; there’s a physio visit every couple of days or so; others too from time to time, including the GP (family-doctor), equipment-providers and various other specialists. But there’s not much sense of coordination – especially across or between different organisations.

Enterprise-architecture (EA) notes: This seems yet another example of the crucial distinction between organisation and enterprise – or more particularly, that organisation and enterprise are not the same thing, and that the relevant enterprise (the enterprise of healthcare, in this case) can be much larger in scope than the organisation (each single healthcare-provider). Or, to put it the other way round, any organisation that takes on a role within a larger shared-enterprise (which in reality probably applies to every organisation) must ensure that it understands and supports the whole enterprise, rather than solely its own part within that enterprise.

— On information, our first-hand experience is that while information-flows within organisations may be good enough, information-flows between organisations can be very poor – sometimes even dangerously so. Key information just got lost: for example, the social-services team had built an entire care-plan on the assumption that she lived alone, even though I’d formally registered, with both hospitals, the fact that I lived in the same house. Likewise lost had been the key-safe code, my phone-number, even my name. The social-care team had also been told that a particular medical-aid was still attached, even though it had been removed before she left hospital. We seemed to be the only ones who had any copy of her medical-discharge notes, even though they were essential for every care-provider. And one of the physios was convinced that it was her left hip that had been broken, when in fact it was her right hip. It’s been an eye-opening mess…

EA notes: Yeah, it’s the same organisation-versus-enterprise problem, applied to information and information-flows as per Open Group’s beloved concept of boundaryless information-flow. Except that the whole problem is that all too often the information doesn’t flow correctly to where it’s needed – and particularly doesn’t appropriately flow across the various arbitrary boundaries within the overall enterprise. Part of this will arise from inherent clashes with other concerns such as information-privacy – which should remind us that those concerns are very much in-scope for any enterprise-architecture. But there doesn’t seem to have been much if any enterprise-architecture here – even of the classic this-organisation-only IT-centric kind, let alone a proper whole-enterprise awareness. And yeah, that absence shows – creating very real risks.

— Importantly, much of the information in the context is non-electronic – and often necessarily so. Each of the two groups of carers who visit here regularly maintain their own set of case-notes in pre-printed books of forms, left at the client’s house. Some of these are graphs and suchlike, though most of these are just daily visit-records. Different carers come and go almost at random, so it’s a key way that they can communicate with each other and keep up to date on progress (or lack of it). The point here is that all of these notes are handwritten – not electronic.

EA notes: No doubt it’d be possible to make it all-electronic, via apps on handheld tablets and suchlike – but the cost would be astronomical, the whole system would likely be less versatile and probably slower and more cumbersome to use, the same information-flow failures as above would almost certainly apply, and the tablets themselves might well be a health-hazard as they’d need to be carried from site to site. One of the more infuriating aspects of the incipient IT-centrism of so much ‘enterprise’-architecture – even in healthcare – is that complexities and trade-offs such as these become invisible: instead, there’s a headlong rush to ‘digitise’ absolutely everything without much grasp of how things are actually used in their real-world contexts – a tendency about about which we definitely need to beware. Important lessons here for every enterprise-architect…

— In the same vein, equipment is only useful if we know what it’s for, and how it can help. The hospital had provided us with a wide variety of equipment, including a hospital-style bed, a walking-frame, a commode and a kind of hand-operated turntable-thing with red handles called a rotunda, as shown in this picture:

They’d shown us how to work the controls and levers and suchlike on each of these devices – but they hadn’t told us anything about how or why to use them, or for what purpose. In essence, we were just left to guess – and for the rotunda, the purpose wasn’t obvious at all. It wasn’t until almost a week’s-worth of multiple middle-of-the-night heave-and-lift struggles that I realised that the rotunda – up until then parked in an out-of-the-way corner of the other room – was exactly what was needed to aid in transfers between bed and commode. It would definitely have helped to have been told about that right at the start…

EA notes: The over-focus on features without a good explanation of what the features are for seems to be an all-too-common characteristic in any technical field. The updated operating-system on my main tablet has a vast array of interesting-sounding new features that they claim would greatly improve my productivity – and they might indeed, if I had any idea of how or why or when to use them. Which I don’t. And there’s no manual, no apparent place to find the information I need, just gaudy marketing-puff about how wonderful the new features are without anything further than that. Hmph. Kinda stuck, really. Yet this seems so common a problem, for so many people, across so many technical domains, that fixing this should be right at the forefront of any architecture – not left to chance or users’ guesswork, as seems to be too much the case at present.

— Another very first-hand experience: front-line work in healthcare is intense, with huge demands across all dimensions of work – physical, mental, emotional/relational and purposive/spiritual. Solving real-time challenges across all those dimensions of work can be very hard when you’re working in the middle of the night with someone who’s in pain, physically frail, poor physical balance and, unsurprisingly, in emotional distress…

EA notes: The common notion that enterprise-architecture needs to address only the IT-issues becomes worse than laughable in this type of context; likewise for the more recent notion that robots will able to address all of eldercare somewhen in the near-future. It’s true that some robotics is becoming available for some aspects of eldercare: emotional-support robots for dementia patients, for example, or exoskeleton systems for the elderly as well as for warehouse-workers. Yet the challenge is that these are each point-solutions to a single part of the context, with nothing to link them together; and despite sci-fi stories such as the film ‘Her‘, it’s unlikely that any robotic system will ever be able to tackle the emotional-purposive challenges that are by far the hardest part of the challenge here. The reality is that in this context, systems only work well if they support the whole of the context, without creating even more fragmentation across the whole than already exists. And this is true not just for eldercare, but for every enterprise-context – a point that is becoming more central to enterprise-architecture with every passing day.

— A painful reality: people who are not doing front-line work often have no clue of just how hard that work really is – or how much their well-intentioned ‘advice’ can often be more of a hindrance than a help. There’s a huge difference between doing the work, versus merely having information about the work…

EA notes: There’s a fundamental rule for all enterprise-architecture that is still too often forgotten: that information alone is not enough. In this case, I had an immediate, first-hand understanding and experience of the anger that so many front-line workers feel when some nominally well-meaning consultant comes past to try to tell them how to do their jobs, without ever actually having done the work itself. As Kentaro Toyama warned in his book Geek Heresy, IT-centrism and a more general over-reliance on the almost literal deus ex machina of technology-based ‘solutions’ is without doubt the most persistent source of failure in almost every kind of change-initiative – especially in those that rely on some form of social-change, within or beyond the organisation. The first requirement for doing it right is to drop the assumptions, and instead go out there to do the darned work, first-hand, – and do so before looking for any kind of technology-based ‘solution’.

— A flipside for that last point is that the work is made harder by having to deal with other stakeholders’ assumptions and emotions. Again, I’ve learnt this one the hard way, not just in this case but in others before. For example, someone can get upset about how they would feel in that circumstance, even though they’re not actually in it themselves – a situation I describe as ‘pseudo-empathy‘. For this context, another example is that people assume that eldercare is the same as childcare: there are some similarities, yes, but also some key differences – not least of which is the debilitating fact that whilst in childcare day by day things do get better, in eldercare things steadily get worse…

EA notes: This is yet another reason why IT-centric approaches to enterprise-architecture are so dangerous: almost by definition, they have almost no concept of emotion, or its very real impacts on the viability or success of the enterprise. If we’re to get anywhere with enterprise-architecture, we must view emotion as an ‘equal citizen’ in the workings of the enterprise – and in the structures and stories that the architectures provide to support that enterprise. For our own sanity’s sake, we also need to map out who the likely stakeholders are, and their relationships, roles and responsibilities for the context – which would in turn also point to probable emotional issues in the context.

— A final first-hand experience, for now, is that eldercare is not a project. Yes, the ‘re-ablement’ aspects of eldercare do have some project-like features, with definite milestones: able to walk unaided, able to get out of bed unaided, able to dress and wash unaided, that kind of thing. For many of the care-provider organisations, each instance of service-provision is a project, of course. Yet for those of us who provide continuity across the whole it’s a continuity, not a project: and if we ever do fall back into thinking that it’s some kind of project with some arbitrary start and end, we’ll miss key points about what’s actually going on in that context – not least that the only end-point as such is, well, the literal end…

EA notes: In this one sense at least, enterprise-architecture has exactly that same characteristic: it’s not a project – it must, by definition, continue on for the entire life of the enterprise. Yes, there are often project-like features, individual time-bound projects within the broader whole – but the architecture itself continues on. If we ever forget that fact, our architecture will be in deep trouble – and likewise, in all probability, our organisation’s relationship with the broader enterprise. You Have Been Warned, etcetera…

Some useful themes to think about, perhaps? Over to you for comments and suchlike, anyway.