Search Results for: business model

Designing Digital Change

by
Session Synopsis for Hong Kong, April 2016: 

In this session Mr. Nigel Green shares his experience of preparing organisations for the Digital World. He introduces key concepts that will help open-up the discussion of the implications, risks, and opportunities, of a digital strategy. Whilst the popular definition of “Going Digital” is often focused on digital channels for Marketing purposes, Mr. Green explains why it also impacts many areas of the organisation, and explains why it is not simply the CMO’s, CDO’s, or CIO’s challenge alone. He will also share tools and techniques used in the design & execution of the transformation to a digitally enabled business. In addition, he will discuss pragmatic next steps to take, and share ideas on how to contribute to a business-wide discussion on the subject.
This session should be of interest to anyone trying to get to grips with what “Going Digital” means to their organization, and how to start planning the change:
  • The components of a digitally-enabled Business Model
  • The implications & risks of adopting “Bi-modal IT”
  • How to design for the protection of existing core business systems whilst embracing the new
  • Dealing with an unknown future, and adaptive long-range planning
  • The dangers of “Big Design Up Front”, and perhaps paradoxically, why “Adaptive Design” is ever more crucial
  • The business and technology architecture implications – including a perspective on the applicability of a pattern adopted by the “born digitals” (e.g. Netflix, Google, and Amazon)
  • Suggested subject matter experts to track, follow-up research material, and next steps to take.

McKinsey’s nine questions for the digital transformation, how relevant are they?

by

what leaders should review, is alternative target operating models or big pictures and new business models for the enterprise, so that they can understand how the business will be changed and be able to make decisions.

Modernizing the modernization strategy

by

I was amused this week to be contacted by Researchgate, a syndication platform that have somehow republished my paper Enterprise resource planning: Componentizing the enterprise application packages that was originally published in April 2000 by the ACM. [ref 1] It was entertaining reading something I authored over 15 years ago, but quite refreshing that much of the thinking makes sense today. The gist of the paper was to discuss how some of the package vendors had responded to the impending Y2K event by componentizing and service enabling their packages, many of which at that time were exemplars of the worst monolithic application architecture (sic). At that time I observed that the componentization was a key factor in the huge growth of the EAI (enterprise application integration) market, and provided a genuine alternative to the conventional “buy or build” choice by enabling “buy, build or reuse”.

And this is really where my thinking has evolved considerably. Fifteen years ago we were very focused on transactional systems with a much lower requirement for flexibility. Today, and indeed for the past decade, I advise a radically different approach which is much more strongly business focused.

All too often the big question that bubbles to the surface is “should we buy or build?” And not surprisingly the buy option is often seen as an easier option because current systems are viewed as problematic and the organization has little or no competence in large scale systems development. In fact, for many organizations that have outsourced IT, development is not seen as a core business capability. So the question of buy or build becomes focused on whether a suitable package exists at an affordable price, where suitable means “supports our processes and information needs as we understand them today”.  And package vendors are well equipped to demonstrate how they have readymade and low risk capabilities that have high levels of configurability.

These days I advise a focus on just two important questions:

