July 2012 Events

Event	Dates	Location	Booking
Business Analysis / Big Data Forum	5 July 2012	West London (Hammersmith)	via Unicom
Assessing Intelligence	9 July 2012	Central London	via SCiO
Business Architecture Bootcamp	18-19 July 2012	Unicom Middlesex	via Unicom

Where were the architects at RBS?

#entarch Some interesting architectural implications of the recent embarrassing failure of banking systems at RBS-NatWest Bank, which has caused financial stress and distress for millions of customers.

A banking software expert quoted in the Guardian offered an interesting architectural analogy.

"Banking systems are like a huge game of Jenga [the tower game played with interlaced blocks of wood]. Two unrelated transactions might not look related now, but 500,000 transactions from now they might have a huge relation. So everything needs to be processed in order."

This analogy suggests that the problem is one of architectural knowledge and governance. This is always a problem for any large and complex enterprise, but outsourcing typically amplifies such problems. From the press reports, it seems that the implementation of the RBS-NatWest application architecture has been delegated to a bunch of relatively inexperienced Indians with little knowledge of the RBS-NatWest business.

The finger of blame is being pointed to CA-7, which I understand to be a middleware product responsible for the orchestration of complex batch runs. As recently as February, there were job adverts in Inda urgently seeking people with CA-7 experience for the RBS contract.

Distributes or centralize job submission, management and monitoring as you choose and simplify job management by automating as much as possible and provides a simple-to-use interface to manage your environment. CA 7® Workload Automation is a mainframe-hosted, fully-integrated workload automation engine that coordinates and executes job schedules and event triggers across the enterprise.

http://www.ca.com/us/products/detail/ca-7-workload-automation.aspx


The Guardian continues

It seems whoever made the update to CA-7 managed to delete or corrupt the files which hold the schedule for the overnight jobs, so they did not run, or ran incorrectly.

ComputerWorld quotes an RBS spokesman.

The focus right now is on fixing the problem, which was triggered during a software system upgrade.

and BBC's Robert Peston adds

the software update that went so badly wrong last Tuesday night was fairly quickly identified and patched by Royal Bank; it is the absence of a contingency plan to deal with the knock-ons from the initial computer failure that many will see as deeply troubling

I presume that CA-7 expertise involves the ability to create and maintain these control files. But these control files essentially contain executable metadata that describe how the applications must be joined up, which must ultimately be based on a rigorous view of the application architecture - in other words, a model of the application layer.

In my discussion of business capabilities, I have always said that the most troublesome capabilities (and the ones overlooked by most business analysts) are the coordination capabilities, and these are the ones that need the most care when outsourcing. The RBS-NatWest incident illustrates this point.

@davidsprott uses the incident to illustrate the need for application modernization. But was the problem in the core application systems, or was it in the platform layer?  

To the extent that application coordination is being managed via CA-7, it looks suspiciously as if the model of the application layer was embedded in the platform layer, and managed as if it was merely technical infrastructure. This suggests a fundamental architectural flaw in RBS systems - a failure to maintain a clean separation of concerns between the application layer and the platform layer.

This is one of the reasons why enterprise architecture is important. With clean separation and robust interfaces between the architectural layers (business, application, platform), we can carry out modernization, innovation and continuous change in each layer separately. This follows the principle of pace layering, based on the notion that each layer has a different characteristic rate of change. Without clean separation between layers, the layers shear apart, resulting in misalignment and system failure. And as @davidsprott points out, service enabling has exactly this (layer separation) outcome.

Conclusions

• It's risky outsourcing the core systems unless the architecture is clearly understood and controlled.
• Good outsourcing‬ requires a good service architecture, which may include business, app and/or platform services.
• Modernization requires good architecture.
• In complex systems of systems, coordination is a core business capability. Outsource with extreme caution.

---

Charles Arthur, How NatWest's IT meltdown developed (Guardian 25 June 2012)

Anh Nguyen, CA 'helps' RBS resolve tech problem that led to massive outage (ComputerWorld 25 June 2012)

Robert Peston, Is outsourcing the cause of RBS debacle? (BBC News 25 June 2012)

David Sprott, RBS Crash - Management Prefer Offshoring to Modernization? (25 June 2012)

See also Architecture as Jenga (September 2012)

The Cybernetic View

#bizarch One of the Six Views of Business Architecture is the Management View or Cybernetic View. To understand this view, let's start by asking what kind of thing management is.

One way of thinking about management is as a particular bundle of capabilities, such as planning, resource allocation, monitoring and control. These capabilities can be mobilized according to some routine schedule of activity (for example, the annual budget cycle), or in response to various events inside and outside the enterprise. So we can view management from a Capability viewpoint, or from an Activity viewpoint.

