Business Architecture Grid

In some of my posts, I have used the terms vertical and horizontal in relation to Business Architecture. The purpose of this post is to analyse what these terms actually mean.

Firstly, the word vertical is often associated with value chain thinking. Typically, there is a process that spans from the raw materials to the finished product or service, and this process may either be divided between different actors or controlled by a single actor. Where a single organization controls the end-to-end process, this is known as vertical integration.

Large organizations typically have several versions of these processes, or even several entirely different processes. Bunding these into a single organization only makes economic sense if they can share resources and other stuff. For example, if procurement is done jointly, this may give the organization more buying power.

So there are typically a number of cross-cutting concerns, which may be referred to as horizontal. TOGAF 9 (released in 2009) identified "rich domain knowledge of both horizontal, cross-cutting concerns, such as human resources (HR), finance, and procurement alongside vertical, industry-specific concerns" as fundamental to Business-Led SOA.

So one version of horizontal integration involves establishing shared capabilities or services, which may support multiple value chains. Even when these value chains are distributed across different companies across different market sectors, one actor may seek to dominate the provision of these shared services, whether by merger and acquisition, technological superiority, or sheer market power.

In a 2005 discussion on Efficiency and Robustness, Stu Berman commented

The US economy is remarkably resilient to a wide variety of shocks (9/11 is a good example, as is Katrina) due to our horizontal integration rather than vertical. It is easy to look at history and see where colossal economic problems occurred - Soviet central planning, Nixonian gas price controls. via Chandler Howell

I have always argued that Business Architecture requires multiple Viewpoints. One reason for this is that the Activity or Value Stream viewpoint concentrates on the vertical dimension, while the Capability or Service viewpoint concentrates on the horizontal dimension. (Further viewpoints are required, because business architecture is not simply a two-dimensional problem.)

Note that the terms vertical and horizontal also appear in discussions of technology architecture, where they mean something rather different.

 

---

Further discussion

Efficiency and Robustness: Central Planning (September 2005)

Business-Led SOA (February 2009)

Towards an Open Architecture for the Public Sector (May 2014)

 

See also

Philip Boxer, The Double Challenge (March 2006)

Richard Veryard, Six Viewpoints of Business Architecture (LeanPub, 2012)

Another Update on Deconfliction

As the situation in Syria goes from worse to worser, the word "deconfliction" has reappeared in the press. On Friday, following a chemical attack on the Syrian population apparently by the Syrian government, the USA bombed a Syrian government airbase.

 "Russian forces were notified in advance of the strike using the established deconfliction line. US military planners took precautions to minimize risk to Russian or Syrian personnel located at the airfield," said a Pentagon spokesperson.

A few hours later, the Russian Foreign Ministry announced it was suspending the deconfliction agreement, accusing the Americans of "a gross, obvious and unwarranted violation of international law".

The normal purpose of deconfliction is to avoid so-called "friendly fire". But in the case of the deconfliction line in Syria, a more practical objective would be to avoid minor incidents that might escalate into major war. (Anne McElvoy quotes a senior former British commander in Iraq talking about the jeopardy of the next crucial months in Syria: "powers tripping over each other – or America hitting the Russians by accident".) We might fondly imagine that the Pentagon and the Russian Foreign Ministry still share this objective, and will continue to share a limited amount of tactical information for that purpose, despite public disavowals of coordination. Deconfliction as minimum viable coordination.

Much less serious, and therefore more entertaining, is the "friendly fire" that has meanwhile broken out within the White House. Gun metaphors abound (cross-hairs, opened fire). Successful businessmen understand the need to establish clear division of responsibilities and loose coupling between different executives - otherwise everyone needs to consider everything, and nothing gets done. But this is not a simple matter - excessive division of responsibilities results in organizational silos. Large organizations need just enough coordination - in other words, deconfliction. It is not yet clear whether President Trump understands this, or whether he thinks he can follow President Roosevelt's approach to "creative tension".

---

Bethan McKernan, Syria air strikes: US 'warned Russia ahead of airbase missile bombardment' (Independent, 7 April 2017 11:42)

May Bulman, US air strikes in Syria: Russia suspends agreement preventing direct conflict with American forces (Independent, 7 April 2017 15:39)