1. What are the systems requirements of our future business?
Many enterprises recognize their business models are changing rapidly and that there are numerous triggers, including technology, regulation, demographics, climate change, economics and more, that only indicate much more volatility. Most enterprises operate established sector specific models that have many conceptual elements that are shared with competitors, with clear areas of differentiation. Geoffrey Moore [ref 2] gave us excellent vocabulary to describe the Core and Context areas of our business, in which Core business capabilities should be highly differentiating and Context capabilities are managed to be equivalent to the competition, but no better. So the primary question to attempt to answer is, how might the balance between Core and Context shift over the coming years? If the shift is likely to be towards the Context, where competitive equality is a high probability outcome, then a buy solution “may” be appropriate if there is a package that really fits with the business model. This could well be true of highly regulated industries, semi-state organizations etc. However all the signs are that in the general commercial market there is likely to be a frenzy of innovation of core capabilities. That a high level of unpredictability inherent in some of the major triggers would indicate the most appropriate strategy will prioritize maximum flexibility  and response to change. And that leads on to the second important question.  
2. What are the cultural requirements of the future business? 
Everyone will recognize the extraordinary innovation culture demonstrated by organizations such as Amazon, Google and the vast numbers of start-ups leveraging technology opportunities. And this cultural paradigm shift is not restricted to so called Internet companies. Many large, conventional businesses recognize the existential threat and have responded, integrating bricks and mortar operations and processes with Internet portals, apps, IoT and B2B architectures. Crucially evolving their products and services in which information is an integral component. And most of these innovating companies are exploring Agile development practices demonstrating the extraordinary innovation, productivity and quality that can be achieved by a convergence of business and IT skills and expertise. Some of these organizations have reinvented their business models because they have been brave enough to change from command and control to delegated responsibility development models. They are demonstrating tomorrow’s enterprise is an information enterprise where conventional demarcation lines between IT and business need to be challenged and reengineered. Do packaged solutions have a place in such a high innovation culture? Of course – for the obviously Context areas of the business such as general ledger and receivables they make sense. But for Core business capabilities, a packaged solution must look like the dead hand of a commodity.
You may ask, “but back in April 2000 you expected a flourishing integration market, based on buy, build and reuse, why is that not applicable today?” And my answer is, “That actually happened in the noughties. But today we have a different challenge. Burdening creative people with huge integration and semantic transformation complexity is not a great way to reinvent the future business, as the past will be an anchor holding you back. Integration will be necessary and essential, but your core business architecture should be optimized as much as possible”
In a recent blog post I said, “modernization is not about achieving a new plateau of capability and functionality. Rather it is about enabling continuous, short cycle time response to change”. It’s about creating an Agile Enterprise.
CODA: Geoffrey Moore’s concept of Core relates to the centrality and mission critical nature of a capability. This should not be confused with the CBDI-SAE concept of Core Business Service, which is the service layer managing the state of the business. 
References:
1. Componentizing the enterprise application packages , David Sprott. ACM April 2000 
Researchgate  (public domain)
ACM (subscription or pay as you go)
2. Geoffrey Moore, Dealing With Darwin

Modernizing the modernization strategy

by

I was amused this week to be contacted by Researchgate, a syndication platform that have somehow republished my paper Enterprise resource planning: Componentizing the enterprise application packages that was originally published in April 2000 by the ACM. [ref 1] It was entertaining reading something I authored over 15 years ago, but quite refreshing that much of the thinking makes sense today. The gist of the paper was to discuss how some of the package vendors had responded to the impending Y2K event by componentizing and service enabling their packages, many of which at that time were exemplars of the worst monolithic application architecture (sic). At that time I observed that the componentization was a key factor in the huge growth of the EAI (enterprise application integration) market, and provided a genuine alternative to the conventional “buy or build” choice by enabling “buy, build or reuse”.

And this is really where my thinking has evolved considerably. Fifteen years ago we were very focused on transactional systems with a much lower requirement for flexibility. Today, and indeed for the past decade, I advise a radically different approach which is much more strongly business focused.

All too often the big question that bubbles to the surface is “should we buy or build?” And not surprisingly the buy option is often seen as an easier option because current systems are viewed as problematic and the organization has little or no competence in large scale systems development. In fact, for many organizations that have outsourced IT, development is not seen as a core business capability. So the question of buy or build becomes focused on whether a suitable package exists at an affordable price, where suitable means “supports our processes and information needs as we understand them today”.  And package vendors are well equipped to demonstrate how they have readymade and low risk capabilities that have high levels of configurability.

These days I advise a focus on just two important questions:

