#eavoices

Enterprise Architecture Approach in an HE Institution: 10 Practical Steps

by

What’s particular about doing EA in a research-intensive HE Institution like the University of Bristol? For one thing the HE sector has some interesting dichotomies to grapple with such as the dual activities of a University like Bristol of both research and education. In a sense we are two businesses: the business of conducting research […]

National Decision Model

by

@antlerboy asks does anyone know theoretical underpinning of the (rather good) police decision-making model?

The National Decision Model (NDM) is a risk assessment framework, or decision making process, that is used by police forces across the UK. It replaces the former Conflict Management Model. Some sources refer to it as the National Decision-Making Model.

Looking around the Internet, I have found two kinds of description of the model – top-down and bottom-up.

The top-down (abstract) description was published by the Association of Chief Police Officers (ACPO) sometime in 2012, and has been replicated in various items of police training material including a page on the College of Policing website. It is fairly abstract, and provides five different stages that officers can follow when making any type of decision – not just conflict management.

Some early responses from the police force regarded the NDM as an ideal model, only weakly connected to the practical reality of decision-making on the ground. See for example The NDM and decision making – what’s the reality? (Inspector Juliet Bravo, April 2012).

In contrast, the bottom-up (context-specific) description emerges when serving police officers discuss using the NDM. According to Mr Google, this discussion tends to focus on one decision in particular – to Taser or not to Taser.

“For me the Taser is a very important link in the National Decision Making Model . It bridges that gap between the baton and the normal firearm that has an almost certain risk of death when used.” (The Peel Blog, July 2012). See also Use of Force – Decision Making (Police Geek, July 2012).

ACPO itself adopts this context-specific perspective in its Questions and Answers on Taser (February 2012, updated July 2013), where it is stated that Taser may be deployed and used as one of a number of tactical options only after application of the National Decision Model (NDM).

Of course, the fact that Taser-related decisions have a high Google ranking doesn’t imply that these decisions represent the most active use of the National Decision Model. The most we can infer from this is that these are the decisions that police and others are most interested in discussing.

(Argyris and Schön introduced the distinction between Espoused Theory and Theory-In-Use. Perhaps we need a third category to refer to what people imagine to be the central or canonical examples of the theory. We might call it Theory-in-View or Theory-in-Gaze.)

In a conflict situation, a police officer often has to decide how much force to use. The officer needs to have a range of tools at his disposal and the ability to select the appropriate tool – in policing, this is known as a use-of-force continuum. More generally, it is an application of the principle of Requisite Variety.

In a particular conflict situation, the police can only use the tools they have at their disposal. The decision to use a Taser can only be taken if the police have the Taser and the training to use it properly. In which case the operational decision must follow the NDM.

More strategic decisions operate on a longer timescale – whether to equip police with certain equipment and training, what rules of engagement to apply, and so on. A truly abstract decision-making model would provide guidance for these strategic decisions as well as the operational decisions.

And that’s exactly what the top-down description of NDM asserts. “It can be applied to spontaneous incidents or planned operations by an individual or team of people, and to both operational and non-operational situations.”

Senior police officers have described the use of the NDM for non-conflict situations. For example, Adrian Lee (Chief Constable of Northants) gave a presentation on the Implications of NDM for Roads Policing (January 2012).

The NDM has also been adapted for use in other organizations. For example, Paul Macfarlane (ex Strathclyde Police) has used the NDM to produced a model aimed at Business Continuity and Risk Management. which he calls Defensive Decision-Making.

How does the NDM relate to other decision-making models? According to Adrian Lee’s presentation, the NDM is based on three earlier models:

  • The Conflict Management Model (CMM). For a discussion from 2011, see Police Oracle.
  • The SARA model (Scan, Analyze, Respond, Assess) – which appears to be similar to the OODA loop.
  • Something called the PLANE model. (I tried Googling this, and I just got lots of Lego kits. If anyone has a link, please send.)

There is considerable discussion in the USA about the relevance of the OODA loop to policing, and this again focuses on conflict management situations (the “Active Shooter”). There are two important differences between combat (the canonical use of OODA) and conflict management. Firstly, the preferred outcome is not to kill the offender but to disarm him (either physically or psychologically). This means that you sometimes need to give the offender time to calm down, orienting himself into making the right decision.

And the cop needs to stay calm. George “Doc” Thompson, who taught US police a de-escalation technique known as Verbal Judo, once said “We know that the most deadly weapon we carry is not the .45 or the 9mm, it is in fact the cop’s tongue … A single sentence fired off at the wrong person at the wrong time can get you fired, it can get you sued, it can get you killed.”