Another way of thinking about management is as a particular bundle of role and responsibilities. These may be presented as a hierarchy or matrix, although such depictions are usually highly simplistic. Management responsibilities may be controlled by a select group of senior staff, with "manager" or "director" or "officer" in their job title. Alternatively, they may be wholly or partially distributed to other staff along with various operational responsibilities. In any case, the real (defacto) distribution of roles and responsibilities is usually much more subtle and flexible than the official (orgchart) distribution. (cf The Four Organizations of Lord Brown.)

We may therefore view management at different levels of abstraction - either specifying the concrete division of responsibilities between named roles or even named individuals, or merely identifying the total set of responsibilities without allocating them to specific roles.

Both the Capability view of management and the Responsibility view of management are useful, but neither of these viewpoints really captures what is distinctive about management. Instead, we need to turn to a systems view of management, inspired by such thinkers as W. Ross Ashby, Russell Ackoff, Stafford Beer and Gregory Bateson. Let's call this the Cybernetic View.

The Cybernetic View is based on the idea of goal-directed behaviour, based on feedback and feedforward loops. This is elaborated into various frameworks, including Stafford Beer's Viable Systems Model (VSM).

A conventional interpretation of the Viable Systems Model is that it models an organization from the viewpoint of a neutral and all-seeing observer. The cybernetic literature can be divided into First-Order Cybernetics, which accepts this interpretation, and Second-Order Cybernetics, in which the position of the observer is itself problematic.

Bateson's work on Second-Order Cybernetics has directly or indirectly inspired many generations of management and organization scientists, including Chris Argyris, Donald Schön, Kenwyn Smith and Peter Senge, and I have used many of their ideas in my own framework for Organizational Intelligence. Some researchers are currently exploring Third-Order Cybernetics, but this is not yet mainstream.

The Cybernetic View should also embrace Robert Rosen's concept of Anticipatory Systems -

"A system containing a predictive model of itself and/or its environment, which allows it to change state at an instant in accord with the model's predictions pertaining to a later instant." Wikipedia

The Cybernetic View provides a useful complement to a conventional process view. As I pointed out in my post on Collaboration Impact Zones, AS-IS models can often be incomplete descriptions of reality, because they fail to document all the informal communication and coordination mechanisms that keep the business running. One way to discover these missing elements is to analyse the AS-IS models according to cybernetic or statistical principles, which may allow us to infer the existence of some coordination mechanism, even though we don't have any visible evidence of coordination taking place.


See also my earlier post Organizations as Brains.

My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/

---

Important note - I haven't read all of these papers myself yet, so I'm putting them here for my own reference as well as yours. Update: Professor Vidgen kindly dug out a paper he wrote ages ago. 

Sabine Buckl, Florian Matthes, Christian M Schweda, A viable system perspective on enterprise architecture management. 2009 IEEE International Conference on Systems Man and Cybernetics (2009)

Gil Regev, Ian Alexander, Alain Wegmann, Use Cases and Misuse Cases Model the Regulatory Roles of Business Processes. Business Process Management Journal, "Goal-oriented business process modelling" Guest Editors: Ilia Bider and Paul Johannesson Volume 11 Number 6 2005 pages 695-708

Richard Vidgen, Cybernetics and business processes: using the viable system model to develop an enterprise process architecture. Knowledge and Process Management, 1998.

Anders Jensen-Waud, Paradoxes in EA and Systems Research (April 2010)

Mohammad Esmaeil Zadeh, Gary Millar and Edward Lewis. Mapping the Enterprise Architecture Principles in TOGAF to the Cybernetic Concepts--An Exploratory Study (2012 45th Hawaii International Conference on System Sciences)

Mohammad Esmaeil Zadeh, Gary Millar and Edward Lewis. Reinterpreting TOGAF’s Enterprise Architecture Principles Using a Cybernetic Lens (Journal of Enterprise Architecture, May 2012)

Six Views of Business Architecture

#bizarch Does it make sense to produce a business architecture from a single viewpoint, such as a Process Viewpoint or a Capability Viewpoint? Or do we need a proliferation of viewpoints, perhaps arranged in a 2x2 matrix such as the Zachman Framework?

In its Business Architecture Overview, the Object Management Group Business Architecture Working Group has identified five key views of a business, which it calls 1) the Business Strategy view, 2) the Business Capabilities view, 3) the Value Stream view, 4) the Business Knowledge view, and 5) the Organizational view. See my previous post on the Five Views of Business Architecture (OMG), in which I also identify a sixth one, which I've been calling the Management or Cybernetic view. (Strictly speaking these are viewpoints rather than views, but I'm trying to stick to the OMG terminology as far as possible.)