1. What are the systems requirements of our future business?
Many enterprises recognize their business models are changing rapidly and that there are numerous triggers, including technology, regulation, demographics, climate change, economics and more, that only indicate much more volatility. Most enterprises operate established sector specific models that have many conceptual elements that are shared with competitors, with clear areas of differentiation. Geoffrey Moore [ref 2] gave us excellent vocabulary to describe the Core and Context areas of our business, in which Core business capabilities should be highly differentiating and Context capabilities are managed to be equivalent to the competition, but no better. So the primary question to attempt to answer is, how might the balance between Core and Context shift over the coming years? If the shift is likely to be towards the Context, where competitive equality is a high probability outcome, then a buy solution “may” be appropriate if there is a package that really fits with the business model. This could well be true of highly regulated industries, semi-state organizations etc. However all the signs are that in the general commercial market there is likely to be a frenzy of innovation of core capabilities. That a high level of unpredictability inherent in some of the major triggers would indicate the most appropriate strategy will prioritize maximum flexibility  and response to change. And that leads on to the second important question.  
2. What are the cultural requirements of the future business? 
Everyone will recognize the extraordinary innovation culture demonstrated by organizations such as Amazon, Google and the vast numbers of start-ups leveraging technology opportunities. And this cultural paradigm shift is not restricted to so called Internet companies. Many large, conventional businesses recognize the existential threat and have responded, integrating bricks and mortar operations and processes with Internet portals, apps, IoT and B2B architectures. Crucially evolving their products and services in which information is an integral component. And most of these innovating companies are exploring Agile development practices demonstrating the extraordinary innovation, productivity and quality that can be achieved by a convergence of business and IT skills and expertise. Some of these organizations have reinvented their business models because they have been brave enough to change from command and control to delegated responsibility development models. They are demonstrating tomorrow’s enterprise is an information enterprise where conventional demarcation lines between IT and business need to be challenged and reengineered. Do packaged solutions have a place in such a high innovation culture? Of course – for the obviously Context areas of the business such as general ledger and receivables they make sense. But for Core business capabilities, a packaged solution must look like the dead hand of a commodity.
You may ask, “but back in April 2000 you expected a flourishing integration market, based on buy, build and reuse, why is that not applicable today?” And my answer is, “That actually happened in the noughties. But today we have a different challenge. Burdening creative people with huge integration and semantic transformation complexity is not a great way to reinvent the future business, as the past will be an anchor holding you back. Integration will be necessary and essential, but your core business architecture should be optimized as much as possible”
In a recent blog post I said, “modernization is not about achieving a new plateau of capability and functionality. Rather it is about enabling continuous, short cycle time response to change”. It’s about creating an Agile Enterprise.
CODA: Geoffrey Moore’s concept of Core relates to the centrality and mission critical nature of a capability. This should not be confused with the CBDI-SAE concept of Core Business Service, which is the service layer managing the state of the business. 
References:
1. Componentizing the enterprise application packages , David Sprott. ACM April 2000 
Researchgate  (public domain)
ACM (subscription or pay as you go)
2. Geoffrey Moore, Dealing With Darwin

The future for enterprise architects

by

The rise of the experience economy have brought with it accelerating developments in organizational patterns, business models, software, hardware and algorithms. Taken together it points the way to something new about how the enterprise architecture profession needs changing. The skills of the new ways of working vary, but they are all examples of how the […]

The future for enterprise architects

by

The rise of the experience economy have brought with it accelerating developments in organizational patterns, business models, software, hardware and algorithms. Taken together it points the way to something new about how the enterprise architecture profession needs changing. The skills of the new ways of working vary, but they are all examples of how the […]

Enterprise Modernization – The Next Big Thing!

by

“We tend to think the strong will survive, but a virus is a very small thing that kills big things.” Horace Dediu, Clayton Christensen Institute, speaking about the fall of Nokia.

All enterprises, be they large or small, national or multinational, commercial or government agency, American or Chinese, Japanese or European, are carrying the dead weight of their history and almost certainly continuing to add unnecessary complexity and excessive cost that will progressively reduce effectiveness, with the potential to trigger existential crises. Newer enterprises including Internet platform and Cloud based companies are not immune from this effect. As Horace Dediu has commented, Nokia is a classic case of a large enterprise brought from market leadership to irrelevance and zero value in an extremely short space of time.

In the past, modernization has become synonymous with technically related “application modernization” The term “modernization” is commonly used to refer to information systems, applications and technologies. And it is very common for systems or applications to be “modernized” because a technology has come to the end of its life, or an application is so antiquated that it cannot support newer business process patterns such as multi-channel and mobile. More generally organizations clearly implement modernizing programs without necessarily using the modernizing name. For example transformation programs or projects will often involve considerable elements of modernization. Similarly adoption of Agile methods may be considered a form of process modernization. Or the introduction of DevOps practices, enterprise architecture, master data management, life cycle management etc. But it is notable that each of these forms of modernization are discipline centric. It is very rare for an enterprise to undertake concerted effort to understand what modernization really means for a specific enterprise and to plan and execute modernization that delivers inter-discipline collaboration in support of specific modernization objectives and goals.

