The Value that Enterprise Architects Deliver to Stakeholders in IT and Business

Scientific research has proven that Enterprise Architecture (EA), performed skilfully and collaboratively in complex business and systems environments, helps organisations to successfully achieve their strategic goals and objectives (Tamm, Seddon, Shanks, Reynolds (2011); Ross, Weil and Robertson (2006)). Many people in the industry see the “art and science” of EA as the nexus of business and IT, and a key enabler of corporate strategy.

Yet, despite such evidence, even the most skilled and successful architects sometimes face scrutiny about value realised from investments in EA. Organisational memories tend to be short, and there is often a time lag between expending EA effort and benefiting from the outcomes of EA effort. Clearly expectations need to be carefully managed and communicated.

It is therefor essential  that we frequently re-emphasise the value we add and re-energise support and buy-in from our sponsors, senior stakeholders and partners. The diagram below aims to provide a 1-page summary of the value gained from EA, drawing on the research as referenced above.

We trust this will be a useful reference, should you need to engage in some re-emphasis and re-energising activities in the future.

Information sources:
1) Ross, Jeanne W.; Weill, Peter; Robertson, David (2006). Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. Harvard Business Review Press. Kindle Edition.
2) Tamm, Toomas; Seddon, Peter B.; Shanks, Graeme; and Reynolds, Peter (2011) "How Does Enterprise Architecture Add Value to Organisations?," Communications of the Association for Information Systems: Vol. 28 , Article 10. Available at: http://aisel.aisnet.org/cais/vol28/iss1/10

Of Business Models and Operating Models

Say What?

We often discuss Business and Operating Models in our consulting and training engagements. These terms are frequently the source of unnecessary confusion, with people not being clear if they are synonymous or distinct concepts, or how they are inter-related. Our view, broadly supported by literature and leading practice, is that business models define how organizations will deliver value to customers in their target market segments in a sustainable manner, while operating models define the underlying arrangement of people, processes, systems and information needed to execute the business model.

Business Model Canvas, by Osterwalder and Pigneur

Osterwalder and Pigneur (2010) did a fine job to define a Business Model through their development of the Business Model Canvas framework in their book titled "Business Model Generation". Their succinct canvas-styled model has become popular amongst those involved in business strategy and innovation, where it serves as an excellent tool for brainstorming, developing different patterns, what-if analyses and the like. 

Hit and miss…

However, from the perspective of Business and Enterprise Architects, as key role players responsible for ensuring alignment between business strategy and IT capability, it seems that even with a well-defined strategic direction, the strategy execution process often still goes awry. It remains challenging for Operations and IT to determine how they need to respond to and act upon the chosen strategic direction, whether it is based on Customer Intimacy, Product Leadership or Operational Efficiency. 

Just get the basics right

Based on Business Model Canvas (by Osterwalder and Pigneur (2010)) and Gartner's Pace-Layered Application Strategy (2012)

We believe that this is where the fundamentals of Operating Model design, as defined by Ross, Weill and Robertson (see: "Enterprise Architecture as Strategy" (2006)), come into play. They call for designing and building a foundation of processes and systems - the essence of an operating model - by interpreting the chosen strategic direction in terms of the appropriate level of process and systems standardization and integration. Based on this insight and well informed, "overt" standardization/ integration decisions, organizations are able to specify the key architectural requirements and subsequently design and build foundational processes and systems, layer by layer. Using an approach akin to Gartner's pace layering model, the initial focus needs to be on routine business activities, digitizing these to a level where it becomes a stable and predictable platform. Achievement of stability at the foundational layer frees the resources to extend the foundation to the next layer (and then the next layer) of processes and systems, which enable differentiation and innovation. 

By using this approach, Operations and Systems team may still not be able to anticipate business changes, but they can increase the likelihood that the needed processes and information are either readily available, or can easily be provided. Inspired’s business architecture approach integrates these and other strategy techniques to accomplish this seamlessly. 

References:

Gartner (2012). Accelerating Innovation by Adopting a Pace-Layered Application Strategy (available at: https://www.gartner.com/doc/1890915/accelerating-innovation-adopting-pacelayered-application) 

Ismail, S., Malone M.S. and Van Geest, Y. (2014). Exponential Organizations: Why new organizations are ten times better, faster and cheaper than yours (and what to do about it). Published by Diversion Books.

Kim, W.C. and Mauborgne, R. (2015). Blue Ocean Strategy: How to Create Uncontested Market Space and Make the Competition Irrelevant. Published by Harvard Business School Publishing Corporation.

Osterwalder, A. and Pigneur, Y. (2010). Business Model Generation. Published by John Wiley & Sons.

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

 

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.

Digital Strategy

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

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.