Creating a career in enterprise-architecture

A few days ago a young IT-architect in India, Nitin Koshy, sent me an email asking for advice on how develop a career as an enterprise-architect. A nice challenge: much appreciated!

There’s plenty of purely pragmatic advice one could give, of course, but I don’t know the Indian context that well – for example, I don’t even know if anyone’s doing TOGAF trainings there as yet, though I guess someone must be doing so by now. But I thought I would concentrate instead on the same kind of advice in one of my favourite books, William Beveridge’s The Art of Scientific Investigation:

Elaborate apparatus plays an important part in the science of to-day, but I sometimes wonder if we are not inclined to forget  that the most important instrument in research must always be the mind of man. It is true that much effort is devoted to training and equipping the scientist’s mind, but little attention is paid to the technicalities of making the best use of it.

So in the same spirit about “the technicalities of making the best use” of the architect’s mind, I suggested the following ideas, in no particular order:

IT-architecture is a cross-disciplinary specialism: the enterprise IT-architect will bridge between the various IT domains, but the focus essentially remains centred around IT alone. By contrast, to the enterprise-architect, everywhere and nowhere is ‘the centre’: he or she must be a consummate generalist, interested in everything. So I would encourage you to lift your eyes from the screen and the imaginary worlds within IT-systems, and look around you. IT-systems describe a digital world, but they are also very physical: they exist in a real world beyond data alone. A real, messy, chaotic world, where computers need to be fed power and kept cool (the two huge demands of present-day data-centres), placed somewhere safe from dust and rain and flood, with all of their cabling and other data-links protected from birds and mice and wayward excavator-operators digging up the roads. And a human world, where real people have real emotions and do the real work, and where passion for code (and, sometimes, a confused passion for ‘control’) is what creates all of this in the first place.

So get interested in everything, in anything that happens. Allow yourself an explicit time in the day – as a meditation, if you wish – in which you allow yourself to notice whatever happens around you. See the four-dimensional shapes that people make as they move down the street, the surging textures of a moving crowd. Notice the momentary sounds and individual words that appear in the midst of the noise and tumult – they may not necessarily mean anything in themselves, they just are, yet noticing them builds a habit that creates space for noticing things that do matter. Watch an individual ant choose its path across the dust; then watch the patterns that a colony of ants will make; then crosslink that to the path you can see in the lifecycle of a single data-entity, the patterns you can see emerge from the flow of data. Be interested in machines as well as IT boxes: learn how a spinning-wheel works, a loom, a sewing-machine; the four-dimensional paths and movements built into the workings of a printing-press; the amazing complexity within an ordinary-seeming office-printer to deal with the physical variation of paper moving through the feed-path, of real particles of toner moving from the cartridge and thence to the paper, all held somehow within precise positions in space and in time. Be interested especially in people: it’s so easy to see them as machines, as ‘manual processes’, extensions of your IT-systems, yet remember to see them also as strange beings with choices unique to themselves, every one of them different, passionate, frustrated, bored, somehow surviving against all the unyielding pressures of entropy. Allow the world to be strange, new, like the world of an ever-curious two-year-old; and remember to keep those images and impressions and feelings with you when you come back to the ‘real’ world of deadlines and meetings and production-schedules and impatient clients who want it all done by yesterday!

Notice your own heritage and culture: notice what is uniquely India, what it brings to the world. So much of the global perspective is dominated at present by the worldview of ‘the West’, of Europe and the US: and it is easy to miss the cultural assumptions that are embedded in technology and business-practices, many of which may not fit well with local ways of working at all. (A significant part of my work here with US-owned multinationals in Mexico has been ‘cultural translation’: US culture assumes the predominance of the individual, whereas Latin culture places far more focus on the family, the collective, leading to some serious confusions around incentive-schemes and rewards for ‘personal’ performance and the like, with impacts rippling all the way through the entire architecture of the enterprise.) Notice your own culture’s enormous strengths: its proud yet unique tradition of mathematics, for example, or its amazingly inventive ability to ‘make do’, leading to world-leading innovations such as robust, lightweight, inexpensive, highly fault-tolerant medical-diagnostic systems for use in all those myriad small villages off the main roads with erratic mains-power and even more erratic network-connections. Notice where those ideas and innovations came from in your own culture – and then find that same place within yourself.

On enterprise-architecture itself, look wider than TOGAF and the other IT-oriented frameworks, to models that encompass more of the overall enterprise. Look at FEAF, the US Federal Enterprise Architecture Framework: note the two not-quite-blank sections in the PRM (Performance Reference Model) marked ‘Human Capital’ and ‘Other Fixed Assets’, and ask yourself what should go there, to complement the [IT-specific] ‘Technology’ in the centre. Look at DoDAF, MoDAF and other defence-oriented frameworks, and ask yourself how you would bring those same ideas back into the civilian world. (TRAK, an adaptation of MoDAF for the rail-engineering requirements of London Underground, would provide some useful ideas there.) For industry-specific frameworks, see SCOR (Supply Chain Operations Reference) or the Telemanagement Forum standards for the telecoms industry: eTOM (enhanced Telecom Operations Map), NGOSS (New Generation Operation Systems and Software) and SID (Shared Information/Data). Look also at how an any enterprise-architecture is put into practice in the real world: for example, balance TOGAF with ITIL (Information Technology Infrastructure Library), to see how IT-services are enacted by IT service-management.

In all of that, I would suggest to keep remembering that enterprise-architecture literally means ‘the architecture of the enterprise’ – not merely the architecture of the enterprise-IT. The IT exists within the context and needs of the broader organisation; and the organisation exists within the context and needs of a far broader shared-enterprise. An organisation is bounded by rules, roles and responsibilities, but an enterprise is essentially a human construct, bounded by aspirations, commitments, hopes, fears. We create an enterprise-architecture for an organisation, but about that broader enterprise. And ‘quality’ in all its forms is what arises from that broader enterprise: hence all those quality-oriented issues in architecture such as reliability, efficiency, resilience, safety, sustainability, security and the like. If you remember to keep that idea of the broader enterprise in mind whilst you work on even the smallest item of code, it will help to show you what an ‘enterprise’ really is – and hence the nature of enterprise-architecture itself.

The last point, perhaps, is to respect that all of this does take time – many years, if we’re honest. But you’re already a long way down that track: after more than ten years in ‘the trade’ you will certainly have learned a great deal about the difference between academic theory and real-world practice! And remember too that every item you notice is a step along the way: we never actually ‘arrive’ as such – as we do with an academic qualification or a framework-certificate – but somehow discover one day that we’re already doing that work, and never noticed the change.

So in a sense you are already an enterprise-architect: the only difference is one of scope (beyond IT itself) and scale (beyond the business-unit, and even beyond the organisation). So enjoy! – have fun!

I hope it’s been useful, anyway – and thank you also for asking the question.

My best wishes to you and to your colleagues
– tom graves