Each enterprise has unique modernization needs. A bank may see a primary modernization goal to establish core banking systems that reduce the risk of negative customer impact, such as delays or errors in transaction processing. Also to be able to introduce price and product change in days or weeks. A healthcare company may similarly see the requirement to change prices rapidly but equally the need to rapidly implement new legislation. A retail enterprise may see the ability to interact with customers using processes that span multiple technology, shopping and delivery channels, and to be able to influence the customer decision making process to achieve maximum customer satisfaction.  A key element apparent in all these modernizing goals is that modernization is not about achieving a new plateau of capability and functionality. Rather it is about enabling continuous, short cycle time response to change, targeted at the very specific areas that are mission critical for the individual enterprise.

The problem with modernization is that it is widely perceived as slow, very expensive and high risk because the core business legacy systems are hugely complex as a result of decades of tactical change projects that inevitably compromise any original architecture. But modernization activity must not be limited to the old, core systems; I observe all enterprises old and new, traditional and internet based delivering what I call “instant legacy” [Note 1] generally as outcomes of Agile projects that prioritize speed of delivery over compliance with a well-defined reference architecture that enables ongoing agility and continuous modernization.

What’s required is a modernization approach and strategy that progressively breaks out business and technology components that establish highly independent units of business capability that comply with a reference model and architecture that ensures architecture agility and implements clear fire breaks between the components.

But as discussed, enterprises are extremely reluctant to undertake modernization as they see it as all cost and risk. Transformation projects are widely viewed in the same way. And anyway immediate business priorities always trump housekeeping!

There are various aspects to a successful modernization approach. But the most important are:
1. Define Agility Vectors. Identify the top priorities for business agility and integrate relevant actions into all business projects. Here are some examples:
a. Radical improvement (time and cost) in response to legislative change
b. Generalization of existing capabilities to support new products and services
c. Dramatic reduction in new product time to market
d. Integration of existing capabilities to leverage disparate channels
e. Separation of common and customer/channel specific capabilities
I refer to these as “vectors”. Mission critical goals that will require actions and change right across the organization. Single projects are generally not going to cut it. Therefore the vectors provide a mechanism to exert influence (demand shaping) over the incoming application demand management pipeline and to select and coordinate multiple project actions.
2. Mandate Reference Architecture for Agility. Establish a reference architecture for business agility that defines the minimum necessary architecture compliance to ensure continuous business evolution. Mandate that all core business capabilities are implemented as software services and components.
3. Integrate Agile Architecture AND methods. Implement Agile practices that give equal weight to agile architecture and agile project delivery. Demonstrate small, incremental delivery steps, business capability by capability, service by service.
4. Govern business agility. Automate governance by establishing model driven architecture and development tooling that ensures compliance with the reference architecture.
5. Integrate Business and IT. Practice conceptual business modelling to establish common business and IT vocabulary independent of existing applications, align business and software services and reengineer the organization around business capabilities and services.
6. Get top level sponsorship for the Enterprise Modernization Roadmap. Recognize enterprise modernization as a major business priority and elevate to the highest levels of the enterprise to make it happen.

The enormous, disruptive creativity of Silicon Valley is transforming how companies make decisions, store data, reach potential customers, outsource activities, processes and capabilities, and how people communicate, make friends, protest and shop. No enterprise is immune from this effect.

Accordingly, modernization today means reinventing the way enterprises work, the business model and systems, and being genuinely agile. You only do this by ripping up today’s world and turning it into a genuinely flexible structure of independent components that can flex and morph continuously.

Application Modernization should be long dead and buried. Enterprise Modernization is an existential priority for all enterprises, not just those with mainframes and COBOL!

Note 1: Understanding Agile Adoption Failure

Enterprise Modernization – The Next Big Thing!

by

“We tend to think the strong will survive, but a virus is a very small thing that kills big things.” Horace Dediu, Clayton Christensen Institute, speaking about the fall of Nokia.

