Architecting Digital Transformation

You are here

Architecting Digital Transformation

Posted September 19, 2016 in Business & Enterprise Architecture, Business Technology & Digital Transformation Strategies Cutter Business Technology Journal

What’s the Need Now?

Customers are demanding faster, cheaper, and better products and services. When customers interact with their insurance company or bank, they are not comparing their experiences to other insurance companies or banks. Rather, they are comparing their experiences to the Facebooks (social), Apples (product), and Amazons (online retailer) of the world. This means that companies can’t stop with benchmarking themselves against their traditional competitors anymore.

Competition is fierce and can come from unexpected directions. TomTom, a map/navigation company, was crushed by Google, a search engine company. Google and TomTom did not even belong to the same industry or have similar business models. Likewise, free video calling services from Microsoft (Skype) and Facebook (WhatsApp) are challenging traditional communications companies like AT&T and Verizon.

Rapid advances in technology can upheave whole business models. Netflix put Blockbuster out of business. Airbnb now manages more properties than Marriott International even though it doesn’t own any rental properties. Amazon, which started out as an online bookstore, drove Borders bookstore to bankruptcy.

No company is immune, but large legacy enterprises with their entrenched mindsets, archaic business processes, and legacy systems are especially vulnerable. While this presents a big challenge, it also presents a big opportunity. If enterprises want to thrive in the fast-changing business environment, they need to be nimble and adapt, they need to innovate and experiment, and they need to operate efficiently and always look out for disrupters.

Fundamental change through digitization is the vehicle for transformation.

The Traditional Way

Many a legacy company’s transformation model follows a “waterfall” approach. The essential stages are strategy formulation, project proposal submissions, prioritization, funding, implementation, and rollout.

In strategy formulation, external factors and internal capabilities are taken into account to determine the strategic direction of the company. Strategy setting is typically done on a yearly cycle. The business strategy then becomes one of the considerations for the downstream IT strategy formulation. In years past, the relative speed of change in the environment was slow, and as a result, the strategic direction of the company did not have to change drastically. Most years, the strategy was similar to the previous years’. The business goals were mostly the same, with metrics being reset. In other words, “business as usual” was the norm.

With the enterprise strategy as guidance, departments formulate their own strategies. They write up business cases and propose projects to fix things that are broken, enhance their capabilities, and/or develop new capabilities. Most of these proposals are siloed in scope due to the restricted span of control for each department. The default stance for a department head is to focus within the department rather than reach across to collaborate. So, few of these proposals span the enterprise, and even the ones that do don’t have integration frameworks to ensure that they are aligned and executed in lockstep. Rather, each project is justified in its own right with respect to its alignment to the overall strategy and the value it will potentially add to the enterprise.

A consolidated list of projects is then presented to the funding committee, which essentially prioritizes the projects and allocates funding to each one. While some high-level categorization is done, the interdependencies among projects are usually not identified. In all like­lihood, there is not enough money in the budget to support all the initiatives, so some are dropped or back-logged. Funding, too, follows the yearly cycle.

Such a list-driven funding allocation mechanism does not even come close to what an architecture-driven funding allocation mechanism can achieve, but since the list is easier to manage on a spreadsheet, it becomes the default management mechanism. An architecture-driven mechanism would have identified dependencies across not just the projects, but also the people, processes, and systems that are impacted by those projects. This could prompt some perceived low-priority projects to be funded because they may be critical to the overall outcome. Wacom, a Japanese company, makes and ships drawing tablets. While the technology aspects of the product are important, a high level of attention is also given to the packaging, though the package does not have any effect on the performance of the product. Wacom has found, however, that differentiated packaging enhances its brand value and the customer’s delight on receiving a tablet, so development of packaging becomes a high-priority project.

