Business Network Optimization

Some @ATKearney consultants have written an interesting article on Business Network Optimization

"Anyone thinking about rationalizing a network would naturally ask whether so many nodes are really necessary. Networks are a great deal more complicated than that, and managing them requires expansive strategic imagination."

A simplistic accountancy view of a network looks at the direct contribution of each node. From this viewpoint, some nodes may not produce enough direct value to justify their continued existence, and there will be calls for these nodes to be closed or merged with their neighbours.

For example, there are several proposals currently under consideration within the UK National Health Service to rationalize Accident and Emergency provision by closing some hospital departments and relocating staff. These proposals are based on arguments about the optimal size of an Accident and Emergency unit, and on claims that smaller units are unlikely to deliver value for money or clinical  excellence.

Opponents of these closures point to the indirect effect of these closures, including the likely consequences on non-emergency healthcare services at those hospitals that will lack accident and emergency provision, as well as the wider social impact on the local community.

The example given in the A.T. Kearney article is the French postal service, and the authors assert the indirect value of the village post office, using an almost untranslatable French term l'animation du territoire, the "animation of the territory".

The Kearney article identifies three types of business network, which it calls Production, Service and Distribution, and eight elements of network management which must be optimized together. It calls these KNOTs, which stands for Kearney Network Optimization Tools, and asks us not to think of them as merely a laundry list of best practices used to build an optimal network. 



The article illustrates the concept of indirect value in terms of the cross-over between physical and online retailing. If a customer views a product in a physical store and then orders it online, the physical store is providing some indirect value to the retail operation as a whole. It is therefore makes sense to optimize the entire online/offline network as a whole, rather than regarding them as two separate networks. See my post on Showrooming and Multi-sided Markets (December 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.

Location, Location, Location

#pacelayering In Stewart Brand's theory, originally titled Shearing Layers and subsequently relabelled as Pace Layering, the slowest moving element of physical architecture was location, or what he (for the sake of alliteration) called Site.

An interesting example of the persistence of site has recently been published in the British Medical Journal. @DouglasNobleMD has found a remarkable similarity between two maps produced 120 years apart.

1. Here is a modern map showing the occurrence of diabetes in parts of East London.

 

2. And here is Booth's 1889 analysis of poverty in exactly the same streets.

Read more: http://www.dailymail.co.uk/news/article-2102485/Updated-maps-Londons-poorest-areas-epidemic-junk-food-diabetes-streets-Victorians-died-malnutrition.html#ixzz1mg5sbE3f

Even though the symptoms and immediate causes are different (diabetes and junk food versus malnutrition), the root causes of poverty remain in exactly the same locations.

---

Douglas Noble et al, Feasibility study of geospatial mapping of chronic disease risk to inform public health commissioning. BMJ Open 2012;2:e000711 doi:10.1136/bmjopen-2011-000711

Via Daily Mail, 17 February 2012

SOA and Enterprise Architecture

The old-style IT practitioner always regarded distribution as a source of complexity, and instinctively preferred non-distributed solutions wherever possible. The Service-Oriented Architecture turns this attitude on its head. The whole point is to distribute functionality across a network of services.

The well-known Zachman framework for Enterprise Architecture has a column for Network, but historically this has generally been regarded as referring to geographical location. Zachman himself calls this column “Where” – the other columns being Data (“What”), Function (“How”), People (“Who”), Time (“When”) and Motivation (“Why”).

But in a fully service-oriented economy, we must abstract away from geographical location. Web Services and related technologies allow the geographical location (and other physical locators) to be completely transparent. Instead, we can now interpret “Where” as referring to locations within an abstract topology or network.

In the service-oriented business we regard the enterprise as a (possibly federated) network of services. It is not geographical distance that matters any more, but abstract notions of distance, including commercial and semantic distance.

Service-Oriented Architecture Frameworks (CBDI Journal, December 2003)