All enterprises, be they large or small, national or multinational, commercial or government agency, American or Chinese, Japanese or European, are carrying the dead weight of their history and almost certainly continuing to add unnecessary complexity and excessive cost that will progressively reduce effectiveness, with the potential to trigger existential crises. Newer enterprises including Internet platform and Cloud based companies are not immune from this effect. As Horace Dediu has commented, Nokia is a classic case of a large enterprise brought from market leadership to irrelevance and zero value in an extremely short space of time.

In the past, modernization has become synonymous with technically related “application modernization” The term “modernization” is commonly used to refer to information systems, applications and technologies. And it is very common for systems or applications to be “modernized” because a technology has come to the end of its life, or an application is so antiquated that it cannot support newer business process patterns such as multi-channel and mobile. More generally organizations clearly implement modernizing programs without necessarily using the modernizing name. For example transformation programs or projects will often involve considerable elements of modernization. Similarly adoption of Agile methods may be considered a form of process modernization. Or the introduction of DevOps practices, enterprise architecture, master data management, life cycle management etc. But it is notable that each of these forms of modernization are discipline centric. It is very rare for an enterprise to undertake concerted effort to understand what modernization really means for a specific enterprise and to plan and execute modernization that delivers inter-discipline collaboration in support of specific modernization objectives and goals.

Each enterprise has unique modernization needs. A bank may see a primary modernization goal to establish core banking systems that reduce the risk of negative customer impact, such as delays or errors in transaction processing. Also to be able to introduce price and product change in days or weeks. A healthcare company may similarly see the requirement to change prices rapidly but equally the need to rapidly implement new legislation. A retail enterprise may see the ability to interact with customers using processes that span multiple technology, shopping and delivery channels, and to be able to influence the customer decision making process to achieve maximum customer satisfaction.  A key element apparent in all these modernizing goals is that modernization is not about achieving a new plateau of capability and functionality. Rather it is about enabling continuous, short cycle time response to change, targeted at the very specific areas that are mission critical for the individual enterprise.

The problem with modernization is that it is widely perceived as slow, very expensive and high risk because the core business legacy systems are hugely complex as a result of decades of tactical change projects that inevitably compromise any original architecture. But modernization activity must not be limited to the old, core systems; I observe all enterprises old and new, traditional and internet based delivering what I call “instant legacy” [Note 1] generally as outcomes of Agile projects that prioritize speed of delivery over compliance with a well-defined reference architecture that enables ongoing agility and continuous modernization.

What’s required is a modernization approach and strategy that progressively breaks out business and technology components that establish highly independent units of business capability that comply with a reference model and architecture that ensures architecture agility and implements clear fire breaks between the components.

But as discussed, enterprises are extremely reluctant to undertake modernization as they see it as all cost and risk. Transformation projects are widely viewed in the same way. And anyway immediate business priorities always trump housekeeping!

There are various aspects to a successful modernization approach. But the most important are:
1. Define Agility Vectors. Identify the top priorities for business agility and integrate relevant actions into all business projects. Here are some examples:
a. Radical improvement (time and cost) in response to legislative change
b. Generalization of existing capabilities to support new products and services
c. Dramatic reduction in new product time to market
d. Integration of existing capabilities to leverage disparate channels
e. Separation of common and customer/channel specific capabilities
I refer to these as “vectors”. Mission critical goals that will require actions and change right across the organization. Single projects are generally not going to cut it. Therefore the vectors provide a mechanism to exert influence (demand shaping) over the incoming application demand management pipeline and to select and coordinate multiple project actions.
2. Mandate Reference Architecture for Agility. Establish a reference architecture for business agility that defines the minimum necessary architecture compliance to ensure continuous business evolution. Mandate that all core business capabilities are implemented as software services and components.
3. Integrate Agile Architecture AND methods. Implement Agile practices that give equal weight to agile architecture and agile project delivery. Demonstrate small, incremental delivery steps, business capability by capability, service by service.
4. Govern business agility. Automate governance by establishing model driven architecture and development tooling that ensures compliance with the reference architecture.
5. Integrate Business and IT. Practice conceptual business modelling to establish common business and IT vocabulary independent of existing applications, align business and software services and reengineer the organization around business capabilities and services.
6. Get top level sponsorship for the Enterprise Modernization Roadmap. Recognize enterprise modernization as a major business priority and elevate to the highest levels of the enterprise to make it happen.