Once funding for a particular project is approved, project work is initiated. The work may span a few months or a few years, but as long as the project has support for the current year, work begins. Some long-term projects are conceptually approved for multiple years, but management holds the right to stop funding them at any time. While this is needed in some cases to shutter projects that are not progressing as planned, on the other end of the spectrum, departments are put in the position of having to justify their work and run through the business case and funding cycle year after year. Department heads typically do not want to return any funding because they are afraid of losing that money forever. Hence we see instances of a low-priority project in one department being funded at the expense of a higher-priority project in another department.

In many cases, it’s only after the funding decisions have been made that IT is brought into the discussion. At this point, it is often too late for IT to strategize across the enterprise to optimize implementation and ensure reuse. So individual business-area projects that require IT implementations are initiated. Some of these implementations are on time and within budget, but many are not. Coordination of timelines or functionality across these projects is an afterthought, and so is integration. Often teams are scrambling at the last minute with major integration issues, since the holistic rollout was not planned appropriately.

When some projects fail to deliver the expected business results, functionality of individual projects is scoped down. So the rollout is scaled down, and the customer experience disappoints. Due to time pressures, the rollout is still done, and an operational budget is allocated to address the below-par customer experience in the hope that it will be fixed “sometime soon.” A lot of energy and money are expended in rework.

Figure 1 illustrates this waterfall model. The right side (in black) illustrates the current problems, while the left side (in blue) illustrates possible solutions.

Figure 1 — The waterfall model and possible approaches to improve different steps in it.
Figure 1 — The waterfall model and possible
approaches to improve different steps in it.


Why Won’t This Work Anymore?

What’s wrong with the waterfall model going forward? As mentioned earlier, today’s pace of change is fast, both in terms of the business environment and customer needs. Companies have to adapt quickly to thrive or even survive. So the waterfall model will not work for essentially two major reasons, both of which are driven by the need for the business to respond quickly to the fast-changing environment. First, the yearly cycle for planning, budgeting, and project initiation will not suffice anymore. Rather, continuous evaluation is needed. This means that strategy setting and adjustment, project initiation, funding allocation, implementation, rollout, and support all have to happen on a more frequent cycle. This does not mean that the three-year and five-year plans or visions are invalid, but there is more emphasis on planning for the short term, while keeping the long-term picture in mind. As the maxim goes, “Prediction is very difficult, especially about the future.” Given that that long-term future will most likely change, companies have to be agile enough in the short term to adapt to whatever the long term may be.

Second, to be nimble and adapt to the environment, the business cannot afford to build everything from scratch. Rather, the thinking should be about architecting, designing, and building small blocks of business value that can be reconfigured and recombined in many ways to adapt. For example, today’s model of taking payments from the customer for products could change in the future — just like the way ApplePay was introduced as a new form of payment. Fingerprint-based identification with instant bitcoin payment is one possibility. While we cannot anticipate the future, we can construct robust and modular systems that can adapt to many of the changes the future will bring. In the example above, if the payment module is architected well, it can be reconfigured quickly to change the user experience and meet the customer needs. The first movers will continue to have a competitive advantage.

To enable such nimbleness, we need to introduce the discipline of a business and IT architecture that starts to build components that can be reconfigured much faster, enabling the business to adapt quicker. Traditionally, IT has had more experience than the ­business in thinking about and implementing modular design, but those principles have to transfer to and mature on the business side, because businesses will dictate more and more of “how IT is done.”

What to Do About It?

If we adhere to the basic principles of architecture in building an enterprise, the enterprise will be more robust. There are many principles that can be applied, such as modularity, reconfigurability, strategy alignment, cross-channel consistency, simplicity, cost-effectiveness, shareability, and security. In the remainder of this article, we will focus on just two of those characteristics and the value they add to the digital transformation journey.

Business-Driven Digital Transformation

Digital transformation is more than just a bullet point in a strategy session or the current buzzword. The visions we cast and execute upon today will likely dictate our organizations’ successes and survival in the future and collectively shape the world in which we live. Digital transformation is real, and it poses both an opportunity and a threat for our organizations, Discover actions you can take now: Order your copy of the complete Cutter Business Technology Journal issue today using Coupon Code BDDT25 and Save 25%!

