Rolling Review

I have long argued for the benefits of an outside-in view of business architecture. In 2008-9, Tony Bidgood and I developed a worked example based on the fictional delivery company Springfield Parcels, to illustrate a range of different business improvement paradigms and modelling notations. One of the key insights from this material was the importance of modelling your customer's process as well as your own. See also my post on Customer Orientation (May 2009).

A few years later, I worked with a regulator that had a complex relationship with the industry (industries) that it was regulating. The regulator's processes consisted largely of a series of complex responses to external events and activities, so I built a business service architecture to provide an outside-in view.

In those not-so-far-off days, regulated companies submitted meticulously compiled dossiers of information to the regulator for review and adjudication. This was a highly sequential and slow process, each stage typically taking several months if not years.

This delay was always a particular challenge in industries such as pharmaceuticals, where regulatory approval is needed before a new drug can be put on the market.

The UK drug regulator, the Medicines and Healthcare products Regulatory Agency (MHRA) was already looking at changing this sequential process before the COVID-19 pandemic struck. With the new Rolling Review approach, the regulator is able to start pre-assessment during the late clinical trials, and substantially reduce the time to market for innovative new treatments. This helps to explain the remarkable speed with which the COVID vaccines were tested and approved. The BBC Horizon programme includes a contribution from Christian Schneider, the MHRA's Interim Chief Scientific Officer.

The principle of rolling review also applies internally within organizations, where innovations often need to be reviewed from various perspectives. Some stakeholders prefer to wait until all the details of the innovation have been worked out, so they can be reviewed holistically. Others prefer to be involved as early as possible, since this provides more chance to influence the overall design and approach. Late involvement may seem a more efficient use of expert resource, but often leaves the expert with little more than a go/nogo decision.

We often see this dilemma with privacy and security. Advocates of security-by-design and privacy-by-design like to get in early; however, it may be difficult to carry out a rigorous Data Protection Impact Assessment (DPIA) if you don't yet know any of the answers to the questions on the template.

The fundamental point here is that all these side processes - regulation, assessment or governance - are only meaningful in terms of the main processes that they are regulating, assessing or governing. So it doesn't make sense to optimize the side process in isolation. The point is to innovate quickly and safely, not to make life easier for the regulators. And the outside-in business service architecture is a great tool for focusing everyone's minds on this.

---

ICO, What is a DPIA?

Sandra Kanthal, Marvellous Medicine (BBC Radio 4 - Horizon, 20 June 2021)

MHRA, Rolling Review for Market Authorisation Applications (UK Government, 31 December 2020)

Richard Veryard and Tony Bidgood, A Brief Evaluation of Business Modeling and Improvement Methodologies (CBDI Journal, December 2008)

Setting off Towards the Data-Driven Business

In an earlier post Towards the Data-Driven Business, I talked about the various roles that data and intelligence can play in the business. But where do you start? In this post, I shall talk about the approach that I have developed and used in a number of large organizations.

---

To build a roadmap that takes you into the future from where you are today, you need three things.


Firstly an understanding of the present. This includes producing AS-IS models of your current (legacy) systems, what data have you got and how are you currently managing and using it. We need to know about the perceived pain points, not because we only want to fix the symptoms, but because these will help us build a consensus for change. Typically we find a fair amount of duplicated and inconsistent data, crappy or non-existent interfaces, slow process loops and data bottlenecks, and general inflexibility.

This is always complicated by the fact that there are already numerous projects underway to fix some of the problems, or to build additional functionality, so we need to understand how these projects are expected to alter the landscape, and in what timescale. It sometimes becomes apparent that these projects are not ideally planned and coordinated from a data management perspective. If we find overlapping or fragmented responsibility in some critical data areas, we may need to engage with programme management and governance to support greater consistency and synergy.


Secondly a vision of the future opportunities for data and intelligence (and automation based on these). In general terms, these are outlined in my earlier post. To develop a vision for a specific organization, we need to look at their business model - what value do they provide to customers and other stakeholders, how is this value delivered (as business services or otherwise), and how do the capabilities and processes of the organization and its partners support this.

