If an enterprise is serious about becoming more digital then it needs to rethink how the business and IT parts of its organisation can better use their different perspectives and complementary capabilities to turn an idea for a digital customer experience from concept to reality as seamlessly as possible. David Trafford and Peter Boggis believe that to achieve this a new form of relationship model is needed: a model that’s based upon a shared language of digital collaboration that brings their respective world-views together in constructive dialogue.
All organisations are changing their trajectory to some degree; a change in trajectory that will take them to a more digital future. In fact IDC estimates that by 2019, companies around the world will have spent a total of $2.1 trillion on digital transformation with the aim of delivering more products and services digitally. Examples are General Electric, which has invested well over a billion dollars on transitioning to an industrial infrastructure business, underpinned by an industrial, data-analytics-based internet, and the UK Government which has recently announced its strategy for developing a world-leading digital economy that works for everyone.
Many organisations start their digital transformation by mapping out target ‘digital customer journeys’; but the real challenge is realising these journeys with what is technologically possible – not so much the newer digital technologies, but more the legacy applications that make up the IT landscape – a landscape to which the new digital applications will inevitably need to integrate. In many respects, it’s this legacy IT landscape that acts as a powerful navigating force, making it difficult for many organisations to transition to a digital trajectory. And it’s not only the more established organisations that experience this constraint: many of the digital enterprises that have emerged in recent years have actually been built upon a foundation of legacy applications.
In many respects this challenge is not new. From the early days of computing, it has been a continuous struggle for IT organisations to accommodate the ever-changing needs of their business colleagues, while at the same time ensuring that existing applications are well maintained and continue to operate smoothly. What’s different now is that technology is advancing at a faster-than-ever rate, and business colleagues are becomingly increasingly frustrated at the pace at which their IT colleagues are able to respond to the business opportunities offered by digital technology.
What lies at the heart of successfully transitioning to a more digital trajectory is how business and IT colleagues work together in defining and realising a digital future – a way of working that has not fundamentally changed since the early days of computing. This working relationship was predicated on the assumption that business colleagues focus on defining business requirements and IT colleagues focus on translating these requirements into IT capabilities. Some would argue that this model is not fundamentally broken – and for it to work better only requires business colleagues to learn more about IT, and IT colleagues to learn more about the business. Others – including us – would argue that, as we now operate in a very different context, a different relationship model is required. This change in context is characterised as follows.
Firstly, it’s often not appreciated – particularly by business colleagues – that the IT landscape, built and adapted over many years, can be extremely complex and difficult to change without risk of causing operational problems or even failing completely. Many of the applications are based upon legacy packages that are no longer supported by the original vendor and written in programming languages that are no longer used. Furthermore, how the landscape was originally designed and built was to support business operating models of the past; for example, business functions and products, as opposed to today’s focus on customers and processes. Such complexity creates a context where IT colleagues are cautious of making any changes for fear of the systems going down – as we have seen several times in recent months, particularly with a number of banks.
Secondly, in an attempt to satisfy business colleagues’ ever-increasing demands for rapid solutions to meet market and regulatory changes, and give customers an increasingly digital experience, IT colleagues have resorted to a behaviour that’s best described as being an ‘order-taker’, where business colleagues define requirements – and increasingly solutions – and IT colleagues translate them into IT capabilities. As a result, IT colleagues rarely challenge requirements (or solutions) given by business colleagues – even if they don’t believe they are the best option for the business in the long term – and instead focus their attention on building, testing and deploying the new, or enhanced, applications into an increasingly complex IT landscape. In many cases they have lost the ability (or will) to challenge business colleagues and take the conversation to a level that focuses on business outcomes, rather than short-term solutions based upon what business colleagues think is technically possible.
Thirdly, in some – particularly larger – organisations, business colleagues have been given (or have taken) the decision rights to engage third-party IT vendors to build applications – and the supporting systems – for them. In some cases this also extends to hosting. While these applications may well be in support of the ‘digital strategy’ aimed at creating a compelling digital customer experience, they are often built with little or no regard to their impact on the broader IT landscape. What’s often not appreciated is that this course of action in effect ‘outsources’ IT architecture decision rights to outside vendors who have no understanding of (or interest in) the broader architectural context of the enterprise. Often the irony is that IT colleagues are then expected to take accountability for the resultant applications as they become part of the extended IT landscape.
Fourthly, the increasing focus on delivering short-term business results – on which business colleagues are often incentivised – can result in myopic thinking, which in turn results in digital applications being added to the current IT landscape, thereby adding a further level of complexity. In these situations there is no interest in – or budget for – thinking about the longer term and the increasingly important need to map-out a multi-year programme to re-architect the IT landscape to one that better supports the digital agenda. The reality is that if an organisation is serious about transitioning to a truly digital trajectory, it will need to re-architect its IT landscape at some stage; the only questions are when and how?
Finally, parochial (business) ownership perpetuates fragmentation and duplication. While many business colleagues often bitterly complain about the functionality of ‘their’ IT applications, the cost of ownership and the difficulty of getting its functionality enhanced, they nevertheless become very protective when it comes to the applications being rationalised or ‘their’ IT applications being replaced with an integrated platform that will be shared with others. At one level, this reluctance to change what they know – even with all its deficiencies – is understandable because, as we all know, IT projects have a poor track-record with respect to coming in on time, to budget and to the required quality. Equally, if the strategic intent is for the organisation to become more horizontally-integrated – resulting in a greater degree of common and shared processes, resources, and IT applications – the IT landscape needs to be rationalised with the resulting applications, data and business rules being shared across multiple business units, processes, customer segments and territories. In our experience, one of the main challenges of achieving greater horizontal integration is that senior business colleagues are often reluctant to give up what they believe they own, simply because they believe they will lose control. The result is a proliferation of applications across the enterprise, with little or no synergy or enterprise-wide learning.
The basis of a new relationship model for business and IT
As organisations become more digitally-enabled and the internal IT function is no longer the sole provider of IT solutions, the way business and IT colleagues work together needs to change.
Some organisations are addressing this need by establishing business-IT relationship managers whose role is to be the ‘interface’ between the business and IT; others have created the role of chief digital officer (CDO), and some have devolved their IT function into the businesses they serve. While all these have their own merits, in themselves they are not the complete answer, as what is missing is the means by which business and IT colleagues can better collaborate: how their different perspectives and priorities can be better understood, and how their complementary capabilities can be best applied to turn an idea for a digital customer experience from concept to reality as seamlessly as possible. A process that not only delivers the target customer digital experience, but does so in a way that is cognisant of the resultant downstream cost of ownership and does not compromise – even ideally enhances – the ability of the organisation to incorporate future change.
We believe that this new model should be based upon a shared language, which makes the transition from business idea to IT-enabled reality a seamless process: a language of collaboration that brings their respective world-views together in constructive dialogue. We believe that this common language is the language of digital collaboration.
The language of digital collaboration
The language of digital collaboration enables communication and shared understanding through the articulation of business operating principles, operating model implications and architecture design principles.
Business operating principles
A business operating principle is a ‘conscious choice between two equally valid alternatives’. Or, to put it another way, we choose for the business to operate this way as opposed to that way. Furthermore, these operating principles should not only define the customer digital experience, but also how the organisation intends to operate enterprise-wide.
For example, a business operating principle defining a digital customer experience for a package holiday company could be:
‘Our customers have the opportunity to switch between the internet, tablet, telephone or seek in-store advice at any stage of their booking journey with us’.
as opposed to …
‘Our customer channels are independent of one another.’
Note that it’s equally important to define the alternative principle, as this explicitly defines how the organisation has chosen not to operate.
Assuming in this example that the organisation had different business units supporting its different brands focusing on different customer segments, a business operating principle defining how the enterprise intends to operate could be:
‘We operate as a horizontally-integrated company, with the highest possible level of common and shared processes, systems and resources – whilst recognising the need for authentic differences across the brands.’
as opposed to …
‘We operate as a holding company comprising independent, self-contained businesses.’
Further examples are given below.
|
Examples of business operating principles
‘We are a digital business where customers only interact with us via smart phones and tablets.’ ‘We value customers based upon their lifetime relationship with us.’ ‘Our business decisions are driven by a deep understanding of our customers’ behaviour.’ ‘Customer support and back-office functions are provided by shared service centres.’ |
It’s important to note that these business operating principles may initially be in conflict. For example, the digital experience that one unit intends to deliver to its customers may well be in conflict with the enterprise principle of delivering a shared experience across all brands. Our experience is that it’s better to identify these conflicts early on and make them explicit: only then can action be taken to resolve them. If they are not resolved at an early stage, greater conflict will result downstream and a compromise solution will emerge that no one will be happy with.
Operating model implications
The purpose of business operating principles is to define how we intend the business to operate in the future – both in terms of how we engage with customers and how we operate enterprise-wide. If these principles are different from those by which the organisation currently operates, there will be implications in terms of changes needed to the current operating model. One of the best ways of assessing these implications is to identify what capabilities need to be in place that are not currently present. Equally, which current capabilities will need to be strengthened and which will no longer be required. It’s important to note that these capabilities are not solely IT capabilities but organisational capabilities that comprise processes, tools, systems, mental models, standards, individuals’ competencies and, of course, digital technology.
In the package holiday company example above, in order to realise the operating principle ‘Our customers have the opportunity to switch between the internet, tablet, telephone or seek in-store advice at any stage of their booking journey with us’, the following capabilities would need to be in place. The ability:
- to uniquely and securely identify a customer.
- to identify, record and retrieve a customer journey.
- for customers to switch channels at any stage and continue their journey without interruption.
- for customer service agents – whether over the telephone or in person in a store – to ‘pick up’ a customer journey and provide advice and support as required.
- for customers to ‘restart’ their journey at any point.
By articulating the implications of the target business operating principles as capabilities that need to be put in place enables the feasibility of each operating principle to be quickly assessed. If the implications are significant, in terms of the time and resources required to put the capability in place, then the operating principles may need to be revisited. Equally, if the implications are not significant then they could be equally revisited in terms of delivering a more ambitious digital experience.
Furthermore, defining how the business intends to engage with customers in terms of operating principles – as opposed to detailed customer journeys – enables rapid assessment of the feasibility of what is being proposed. This in turn facilitates closer collaboration and shared thinking through rapid iteration of ideas and possibilities.
Architecture design principles
As with business operating principles, an architecture design principle is a ‘conscious choice between two equally valid alternatives’. Or, to put it another way, we choose to design the organisation’s operating model this way as opposed to that way. Furthermore, these architecture design principles cover all facets of the operating model, thereby forming a specification by which designers – whether in IT or organisational development – can redesign the operating model in a coherent manner.
Returning to the package holiday company example above, the specific architecture design principles would very much depend upon what changes need to be made to the current operating model and IT landscape. As a consequence they are very context-specific. However, by way of example the architecture design principles could include:
‘The complete customer journey is supported by automated business processes that require no manual intervention.’
as opposed to …
‘The complete customer journey is supported by a combination of automated and manually-executed processes.’
‘Customer data, product rules and business (process) rules are stored once and accessed by multiple applications.’
as opposed to …
‘Customer data, product rules and business (process) rules are replicated across multiple databases.’
When it comes to defining the IT architecture principles there is an increasingly important set of principles that don’t necessarily emanate from the business operating principles and their implications. These are the principles that enable, as opposed to restrict, future organisational agility. These are important because as the organisation becomes more digital it will want to become even more digital, and it’s therefore important that this trajectory is not impeded by the organisation’s ability to continually change and adapt its IT landscape.
These IT architecture design principles should also reflect what is now technologically possible. In recent years IT architecture design thinking has come a long way, as has the technology that enables this thinking to be realised. For example, using middleware technology and enterprise service bus (ESB) technology along with APIs (application programming interfaces) is increasingly the norm. As a result, there has emerged a set of generic IT architecture design principles to which organisations are increasingly adhering. Examples of these generic IT architecture design principles are given below.
|
Examples of IT architecture design principles
‘Only use applications that have APIs (Application Program Interfaces) and are compliant with Service Oriented Architecture (SOA) based architecture.’ ‘Integrate components via applications infrastructure and middleware.’ ‘Innovate at the ‘edge’ of the IT landscape rather than the ‘core.’ ‘Use (and re-use) application software components that are common and shared.’ |
Final thought
As organisations become more digital – and the technology enabling it becomes more pervasive – the traditional relationship between business and IT colleagues becomes less sustainable. It’s no longer about business colleagues defining requirements, and IT colleagues writing applications and configuring systems; rather it’s a joint, collaborative exercise in design that brings different perspectives and complementary capabilities together in a way that turns an idea for a digital customer experience into reality as seamlessly as possible. This requires different capabilities that are borne from different world-views and built on a language of digital collaboration that enables constructive dialogue. The benefit of this new working relationship is that it is based upon a language of digital collaboration that facilitates iterative, as opposed to sequential, design thinking. Ideas can be explored rapidly, and accepted or rejected quickly. Most importantly it’s an effective means for setting the organisation on a trajectory to a digital future.
We welcome your thoughts.
David Trafford
david.trafford@formicio.com
Peter Boggis
peter.boggis@formicio.com