But first, a word about digital transformation. What does digital transformation include? Today much of an organization is controlled and managed, at the most basic level, by 1s and 0s — that is, digitally. Anywhere the 1s and 0s appear, it is digital. When customers browse the company website and click on a product to purchase, they are interacting with 1s and 0s. When the order is transmitted to sales, it is done through 1s and 0s. When the order triggers the customer-configured product to be assembled, the manufacturing or assembly process is controlled by machines that are ­provided instructions depicted in 1s and 0s. Physical product parts are modeled as CAD models in 1s and 0s; so are conceptual products like bank accounts and insurance. RFID ­sensing, which enables product manufacturers to track where products are in the process and share that progress with customers, is done with 1s and 0s. The payment for the order is received through a credit card, and that’s facilitated by 1s and 0s. You get the picture. Much of how the whole system works is controlled by 1s and 0s, and that is the scope of the digital organization. Changes to any of those parts fall under the purview of digital transformation.

With this backdrop, the two principles of well-engineered digital systems that we’ll focus on are modularity and reconfigurability. Many products and services are nothing but fundamental elements put together in various com­binations to offer something of value to the customer. Take a car, for example. The customer is interested in the complete product — a drivable, fast, comfortable, good-quality car. However, the car is made of many parts, including the chassis, drivetrain, engine, steering wheel, seats, and so on. These parts are designed and engineered in such a manner that they can fit into the design of many different types of vehicles. Changing the configuration of how these parts are combined, and/or the configuration of the individual parts, yields many possible options, options that enable new vehicles to be designed faster to meet the changing customer needs. Sure, if the customer needs a special vehicle that can move on swamps, we may have to design a few new parts, but many of the existing parts can be reused.

The core of engineering design and architecture is to identify the fundamental elements that make up a system, which in our case is the enterprise, and then figure out how to assemble those elements to produce value that the customer is willing to pay for. These elements include assets, people, knowledge, products, and a whole lot more. These elements combined in various ways produce different business capabilities in the enterprise. Some of these capabilities provide a competitive advantage to the enterprise and hence have to be preserved. Some capabilities help the enterprise to better adapt to the future and hence have to be further matured. Some capabilities are missing and need to be developed. And some capabilities add little value and can be abandoned.

The business areas have to understand the library of capabilities required by the enterprise to achieve its strategic objectives. Then, leaders can make decisions on the capabilities that subsequently drive IT implementations. The capability map is one such framework to help the business in this context.

Enterprises’ Role in the Ecosystem

An enterprise does not exist in isolation. Rather it exists in an ecosystem of government regulations, competitors, customers, partners, and so forth. If the enterprise finds its “right” place in this ecosystem, doing the “right” things, then it can thrive.

Hyperscale” is a term used to define the new eco­system where enterprises interact with one another to provide the customer experiences in the future. In this ecosystem, enterprises of all sizes can participate. No single enterprise will provide the “end-to-end” experience for the customer. In such an ecosystem, sometimes enterprises collaborate and other times the same ones compete. This has been termed “co-opetition” to describe cooperative competition.

In the digital world of tomorrow, customers will expect the services provided by companies to revolve around them. When self-driving smart cars become a reality, here’s one set of interactions that’s possible. Let’s say when customer Lisa leaves work and walks out of the building, her car starts itself and comes to the door to pick her up. She hops in, and 20 minutes before she reaches her home, the car sends instructions to adjust the thermostat and turn on the oven. One minute before she enters her house, the music system turns on, playing what she likes. Since Lisa calls her mom every other day on the way from work, that pattern is learned, and the car asks her if she’d like to call her mom. The possibilities are endless. The critical thing is that different companies provide different services that are brought together in the context of the customer, Lisa. All services revolve around Lisa, and the companies offering the different services have to collaborate to create the desired experience for her.

