How do regional differences impact EA?

Another great enterprise-architecture question that came in via Twitter, this time from Swedish EA consultant Jörgen Dahlberg (@greblhad):

Have you ever experienced regional character in the expression of #entarch ?

My Twitter-sized answer was ‘yes’ – “IT ‘ent-arch’, not really; whole-of-ent arch, huge diffs” – to which Jörgen perhaps unsurprisingly asked for a better explanation – “can you share some insight as to what these diffs in WofEA where?”. Hence this. 🙂

The not-quite-so-short summary is three words: environment, culture, politics. More precisely, the ways in which three themes interweave with each other, namely physical environment, social culture, and politics/economics.

Many purported ‘enterprise architects’ only work within the IT domain of the enterprise, but even there those three themes can have major impacts. By the time we get to the true whole-of-enterprise level the impacts are often much larger, though paradoxically often rather more subtle. (This is going to be long, so I’d better put in a ‘Read more…’ link here.)

Impact of environment

At least three sub-themes here: distance, climate and geology.

Distance: In Britain, distances are small: there’s nowhere in the country that’s more than 100km from the sea, and few places that have no wired connection to telecommunications. In Australia, distances can be huge: ‘urban’ is the same as anywhere else, but ‘suburban’ is much the same as most of Britain’s ‘rural’, much of ‘regional’ is what Britain would call ‘remote’, ‘rural’ often implies places that are hours apart, whilst ‘remote’ really does mean what it says. Australia’s ‘regional’ is often beyond the limits of cabling, and with frequent gaps in GSM coverage; much of its ‘rural’ is at the limits of the old longer-range analogue mobiles, whilst telecommunications in ‘remote’ often means a telephone-booth out the back-end of nowhere with a solar-powered satellite-phone. Quite apart from cultural implications – the social impact of even having some form of telecomms out there ‘beyond the black stump’ – this means that the technology-architecture needs to allow for a much more heterogeneous infrastructure.

Climate: Most IT equipment is designed to operate in the relatively balmy range of 5-35°C, <95% humidity – which means we need to do something to protect it as soon as we move outside of that range. Arctic regions frequently drop to temperatures where tyres will shatter; in tropical deserts, such as in Australia, ordinary tyres may even melt; but telecomms and power-transmission equipment still has to work. Solar flares and ionospheric effects are serious problems in places like Alaska; insect-attack on cabling and the like is a nightmare in places like Honduras and equatorial Africa. Tropical storms can make a serious mess of physical infrastructure, too; likewise bushfires, tornadoes and many other climate-driven disasters. On top of that, many of these places are seriously inaccessible. This means that your technology in these regions needs to be much more resilient and self-repairing, and have much better self-monitoring and self-reporting of potential or actual faults. Which means significant differences in the infrastructure-architecture, compared to the relatively ‘easy’ and uncomplicated temperate climates.

Geology: If you’re in an earthquake region, or one that that’s likely to suffer tsunamis or severe storms, your technology-infrastructure is going to need to be alot more resilient than elsewhere. Business-continuity and disaster-recovery planning will play a major part in your enterprise-architecture; many of your business-processes will need to be designed to allow for the  near-certainty that at times your IT may be inaccessible, or may even no longer exist. On the other side, modern data-centres can be placed anywhere in the world, but have huge demands for energy and cooling, in some cases almost on a par with an aluminium smelter – which places some interesting geological constraints on where it’s feasible to operate them. In temperate regions, big rivers are almost a must; naturally-cooler regions which also have copious amounts of natural power are even better. Hence Iceland is attracting a lot of interest from operators of very large data-centres: lots of hydroelectric power, less need for coolant anyway, physically remote (hence fewer physical-security risks) and a technically-literate population as well.

Impact of culture

In my experience, culture mainly impacts the applications and business layers of the architecture, but also has some impacts on data and technology-infrastructure as well. The key themes I’ve seen are motivation and collaboration, but also some perhaps-unexpected issues such as gender-roles.

