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*