For example, I worked with an organization that had done a fair amount of work on modelling their internal processes and procedures, but lacked the outside-in view. So I developed a business service architecture that showed how the events and processes in their customers' world triggered calls on their services, and what this implied for delivering a seamless experience to their customers.

Using a capability-based planning approach, we can then look at how data, intelligence and automation could improve not only individual business services, processes and underlying capabilities, but also the coordination and feedback loops between these. For example in a retail environment, there are typically processes and capabilities associated with both Buying and Selling, and you may be able to use data and intelligence to make each of them more efficient and effective. But more importantly, you can improve the alignment between Buying and Selling.

(In some styles of business capability model, coordination is shown explicitly as a capability in its own right, but this is not a common approach.)

The business model also identifies which areas are strategically important to the business. At one organization, when we mapped the IT costs against the business model, we found that a disproportionate amount of effort was being devoted to non-strategic stuff, and surprisingly little effort for the customer-facing (therefore more strategically important) activities. (A colour-coded diagram can be very useful in presenting such issues to senior management.)

Most importantly, we find that a lot of stakeholders (especially within IT) have a fairly limited vision about what is possible, often focused on the data they already have rather than the data they could or should have. The double-diamond approach to design thinking works here, to combine creative scenario planning with highly focused practical action. I've often found senior business people much more receptive to these kind of discussions than the IT folk.

We should then be able to produce a reasonably future-proof and technology independent TO-BE data and information architecture, which provides a loosely-coupled blueprint for data collection, processing and management.


Thirdly, how to get from A to B. In a large organization, this is going to take several years. A complete roadmap cannot just be a data strategy, but will usually involve some elements of business process and organizational change, as well as application, integration and technology strategy. It may also involve outside stakeholders - for example, providing direct access to suppliers and business partners via portals and APIs, and sharing data and intelligence with them, while obtaining consent from data subjects and addressing any other privacy, security and compliance issues. There are always dependencies between different streams of activity within the programme as well as with other initiatives, and these dependencies need to be identified and managed, even if we can avoid everything being tightly coupled together.

Following the roadmap will typically contain a mix of different kinds of project. There may need to be some experimental ("pioneer") projects as well as larger development and infrastructure ("settler", "town planner") projects.

To gain consensus and support, you need a business case. Although different organizations may have different ways of presenting and evaluating the business case, and some individuals and organizations are more risk-averse than others, a business case will always involve an argument that the benefits (financial and possibly non-financial) outweigh the costs and risks.

Generally, people like to see some short-term benefits ("quick wins" or the dreaded "low-hanging fruit") as well as longer-term benefits. A well-balanced roadmap spreads the benefits across the phases - if you manage to achieve 80% of the benefits in phase 1, then your roadmap probably wasn't ambitious enough, so don't be surprised if nobody wants to fund phase 2. 


Finally, you have to implement your roadmap. This means getting the funding and resources, kicking off multiple projects as well as connecting with relevant projects already underway, managing and coordinating the programme. It also means being open to feedback and learning, responding to new emerging challenges (such as regulation and competition), maintaining communication with stakeholders, and keeping the vision and roadmap alive and up-to-date.

---

Related posts

• Embedding Intelligence into a Business Capability (December 2010)
• Organizing Business Capabilities (February 2012),
• Towards the Data-Driven Business (August 2019)
• Developing Data Strategy (December 2019)

See also

• Design Council: Double Diamond
• TOGAF: Capability-based planning

Towards an Open Architecture for the Public Sector

#diggovreview #publicsectorIT .

Attended an interesting workshop last week to discuss some of the architectural aspects of Digital Government, hosted by Skyscape. One purpose of this discussion was to feed into the Labour Party Digital Government Review, and possibly into the Labour manifesto for the next election. Under modified Chatham House rules, I believe I am permitted to blog about the workshop as long as I don't attribute anything to anybody or any organization.