So it’s not just about having a faster OODA loop than the other guy (although clearly some American cops think this is important). And secondly, there is a lot of talk about situation awareness and anticipation. For example, Dr. Mike Asken, who is a State Police psychologist, has developed a model called AAADA (Anticipating, Alerting, Assessing, Deciding and Acting). There is also a Cognitive OODA model I need to look into.

However, I interpret @antlerboy’s request for theoretical underpinning as not just a historical question (what theories of decision-making were the creators of NDM consciously following) but a methodological question (what theories of decision-making would be relevant to NDM and any other decision models). But this post is already long enough, and the sun is shining outside, so I shall return to this topic another day.

Sources

Michael J. Asken, From OODA to AAADA ― A cycle for surviving violent police encounters (Dec 2010)

Erik P. Blasch et al, User Information Fusion Decision-Making Analysis with the C-OODA Model (Jan 2011)

Tom Dart, ‘Verbal judo’: the police tactic that teaches cops to talk before they shoot (Guardian 21 July 2016)

Adrian Lee, Implications of NDM for Roads Policing (January 2012).

Steve Papenfuhs, The OODA loop, reaction time, and decision making (PoliceOne, 23 February 2012)

National Decision Model (ACPO, 2012?)

National Decision Model (College of Policing, 2013)

SARA model (Center for Problem-Oriented Policing)

Related Posts
National Decision Model and Lessons Learned (Feb 2017)

Updated 28 February 2017

Not Another Framework? Part 2

by

In my last post Oh No! We need another Practice Framework,  I developed the earlier theme commenced in “Beware the New Silos”. I argued that the widely used frameworks are narrowly discipline centric and actually inhibit cross discipline working. I described how my own firm’s experiences have led to the development of a de facto framework, (we call it SOAM) and illustrated how this is essentially a value chain commencing with customer demand and finishing with value add to some enterprise.

I ended by sketching some basic principles concluding that we need a new framework that is goal driven and incorporates the entire value chain of capabilities, which of course may selectively reuse some parts of existing frameworks. In this post, I suggest a strawman that covers a) principles and b) capability model.

Before diving into principles, it will be useful to declare some scope. Our framework has developed from working with larger enterprises, both commercial and government in the area of business service and solution delivery. All of these enterprises share common issues that they have extensive legacy application assets that act as a serious inhibitor to business change, and successive, narrowly scoped solution projects over many years have often resulted in great complexity and technical debt. It is also common in my experience that enterprise architecture functions are routinely bypassed or ignored; that Agile methods have been attempted and found useful on narrow focused projects, but because of the constrained focus, tend to increase overall complexity of the ongoing application asset base; that consistent customer experiences are commonly compromised by narrow focused projects; and line of business managers in large enterprises are frequently dissatisfied with IT application service support.

The objectives of the framework are to:

– describe practices relevant to service and solution delivery in the digital business environment
– achieve a balance between short term goals and longer term objectives
– support progressive transformation to an enterprise comprised of independent business capabilities
– facilitate continuous, short cycle time evolution of business capability
– progressively and continuously resolve legacy portfolio complexities
– enable rapid delivery at low cost without compromise in quality

Principles are foundational for any framework. 

Principles should be enduring and lead to both excellent policy communication and policy interpretation in everyday situations. I also find it useful to classify principles by subject.

Capability Model

In business architecture the capability model has become ubiquitous. And in thinking organizations I observe delivery of highly independent service and solution components that reduce dependencies and the impact of change, as well as mirroring the IT architecture on the business organization. Why wouldn’t we use the same approach in defining a set of activities to deliver services and solutions?

If you are uncertain about the capability concept, it’s important to appreciate that the optimum business capability is one that enables:
– maximum cohesion of internal functional capability, plus consistency of life cycle, strategic class (core, context, innovating . . . ), business partition (global, local, LoB . . ), standardization, customizability, stability, metrics and drivers
– defined, stable dependencies that are implemented as services
[Further reading on capability optimization ]

In the capability dependency model below, the arrows are dependencies. For example, Demand Shaping is dependent upon Conceptual Business Modeling and Portfolio Management.  So this is not a flow diagram, rather all the capabilities should be regarded as iterative, I will come back and discuss how Lean principles operate in a framework like this, and as discussed above, highly independent.