Your company will probably play only a small role in such an ecosystem of collaborating and competing companies. The challenge for architects of digital transformation is to design and deploy services in such a way that they can be combined and reconfigured dynamically with services offered by other organizations to provide uniquely tailored experiences for customers like Lisa. Figure 2 illustrates this concept. The ovals represent different companies in the ecosystem, and the size of each oval represents the size of a company relative to others in the ecosystem. Each company may offer different services to complete the end-to-end experience of a customer. Each customer could potentially have a different set and sequence of interactions with different companies, leading to a highly personalized experience. 

Figure 2 — An ecosystem in which customers’ experiences are driven by their interaction with multiple companies.
Figure 2 — An ecosystem in which customers’ experiences
are driven by their interaction with multiple companies.


Core Architectural Principles

That brings us back to architecture, which first starts with the business and then drives the technology ­implementation. Business leaders will set the strategic direction of the enterprise to meet the needs of the future. They’ll do that through “painting a picture of the desired possibilities” of the future. The discipline of business architecture, which sits between strategy and execution, interprets the strategy to identify tangible changes to the business and guide design that will realize the desired future.

The critical role of a business architect is to understand the business needs and design the fundamental business elements that can be configured in many ways to realize what the business wants. Such elements should have the characteristics of modularity and reconfigurability, among others, so they can be assembled to create customer experiences. As the ecosystem of collaboration and competition changes, some of these elements will change, which in turn will drive some business capabilities to be enhanced, some repurposed, some protected, and some abandoned. The architects manage this directional maturity as dictated and driven by business changes.

The business architects also work closely with IT architects to ensure that the business design is translated well into the digital and systems design, while preserving the principles of the architecture. Unlike the common practice today, where IT is brought into strategic discussions at a later stage, business and IT architects will work together much earlier, right after the enterprise strategy is formulated.

As an example, take a payment service. In Lisa’s case, she may make the payment for the services she receives through one of many different possibilities that cover the who, when, and how. The possibilities for “who” include paying each provider or paying one provider who then computes and distributes the money to others. The possibilities for “when” include paying yearly, monthly, daily, instantly, or some other variation. The possibilities for “how” include credit cards, bank debit, mobile pay, bitcoin, and whatever new mode the future may offer. This means that your company’s billing and payment system should be designed to function in that future, a future where a currently unknown functionality may be required.

Where to Start?

How does an organization get started on the digital transformation journey? Work can be started on two separate fronts that collaborate along the way:

  1. Look externally to understand what changes are happening in the environment that are driving change and organize that knowledge in a framework to make informed decisions. New information can be fitted within this framework to enable continuous decision making.
  2. Look internally to capture current business capabilities to determine which ones provide the competitive advantage and have to be protected, which ones need to be repurposed, which ones enhanced, and which ones can potentially be abandoned.

In starting this effort, no special tools are needed. Simple stories can be crafted for management and shared with existing tools such as Word/Pages, PowerPoint/Keynote, and Visio/OmniGraffle. The main focus should be on the content and less on the mechanics of capturing and storing it. Once the initial framework evolves and starts providing value and credibility, more suitable tools can be evaluated.

Experienced business architects can lead both the activities above. A small team of such people will work with a number of business partners (including staff and leaders from business areas, product lines, and customer research) to understand the ecosystem and the organizational strategy within that ecosystem. The company’s strategy determines its place in the ecosystem, the role it wants to play, and how it will be uniquely positioned in that ecosystem. This helps the company explore the capabilities at which it needs to be the best. These capabilities will provide the competitive advantage. The business architects will also need to understand the business model, which speaks to how the company will add value to its customers. Business architects may use a variety of business modeling and business management tools, such as the Business Model Canvas or Balanced Scorecard, to understand that.

What Are the Implications for IT?

