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:
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
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.
For services related to this material, see my website.