Most of the capabilities in the model are self-explanatory. However some need explanation:
1. The Conceptual Business Modeling capability is the ability for business stakeholders to describe business improvement in conceptual terms. Many business people speak in solution terms. Most business requirements therefore surface as solutions, some more baked than others. Because the business stakeholder generally has the budget, the solution vision frequently drives and shapes the project with outcomes that frequently compromise the existing and planned portfolio. By educating business stakeholders to communicate in concepts, the opportunity is created to develop the business improvement idea without preconceptions of implementation or product, and to optimize architectural and portfolio integration. 
2. Demand Management is reasonably well understood. Demand Shaping is best regarded as a complementary capability that takes raw customer demand and decomposes into components such as pre-existing or planned services/APIs, considers opportunities for modernization and provisioning, and reassembles as a set of projects or project components that optimize the progressive development of the portfolio. Demand Shaping is primarily an architectural task, but should be run by a cross functional team including architect, product management, business design and technical expert roles. 
3. The Architecture Capability is shown as a decomposition of sub-capabilities, essentially one for each View, plus modernization. Whilst modernization is not classically an architecture view, there is commonly a specialist requirement for modernization architecture that will include identification of appropriate transformation and transitional architecture patterns. The primary objective of all of the architecture sub-capabilities is to define realizable structure to meet the demand and, as discussed above, to optimize opportunities for modernization and provisioning. While there is no explicit enterprise architecture View called out, each architecture capability should be executed separately and iteratively for reference, portfolio, program, project and module, thereby defining progressive layers of standard functionality that will be common to the defined scope, as well as situation specific business functionality. 
I will detail all the capabilities in a subsequent post.

Final remarks. 

This high level view of the framework has attempted to list a set of principles and associated capabilities required to support the value chain illustrated in Part 1 of this extended blog post. What will hopefully have become clear is the need for architecture capabilities particularly to be involved throughout the value chain. This approach integrates all types of architecture (enterprise, service, solution, deployment  . . . ) into the business improvement value chain and creates better opportunity to demonstrate the ROI on architecture. Further the approach prevents enterprise architecture particularly becoming divorced from mainstream business improvement and encourages a better balance of short term and strategic goals. What will not yet be fully clarified is how the framework is very strongly focused on realizing architecture in delivered services and solutions, as a series of successive collaborations. I will describe how this is done using a Lean approach in a subsequent post. 
                  Beware the New Silos

Oh No! We need another Practice Framework?

by

A few years ago I commented [in Beware the New Silos, ref 1 below] that in a complicated world we cope by specialization – and across the industry in general and in individual enterprises specifically we have created silos of our primary disciplines. The widely used frameworks and methods illustrate that common practice of discipline centricity. We don’t have to look too far for examples such as Enterprise Architecture (TOGAF), Governance (Cobit), SOA (separately by OASIS, OMG, Open Group), Agile methods (many and various), Business Process Management (BPM) and IT Service Management (ITIL). All of these disciplines, whether de jure or de facto standards, are all very narrowly focused with minimal treatment of how the disciplines might work together.

A good example is how Agile methods are tightly focused on application development and architecture is assumed to be an integral part of the Agile delivery project. Yet the reality in all enterprises is that significant aspects of architecture must be consistent at the domain or enterprise level. Another good example is how the three standards bodies OASIS, OMG and the Open Group were so divergent in their treatment of SOA, they commissioned a report [ref 2 below] to explain how these inherently duplicating standards and specifications relate to each other.

The level of adoption by enterprises or service providers of all these and similar practice frameworks and standards is of course highly variable. However it must be said that the very existence of the discipline based materials will frequently have some considerable influence on how enterprises organize themselves.

The thinking IT or business professional might also like to question just how up to date these frameworks are, and how they support today’s business goals, which for most of us have changed dramatically over the past few years. We might also speculate whether the education and certification ecosystems that feed off some discipline based frameworks may discourage rapid evolution. A good example is how TOGAF maintains the core architecture style as application centric and treats SOA as a style extension. This is really quite extraordinary because by now everyone knows and many accept the digital business is going to be inherently service oriented. In practice of course the TOGAF specifications are so extensive that making fundamental changes may be very difficult, but it demonstrates neatly how legacy capabilities become “part of the furniture”, not just in frameworks but also in delivered systems and services.

Which brings me right back to the question – do we really need another practice framework? 