IT has been architecting software for much longer than business architects have been architecting the enterprise. Therefore, IT has been able to incorporate lessons learned from the old waterfall methodology to the more recent Agile methodologies to mature its architectural principles. Along the way, many architectural principles such as encapsulation, separation of concerns, services, reusability, configureability, externalization, and more have been adapted into the software and systems development methodologies. However, since we can almost never start from scratch (i.e., so-called greenfield projects), IT has had to make strategic decisions and compromises to optimize spending and resource utilization.

Previously, IT interfaced directly with the business areas to understand and capture requirements. These business requirements were framed in the context of what the system’s and software application’s features needed to be. Meetings with the business areas were conducted in silos because the purpose was to understand the business needs for each area. IT then had to consolidate requirements across all business areas and infer the collective intent of the business. This exercise often went awry because the business areas themselves may not have been operating from the same model or framework. Hence, there was a high degree of conflicting business needs, leading to conflicting software requirements. This is akin to piecing together a puzzle that had no unique solution.

By leveraging business architecture as the mechanism to connect across business areas and drive toward a collective intent, IT will be in a better position to plan its strategy and roadmaps. What comes down the pipe from the business should be self-consistent and offer a holistic picture of the collective intent of the organization.

This means that IT will now, in addition to interfacing with the business areas, interface with the business architecture team. It’s the business architecture team’s responsibility to work with the business areas to create a consolidated view of the enterprise. This is even more critical in a digital transformation effort, where all parts of the organization need to be in alignment for the transformation. The changes being made in one area will impact other areas, and since such changes will be more frequent as the business areas try to adapt to the changing environment, some team has to ensure the integrity of change — and that would be the business architecture team.

While IT gets the big picture from business architecture, the detailed requirements will still flow directly from the business areas to IT, as was done previously, because the business has deeper domain knowledge.


Given the fast-changing business environment, large legacy organizations need to embark on a digital transformation journey to stay relevant and flourish. Specifically, they need to work with a business-driven framework that enhances business capabilities with architectural principles in mind so the business can adapt faster. The scope of digital transformation can be very large — potentially anything in the company that is enabled by 1s and 0s. Due to this immense size and complexity, coupled with the need to break down silos and change culture, an overarching framework and understanding are mandatory for successful transformation.

Business architecture is a discipline that can help in this journey by bringing to the business the same rigor and adherence to architectural principles that IT has matured over the past few decades. Introducing such structure into the business right after the strategy formulation phase will make sure that the different business areas are in alignment with the strategy and also with one another. While all of the architectural principles are critical in such a transformation, two specific ones — modularity and reconfigurability — are needed so the enterprise can adapt and respond quickly to a fast and continuously changing environment.

Share This

About The Author

Raj Ramesh has more than two decades of experience in business and IT across many domains. Dr. Ramesh has worked with senior-level business and IT leaders in Fortune 500 companies as an adviser and architect to foster deeper business-IT collaboration through consulting, advising, and building customized frameworks for common understanding. These frameworks are the tools to help the business and IT leaders achieve their specific objectives. He... Read More

Leave a reply

Your email address will not be published. Required fields are marked*

Philip O'Reilly

Beyond Fintech: New Frontiers — Opening Statement

by Philip OReilly

This issue focuses on key topics of interest for financial services organizations, namely equity crowdfunding, legacy systems migration, robo-advisors, test outsourcing, and refining the reconciliation process.

Bhardwaj Velamakanni

Implementing Design Thinking in Agile

by Bhardwaj Velamakanni

This Advisor presents an overview of improving Agile techniques and practices by using design thinking within the Agile space and describes three techniques from design thinking methodologies that tend to yield benefits to Agile practitioners.

Gustav Toppenberg
Executive Update

Data’s Story: An Enterprise Asset in the Digital Backbone

by Gustav Toppenberg

The existence of a digital backbone in an organization means that anyone aspiring and planning to transform different parts of the enterprise can leverage the digital backbone in a consistent and sustainable way, ensuring that each transformation effort connects and leverages a common platform. Digital transformation leaders are starting to realize that a powerful digital services backbone to facilitate rapid innovation and responsiveness is key to successfully executing on a digital strategy.