Motivation: The key distinction is that the US/Western model assumes individual/extrinsic motivation, whereas many other cultures assume collective and/or intrinsic motivation. (Spiral Dynamics is a useful lens to explore this, though note some caveats about how to apply it in whole-of-enterprise architecture.) One clear example was with a client in Latin America, where every one of the senior executives said that their own first priority was family, followed by church: we might see the same in the Bible Belt in the US, perhaps, but rarely so in most major US cities. Most Western-style systems (typically emphasising ‘Orange’, in Spiral terms) place recognition and rewards on the individual; but in ‘collective’ cultures in Latin America and elsewhere (emphasising ‘Purple’, ‘Blue’ or ‘Green’, in Spiral terms), over-emphasis on the individual causes social-fragmentation and can even be interpreted as personal punishment. This means that we need radically different approaches to performance-monitoring, reward-systems and much else – with significant impacts on overall application-architecture and business-architecture, as well as to how the organisation interacts with its broader enterprise.

Collaboration: The individual-versus-collective cultural-axis also impacts the trade-offs on how work is divided up and managed. IT systems that assume tasks are always assigned to individuals will result in major  off-system (and often undocumented) work-arounds in cultures that do or must spread the work across a more diffuse collective – which also has major impacts and implications for system-security. This applies not only to regional-cultures, but work-cultures in general: I came across problems of this kind with a CRM system that had been bodged-up to sort-of-work in a child-protection context. Getting the balance right, especially in a multinational or global organisation, will pose significant challenges across just about every aspect of an enterprise-architecture – though conventional IT-centric architectures are unlikely even to be aware that these problems exist.

Social culture: Religion and culture impact on any architectures in many ways, some of them obvious, some not. Most of these will affect business- and applications-architectures, but sometimes other architectures as well. One obvious example is language: for any multinational or multi-lingual organisation (often required by law in countries such Canada, Mexico, Australia, and increasingly the US too), the applications-architecture will need at least one extra service-layer to deal with presentation, translation and duplication across languages. (Presentation-architectures can get horribly complicated with left-versus-right, horizontal-versus-vertical orientations and the varying space taken up by texts in different languages.) Usage of icons and colours can be a socio-religious minefield for presentation-architectures; use of photos and avatars for identification can be tricky given that some cultures (particularly East Asian) have a strong aversion to displaying personal images. Addresses and even personal-names cause real headaches for data-architectures and presentation-architectures: for example, forename-first (Europe/US) versus family-name-first (East Asia), patronymic surname (UK/US), gendered patronymic surname (Russia, many Slavic countries), patronymic-plus-matronymic surname (many Latin American countries). Consider also the importance of seniority in many Asian cultures, gender in Muslim ones, or ‘citizen’ versus ‘gastarbeiter/non-citizen’ in almost every country: these can have major impacts on the way that business-processes and applications operate and present information – not to mention some significant impacts on security-architectures too.

Impacts of politics and economics

The main themes I’ve seen revolve around control, money and property – particularly so-called ‘intellectual property’.

Control: At a basic level this is a key component of organisational culture, hence directly impacts organisational-architecture, business-architecture and more. Many orgs are still run on strict hierarchical/Taylorist lines, which is reflected right down to the technology-architecture – which is one reason why so many orgs have trouble with ‘Enterprise 2.0’ tools and techniques, even though the technology itself is a only minor variant of IT-systems that almost every organisation will already have in place. Conversely, orgs that base much of their work on self-organising teams will have real problems with classic monolithic IT-architectures. One of the key architectural themes is that an organisation is bounded by rules, whereas an enterprise is bounded by shared commitment; this means that control can (sort-of) work within an organisation, but must be replaced by negotiation and trust as soon as we move beyond organisational boundaries – which has huge implications for whole-of-supply-chain architectures, customer-centric business-models, security-architectures outsourced/distributed business/process-architectures and even technology-architecture issues such as use of cloud-services.