I have used all of these views for business modelling, and I am convinced that they are all useful - although they may not all be required on every project. (I don't expect you to believe this without further evidence, and I am currently assembling a set of worked examples.)  I have presented earlier versions of this schema in the past, with slightly different names, but I believe the current names and explanations are clearer.

Business Motivation View (aka Purpose)

This viewpoint describes what the business achieves for itself and its stakeholders (direct and indirect value). It specifies desired, potential and actual performance in terms of goals and objectives as well as positive and negative outcomes. (For example, a risk is a potential negative outcome.)

Outcomes may be described qualitatively or quantitatively, and there are different analysis techniques and notations associated with the transition from quantity to quality.

A more sophisticated view would consider the uncertainty associated with these outcomes, as well as the potential conflict between the goals and values of different stakeholders. It would also recognize that there is often a subtle difference between the official or espoused goals and objectives of an enterprise and its defacto goals and objectives. See my post on Enterprise POSIWID.

The OMG calls this the Business Strategy view, but I think this is a misleading name. The strategy doesn't reside in motivation, but in how the business mobilizes itself to satisfy some set of motivations.

The name Business Motivation view reflects the Business Motivation Model (BMM), which provides some limited coverage of this view. Alternatively, I could call this the Business Performance view.

Business Capability View (aka Component)

This viewpoint describes how the business delivers direct and indirect value in response to the challenges of the environment. Many business architects merely decompose the business into something that looks like an old-fashioned functional hierarchy, but there are several important architectural issues that need to be addressed within the business capability view.

• Coordination of internal and external capability. When an organization chooses to delegate or outsource a particular capability, the coordination of the outsourced capability remains.

• Capability dependencies - how strength or weakness in one capability affects the performance of other capabilities.

• Requisite variety. An organization chooses what range and variety of events it is capable of responding to, and this variety is reflected in specific capabilities.

• Through-life capability management. Establishing a capability requires some level of investment, in terms of equipment and recruitment and training and so on. The costs of maintaining a capability may escalate, especially if the demands keep changing.

• Performance, quality and value-for-money. It is always possible to devote more energy and resources to improving any given capability, but this is only justified if it is reflected in business performance (aka "the bottom line"). Business excellence models (such as Baldrige and EFQM) address this kind of alignment.

Capabilities may be encapsulated in what I have called Business Components, as in my 2001 book on the Component-Based Business. Thus we could also call this the Component View.

Business Activity View (aka Process)

This viewpoint describes the day-to-day behaviour of the business, or what the OMG calls "business in motion". Traditionally processes are seen as a chain of value-adding process steps, thus the OMG calls this the Value Stream view. However, the value network paradigm looks significantly more powerful than the value chain paradigm, and I prefer to use the neutral term Business Activity.

Business Knowledge View (aka Concept)

This is a well-established architectural viewpoint, previously known under various names such as Conceptual Information Model or Business Data Architecture. It basically captures what the business knows, and the semantics of how the business talks to itself and its partners. This viewpoint is critical for business interoperability. Knowledge also includes contextual knowledge, which is essential for providing differentiated services.

At this level, I'm not distinguishing between data, information and knowledge. Classifying information as "structured" and "unstructured" is not as important to the business architecture as it is to the IT architecture. What is important, however, is the question of business epistemology - what it is possible for the business to know, and with what level of confidence. There are various sociotechnical mechanisms that may make it possible for a 21st century business to know all sorts of things that were simply not available before. But of course, the business architect is not directly interested in the mechanisms themselves - these belong to some other architecture.

Responsibility View (aka Organization or Relationship)

The OMG defines an organizational view in terms of the relationships between organizational units, so I think the term Responsibility View is a better name for this view. I have done a lot of work on business relationship modelling, looking in particular at questions of the organizational responsibility and accountability for activities and outcomes, and this work can be traced back to the ORDIT methodology of the early 1990s. These relationships and organizational interfaces may be represented as services, with various levels of formality in defining and measuring service levels. There are also important architectural issues in dealing with the idea of Business-As-A-Platform, in particular in relation to multi-sided markets.

Cybernetic View (aka Management or Governance)

Finally, the cybernetic view describes how the organization and its management thinks. This covers all the aspects of organizational intelligence, from information gathering, through sense-making and decision-making, to organizational memory and learning.

See separate post on the Cybernetic View.

Hybrid Views

These views are not sacrosanct, and there are some useful business models that may not fit neatly into these six viewpoints. For example, Martin Ould's Activity Role Diagrams seem to involve a combination of Activity and Responsibility, while Stafford Beer's Viable Systems Model combines the Capability View and the Cybernetic view.

I am also convinced that business strategy is not contained within a single view (as the OMG would have it) but is about the relationships between the views.

Levels of Abstraction

Each of these viewpoints can be applied at different levels of abstraction. For example, in business relationship modelling, we may identify a partner-independent model (which merely defines an abstract relationship with a notional business partner) and a partner-specific model (which defines a concrete and contractual relationship with a real business partner).  Meanwhile, in the capability view we may need to distinguish between abstract capabilities (which some frameworks regard as the only true capabilities) and sociotechnical lumps that implement these capabilities (which may be called components or nodes).

This relationship between abstract and concrete is what Zachman calls reification, and everyone else calls realization. Note that both the partner-independent model and the partner-specific model belong to the business architecture and not to any other architectural domain.

---

My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/