Apr 072015

Every company claims to be customer centric these days. But, then, if you look back, companies always claimed to be customer centric. “We are focused on what the customer wants, right?” They say. In fact, it was and is the bed rock of American industry, we are told.

All true. In deed, organizations have been focused on the customers always. However, when it comes to IT, the story is not so straight forward. Consider the following evolution of IT.


Let us look into a brief background of this evolution, with some examples.

System Centric IT

As organizations started going beyond payroll systems to using computers in running the business, the primary concern is about the functionality of the applications. To large extend, the PCs of that era also influenced the purchase decisions: We want as many tick marks as possible in features.

Consider the IT manager trying to automate procurement. Any procurement application requires partner qualifications, tender management, contract management, PO generation, quote generation, etc. (I am not an expert in this area, but you get the gist). The IT manager looks at various products and makes a judgment based on several factors, including functional fitment. That is the how IT is built of several systems, selected for different functional capabilities.

What is the flipside of this kind of selection? Let us look at the problems and the ad-hoc solutions that IT had to deal with because of the fragmented systems in IT.

Overlapping functionality

The overlapping functionality of the systems in the enterprise leads to lot silly problems that IT vendors have been making money off for several years:


Of course, there is a simple solution: Buy one system that solves every problem of running a company. The big ERP systems (an excellent example would be SAP) promises exactly that. You get a unified view of the world, with one application (even if it is broken as modules) dealing with standardized data, clear delineation of responsibilities, and best practices about what functionality is to be implemented in what module.

Despite all these promises, enterprises still will have to build applications, buy different applications for different functionalities, and live with the consequences.

Process Centric IT

System perspective of IT enables an IT to automate all the core functions. Yet, when we look at an enterprise, more and more, the business sees itself as carrying out some processes. For example, procurement is a process, managed by a business unit.

This process view in a company has several benefits: firstly, companies can measure themselves by process. For instance, how long does it take to procure a new computer for a company? If that is the metric that needs to be lowered, then, people can modify the process, optimize the process, or simply train the people to process requests faster. Secondly, process is natural to companies, as they are optimizing for operations. Since operational responsibilities fall along the lines of process, it is convenient to create KPI’s based on the process.

In the world of IT that is built on systems, this process centricity poses a problem. Let us look at the ways:

  1. If a process is entirely contained in a single application, it looks almost like a functionality, right? Then, what is the problem? The problem is process view demands certain uniform approach to process management. For example:
    1. Process visibility: Where exactly is that request for new onboarding of a supplier stuck?
    2. Process metrics: How long does it take to process this new supplier on-boarding?
    3. Process delegation: Jane went on vacation. Can John who reports to her approve the request?
    4. Process allocation: We have three people verifying the supplier bank information. That is the where the lag is. Can we increase the number of people handling that task?
    5. Exceptional processing: We have an important project for which we need this new supplier. Can we hand-hold the process to move it past the gate?
  2. If a process spans multiple applications, that creates additional problems. For example:
    1. All the process management requirements become that much harder to implement. For example, consider delegation: You may have to repeat the same delegation in two different systems.
    2. Integrating the processes is complex. We need to bring the data in sync between different applications.
    3. Process optimization is complex. It is difficult to change two systems and keep them in-sync when the overall process is changing.
  3. If a process is not fully automated, it creates even more problems:
    1. Process management may be impossible, with manual steps. In particular, visibility, metrics, and allocation – all have to be done manually, leading to inconsistent results.
    2. Process operations may be costly, because of the manual steps. In addition, it may be error prone and inconsistent.

With all these problems with systems view of IT in a process world, what is the solution?

BPM for process management in a company

BPM as a emerged as a general mechanism for business process management in an enterprise.


Consider the implications of the picture presented:

  1. It is preferable to implement a process outside of the systems, in the BPM, if we are looking to manage effectively.
  2. Even if the process is contained one application, it still may be preferable to implement in BPM.
  3. BPM can provide additional benefits, in addition to process management:
    1. customization of process, which may be simpler do in BPM than the application
    2. Reconciling different data models – customers, partners, orders etc.
    3. Automating simple tasks, without being custom systems – to full automation of the process.

The enabling technology is SOA, which lets applications work with a BPM system.

People Centric IT

Process centric view is fine for lot of purposes. It lets IT support efficiency drive in enterprises. It lets the companies focus on the processes that matter most. In fact, it gives the organizations a blue print on understanding which processes to customize and which processes to leave alone.