Matt Gertz, Breitbart takes on Jared Kushner: Steve Bannon is shielded as Trump’s son-in-law is in the crosshairs (Salon, 6 April 2017)

Matt Gertz, To Defend Bannon, Breitbart Has Opened Fire On The President's Son-In-Law (Media Matters, 6 April 2017)

Anne McElvoy, Washington is confused by Trump’s act. What became of America First? (Guardian, 9 April 2017)

Reuters, Kushner and Bannon agree to 'bury the hatchet' after White House peace talks (Guardian, 9 April 2017)

---

Related Posts

What is Deconfliction? (March 2008)
Update on Deconfliction (November 2015)
The Art of the New Deal - Trump and Intelligence (February 2017)

Functional Organization at Microsoft

@iamjaygreene and @jimkerstetter of @CNETNews are not surprised by the departure of unpopular Windows boss Steven Sinofsky from Microsoft.

• Jay Greene, Steven Sinofsky: Microsoft's controversial Mr. Windows 8 (CNET 21 October 2012)
• Jim Kerstetter, A tale of two execs: Microsoft's Sinofsky and Apple's Forstall (CNET 3 November 2012)
• Jay Greene, Shocked by exit of Microsoft's Sinofsky? You shouldn't be (CNET 12 November 2012)

Some pundits (e.g. ZDnet's Larry Dignan) had predicted that Sinofsfy would survive if Windows 8 was a commercial success. By letting him go immediately after Windows 8 went live rather than waiting, Ballmer has clearly signalled that it is not about Windows 8 success but about something else.

In pieces written in the weeks before Sinofsky's departure, Greene and Kerstetter mention the following issues.

• Sinofsky successfully battled with Ray Ozzie for control of Windows Live Mesh. Ray Ozzie left Microsoft immediately after Ballmer folded Windows Live Mesh into Sinofsky's organization.

• According to unnamed critics within Microsoft, Sinofsky created a rigid product development process that puts more control in his hands and diminishes Microsoft's ability to innovate.

• In a similar fashion to Scott Forstall at Apple (who also lost his job recently), Sinofsky zealously promoted his group's work at the expense of the rest of the company.

• Manu Cornet's cartoon of Microsoft's organization chart is thought to be a reference to Sinofsky.

 

But this story isn't just about personality clashes and organizational politics. Sinofsky has championed an approach to organization structure, which he calls Functional Organization, and this is described in a book called "One Strategy: Organization, Planning, and Decision Making," (2009) co-written with Harvard Business School professor Marco Iansiti.

The Functional Organization builds management reporting lines around job functions -- such as product management, development, software testing. This may be contrasted with a Product Organization where multi-disciplinary teams work on specific feature sets together.

Sinofsky and Iansiti argue that functional organizations create clearer road maps for workers to march toward a final goal. However, critics within Microsoft disagree. Apparently referring to Sinofsky's Functional Organization, Charlie Kindel, another ex-Microsoft executive is quoted as saying that "it represents a siloed perspective, it represents an us versus them perspective".  Another former senior executive (unnamed) has referred to the approach as "Soviet central-planning", where tight control from the top squeezes out innovative thinking from below.

Announcing Sinofsky's departure, and the appointment of Julie Larson-Green as his successor, Steve Ballmer wrote "The products and services we have delivered to the market in the past few months mark the launch of a new era at Microsoft. To continue this success it is imperative that we continue to drive alignment across all Microsoft teams, and have more integrated and rapid development cycles for our offerings. ...  Her unique product and innovation perspective and proven ability to effectively collaborate and drive a cross company agenda will serve us well as she takes on this new leadership role".

(BBC News 13 November 2012)


So is this the end of the Functional Organization in Microsoft? Martin Fowler talks about the oscillation between FunctionalStaffOrganization and TechnicalStaffOrganization, essentially the same dynamics (he reckons) as drive the boom-bust cycle of EnterpriseArchitecture. (PreferFunctionalStaffOrganization). So perhaps now the cross-company silo-busting agenda will have the ascendency for a little while.

Except that the new organization also seems to attract the label "functional".

In a 2,700-word internal memo rich in management-speak drivel , Ballmer announced a "far-reaching realignment of the company that will enable us to innovate with greater speed, efficiency and capability in a fast-changing world". The various internal warring silos known as "product groups" will be disbanded and the entire company (97,000 employees) is to be rejigged on "functional" lines (engineering, marketing, advanced strategy and research), with the aim of "focusing the whole company on a single strategy".

John Naughton, How Microsoft spent a decade asleep on the job (Guardian July 2013) 

What are silos good for?

@markgould13 tells us why the silo doesn't work

Of course they do work - after a fashion. As Mark points out, they are resilient structures, from which we can infer that they serve some purpose for someone in the organization, or the organization as a whole. It is common (Mark calls it a cliché) to reject information or work silos in most organizational contexts. But what exactly is the alternative?

Another useful observation about silos is that they generally represent some attempt, whether planned or emergent, to decompose an organization according to some notion of specialization and clustering. When people complain about silos this could be because they reject any kind of decomposition, but what is more likely is that they dislike this particular decomposition pattern. However, anti-silo rhetoric is often pretty vague about the difference if any between silo (=bad decomposition) and autonomous loosely coupled functional cluster (=good decomposition), and architects who automatically dismiss all previous attempts to structure an organization as "silos" create much the same impression as plumbers and electricians who automatically criticize the existing plumbing and wiring.


The main issue with any decomposition (whether or not we choose to label the chunks as "silos") is the coordination between the chunks, and I think this is Mark's main point. He quotes someone calls Ed Smith as saying

"Insight is the gap and overlap between silos."

Thinking about the requisite coordination between the chunks is an excellent route for understanding whether the architects should pay attention to the shape of the chunks or to improving the links and feedback loops connecting them. Or both. An architecture that is exclusively focused on cutting the enterprise into perfect chunks (relative to a fixed and abstract model of "the requirements") is probably not going to be much use in the long run.

---

Update

Chris Bird expanded his Observations on Silos (see comment below) on his own blog.

Excellent defence of silos by Venkat, The Silo Reconsidered

Interesting discussion on Linked-In - What are the advantages of working in silos?

 

Related post: Requisite Coordination (November 2010)

Differentiation and Integration 2

In my previous post on Differentiation and Integration, I mentioned the Operating Model propounded by Jeanne W. Ross, Peter Weill and David C. Robertson in their book Enterprise Architecture as Strategy (Harvard Business School Press 2006). I shall continue to refer to this book as RWR.

The publisher offers a pdf extract from the book, in which you will see the following diagram, depicting what RWR call a “traditional” approach to IT solutions. (It's a secure pdf, so I've had to scan my library copy instead.)

According to RWR, the “traditional” approach is characterized as follows

• Each strategic initiative results in a separate IT solution, each implemented on a different technology, producing a set of silos.
• The company’s data is patchy, error-prone, and not up-to-date.
• Companies often extract from silos to aggregate data from multiple systems in a data warehouse; but the warehouse is useful only as a reference – it does not offer real-time data across applications.

RWR cite a company whose systems were linked together so effectively that no human being ever touched a transaction (straight-through processing - sounds pretty integrated to me) but for some unspecified reason this provided “a lack of foundation for execution”.

Sounds like there is “good integration” and “bad integration”. Which brings us to the squiggles in the diagram. RWR appear to have adopted a notation in which “good integration” is denoted by straight lines and “bad integration” is denoted by squiggly lines. As far as I am aware, this notation has not been not formally defined, and is therefore purely a rhetorical device.

While I accept the need for enterprise architecture to create a powerful strategic narrative, I fear that these rhetorical devices permit and even encourage a kind of woolly uncritical thinking, which is not capable of dealing with the real challenges of enterprise strategy, and could easily be dismissed as intellectually lightweight by sharp CEOs presented with this kind of stuff. Vague diagrams with undefined notation are no substitute for proper analysis.

It doesn't matter how often the three characteristics identified by RWR above are found together, the key question is whether it is possible and practical to separate them. Is data sharing (as RWR believe) the only way to achieve “good integration”, or are (as I believe) other aspects of integration (coordination, organizational intelligence) more strategically important?

Contingency Theory

RWR identify two key questions for determining your organization’s strategy.

• To determine your organization’s integration requirements, ask yourself to what extent the successful completion of one business unit’s transactions is dependent on the availability, accuracy and timeliness of other business units’ data. (RWR p30)

• To determine your organization’s standardization requirements, ask yourself to what extent the company benefits by having business units run their operations in the same way. (RWR p30)

These would appear to be critical questions for enterprise architects to consider, so it would surely be useful to have some rigorous methods for analysing these questions systematically, instead of merely a few pen pictures of companies that have followed one or other path.

Furthermore, both questions seem to be questions of degree ("to what extent") rather than questions of kind (either/or) - so where are the examples of companies whose rightful place is half-way along the path, rather than at one or other extreme?

Differentiation

RWR then introduce the notion of strategic differentiation. "The operating model concept requires that management put a stake in the ground and declare which business processes will distinguish a company from its competitors." (RWR p43).

I find this statement puzzling, because there is no obvious connection between the two dimensions of the operating model identified by RWR (viz standardization and integration qua data sharing) and the idea of competitive differentiation.

There are methods that focus on identifying which business processes will distinguish a company from its competitors, such as the method developed by my former CBDI colleagues out of the ideas of Geoffrey Moore (see my post Tesco Outsources Core ECommerce) but this is not the same as the RWR method.

Shared Services

One way of achieving some kinds of standardization is through shared infrastructure. When talking about shared services, RWR implicitly shift the scope of “the enterprise” from a single organization to a partnership ecosystem.

“A strategic partnership forces a shared-services mentality, requiring business leaders to come to agreement on which services will be provided centrally and which will be provided locally.” (RWR p148)

The decision of which services will be provided centrally or locally is a matter of standardization, and therefore an aspect of enterprise-architecture-as-strategy.

Enterprise Architecture as Quantitative Practice

What I find troubling in many popular accounts of enterprise architecture, including RWR, is the apparent disregard for economics. RWR talk glibly about the costs and benefits of standardization, but they are not willing to explore the economies and diseconomies of scale, or the distribution of fixed and variable costs, and there isn't much meaningful quantification. Handwaving as strategy?

Intelligent Knowledge Management

@snowded has started a series of blogposts about knowledge sharing across silos (part one, part two). He starts by identifying a number of different types of knowledge that (some people think) it might be valuable to share.

• Data - avoiding duplication between data stores - for example consolidating all health records in a single database
  

• Information - ensuing all relevant information is available to support critical decisions and actions - see for example my post on Joined-up Healthcare
  

• Transactions - a sense that the citizen or customer has to navigate tortuous pathways through the bureaucracy

• Practice - good practice developed in one area is not appreciated or understood elsewhere
  

• Ideas - innovative combination and variation of issues, ideas, solutions and problems from within different silos

Obviously a mixed bunch of stuff here, and it seems very confusing to lump all of this under the heading of "knowledge management". As Dave points out, some of these look more like information flow. However, suppliers of knowledge management products and services (consultants and tool vendors) typically want to find as many different applications for their stuff as they can. Knowledge is therefore presented as a way of achieving a bunch of different things.

• more efficient information systems and working procedures
• improved decisions
• more effective and convenient customer service
• faster, more efficient and more consistent innovation
• greater cooperation and collaboration
  

Underlying the knowledge management agenda are a number of (usually) unexamined assumptions

• most of the knowledge we need already exists in people's heads - we just have to get it out
• knowledge is additive - the more knowledge we can "capture" or "extract" the better
• explicit knowledge is better than implicit or tacit knowledge - codification is a "good thing"
  

Thus knowledge management becomes a combination of documentation/codification and librarianship, plus whatever persuasion or coercion may be necessary to encourage people to participate in this game. Added to this is a kind of open-ended information retrieval, as exemplified by IBM's Lotus Knows campaign. (See my comments here.)

Undoubtedly there are some situations where this kind of thing can deliver direct value to the organization - for example in pharmaceuticals, where any delays in the assembly of regulatory information for a new drug can cost millions of dollars in lost revenue. But is this really knowledge management, or just a sophisticated form of information management?

An alternative approach to knowledge management is to leave it in people's heads, but then to provide knowledge maps that tell everyone whom to ask. The trouble with this approach is that the genuine experts often keep their heads down, for fear of being swamped with enquiries from around the globe, while attention-seekers use this as an opportunity to promote themselves. Thus questions of motivation and excellence must be addressed, and knowledge management becomes a branch of Human Resources.

---

Meanwhile, I've been reading a couple of older critiques of the 'knowledge management' industry.

• Erik Bergman, When bad things happen to good ideas (CIO, May 2001) via @rotkapchen
  
• T.D. Wilson, The nonsense of 'knowledge management' (Information Research, October 2002) via @oscarberg
  

Although these papers predate the recent explosion of web-based knowledge management tools (including Enterprise 2.0, however that is defined), the issues raised in these two papers largely remain unaddressed. Bergman points out that knowledge management is often regarded as a technological initiative. He mentions a number of very expensive white elephants, which failed largely because they failed to address the real business objectives or the real cultural and working practices of the organization. Wilson raises some more fundamental issues, suggesting that the knowledge management agenda is muddled and self-serving, and that Polyani's original concept of tacit knowledge has been grossly misinterpreted in order to promote an utopian fantasy of the manageability of the human mind.

So what (if anything) can we rescue from this mess?

Well we might start by shifting from "knowledge as a resource" to "knowledge as a process", as Gil Ariely argues in his paper Knowledge Management as a Methodology towards Intellectual Capital (Sept 2003, pdf). See also Interview with George Siemens (Dec 2009). Unfortunately, this phrase was long ago coopted by solution providers - for example in their paper Knowledge Asset Management, (June 2001), Ron Young and Gregoris N. Mentzas describe what they claim to be "one of the world’s first truly holistic and integrated knowledge management solutions". Holistic, huh?

Perhaps knowledge management shouldn't be about grabbing and hoarding stuff but about deploying it intelligently. This points us towards concepts like Evidence-Based Management, where knowledge is collected, analysed and deployed within a management loop. Consultancies promoting this and similar concepts include Pfeffer's and Sutton's Evidence-Based Management, as well as Management Epistemology. and the Knowledge Management Consortium - see for example the KMCI paper Corporate Epistemology (November 2003, pdf).

This kind of approach shifts the emphasis from knowledge sharing to knowledge embedding - grounding the work in the best available and critically evaluated knowledge, as well as actively seeking well-grounded knowledge to support organizational learning. Obviously collaboration is important here, but there is a distinction between collaborating-in-the-work (for example shared responsibility for decisions) and collaborating-in-the-knowledge (for example, shared responsibility for collecting and interpreting intelligence, connecting the dots). This distinction builds upon the RAEW technique we have long used for analysing organizations. A key question here is the relationship between decision and intelligence - how closely the expertise and authority should be coupled/aligned to the work itself.

What characterizes the intelligent organization is not just having more knowledge than its competitors, or even doing better at sharing the knowledge it has, but how effectively it invests its entire knowledge capital to increase its own viability and survival. This is so not a technology question, or even a best-practice question, but a strategic question. But you already knew that, didn't you?

---

see also When does Communication count as Knowledge Sharing?

Silo Culture at UBS

Following my note on Silo-Busting, I wanted to discuss a specific example - UBS.

On its website, UBS offers a full range of jargon-compliant banking services to other banks, including "straight-through processing" and a "modular client interface". It also claims that its approach is unique "because we implement this solution with you – and focus on integrating what have traditionally been functional silos". [UBS: Cash Currency Services]

I also found an advert on the UBS website entitled Global Cash Custody: Thinking Outside The Silos (pdf).

But how is this silo-busting reflected in UBS's own organization and business model(s)?

---

In April 2008, an internal report blamed "silo culture" for poor risk management across the group. In response, UBS merged the Group's Market Risk and Credit Risk functions into a single unit, with responsibility for the monitoring and controlling of the firm's overall risk exposure across credit, market and country risk, as well as performing portfolio analytics on risk evolution at the overall portfolio level. According to Joe Scoby, Group Risk Officer, "These changes are designed to establish a best in class Risk Control team with an overall view of all risks. The creation of an integrated portfolio and concentration risk group will help break down any remaining information silos between the different risk functions." [Reuters, May 2008. See also Risk Australia Spring 2008 and Online Financial News, June 2008]

Or perhaps not. On 12 August 2008, UBS announced that it was stepping away from its integrated model and establishing its investment-banking, wealth-management and asset-management divisions as stand-alone entities [Economist, 14 August 2008]. UBS chairman Peter Kurer said: “Our review has clearly revealed the weaknesses associated with the integrated ‘one firm’ business model. Some of these weaknesses – such as the blurring of the true risk-reward-profile of individual businesses – are the source of substantial risk, as we have seen in the past few months.” In other words, risks result from putting different businesses in a single silo. [Wealth Bulletin, 18 August 2008]

Writing in CIO Magazine, Chris Potts viewed this as raising two important questions for Enterprise Architecture: The Model or the People? [20 August 2008].

"Firstly, to figure out the balance in our own organizations between having the ‘right' business model, and everyone's collectively ability to manage it. But also, much closer to home, to remind us to strike an appropriate personal balance between modelling our organization's EA, versus influencing the people who manage it in practice and invest in changing it. "

I think there are two deeper questions here. Firstly, enterprise architects need to be thinking of a business as a viable sociotechnical system, which means (among other things) that management command-and-control capability must be included. Secondly, this management capability depends on how complexity is distributed across a large organization - the proper balance between differentiation and integration.

It is complete nonsense to imagine a straight choice between differentiation (completely different business model and organizational silo for each business line) and integration (completely uniform one-size-fits-all business model across all business lines). For me, one of the exciting aspects of service-oriented architecture is the degree to which it supports more sophisticated ways of getting the best of both worlds - differentiation AND integration. But this in turn requires a more sophisticated approach to business modelling. Which (sadly) many enterprise architects don't seem to be ready for.

It will be interesting to see how the current UBS experiment with organization structure pans out. This is certainly the sort of initiative that enterprise architecture should be able to contribute to. If anyone has any inside information, on or off the record, I'd be delighted to hear from you.

Business Value from SOA - Silo Busting

One of a series of posts exploring the business value from SOA.

---

A common complaint about legacy IT is that it is organized into silos. This doesn't just affect legacy systems, but it may also affect new projects.

In his classic book on the evolution of buildings (How Buildings Learn), Stewart Brand showed how the townscape often lasted longer than the buildings themselves. In an already built-up area, new buildings typically occupied the same footprint as the old building it replaced. The same is often true of new IT systems - the functionality may extend into previously unoccupied areas, but it is more difficult to make radical changes to the boundaries between systems. I have a lot about this in my 2001 book on the Component-Based Business.

But if the sponsorship and funding for new IT projects emerges from a host organization, and if the host organization is itself organized into functional silos, then it is hardly surprising when this structure is reflected in IT. This is an example of Conway's Law.

So we have long argued that new modes of IT sponsorship and funding need to be developed if an organization wishes to get maximum benefit from SOA. But what about the effects on the host organization itself?

There is now a strong pressure within the business world for silo-busting. This is nothing to do with IT, and everything to do with making business operations more effective and joined-up. Ranjay Gulati, a professor at the Harvard Business School, published an article on Silo-Busting last year (Silo Busting: How to Execute on the Promise of Customer Focus, Harvard Business Review, May 2007). He argues that "companies claim to offer customer solutions, but most aren’t set up to deliver them without specific changes in organizational structure, incentives, and relationships". I'm looking forward to reading his forthcoming book on the same subject.

A quick search for Silo Busting finds the idea applied to several areas of management.

• Healthcare ("health care organizations suffer from internal functional barriers that get in the way of achieving the level of success that they want and need"): Leta Beam (April 2006 pdf), R. Wade Schuette (September 2006)

• Marketing: Roy Young (April 2008)

• Retail: Eric Olafson (September 2007)

• Supply Chain: Robert Bowman (September 2008)

I also found some material from an improvisational comedy group, which trains managers to develop a silo-busting mentality (August 2003).

So this is a common theme within the business literature, and SOA offers strong support, especially for multi-channel operations.

---

Gulati identifies four success factors for silo-busting

• Coordination (Structure and Process - this is the first area where SOA and BPM can help)
• Cooperation (Sharing - this is where Web 2.0 or Enterprise 2.0 can help)
• Capability Development (this is perhaps where improvisational comedy comes in)
• Connection with Customers (there is a secondary role for SOA in providing joined-up customer-facing services)

But how much is this worth?

---

Conway's Law doesn't work in reverse. You can't just build joined-up systems and hope that the desired organizational change will follow automatically. There is always going to be a larger organizational change programme, with a significant but not exclusive role for SOA (and related activities, especially Service-Oriented Business Modelling). So it is hard to quantify exactly how much business value is created by the SOA piece. But we may be able to get some clues from the organizational change projects people are already doing ...