The enormous, disruptive creativity of Silicon Valley is transforming how companies make decisions, store data, reach potential customers, outsource activities, processes and capabilities, and how people communicate, make friends, protest and shop. No enterprise is immune from this effect.

Accordingly, modernization today means reinventing the way enterprises work, the business model and systems, and being genuinely agile. You only do this by ripping up today’s world and turning it into a genuinely flexible structure of independent components that can flex and morph continuously.

Application Modernization should be long dead and buried. Enterprise Modernization is an existential priority for all enterprises, not just those with mainframes and COBOL!

Note 1: Understanding Agile Adoption Failure

What’s Your EA End Game? Tales From TWC 2015

by

bg outline

By: Dave Hood, CEO, Troux

end game v2 042915 blogA couple weeks ago we held our annual Troux Worldwide Conference, inviting customers and partners from across the country and even the world to meet us in our hometown of Austin, TX. We hosted customers from healthcare to banking, from public sector to consumer packaged goods. Aside from the compelling conversation, fantastic food and inspiring keynotes from the likes of TED alum David McCandless, it never ceases to amaze me what our customers are able to achieve through enterprise intelligence and EA toolsets. That’s the spirit of the conference – to help customers learn from the innovative approaches of their peers and to get the synapses firing on how they can transform their businesses through EI.

Basic transparency into a company’s IT operations, resources and processes is a victory, albeit one that should really be a given. It’s when more direct business value or tangible results can be derived from enterprise intelligence that EA becomes especially formidable and invigorating. You do need to have a clear goal of what you want to get out of an EA program, but the possibilities are figuratively endless.

Is your implementation a straightforward costing-cutting effort or an exercise to simplify your business model? Is it linked to business capability planning? Does it have to do with any of the extensive subset of application portfolio management outcomes, which include the creation of shared services, analyzing which apps are prime for cloud migration, shoring up cybersecurity through asset management, or reconciling shadow IT and standards? The list of possible outcomes goes on, but business leaders need to be able to see demonstrable results and understand exactly what they’re getting out of enterprise intelligence. Quite a few of the customers that presented at TWC have figured out how to tell their EA story in a way that resonates.

Consider Wells Fargo’s Consumer Lending Group, which has begun its EA journey by thinking big and having the courage to change, while starting small in an endeavor to bring shadow IT back under the appropriate umbrella. To date, they’ve been able to streamline, eliminate redundancies, consolidate and cut costs associated with over 250 standardized business functions, more than 2200 business processes and about one-fifth of 5000 existing apps. That’s a heck of a lot more value than just basic IT transparency.

Or take Devon Energy Corporation. Using EI, the company smoothly integrated 27 corporate acquisitions and was able to enforce data stewardship, going from just 1 percent of data being complete to 85 percent complete in only two months. In a sector that’s changing as rapidly as oil and gas, where prices and market factors soar and dive at the drop of a hat, it thrills us to know that enterprise intelligence can help Devon evaluate next steps for the business every single day.

Or how about Moffitt Cancer Center, where a core team of architects leveraged enterprise intelligence to evaluate a migration of key applications to the public cloud. Some of those apps and processes audit personal health info in a matter of hours rather than days or weeks, preventing black market insurance fraud. Talk about being critical and needing to know that they will absolutely work.

And last but certainly not least, our Troux Innovation Award winner: The U.S. Department of Energy, represented by Chief Enterprise Architect Rick Lauderdale. As another TWC guest Jason Bloomberg outlined, “[Lauderdale] helped the DOE transform the way they dealt with the risks inherent in obsolete software…Connecting the dots between IT asset management, cybersecurity, enterprise architecture, and the operationalization of IT information is a tall order, but is an increasingly familiar enabler of business agility.” Lauderdale not only revamped an application portfolio and increased cybersecurity, but he helped the DoE cut costs and is actively working on transferring the model to more than 10 other federal government agencies. Again, that’s serious impact.

Trust me when I say that these are just a few of the brilliant examples shared at TWC. You’ll see more on all of these customer programs over the rest of this year as their strategies and execution unfold. In some cases they’re just getting started on producing real change for the business, but they all prove one critical point. In order to see true value from enterprise intelligence, start by asking yourself, “What’s my EA end game?”