But, one important aspect that gets hidden is this: How do people use the systems? Are they happy to use the systems? Do these systems work in the context of the usage (like, say on the go, or in the office)?

As an analogy, consider a government office, say DMV. If you are there for license renewals, you stand in one line. If you are there for registrations, another one. Auto titles, yet another one. That is, users are tasked with figuring out where they should stand.

Much like that, most of processes typically have their own way of serving users. Even if we were to integrate them in one portal, the experience is different. In fact, users may be forced to learn lot of different interfaces depending on the context.

Or, consider a corporate website. Typically they are designed describing the way the company is organized.  But, a visitor does not care about how the company is organized – they only care about how their interactions are organized.

When we start taking a user centric approach to IT, we should not expose the systems or processes to users. After all, systems are the way vendors developed the applications, and processes are the way organizations carry out their work. We should design the interactions of users with the internal systems and processes and focus on providing the user interface supporting the context of the usage.

What customer centricity means to IT

If a company decides to reshape their IT to incorporate customer centricity, what should it do?

First and foremost, it should realize that the most of the systems that it can acquire still will be operating in the old-fashioned mode. And, internal processes will remain the same. Until products and internal applications are retooled to customer centricity, we will have to implement customer centricity differently.

Designing for one

Ideally speaking, we should design an application for every user. After all, every user is different in the way they want to use the systems. But then, it is too costly for that level of customization even with personalized applications.

The right approach to that is through Extreme Segmentation. That is, we do not divide people into segments based on static attributes. Gone are the days when people are classified into established buckets such as “college educated over 50’s white male”. Instead, we provide several attributes of users that lets us group users into very many overlapping sets.

To support that many segments, we may want to retool the IT in the following way:

  1. Self-provisioning, community-supported, discoverable applications
  2. Easy to develop, deploy, and operate applications
  3. Standardized applications catering to segment specific interactions.

I will be writing more about extreme segmentation in digital marketing soon.

Three main groups of users

While it is nice to talk about extreme segmentation, I find the following three groups of the users very important:


Each group of users use the IT systems differently. And, as such customer centricity would mean different for each group. We can consider other groups such as partners, operations people etc – their needs tend to be a combination of these three groups.

Standard approach to customer centric applications

Finally, let me summarize by describing a standard reference architecture that can be used for developing customer centric applications.


This is somewhat simplistic, but the essential principles are going to be same even in a full blown picture. In summary, the architecture uses:

  1. API’s to build the experience on top of existing applications
  2. Use modern UI technologies to design applications
  3. Applications can replicate functionality, in catering to different sets of users.

Concluding remarks

In this note, we discussed the emergence of customer centricity in IT. We described what it means to IT and architecture. In subsequent notes, I will describe the following:

  1. What extreme segmentation means and how it works in digital marketing
  2. A prescriptive approach to creating a customer centric IT – an enterprise architecture approach
  3. An in-depth look at architecting a customer centric application: concept, design, and implementation

Till then, happy reading!

Mar 272014

You are the CIO. Or, the director of application development. You hear about consumerization of IT, in different contexts. You hear about mobile applications developed by teenage kids in only months, and these apps are used by millions of adoring people. And, your business people are demanding why can’t be more like those kids.

What should you do? Retrain your staff on some of the consumer technologies? Get a partner who has the skills in the consumer technologies? Move existing applications to consumer-friendly devices? Are they enough? And, why are you doing all these anyway?

In last couple of years, I have been working with different IT leaders to evolve a definition and an approach to this problem. By training, I am a technology person – the kind that develops the consumer technology. By vocation, I help IT departments help adapt technology to meet their strategy. Being in both the sides of fence, I have a perspective that may be interesting.

This note is derived from a few presentations I made at different industry conferences. The self-explanatory slide deck is available at: http://www.slideshare.net/kramarao/consumerization-32279273

Let’s look at the following three questions, in order:

  1. What is consumerization of IT?
  2. How does it affect IT departments?
  3. What should the IT departments do about it?

Consumerization of IT: A bit of history

The as coined in 2001, consumerization refers to the trend of building application that are people centric. Have we not been doing that always? Yes and no. While we were developing the applications for people, our main focus was some where else. The focus was about either growth of the business (by managing the volume of data), automation of activities to speed up the processes, or automating the entire business value chains, or only recently, focusing on the customers.

When we were building applications earlier, we were building them for a purpose: to solve a business problem. People were another peace of the puzzle – they were meant to be a part of the solution, but not the purpose of the solution.

Enterprise IT application development

How are these applications developed? Take a look at the sample development process.