This gets a lot messier at the political level. Doing just about any kind of online business in China, for example, means that you must include a real-time censorship layer into your architecture, where part of control is passed to government agencies; since very few IT systems can handle the real-world complexity of censorship, this means that your process-architecture needs to handle rapid transits between IT-based and ‘manual’ process-components, often in near-real-time. (This isn’t just China, by the way: don’t forget Echelon and the like. Some while back I wrote a business-oriented article about ‘the rise of the business-anarchist‘: I had a response from someone with a ‘.mil’ [US military] internet-address mere minutes later. A good conversation, I might add, but clearly something/someone was watching!) At the less overtly political level, Australia and many other countries now operate some kind of basic content-filtering over the entire internet-space, in the name of protecting children from ‘inappropriate’ content: this requires its own distinct layer in the respective IT-architecture, though that may occur at various levels within the overall applications/technology continuum.

Money: Any transaction that involves money will introduce significant complications into the architecture: distinct service-layers for identity-management, authorisation, funds-transfer, tax-reporting and much else besides. Every country and region is different in the way it handles this – which adds another whole layer of complexity for architectures in multinational organisations (or even those that handle transactions across states, as in the US). Transactions and cultures that don’t get lost in the time-wasting disaster-area that is the money-economy can use much simpler architectures.

Property: Mainstream Western cultures (and pretty much anyone else in the ‘globalised’ business-economy) operate on a possession-based model of property, usually described in terms of ‘property rights’. This sort-of works for property that is physical or ‘alienable’ (if I give it to you, I no longer have it), but doesn’t work properly work for virtual-property that is ‘non-alienable’ (if I give it to you, I still have it – is the case for most forms of information or data), andreally doesn’t work for relational-property and the like (for which I can create conditions under which it sort-of transfers, but can’t actually transfer it as such – as in business-goodwill or reputation). Unfortunately, mainstream economics assume that the physical model of property applies to everything, which createshuge complications for all architecture domains – not least because there’s no guaranteed way to enforce ‘alienability’ of naturally ‘non-alienable’ property. Every attempt at ‘digital rights management’ has created unwieldy complications, and together with some surprisingly arbitrary and questionable assertions of ‘rights’; in every case, some way has been found to circumvent it. The same goes for ‘need to know’ security: the nature of information is that it ‘non-alienable’ and hence by definition ‘wants to be free’ – hence the only tactics that actually work in practice are those that enhance that ‘non-alienability’, such as transparency and openness. Anything that attempts to enforce ‘proprietary rights is going to be messy and complicated at some if not most levels of the architecture; by contrast, openness makes the architecture a whole lot simpler. Cultures and sub-cultures which operate on a responsibility-based rather than possession-based model – such as the Open Source movement, video-pirate websites and most of the ‘grey economy’ in emerging-nations and elsewhere – make use of the architectural simplicity in a way which runs rings around any proprietary model.

Combined impacts

Fairly obviously, these factors interact in many different ways. Some quick examples:

Geology and climate interact: If you’re in an area that’s prone to ‘natural disasters’, you need to be doubly certain that your architectures embed some very solid disaster-recovery planning, with very clear switchovers from IT-based processes to human-based ones (often paper-and-pencil), with clear mechanisms for recovery and update from the manual records back into the IT once the disaster is passed.

Culture, economics, distance and technology all interact: Infrastructure- and application-architects who are used to easy assumptions about guaranteed ‘always-on’ network connectivity could learn a lot from India, where there’ve been some brilliant solutions – especially in the medical-electronics space – to the local reality of unreliable power-supplies and extremely erratic bandwidth. Mobile-applications architects could look to Africa, where the most common banking interface is SMS on an entry-level mobile phone, and where even surgical instructions for shoulder-amputation may be sent by text-message.

In summary, simple technology-architectures might at first glance seem to be the same worldwide; but in practice, regional variations of environment, culture and politics create conditions that demand significant differences in the architectures we develop to work with them, at every level and in any domain of the enterprise. A true whole-of-enterprise architecture needs to be structured in such a way that these regional differences are clearly exposed within the architecture, so that adjustments can be made when applying the architecture in a different regional context.