New Call-to-action

The Digital Race, Enterprise Edition

by

bg outline

By Dave Hood, CEO, Troux

race to digitize 030815 blogIn today’s global, hyper-competitive economy, you’re seeing all kinds of heated races to be the first to digitize an industry. You’ve got Uber battling Lyft to digitize (and displace) the traditional taxi industry. Apple, Google, PayPal, Square and others are slugging it out in a race to digitize the majority of retail transactions. Even seemingly mundane industries like shipping and storage – with Austin tech comrades uShip and SpareFoot racing incumbent competitors – heat up when digitization starts making things more efficient and accessible. And this makes the stakes quite high in the IT world, as enterprises leverage IT as they engage in a similar race to innovate digitally.

Call it what you will – digital transformation, digital revolution, digitization – but the C-suite recognizes a game-changing market disruption is underway. It’s a disruption that requires them to revamp their business model and determine how to deliver a sustainable competitive advantage. At its core, it’s a strategic imperative that C-suite decision makers of all types have to take seriously. According to a recent Gartner report titled “Digital Business Requires CIOs, CEOs and Strategy Officers to Improve Technology-Related Competitor Intelligence,” digital business is now competitive turf that differentiates between companies’ health, efficiency and product sets. We wholeheartedly concur with that.

The Gartner report encourages business leaders to look at their competitive landscape and evaluate where they stack up (no pun intended) in IT infrastructure, processes and advancement when it comes to emerging areas like the cloud, BYOD, data analysis and cybersecurity. The role of the CIO in this process and analysis is also made crystal clear:

“Discuss the traditional competitor landscape, so you know and agree where its natural boundaries lie. Then frame a new view of competition to include startups, entrants from adjacent industries and attack from the tech sector itself…If there is corporate myopia, the CIO must be an agitator, ensuring that the analysis of competition extends beyond traditional competitors and industries.” 

That’s a pretty weighty role for the CIO to play; they’re continuing to be relied upon as a business leader, not just an advisor or even worse an IT “utility provider.” And while we know that CIOs and their teams of IT decision makers are eager to innovate for the business and meet competitive challenges head-on, there may be a step missing here. How does a CIO (and their traditional business strategist counterpart) decide how the company compares to the competition if they don’t holistically understand where gaps exist in their own journey toward becoming a digital business? What areas need investment and how can they prioritize the changes that need to be executed? In other words, how can you compare your house to others’ when you don’t have yours cleaned up and in order or don’t even completely know what the blueprint looks like? To nail down improvements to the digital business and lead or follow fast in the industry, CIOs need to employ enterprise intelligence (EI).

Enterprise intelligence is complete, fast, prescriptive and (perhaps most importantly) real-time, all of which are key characteristics for CIOs as they use EI to do their benchmarking and strategic planning. Joe McKendrick recently covered the broader EA discipline for ZDNet, and a quote from McKinsey’s Oliver Bossert, Chris Ip and Jürgen Laartz does a good job of setting up the pressures related to digital business that enterprise intelligence can help alleviate:

“While most companies would have been comfortable in the past going through a three- to five-year transformation and not implementing new features in the meantime, today’s highly competitive markets no longer allow players to alter architecture and business models sequentially. It is therefore important to realize that the transformation toward digital is a continuous process of delivering new functionality.” 

The McKinsey trio also does a standout job of breaking down “two-speed IT architecture,” which addresses the two prongs of customer-centric front-end IT (apps, UIs, etc.) and the legacy systems IT back-end (compute resources, storage, etc.), both integral competitive fronts in digital business. Fortunately, enterprise intelligence can help CIOs, CEOs, COOs, CFOs and other strategy officers understand where they stand from both angles, appropriately relate their progress to that of the competition, and ultimately break the tape in the race to digital prowess and a better, sustainable competitive advantage.

Download the complimentary Gartner report here and check out our whitepaper, The Power of Enterprise Intelligence, to learn more about how our solutions help decision-makers take a step back to see the big picture to understand exactly where they should be investing in their business and where they should not.

 



New Call-to-action

Categories Uncategorized