Skip to main content

More About Business Drivers

Printer-friendly version

Business drivers for Transformation come in many different flavors and the perception of them often changes during the needs assessment process. At the start of the assessment process, a need may be obvious and well-recognized by much of the company or it may be an obscure problem, perhaps recognized by only one person and it may not have occurred to that person better software could fix anything. Drivers may be common to many companies or very idiosyncratic to a specific company and its own business processes. And, while it is perhaps most common to think of business drivers in term saving existing costs or improving efficiency, there are also drivers which relate to increasing revenues or creating new business opportunities. One also often thinks of business drivers in terms of their size, either relative to the impact on the business or the perceived difficulty of a solution.

Among the business drivers which are quite often the trigger for considering transformation are those which are obvious and big. Some common examples are:

  • Changing the user interface of some or all of the application to a more modern form or to a web interface for remote access;
  • Integrating multiple systems in a point to point fashion, which becomes increasingly burdensome as more systems are added. This is common in companies which are growing by acquisition;
  • A demand for substantial supply chain integration, which might come from a shift in business practice in the industry. This category first expressed itself significantly with the move to EDI, but more recently there is a demand for more real-time and complete integration, often through web services.

While this type of big obvious driver is easily recognized, it is also the kind of driver which can cause a company to despair since it is so overwhelming in scope and difficulty. At the same time, they can also be drivers which have substantial financial impact on the company and thus are worth the effort and cost. However, one has to look at each driver and each company individually since mere obviousness does not necessarily imply a real business need. Moving to a more modern user interface is one example of a very obvious possible driver that may or may not have any real business justification for a particular company or where there may be a real justification that only applies to a small part of the application.

Drivers which are specific to the company and application are more difficult to talk about in a general way. Typically, though, they are cases where either

  • A business process has been deeply hard-wired into the software and now that business process needs to change; or
  • Where the process itself hasn’t necessarily changed, but industry expectations about the speed with which that process must operate have changed dramatically and the mechanisms used to implement the process are no longer adequate. There are many dramatic examples of this kind of shift in the financial sector such as the move from three day settlement of stock transactions to near real time resolution.

This type of driver is often characterized by movement from satisfaction to dissatisfaction gradually over a period of time as that which was once adequate becomes less and less so until it becomes an acute business problem. In the most extreme cases, particularly if there are regulatory issues involved, this type of driver can be the primary one instigating consideration of transformation.

Another large group of drivers might be characterized as pervasive issues which are typically under-recognized. One example is code which has undergone years and years of patches upon patches with no overriding architectural guidance and which has gradually become very brittle and difficult to maintain. This condition of brittleness is often accepted simply as “the way things are” without the recognition that the current state is not only much worse than it used to be, but also that substantial cost savings could be realized if conditions were improved. Similarly, with the change in the pace of business change, the time required to make changes for new business processes or rules, which may have been perfectly adequate some years ago, now is too slow to keep up. Some of this time requirement can come from outdated development processes, but a lot often comes from the application architecture itself. One of the key goals in modern architectures is “nimbleness”, the ability to make changes quickly, confidently, and with little effort.

Another common opportunity which is partly of this last type, but which is more likely to be recognized by the individual business is having an application architecture which is inherently monolithic and centralized, but a business which has evolved to be geographically distributed, perhaps even globally. Especially if there is a need to keep systems running when communication lines are down or if there are individuals who are only irregularly connected, moving from a monolithic structure can imply dramatic changes in application architecture.

A common theme among the major business drivers for transformation is that the scope of the change or the nature of the change required is very different than the routine maintenance operations which have constituted the day to day management of the application in the past. This can easily lead to a sense of panic since not only is there no existing budget for such work, but the apparent scope of the project can greatly exceed any previously undertaken. This issue is underscored when the staff and management have no experience in the type of work involved, e.g., a long history working with character user interfaces and a sudden need to create graphical or web applications, possibly not even using ABL.

UPCOMING: Next time I will talk about different types of transformation as a first step in understanding how to meet this seemingly overwhelming challenge.