Tuesday, July 31, 2012

Is there a place for LOCATION in Business Architecture?

#bizarch #entarch Most enterprise architecture frameworks put LOCATION into the business architecture domain. So am I merely being contrarian when I ask whether it really belongs there?

My first point is that some IT people may regard the business architecture domain as a dumping ground for anything that doesn't belong anywhere else. For example, TOGAF 9.1 includes a skills matrix and set of job descriptions in the business architecture (Chapter 8), and I found a framework called Lite EA that includes staff demographics. There is perhaps an idea that the business architecture includes all non-IT aspects of the solution architecture, including physical processes as well as human activity.

My second point is that business architecture doesn't just mean a complete collection of business-oriented IT requirements. Maybe some of the staff work from home on Fridays, and this has some important implications for IT systems and infrastructure, including security. However, people sometimes working from home does not affect the structure and behaviour of the business, so it's not really business architecture.

My third point is that a lot of these frameworks have evolved from earlier work, dating from an era when geography was (a) more significant and (b) more straightforward.
My fourth point is that there are some aspects of geography that may be indirectly relevant to business architecture. For example, the concept of jurisdiction - which set of laws and taxes apply to a given asset or transaction - although large firms employ armies of lawyers and accountants to quibble such matters. And many organizations define responsibilities semi-geographically - for example, which country manager or regional manager owns a given asset or transaction. However, these are often complicated by cross-border arrangements, especially between global enterprises, and cannot be automatically derived from geographical location. Even if we are interested in geography in the business architecture domain, it serves primarily as a classification rather than a set of elements.

My final point is that physical location belongs to an entirely different domain, which I want to call Physical Architecture, which might include office facilities, storage facilities, transport links, and suchlike. These are clearly necessary for the implementation of a particular solution to a geographically distributed business process, just as the computing and communication facilities are, but they aren't part of the business architecture.

This post has prompted two questions on Twitter.

Eric Stephens asked Are locations/buildings just tech? My answer: pretty much, yes. Le Corbusier said that a house was a machine for living in.

Alex Matthews asked Are you also going to separate time as a domain? My answer: I see neither time nor space as architectural domains, but as dimensions affecting one or more architectural domains. Clearly time affects several domains. The argument here is whether the business architecture domain is significantly affected by the spatial dimension. I don't think it is.

1 comment:

Tom Graves said...

Agree with all of your points above, and will add two more:

Physical location also matters a lot to IT, once the architecture moves down into the physical deployment space. In addition to the jurisdiction issues you mention above, there are all manner of practical concerns such as power-supply, cabling, cooling, racking and physical disaster-recovery, to mention just a few examples. There are lot of very serious risks - not to mention design-issues - that only become visible when we step out of a purely virtual space.

And virtual-locations are just as important architecturally as physical ones: think of IP-addresses, rack-IDs, cable-IDs, virtual-server IDs and so on.

In short, location in general is a fundamental dimension of every architecture - not solely of IT or 'business'-architecture.