In the current traditional situation, the EA people map the needs of an enterprise to a technical gap, see if there is a packaged app, and either customize one or build a new one. The biggest questions often boil down to “Build vs. Buy” or, what to buy.

A few things that you will observe are these:

  • Applications take long time to develop: Typically they are large, and serve long term needs of the enterprise. Any other kind of applications are difficult to retrofit into this model of development. For example, if you want an application by marketing department for one-time event, existing processes of IT makes it difficult to offer that service. That is why, we find marketing is one of the prime movers behind consumerization.
  • Applications serve common denominator: They address most common needs of the people. If your needs are very different from others, they will be ignored, unless you are the big boss. No wonder, that IT departments still develop applications with “Best viewed on IE 6+” sticker.
  • Applications lag behind the market needs:  Since the focus is to create the applications with longevity, the design uses tested technologies. The pace at which these technologies are evolving, this design decision makes the technology foundations obsolete by the time applications are delivered. For example, even today, IT departments use Struts in their design – a technology that is already dead.
  • Applications, developed based on consensus needs, lack focus: Since there is a going to be one large monolithic application meeting requirements of several groups with different needs, the applications lack focus. For example, the same application needs to support new users and experienced users. Or, it needs to support management interested in the big picture view and the workers interested doing the processing.  Naturally, any application that is developed to such diverse and divergent needs ends up being unfocused.
  • Applications are expensive to develop: Compared to consumer apps, where we hear apps getting developed for a fraction of cost, the process and the “enterprise quality” requirements impose lot of additional costs on the application development.

That is, this process yields applications that are built to last.  Let us look at how consumer applications are developed.

Consumer application development

Historically, consumer applications have been developed differently.


As you can see, in each era, the consumers are different; the focus is different; and the distribution mechanism is different. File it away, as this historic view is important as we look at consumerizing IT. Dwelling deeper into the current era, we see the following:


Consumer applications almost always are better focused on end results than the users needs. For example, take the case of Instagram. In its history, it discovered if it followed user needs and demands, it would end up being another FB clone. Instead, it decided to keep the focus on one metric: “How to get most number of photos uploaded by the consumers”. That focused design led to its success.

Consumer applications are also built in collaboration with the consumers. By creating a model of constant experimentation, feedback from the field, and ability to improve the application, without ramifications of user support, the creators of the applications are able to build systems that are “built for change”.

But, what are the disadvantages for the consumer applications, compared to enterprise applications?

  1. Only interesting applications get developed: Go to Apple’s app store, and you find so many applications around weather apps or gaming apps. You do not find enough applications to do genome analysis. Developers are impatient with problems they do not understand, or the problems that require lot of knowledge to solve.
  2. Capabilities may be replicated in many applications: The strength in consumer applications, namely catering to different groups of people, means some core functionality gets repeated in applications. Instead of getting high quality apps, we might end up with lot of apps that are mediocre.
  3. Lack of uniformity in solutions (depends on the platform): While some platforms are famous for creating a uniform and consistent experience, the applications themselves, provide fragmented experience.  Unlike enterprise applications, they lack control or governance.

Consumerization: Why should IT care?

We established that enterprise applications and consumer applications have different focus. We also established that they are built, distributed, and operated differently. Still, why should IT care about consumer applications? Why should it consumerize itself?

I can think of three reasons.

Consumer focus of the businesses

Several service industries like retail, banking, entertainment, music, and health deal with consumers daily. Their business models are being disrupted by startups that bring new technologies and new breed of applications. While IT does not exactly lead the business transformation, at least by bringing the right capabilities, IT can support businesses better.

Internal users as consumers

Demographics of the employees are changing. More and more young people are joining the workforce. They are used to different kind of experience using modern devices and modern applications.


Even the older people are used to consumer applications: they use Gmail at home, facetime on their IPad, Facebook on their laptop, and LinkedIn at work. They come to work and they use Exchange without the benefit of Bayesian spam filters; they use Lync video instead of facetime or Hangouts; they do not even have something like Facebook or LinkedIn at work.

By not exploiting the modern technologies and application paradigms, enterprises are risk losing productivity and ability to attract the right talent.

Cheaper and better Consumer technologies

Large investments in the consumer technologies are making them cheaper and better, at a faster pace than the enterprise technologies. For instance, git is improving at a faster pace than perforce. Those companies that took advantage of the cheaper alternatives in consumer technologies, reaped the benefits of cheaper and better infrastructure, application construction, and operations. Google built their data center on commodity boxes. Facebook leverages open source technologies fully for their needs. The following are the main reasons why the consumer technologies are often better choices than the enterprise grade technologies.