Effort score and priority rank for requirements in our sample project.
Executive Summary

Can We Measure Agile Performance with an Evolving Scope? An EVM Framework (Executive Summary)

by Alexandre Rodrigues

Can a method like EVM, developed to control projects with well-defined objectives, be applied to control product development initiatives that evolve continuously toward a “moving target”? In an Agile environment, we are faced with the dynamic evolution of a finite boundary of integrated scope, cost, time, and resources; this finiteness — essential for business management and decisions — is the cradle for project management techniques, tools, methods, and frameworks. The EVM method was first developed to help with managing complex R&D projects mostly characterized by an unstable, volatile, and evolving scope. It is therefore no surprise that EVM applies to Agile projects.


The Frontier of Fintech Innovation — Opening Statement

by Philip OReilly

It’s a pleasure for me to introduce the first of two special issues of Cutter Business Technology Journal (CBTJ) showcasing the thought leadership and cutting-edge research and development (R&D) being done in State Street Corporation’s Advanced Technology Centres in Europe, the Middle East, and Africa (EMEA) and Asia Pacific (APAC), in partnership with University College Cork (UCC) and Zhejiang University (ZJU), respectively. The articles in this issue represent a small sample of the output from the R&D undertaken in these centers, which combine academic excellence with real industry impact.

Executive Update

Business Architecture’s Role in Crisis, Risk, and Compliance Management

by William Ulrich

Every business must deal with crisis, risk, and compliance challenges. Teams chartered with addressing these challenges are often split across business units and regions, which fragments crisis, risk, and compliance management efforts. Business unit silos and related complexities obscure ecosystem transparency, which in turn constrain an organization’s ability to identify risks, assure compliance, and prevent and disarm crises. Business architecture delivers business ecosystem transparency as a basis for improving a business’s ability to collectively address challenges related to crisis, risk, and compliance. 

Curt Hall

Building New Business Models with Blockchain

by Curt Hall

Organizations are using blockchain to create new business models — exploiting its capabilities for optimizing contract management, financial transaction management, and identity management.

Nine Policy Recommendations for Managing Technical Debt
Executive Update

Managing Technical Debt: Nine Policy Recommendations

by Rick Brenner

For technology-dependent products, companies, institutions, and even societies, sustainability depends on learning how to manage technical debt. Like most transformations, incorporating new practices into our organizations will likely be an iterative process. We already recognize the problem, and researchers are making progress, albeit mostly on technical issues. This Executive Update proposes a policy-centered approach to the problem. It begins with a principle that can serve as a guide for constructing technical debt management policy, and then shows how to apply that principle to develop nine recommendations that enable organizations to manage technical debt effectively.

Bhardwaj Velamakanni

Emerging Agile Anti-Patterns

by Bhardwaj Velamakanni

Agile methodologies, however popular they are, bring their own sets of “smells” and anti-patterns to the table, sometimes causing irreparable damage to the team. While the sources of these smells are many, one of the primary culprits is the mindset that treats Agile as “yet another methodology,” totally ignoring the cultural aspect. This article throws light on some of the prominent smells that are emerging of late in the Agile world.

Jens Coldewey

Middle Management in Flux

by Jens Coldewey

If you start changing an organization toward an Agile mindset, there’s no real end. Agile is about creating an organization of continuous learning and the transformation is done when there is nothing new to learn, which will probably be never. This puts an enormous challenge on middle management.


Business Opportunities in the New Digital Age — Opening Statement

by San Murugesan

The articles in this issue present perspectives and ideas on business transformation in the digital age. We hope they will inspire and encourage you to visualize the likely future of business in your domain and to explore the opportunities it presents. Finally, we hope their insights will help you identify suitable transformation strategies and plans and, if needed, choose viable collaboration models for partnering with startups and other firms in your digital business efforts.