There are several architectural themes that are probably shared between the political parties, although there may be some differences of emphasis and interpretation. For example, everyone seems to pay lip service to the idea of opening up public sector IT, and reducing the power of the incompetent and self-interested, whoever these may be. But there will undoubtedly be different views on the right tactics for redistributing commercial and bureaucratic power.

Openness leads to fashionable ideas about IT acquisition - a preference for consuming rather than self-build, and a preference for agile development rather than waterfall. These are great ideas when used properly, but we must be careful not to encourage the illusion that these ideas provide a magic solution to the troubles of public sector IT. Indeed, some recent IT disasters have been attributed to an ill-considered rush to "Agile". And the Buy-Not-Build agenda must be governed properly, to avoid ceding too much architectural control to the large platform providers.

Openness also means structural change. For example, a shift from vertical integration and vertical silos to lateral modularity and co-creation, which my friend and associate Philip Boxer calls Collaborative Composition. This connects with the notions of Shared Services and Platform.

Finally, there is the question of the tempo of change. Government policies have a fairly rapid cycle time - in some cases around 18-24 months depending on department - but we cannot afford to reengineer systems and services, let alone platforms, at this sort of frequency.

So there was considerable discussion about the role of Government in providing a platform, and whether the platform should be a Minimum Viable Platform (similar to the Internet) or provide added value. There was also some debate as to whether politicians could be persuaded to support systems and platforms that would last longer than the policies that they were intended to implement.

The Public Sector suffers, perhaps even more than other organizations, from a confusion between Requirement and Solution. So people like to talk about Open Standards or Agile as the solution to high IT costs, or advocate Big Central Database as the perfect solution to any information needs, instead of talking about the requirements, such as interoperability and low switching costs. I hope that the Labour Party (or any other party for that matter) can be encouraged to express its policies in terms of the requirements and governance approach, rather than mandating specific technological solutions.

As I've pointed out before, the term "Joined-Up Government" has several different interpretations. From an Inside-Out (supply-side) perspective, it is commonly taken to imply improved integration between separate government departments and agencies - in other words, some kind of reorganization, not merely of IT systems and services but also the agencies responsible for these services. Of course, reorganization might sometimes be needed, but this is merely one possible solution to the real requirement, which in my opinion comes from the Outside-In (demand-side) perspective - the citizen's need for a coherent experience of government services.

For example, the much-discussed integration between Healthcare and Social Care doesn't entail merging two massive and inefficient silos into one even more massive and inefficient silo, but could be achieved simply by opening up the silos and improving the flows of information between them. The Outside-In perspective merely calls for the citizen to get a coherent joined-up service across both healthcare and social care, however this may be done.

And consider the much maligned Contact Point, which had somehow morphed from an information sharing platform ("System of Engagement") to a Big Central Database ("System of Record"), largely under the control of people who didn't appreciate that these weren't necessarily the same thing.

Effective multi-agency working depends on effective information sharing, but this doesn't mean putting all the data into a single source of truth. Many of the breakthroughs of Digital Government have come, not from building massive central databases, but from improving collaboration between different agencies – health, social care, police, justice, etc – often dealing with the same problem families from different professional perspectives. 

---

Some of us have been talking about these themes for a long time. In my own small way, I have written a number of articles and blogposts about eGovernment and Joined-Up Government, and I submitted something on Shared Services to the Cabinet Office in January 2006, most of which is probably still valid. See previous posts on this blog - eGovernment, Joined-Up, Shared Services.

Philip Boxer, Creating Value in Ecosystems (December 2010)

Jerry Fishenden and Mark Thompson, Digital Government, Open Architecture, and Innovation: Why Public Sector IT Will Never Be the Same Again (Journal of Public Administration Research and Theory September 2012)

Mike Martin, Open Architecture Critique - A Draft (March 2014)

David Sprott and Richard Veryard, Shared Services for the UK Public Sector (Submission to the Cabinet Office, CBDI Forum January 2006)

Richard Veryard, Joined-Up Services (Review of the Public Management and Policy Association. February 2002)

Richard Veryard and Philip Boxer, Public Sector IT - The CSA Case (December 2004)

---

