Livewire: The Communications, Media and Entertainment Blog

What is Rationalization or Application Modernization?

Rationalize is an oft used word in mathematical parlance. And what it means is that it removes radicals (remember square roots 3, 5, etc in the denominators), such as from denominator, without changing the value (of an expression).

Mapping this definition from mathematical to Business application system context, we can say that Rationalization of Applications is nothing but the removal of specific parts in the application ecosystem which will make the ecosystem leaner and efficient, nevertheless, will not have any impact on the functionality delivered by it.

For IT Systems/Applications, what to rationalize?

In Mathematics, when we see a fraction, with say square root 3 in denominator, we know to Rationalize, it we have to multiply the fraction by the same radical. Unfortunately, this is not very easy when we try to map the analogy to IT Applications. So the question of what to rationalize can be answered by the business application designers by identifying the radicals in the system.

The rule of thumb should be that, if removing an application from the stack, keeps the functionality intact, then it is prudent to remove the application from the stack.

Evaluating an application for Rationalization:

The problem which large organizations face is that over a period of time, the number of IT applications reaches a stage or are so huge in number, it becomes difficult to calculate the utility of all the applications and the result is inefficient use of IT Applications.

But, how to evaluate an application for Rationalization?

These are the general guidelines:

-          The application is legacy.

-          The application is tactical, that is historically, and it was perceived to fulfill the tactical requirements of business.

-          The data elements in an application bear similarity with other applications, which covers more functionality. (This is an application which has more number of functionality compared to the application to be rationalized.)

-          The functionality provided by this application can be fulfilled by any other application with little impact.

-          The removal of this functionality from the stack, does not impact the business in anyway.

The success of rationalization will depend on this.

Posted by Akshay Joshi at 11:04 AM | Permalink | Comments (1) | TrackBacks (0)

There is a stiff competition among telcos especially in global enterprise space to capture the market. Gone are the days when telcos use to launch frequent network based services to capture the market. These network based services on technologies like MPLS, ATM, Frame etc have become mature and saturated.  To launch a new flavor or a new variant of these services does not take long time.  Having said that, there is always a need to tweak these services based on customer requirement but it does not impact the launch process too much. The reason being is that operations, supplier contracts, business processes and OSS do not undergo much change. Apart from this, there are new and new network based services arriving especially in Ethernet and fiber space which might have major impacts on the OSS and process.

To create the differentiation, telcos are exploring to capture more of managed outsourcing deals and that too in the space of value address services. The example of these services would be launching and managing the contact center services or building and managing data center services for a big enterprise. Telcos have experience in dealing with these services for long time at small scale. The challenge they are facing is that launch of these services as a standard service takes very long time and needless to say, they lag behind their competitors. I was talking to head of the product and marketing of a big telco in South East Asia and he resonated with me and confirmed these challenges. It takes almost a year to launch these services which they cannot afford. The reason for such a long delay is the current product/service launch process practiced in the organization is not capable enough to take these new kinds of services. These processes were defined to launch network based services. Because of the market pressure, product managers would attempt to launch new services using the existing process or without any process. As a result of this, there would not only be huge delay in product launch but also the faulty product launch which impacts the customer experience. This is a visible trend in all telcos especially telcos who are new in launching value added services. There is a huge demand in this space. Telcos are looking towards business process consulting companies for the help in not only defining their product launch process but also establish the product/service launch center which will manage the roll out multiple parallel products in the market.

We are currently working on the solutions in this space which can be taken to multiple telcos to launch their value added services. Please share your views if you have also came across similar challenges with your client.

Posted by Anupam Agarwal at 5:44 AM | Permalink | Comments (0) | TrackBacks (0)

It is an ever going debate whether B/OSS should be based on business processes or business process should be defined based on functionality provided by B/OSS. Most of the business process consultants support the "process based system" school of thought. According to them, operators should first define the hierarchy of business processes based on the business strategy and then develop or buy the systems to realize these processes. This way, Business processes and systems would be in alignment with business goals. This at least holds good for green field operator. On the other side, many operators (especially brown field operator), under the time pressure to launch new service or respond to a big client request, adopt the "system based process" approach. They would first modify the system and then tweak the process accordingly. Sometimes, process design and system design goes hand in hand.  There are times when process design and system design conflict with each other. Based on my experience, during these conflicts, process needs to be compromised based on system capability.

Telecom industry especially wireless is undergoing tremendous changes. Wireless operators not only have to compete with other wireless operators but also with new animal named OTP (over the top). Players like goggle, skype, and yahoo are eating their pie more and more every day. For the top players, customer acquisition is going up but ARPU is flat or marginally going down especially in India. CIOs are struggling to control the opex and squeeze time to market to launch new services. In this scenario, this debate of "Process based system" Vs "System based processes" takes the new meaning. It is no more the academic discussion. This has become very critical to the business. These days, most of the CIO wants low cost strategic IT solution. Cost is the number one priority with no compromise on extensibility and flexibility of the solution. They want solution which does not need customization and can be implemented with minimum configuration/customizations. They don't want to invest money in first designing the business process and then customize the system to realize the processes. Their wish is to use the process defined and implemented by the COTS vendor in their solution. I interacted with two senior executive from CIO office of two wireless operator last month and both resonated this approach. They believe that this is the best cost effective approach in the current frame of time. The key issue in this approach is the integration of different solutions from different vendors to achieve seamless operation. Without any defined process hierarchy, common information model, crisp interfaces, this integration will be nightmare. Luckily frameworks like TMFs frameworx (eTOM, SID and TAM) have rescued the situation. TMF has defined the process elements and business entities, which can be readily used by COTs vendor to define the solution. This way solution would be extensible, integratable and readily deployable. On top of this, TMF also provides the conformance framework, to evaluate the COTS package against the 7 level of conformance levels. Around 10 COTS vendors have published their conformance against the framework which makes it easy for operator to select the right COTs vendor. We will talk about challenges in the conformance some other time.

Posted by Anupam Agarwal at 8:44 PM | Permalink | Comments (0) | TrackBacks (0)