Unlocking Value from Digital Initiatives

by Joe Peppard, by John Thorp

Beyond buzzwords, what we are seeing is a seismic shift in the role of technology in organizations. Technology is more and more embedded in everything we do as we move into an increasingly hyper-connected digital world, a world in which technology is driving significant social, organizational, and industry change.

Digital Data Steams impact bottom line

Improve Customer Experience — Leverage Your Digital Data Streams

by Federico Pigni, by Gabriele Piccoli

In this on-demand webinar, you'll discover the strategic and tactical opportunities made possible by Digital Data Streams and the opportunities for improved customer experience made possible by DDS.

Lou Mazzucchelli

Why Are They Twittering? A Modest Proposal

by Lou Mazzucchelli

At the Cutter Digital Transformation & Innovation Bootcamp, Cutter Fellow and Harvard Business School Professor Karim Lakhani talked about digitally-driven disruption of traditional business models for value creation and capture, discussing platform models like Facebook and Twitter. To date, Twitter has clearly done a good job “creating value.” But unlike Facebook, it continues to struggle with the capture part of the equation.

social collaboration
Executive Update

Seven Ways to Gamify Social Collaboration

by Phaedra Boinodiris

Social collaboration is not about technology. It’s about connecting people, and it’s changing the way business is being conducted. Similarly, gamification is not about games. It’s about motivating the per­sonal and professional behaviors that drive business value. Together, social collaboration and gamifi­cation help companies reap great benefits — among them, the ability to deepen customer relationships, drive operational efficiencies, and optimize their workforce. 

Figure 1 — Tracing a roadmap to projects.

Using Roadmaps Strategically

by Roger Evernden

Roadmaps have two key functions in strategy planning. The first is to outline planned architectural changes that will deliver the required strategies; the second is to outline alternative ways to achieve the same results.


Technology Trends, Predictions, and Reflections 2017: Opening Statement

by Cutter Team

Just as recent global events have given us reason to pause and reflect, the pace of technology emergence and disruption is proving to be a source of inspiration and uncertainty. Transitioning to a digital world is front-of-mind for many business executives, yet finding the right path is an ongoing challenge. So we asked Cutter’s team of experts for their insights on some of the technologies, trends, and strategies that will be relevant in 2017 and beyond. In typical Cutter Business Technology Journal fashion, our call produced a wide range of opinions and reflections worthy of consideration as you chart your business technology journey for the new year.


AGI: A Threat, an Opportunity, or an Inevitable Unknown for 2017?

by Alexandre Rodrigues

Artificial general intelligence (AGI) is currently emerging as an area where recent developments are likely to have a major impact on the way organizations do business, societies organize themselves, and even on how we address values and ethics.

The fact is that AGI already exists in our daily life. A common example is the GPS systems present in many new cars manufactured today; and let’s not forget the drones being used to deliver pizzas and cars that drive themselves. While automatic pilots have been used in commercial planes for quite some time, what AGI is about to offer to general business and human activity is well beyond what most of us have seen so far.


The Tech-Driven Tech Backlash

by Carl Pritchard

2017 is going to be a year of strange winners, and perhaps the strangest of all will be a giant leap away from technology and back to solutions that don’t rely on 24/7 connectivity. With the onslaught of major hacks and Facebook embarrassment, the antitech crowd may have its best year in decades. 


Rapid Technology Innovation in Blockchain: Should You Be on the Front Lines?

by Nate OFarrell

One of the most prevalent blockchains in the world, Ethereum, is poised to switch from a proof-of-work (POW) algorithm to a proof-of-stake (POS) algorithm, likely in 2017, with the release of the Casper codebase. Why does this matter? Because blockchain technology is becoming increasingly relevant and prevalent in businesses across the globe. It holds great potential to disrupt how businesses perform basic transactions, from payments, to programmable, self-executing contracts, to identity verification.