What is enterprise? What is architecture?

What the heck is ‘enterprise-architecture’? Why are there are so many arguments on this, so many conflicting opinions?

Perhaps a key clue is in the fact that there is so much argument about this? And that maybe the best way to resolve it is to accept that the argument is itself an essential aspect of the architecture?

The background here is that we’d planned a three-way debate on “What is EA?” at the BCS-EASG (British Computer Society – Enterprise Architecture Specialist Group) conference in London last week. For the debate, our plan was that Daljit Banger would argue for the idea that EA is and should be centred on IT; Petra in’t-Veld Brown would argue that it should be centred around business-architecture; whereas my line would be that there should be no ‘centre’ at all – that of necessity, everywhere and nowhere is ‘the centre’ of an architecture, all at the same time.

To support my position in the debate, I’d prepared a set of questions for the participants to play with, to explore the themes for themselves. In the event, though, we did the debate a different way, and the question-set I’d set up didn’t get its airing.

Yet it’s a set of concerns that I’ve so often been asked to address – such as in my recent videos on ‘The boundaries of an enterprise‘ and ‘Organisation, enterprise, structure, story‘ – that it seems worthwhile to put that question-set out there for more general use:

— A: What exactly is ‘architecture‘?

In many jurisdictions, ‘architecture’ is a protected-term, relating only to design and construction of physical buildings. In a more colloquial sense, though, we see it being used in all manner of different contexts: IT-infrastructure architecture, brand-architecture, data-architecture, process-architecture, chip-architecture, applications-architecture, security-architecture, business-architecture, skills-architecture, software-architecture, financial-architecture and many, many more.

In which case, what is an architecture? What is it that links together all of these usages in such disparate domains? For example, is it primarily about structure? – about models and suchlike? To what extent is it also about story? – the drivers for the respective context? Is it about the balance between structure and story? And where does governance come into the picture? – governance of implementation of an architecture, and/or of the architecture itself?

— B: What exactly is ‘enterprise‘?

Is ‘enterprise’ the same as ‘organisation’? – or is there a distinction between ‘organisation’ and ‘enterprise’ that’s important to architecture? Does the term denote a specific type of role? – does it apply only to commercial organisations, or any type of organisation? Does the term denote a particular scale? – for example, that it only applies to organisations above a specific size, or any size at all? Or is there something else entirely that’s in play here?

Right now, we’re coming up to the 50th anniversary of the first moon-landing, so let’s use that as an example:

What exactly was ‘the enterprise’ in that context? If we think of ‘enterprise’ as organisation’, was it just NASA? Or did it include others in the consortium of US organisations that designed and built the launchers, the landers, all of the equipment for the missions? Did it include the broader international consortium of support-facilities such as ‘The Dish‘ at Parkes, New South Wales, through which the TV transmissions for the first moonwalk came? Did it include ‘competitors’ such as the Russian, Chinese and other national space-organisations?

If we think of ‘enterprise’ as ‘a bold endeavour’, what was the respective endeavour? Just one moon-landing mission? – or all of them, from Apollo-11 to Apollo-17? Should we include all the other Apollo missions? All of the other US space-missions, before and after Apollo? To what extent would we include other moon-missions from other nations in the same enterprise? Space-explorations in general? Only crewed-missions, or robotic missions as well?

Or could and should we extend this enterprise to include the overall story? – the dream of spaceflight and suchlike?

In each case, where do we draw the boundary of ‘enterprise’? Why draw the boundary there, and not elsewhere? Who decides on that boundary? Why do they get to decide that’s the right boundary?

— C: What content-types and constraints in the enterprise must the architecture address?

To continue with the NASA example, what are the content-types for that enterprise? – the asset-dimensions of hardware, data, people-relations, brands and more? What are the processes, services, events, locations, capabilities, skills, decisions, that interact with each of those assets and resources? What are the implications of non-negotiable constraints such as gravity, radiation or the speed of light? What are the uncertainties and unknowns – whether known or unknowable? What must you do about contingencies, about events and interactions that can be identified and resolved only at run-time? What architecture and design do you need for disruptions, disaster-recovery, business-continuity, in the event of any breakdown from any direction?

How will each of these vary for each distinct stage on the change-management lifecycle, from initial ‘I have a dream’ to end-of-life decommission? What’s different in each case? How long must everything last? What happens to each item when it’s no longer needed in that form? What aspects of that lifecycle must the architecture address? If not all of the lifecycle, why not?

Perhaps most important, who or what would be responsible the parts that this architecture would not address? What are the boundaries of responsibility here, across the enterprise as a whole?

Now apply the same questions to your own architecture context. For example, what industry are you working in? – because each will have their own content, their own assumptions, expectations and frameworks. And what are the constraints in that context? – for example, speed-of-light is a very real constraint for any working on chip-design or on global-scale communications, such as almost any internet-addressable web-site. What does that tell you about the actual scope of your architecture? – and about who or what must be responsible for the parts of the enterprise that your architecture doesn’t address?

— D: How, for whom, and by whom this architecture developed, delivered and maintained?

Who uses the architecture, for what purpose, with what expected outcomes? What is it that is ‘delivered’, over what timescales, to serve what needs?

Can the work be done only by members of the organisation itself? What role, if any, could or should external consultants play? – for example, how valid is it to talk about ‘Enterprise-Architecture As A Service’?

— Given all of the above, what exactly is ‘enterprise-architecture‘?

How do ‘enterprise’ and ‘architecture’ fit together, as ‘enterprise-architecture’? How does the result differ from other forms of architecture? – what makes it distinct from those other architectures?

In short, it’s probable that the only real answer to the question ‘What is enterprise-architecture?’ is some variant on the Architect’s Mantra:

“I don’t know…
it depends…
we need just enough detail to get the right answer for this context…”

In other words, it’s like the old tale of the blind men and the elephant: everyone has a valid interpretation from their own perspective, yet none of them can see the whole. The arguments arise not just because each of the blind men thinks that they alone have the right interpretation, yet also because they refuse to acknowledge that the whole is more than they alone can perceive. More than that, it’s actually greater again than the sum of all of those views.

Our own answer to ‘What is enterprise-architecture?’ is whatever we choose it to be – as long as it relates in some way to both ‘architecture’ and ‘enterprise’. Everyone’s interpretation is different, because everyone’s choices are different, and the constraints placed upon us in our own context are often different, too.

Hence the way we will all get best value from the discipline of enterprise-architecture is this: to put an end to the fighting – because, to use a phrase from Edward de Bono, “Everyone is always right, but no-one’s ever right” – and instead learn from others’ understanding and experience of enterprise-architecture to expand and extend our own.