For several years now I and my colleagues have been evolving and implementing a different transformation approach. Initially we focused on SOA. And as many will know, we were fundamentalists in this area and we published detailed and open meta models for the service architecture and delivery life cycle based on “everything is a Service”. This approach has been very successful, particularly when the service architecture conforms with a strong layered reference architecture and rigorous componentization of services and business capabilities. But because we always knew that there was no such thing as a green field, we worked to harvest knowledge from existing systems. And over time we made a virtue of this,  focusing on continuous modernization as a matter of principle. More recently we have further evolved the approach to embrace Agile and MDD, establishing an agile service factory and generating code from rigorously defined service specifications.
But we found many of our customers struggled to implement a strategic SOA because business change was implemented project by project. And sure enough, project specific services and SOA have become ubiquitous; you might say almost a contradiction in terms. To counter this we advise that the demand management process should be complemented with demand shaping that decomposes the customer solution based demand to discover requirements for services and other sharable components and then re-aggregates the raw component demand into related projects that coordinate the delivery of business solutions and strategic services. 
But even though this approach works well at a project and technical level, we frequently encounter difficulty in persuading business stakeholders to balance short term advantage with more strategic goals. And we recognize this is because business stakeholders habitually make investment decisions on flawed criteria, because the ROI model only looks at the solution in isolation, rather than looking at the strategic opportunities to implement better architecture, address portfolio rationalization and reduce technical debt. This prompted us to find ways of working more effectively with business stakeholders. To encourage them to understand and indeed influence the conceptual business model and to understand a richer underlying business model that reflects a more comprehensive cost benefit model. And this helps to bring LoB managers into the conversation on demand shaping – balancing immediate solution requirements with longer term goals. 

In effect what we did was to establish a service and solution delivery value chain that commences with the raw customer demand and finishes with the delivery and integration of some useful business capability, but crucially with a much improved balance between immediate solution needs and longer term strategic goals. And it’s this balance that many enterprises find extremely difficult to achieve.
The core problem is that disciplines are vertically integrated; set up to optimize the discipline at varying levels of abstraction. In contrast the value chain approach optimizes across disciplines in pursuit of overall value chain outcomes. And this is only achieved by value chain activities that encourage effective collaborations between multiple capabilities and disciplines.

In the beginning we (Everware-CBDI) had a framework – Service Architecture & Engineering (SAE). The name makes it clear this is a forward engineering approach, and whilst it was very strongly business driven, it would be fair to say that the business modeling components were less well worked than the architecture, design and delivery. And as described we have very naturally, as part of the process of supporting large enterprise initiatives, expanded the framework capabilities and embraced an inherently Agile approach.

The principles underlying the framework now include:
– business capability based modularity
– pervasive service architecture
– continuous modernization
– service evolution not (one time) delivery
– model driven architecture and development
– everything is inherently agile – iterative, evolving, and narrowly focused on specific business capability delivery.

So to answer my own question, we clearly need a new framework. But it’s a very different practice framework to the ones that we are are accustomed to.
In our natural evolutionary process we recognized that the original (SAE) framework was merely one component of a much broader body of knowledge and practices. The new framework is goal driven, not discipline driven and incorporates the entire value chain of capabilities. But the capabilities are not standalone, they are effectively services that are executed in a way that supports the overall business goals of the enterprise, domain or program. We refer to this as  Service Oriented Application Modernization (SOAM).

Interestingly this is not a monolithic framework. It’s vital to treat the framework as a set of capabilities with defined services and dependencies. Some might say, “eating our own dog food”. In this way we don’t make the same mistake as legacy frameworks such as TOGAF, that are very difficult to keep current.

Finally what happens to the existing discipline based frameworks and standards? Of course they can be used in conjunction with the SOAM framework. But we do need to be careful not to just inherit monolithic capabilities. Increasingly we find it necessary to do this very selectively in order to use capabilities that fit and support the value chain. Perhaps in time the various disciplines will recognize the monolithic nature of their practices, and decompose and modernize into more goal oriented components. Meanwhile, in SOAM we have demonstrated that it is possible to reinvent the wheel.

Some SOAM Components:
    Agile Service Factory
    Agile Modernization
    Conceptual (Agile) Business Modeling
    SOA Reference Framework

Ref 1: Beware the New Silos

Aligning the Infrastructure Architecture with the Systems Application Architecture

by

Earlier this year we launched a new team within IT Services: the Technical Architecture Virtual Team. I lead this team, reporting via the Assistant Director of IT Services for Services Development (the team’s Sponsor) to the Senior Management Team. The team is made up of a small number of technical experts within the department, representing […]

The Zachman Framework – The Perfect Tool for Operating Model Management

by

I have written previously on this blog about leveraging Enterprise Architecture as a methodology for the Operating Model creation and management. In this blog post I will briefly outline mechanism and benefits of using industry leading Zachma…

Designing for Emergence

by

The world around us is becoming more complex, it is almost accelerating away from us. Being able to plan in this ever evolving world is becoming even more difficult as time passes.  New technology, and approaches almost appear daily, which makes planning for these events, almost impossible. Linear approaches to design are no longer the Read More