See also David Sprott's response to this post. Open Architecture for the Public Sector (May 2014)

Ecosystem SOA

The SOA world is finally catching up with some of the ecosystem ideas that I published in my 2001 book on the Component-Based Business (see my Slideshare presentation) and developed further in several articles and presentations for the CBDI Forum over a number of years.

• Supply and Fit (September 2000)
  
• Identifying Components 2 (October 2001)
• Opportunities in the Insurance Ecosystem (December 2004)
• Business Strategy Planning for the Service Economy (May 2006)
  

The biological approach to creating business and software services is radically different to the solution-driven approach, and is based on biological and ecological metaphors.

• First we identify an ecosystem, which may contain both human users and existing artefacts.
• Then we identify services that would be meaningful and viable in this ecosystem.
• Then we procure devices that enable the release and delivery of these services into the ecosystem.

I previously defined Three Types of Requirements Engineering, and we can map these onto different styles of SOA.

Solution-Driven (Specific)	Solution-Driven (General)	Evolution-Driven
Identify Business Problem Identify "Users" Negotiate Requirements Define Solution	Identify Domain Identify Domain Experts Define Requirements Design Solution Kit	Identify Ecosystem Identify Services Procure and Release Devices
Experimental SOA	Enterprise SOA	Ecosystem SOA

