Digital Transformation: On your marks, get set…

Digital transformation is turning from hype to reality - So says the findings from a recent PWC Industry 4.0 global research survey. Research participants plan to invest as much as US $960 billion per year over the next 5 years (spending as much as the equivalent of 7% of turnover in certain geographies) in new digital products and initiatives.

So, is this relevant to Enterprise Architects? We would argue that EA practitioners are best equipped to deal with challenges such as:

* bridging from digital strategy to execution/ delivery and business benefits realisation

* guiding delivery of change to be quick and cost-effective, by identifying the high-leverage change areas and low hanging fruit

* balancing digital transformation with various other change agendas, in a manner which is analogous to solving all 6 sides of a Rubick's cube: not too difficult to solve for 1 side, but it takes a different level of thinking to simultaneously solve 5 other sides without muddling things up!

EA practitioners are ideally placed to guide digital transformation stakeholders through a process to define and develop affected Business and System Capabilities against a Digital Maturity Model (DMM). Evolving EA techniques and deliverables, including Business Models, Operating Models and Channel Architectures, could be instrumental in getting real dialogue going, and forming a deep understanding of business needs and affected Business Capabilities.

EA practitioners must then lead efforts to interpret business needs in terms of affected baseline and target System Capabilities, including those related to Web/ Mobile, Social Media, Big Data/ BI, Cloud and Internet of Things. In bridging the baseline/ target capabilities gap, a number of well-established EA concepts are bound to come into play, e.g. Information Management and Boundaryless Information Flow (given the premise to support business activities anywhere, anytime and from any device).

Make sure that EA at your organisation is in an “on your marks, get set…” position for Digital Transformation!

Three Ways in which Business Architects help Improve the Success Rate of Acquisitions, Mergers or Business Unbundling

Corporate mergers, acquisitions or unbundling initiatives are intended to bring about net wealth creation for shareholders. However, researchers have found that intended benefits rarely accrue to stakeholders as planned (apart from the shareholders of a business being acquired - who typically receive a premium to the market value (1)).

Realising potential benefits associated with economies of scale/ scope, market power, synergy or efficiency improvements (and other stuff they teach MBAs), are often easier said than done.

Fact is, the realisation of potential benefits depends largely on management teams’ ability to drive post-merger/ acquisition/ unbundling processes in an effective way.

Fortunately, help is available!

Numerous Business Architecture Techniques and Deliverables have been used successfully to inform executive decision-makers about the viability of deals before-hand, and to subsequently plan and deliver change initiatives. 

One: Frame It!

An essential part of a Business Architect’s approach is to define a framework which can help individuals and teams to cope with the complexity and sheer volume of information and inter-relationships. Business Architects (or the good ones, at least) are also adept at using Modelling and Knowledge Management software tools to accelerate efforts associated with Data Gathering, Analysis - including identifying relationships and dependencies that might otherwise be overlooked - and Visualising and Sharing findings.

Two: Let’s Get Capable

View fullsize

Several case studies in business architecture literature have documented how Business Capability and Value Stream analyses have been successfully used as a basis for strategic value and process alignment across reporting structures and lines of business (2). And by assessing the appropriate degree of top-level process standardisation (or differentiation) and information sharing across business building blocks (the essence of the Target Operating Model), management teams have succeeded in identifying the top-priority change areas, to realise benefits from the merger/ acquisition/ unbundling (3).

Three: Make the Dog Wag the Tail

The beauty of rigorous Business Architecture techniques and deliverables is that they easily extend to IT Architecture efforts, to facilitate IT changes that often need to follow from merger/ acquisition/ unbundling initiatives.

1. Birkinshaw, J., Bresman, H. & Häkanson, L. (2000). Journal of Management Studies 37:3 May 2000

2. Ulrich, W., McWhorter, N. (2011). Business Architecture: The Art and Practice of Business Transformation. Meghan-Kiffer Press. Tampa, Florida.

3. Ross, J.W., Weill, P. and Robertson, D.C. (2006). Enterprise Architecture as Strategy. Harvard Business School Press. Boston, Massachusetts.

Public Private for Banking

With all the scary stuff about identity fraud, banking scams on the internet and the issues around disclosing bank details, I wondered why banks don't take a leaf out of the encryption book? In sending secure messages it is common practice to have the concept of a public and a private key. A message is encrypted using a public key, but can only be decrypted by someone with the matching private key. So, I can publish my public key on my website or in email without compromising security. 

The same idea could be used by banks to protect our accounts from withdrawal. We often need to provide banking details for someone to deposit money - at least that is the intent. But the same details could potentially be exploited to withdraw money. My point is that we could have "deposit only" accounts in the banking system which would only allow deposit transactions. This would mean that we could freely publish these details without concern. Within the bank, there would be a linked account with another number, known only to the owner of the two accounts, from which withdrawals could be made. 

Funnily enough, the cryptographers got the idea for the public / private key from bankers - the physical system used to protect safety deposit boxes where both the bank and the owners keys had to be present to open the box.  

Customer Service?

Today I was searching for images for a new website. I wanted something to represent delivery of desirable outcomes for customers. I searched images libraries on the term "customer service". Interesting: about 60-70% of the images were related to a smiling call centre operator or something similar. That jarred for me. I don't know of a single person (aka "customer") who actually likes dealing through or with a call centre! Call centres are mostly a way to push customers away from real person interaction and save the delivery organisation money. How can that be a symbol for customer service?

Many "customer centricity" drives in organisations equally miss the point. One consulting client, when we asked about their stand on customer centricity replied: "We take it very seriously, we have 3 ongoing projects and 7 CRM systems" - Oh boy, what are the chances of any client of theirs receiving seamless service...

Better that we start from the outside in. We like to use a model called a Stakeholder Net Value Exchange. This puts the service organisation at the centre, as a single box, with no detail of its internals (deliberate: we don't want to see the org structure, or the processes, or the systems.. These are mechanisms to achieve delivery chosen at some time in the past). We do want to see the interaction of the organisation with the outside world and what value it adds. We show all external stakeholders (customers, suppliers, government, community etc. ) on the outside of the organisation; what they provide to the organisation and what they expect from it in net terms. E.g. for a bank, a customer might provide us with deposits and expect interest and capital growth. Here is an example:

After we discover who we are dealing with and what they expect, then we can begin to drill down to how that interaction should occur, from the external party's perspective. Then we can design a customer experience to match. Finally, we can create the internal (or outsourced) mechanisms to deliver that.