So, considering that enterprises are being pushed towards consumerization, how should IT react?

Consumerization: an IT perspective

The best course of action for IT is to get the best of the both worlds. On one hand, it cannot run business as usual without its control and governance. On the other hand, it cannot react to markets innovatively without the consumer technologies.


As we bring both these best practices together, we see some interesting facts emerge. At least for certain aspects of application domain,  we see that old style of large scale application development does not work.


As consumerization increases,  we end up with large number of small applications instead of small number of large applications. Of course, the definition of application it self is subject to change. For our purposes, consider any isolated, independent functionality that people use to be an application. Historically, we used to talk about modularizing the application. Instead, now, we break down large application into smaller pieces. Some of these smaller pieces may have multiple versions to suit the extreme segmentation that consumerization supports.

If we are moving towards such IT landscape, what does it mean to traditional activities? In fact, all the following are impacted by this aspect of consumerization.

  • Development
  • Life cycle plan
  • Deployment
  • Support
  • Governance
  • Enterprise Architecture

Let us look at some of these challenges.

Challenges in consumerization of IT

I see three challenges in consumerizing IT.


These costs are easy to rein in, if IT can bring in some of the consumer technologies. In the next section, we will describe each of the technology changes that can help IT address these challenges.

Coping with consumerization: A recipe for IT

There are four questions that we should ask ourselves as we are embarking on consumerization of IT:


Each of these questions require an adjustment to the way IT operates. Each of these key concepts need full explanation. Since this article already has grown long, I am going to be brief in describing the key concepts.

Pace layered architecture

The idea behind pace layered architecture is that different parts of the IT move at different speeds. For instance, front end systems move fast as the technology advances faster there. The ERP packages move slow, as they focus on stability. Based on this idea, we can divide IT systems into three groups:

  1. Systems of record
  2. Systems of differentiation
  3. Systems of innovation

If we were to divide systems this way, we know where consumer technologies play a big role: systems of differentiation and innovation. To take advantage of this idea for consumerization, I recommend the following steps:


Platform based development

Typically, when we develop applications, we are given just a set of tools that we can use: Java, app server, database etc. Putting together these parts into a working application is left to the developers. At best, standard configurations are offered.

Most of the tasks developers need to do are standard: add security, add user authentication, add help text, add logging, add auditing, and so on. Considering that there are lot standard tasks that developers need to do, is there a way that we can reuse the effort?

We have been reusing different artifacts in several ways. We used libraries, templates, and frameworks. With the advent of cloud technologies, we can even turn into a platform that is ready for cloud. Platforms turn out to be useful in several ways: they standardize development; they reduce the costs; they reduce the time to get the systems ready for development; they improve quality of the systems.

In addition, within any enterprise, there might be standard best practices that can be incorporated into the platform. With these additions, we can enforce governance as a part of the platform based development.

There are industry standard platforms as well for specific purposes: Google platform, Facebook platform, Azure platform, and SFDC platform. Each of them offer different capabilities and can be used for different purposes. Instead of standardizing on one platform, an enterprise will have to classify its needs and plans, categorize its applications, and from that basis, devise multiple platforms for its needs.

Internally, Microsoft has positioned SharePoint services and Office 365 as such a platform. Coupled with .NET technologies, it can be a full platform for delivering user defined applications.

Backend as APIs

The potential of the platform can be fully realized if the enterprise data and functionality is available to the apps developed on the platform. For instance, the data locked in the ERP applications is valuable for many modern applications. Existing logic within the system is difficult to replicate elsewhere and may be needed by the application.

By providing this information, both data and logic alike, as API’s, we can enable internal application as well as external applications. In fact, the current application development paradigms around API based front end development offer several different frameworks for this style of development.


Using REST+JSON API’s, we can develop web as well as mobile applications from the same backend.

Modern app stores

Once applications are developed, they need to be operational for the people. There are four different aspects to putting applications to use.


There are several different ways such an app store or platform for delivery is handled historically. Popular choices for different ecosystems include, Apple’s app store, Google Play, FB Apps, etc. If we build it right, we do not have to restrict the app store to mobile applications alone. Instead, the same delivery and support mechanism can support mobile and web applications as well.

Concluding Remarks

Consumerization of IT is a desirable trend, if handled correctly. The right way to handle to bring the useful elements of consumerization to appropriate kind of applications. The core features from consumerization include conceptualization of apps via pace layered architecture, development via platforms, integration via API’s, and delivery via app stores.