(Some people use the term Web Oriented Architecture (WOA) for what I'm calling Ecosystem SOA.)


If we regard these as phases of maturity, then we can have a straightforward roadmap from left to right, as in for example the CBDI SOA Roadmap. However, some organizations may need to tackle these styles of SOA in parallel rather than in sequence.

---

A service portfolio plan for Enterprise SOA can be based on an enterprise model that identifies the capabilities of the enterprise and clusters these into domains. In the CBDI Forum's SAE methodology, the domains are classified as Core and Contextual according to a matrix derived from Geoffrey Moore. (Note how the domains migrate around the matrix over time.) See for example my blogpost Tesco outsources core eCommerce.



A similar model, derived from Amin and Cohendet's book Architecture of Knowledge, explicitly describes Core and Periphery in terms of knowledge intensity. In other words, the reason something is classified as Core is because it encapsulates some important (strategic) knowledge.

For example, an insurance company knows more about insurance than about cars, so when providing car insurance it may decide to partner with other organizations that know more about cars than about insurance. This results in a composition of insurance-related services and car-related services (for example, determining the insurable value of a used car). Such compositions can be either directed (in other words, composed by a single dominant player) or collaborative (in other words, emerging from the interaction between multiple players within the ecosystem).

For example, an online retailer knows about her products and services, but doesn't wish to become an expert in credit card handling, or to be responsible for data protection and security, so she delegates these concerns to a specialist provider that knows more about these matters.

Similar considerations can apply to industry consortia, such as ACORD (for the insurance market). ACORD can define generic service-based assets (such as models, schemas, interfaces and so on) for insurance. However, insurance companies will also wish to use generic service-based assets to cover requirements that are not insurance-specific, such as customer management or complaints handling, where ACORD may not be able to add any knowledge-value, and it would be appropriate for ACORD to regard these as peripheral to its own activities rather than core.

---

So one approach to Ecosystem SOA is to push out from the enterprise into the ecosystem. John Hagel calls this Inside-Out Architecture, which he contrasts with Outside-In Architecture. (See my post on Outside-In Architecture.)


An Outside-In Architecture starts with a model of (the flows of) knowledge and value in the ecosystem as a whole. The strategic question for an enterprise is how to find way of both contributing value to the ecosystem, and drawing value from the ecosystem, through the provision of ecologically viable services.



For example, a telecoms company might reasonably consider that its core competence is something to do with communications. So a positional strategy would drive it to a dominant position in the middle of a large communication ecosystem, providing a platform of services that add value to a diverse range of communication activities by other people. The dominant position would allow it to negotiate a strong share of the value generated.

However, respect for the ecosystem would lead it to leave sufficient value to third parties to maintain the economic health of the remainder of the ecosystem. Instead of a simple positional strategy, a relational strategy (based on mutual trust with ecosystem partners) should produce a more sustainable and ecologically sound ecosystem.

---

Service Ecosystem from Richard Veryard


Related post: Ecosystem SOA 2 (June 2010)

Outside-In Architecture

Among many other interesting topics in his latest post (Unanswered Questions ...), John Hagel distinguishes between "inside-out" and "outside-in" architectures.

For Hagel, inside-out architectures are those that have evolved in many large organizations over the past couple of decades: starting from centralized IT architectures, gradually embracing distributed computing (client-server) and SOA, and very cautiously moving towards B2B. Such architectures are generally transactional, and controlled ("held captive" says Hagel) by IT architects.

A key challenge for inside-out architectures is the ability to connect and coordinate activities across large numbers of independent business partners, and to scale up to large and highly complex service-based ecosystems. Hagel believes that outside-in architectures will provide better support for complex collaborative ecosystems. He calls this relational - not using this term in the traditional IT sense ("relational databases"), but focused on supporting business relationships (and long-term business transactions) rather than short-term transactions.

The term "outside-in" seems to have a range of overlapping meanings, including:

• Looking at your business from the customer's perspective. There are several consultancies that claim to offer this as a service. For example, here's a curious page on the Outside-In company - with painfully bad graphic design and a revealing spelling mistake ("ourside in"). See also High-Yield Methods.

• Business-driven systems. For example, Zapthink uses the term to refer to "flexible business processes that respond to the way humans work, rather than processes that constrain humans to work the way the systems want them to work".

• Strategic Outsourcing. See for example What India and China can teach us about Innovation by Hagel and Seely-Brown.
  

• Outside-in SOA. This term seems to have been coined by Dave Linthicum, and refers mainly to interaction with external services (SaaS). See also Chuck Allen.
  

These are all very interesting trends to be sure, but is there a deeper pattern underlying some or all of them?

• Some of them are largely about extending the scope of the solution - finding new (more cost-efficient, more flexible) ways of satisfying the same old requirements. I think strategic outsourcing and SaaS come under this heading.

• Some of them are about extending the scope and perspective of the requirements - trying to add value to the customer's process, not just your own internal processes.
  

• And some of them hint at the need to reframe architecture itself - looking at the positive space between systems and organizations, not just the systems themselves.
  

Hagel avers that outside-in architectures must be "designed from the outset to support sustained collaboration". I agree that these opportunities call for a new kind of architectural thinking, and I agree that it may not always be easy to make the transition from existing inside-out architectures; but I think the evolutionary path is possible, given sufficient business motivation.

Value Deficit

Roman Rytov has blogged before about services from the consumer perspective. (For example, my previous post on Self-Service draws on his ideas about customers having access to their own CRM data.) In his latest post, he blogs about flaws of frequent flyer programs and sensitivity to customer needs. He points out that the standard reward point program, as provided by airlines, hotel chains and other service providers, is no longer working. It doesn't provide real competitive advantage to the service provider, and fails to accommodate the needs of different categories of customer.

For many customers, one of the most important differentiators is between private travel (where the customer is paying) and business travel (where someone else is paying). Rytov imagines (probably correctly in most cases) that private travellers would prefer to receive compensation for delays or other service shortfalls in the form of a cash refund ("the internet in your room was a bit slow - okay we'll delete that item from your bill"), while business travellers would prefer to receive extra airmiles or reward points.

But how is the service provider supposed to differentiate between private travellers and business travellers? I don't think this is as easy as Rytov asserts, and I don't think it should be that easy. Am I flying to Las Vegas for a business conference or a weekend of excess - and do I really want this to be public knowledge? Surely the best approach is to allow the customer a choice between alternative compensation schemes, rather than try to second-guess the customer's preference based on an attempted invasion of the customer's privacy.

But there are larger problems with the whole pseudo-economy of reward points, which this kind of differentiated service will not address.

• The schemes are complicated, with all sorts of arbitrary restrictions, making it practically impossible to compare like with like. Benefits are tied, and are generally not transferable. This increases the transaction cost, and reduces the economic efficiency of the market. This exemplifies a general pattern of dysfunctional service relationships - see review of Support Economy on this blog.

• The schemes are closed. Given that there is a value deficit, there is a theoretical opportunity for an independent service provider to create some value-adding services, perhaps through some kind of mash-up. But something tells me that the airlines and hotel chains would be less than enthusiastic about such innovation; and I doubt that the schemes are open enough to make such mash-up feasible.

• The schemes are primarily designed to reward employees, ultimately at the expense of their employers. I am sure there are lots of people who take extra business trips, with questionable value to the business, in order to win or retain some privileged status with the airline. Therefore the whole economy of reward points and airmiles only appears to be value-adding if you ignore the companies that are ultimately funding it.

Of course SOA thinking (such as differentiated service or context-based service) can be used to put sticking-plaster on the current schemes. Rytov is correct as far as he goes - service providers certainly need to be more sensitive to customer needs. But I believe there is an opportunity for much more radical and genuinely value-adding transformation.

• Can we unbundle the services? Why am I paying the hotel for the internet connection? Why isn't the hotel just providing me with a platform of services, from which I can compose my own experience? Who pays whom for what?

• Can we decouple the services from the reward point program? Surely there are economies of scale for the providers, as well as increased flexibility for the consumer, if reward points are transformed into some form of exchangeable token. Especially as the reward point program has long since ceased to be a focus of innovation or competitive advantage, and has become a tiresome necessity.

Retail Tagging

In order to maintain some kind of control over the Veryard household finances, we resolve to monitor how much we spend in different categories. These are of course our private categories, and do not necessarily correspond to the categories defined by the retailer. For example, we buy lots of books; some of them are intended as birthday presents, some of them are for the children, some of them are work-related, and so on. One category: Christmas Presents; another category: School Requisites.

At the end of the month, we get statements from the bank and from various shops, showing the amounts spent using several different cards. Translating these data into a more useful form is tedious - it requires a combination of recollection, receipt-shuffling and manual data entry.

What I'd like to be able to do is attach categories onto each item at the time of purchase. My monthly statements from the bank and other service providers will come in XML format, with all transactions broken down using my own categories and ready to be imported into a spreadsheet or accounting program. Surely with the explosive growth of tagging this facility shouldn't be too far off now?

The retailers will no doubt be delighted with the extra data; it will give them access to another level of meaning over our purchasing behaviour. Meanwhile, traditional banks will be horrified by the cost and disruption to their antique systems, and may well resist any innovation.

Did I say monthly? Make that real-time please. I want all my service providers to populate my personal data warehouse (on some server somewhere, permanently linked to my Blackberry, with appropriate BI tools thrown in), using my own tags and alerts.

From the demand-side perspective, this sounds too good to be true. What makes it radical (and therefore probably hard for the supply side to comprehend, let alone implement) is that it puts the user (and context of use) at the centre of the service environment.

Most service providers put themselves at the centre. This is a vending-machine metaphor of service: the user puts in some coins, makes a selection, and gets a bar of chocolate. We can specify the behaviour of the vending machine as a series of use cases, and design a system from these use case specifications. But this design approach (which is very common, not only among SOA methods) is exclusively supplier-centric and develops no understanding of the demand-side.

(I am aware of the user-centric design movement, but this is often little more than user-centric interface design - in other words, website navigation, with no basis for a broader analysis of the service economy. And even this is strongly resisted by a supply-side-dominant software industry.)

Our approach to SOA modelling embraces the demand-side as well as the supply-side. At present, we believe this is unusual if not unique.

Update: I just found a post by Rebecca Dias requesting something similar. She wants some technology that saves time producing expense reports. There are some responses to this request in the comments following her post. But the categories on my expense form don't match the categories defined by the retailer. The restaurant receipt doesn't show whether I'm just having dinner on my own or entertaining a client, but this difference is important when I do my expense report. So I think some form of user-defined tagging is an important requirement here.

Rebecca Dias, iPAQ without a phone, why bother? (30 November 2004 via WaybackMachine)