Workflows Everywhere

 Reporting  Comments Off on Workflows Everywhere
Oct 242011
 

Workflows everywhere: In trouble ticketing platforms, CRM, Inventory Management Systems, Service Management Systems, Order Management Systems. Each of these systems implement some kind of workflow engine to automate the processes they depend on.

Would not it be wise to merge all those in a common workflow engine? Would not it be more easy to manage the workflow environment  and migrate to a BPM one?

It will definetly increase managebility and reduce costs. But the biggest obstacle that rises is the integration tax. Centralization means complete integration. Each and every platform should be integrated to this centralized workflow management system via some kind of distributed computing technology such as web service or CORBA. The systems that implement older technologies will not support the newer integration enablers. When this happens, it will be a necessity to install an ESB in the middle.

The second concern that may appear at the application side is the flexibility of those applications. The applications should allow to hand over control logic to an external application, and some of those, especially the legacy ones will not allow you to touch their logic. (The same problem will also be faced when dealing with BRMS platforms) . To overcome this, we may implement “dummy” workflows that will trigger the main workflow engine, but again, you will have to design the workflow in two places.

Because of these reasons, the centralized workflow environment may bring additional burden instead of removing some.  For the greenfield type operators , that can be a highly applicable strategy but for operators who has lots of diversed systems and vendors, that seems not be very feasible.

 

Common Reporting Platforms

 Reporting  Comments Off on Common Reporting Platforms
Jul 242011
 

CSPs have lots of OSS and BSS tools. All these tools come with some kind of reporting solution. Some reports are embedded in the product, some OEM Business Objects, Cognos like tools on the top of their databases.

The problem with these reports is two fold. One is, they are just built to show operational data to operational people that are in charge of that specific OSS/BSS domain. These reports often include lots of technical data that are meaningful only to the technical people. Business people, or even the technical people from other domains usually need for some kind of “translation” in the provided data. If the tool allows, the domain owners would create (or ask IT to create) new reports that are meaningful to other parties.

While translating the “language” of the reports, the look-and-feel is also taken into account as business and executive reports should look fancy and include charts, graphs and some kind of analytics on the top. This report beautifying process, also adds another burden to the operations’ day-to-day activities.

Second problem arises in the nature of data. The data that can be extracted for the reports is for the tool’s domain. This prevents cross-domain analysis report creation which is crucial for the business people. The organizational functions that operate on the service management layer (such as SOC) also need these kind of reports to run historical analysis on the operational performance.

As mentioned before, most of the products do include a separate reporting solution by either OEM’ing or utilizing CSP’s reporting platform licenses. These also bring additional license costs and maintenance effort to the customer, resulting an increase in both OPEX and CAPEX.

Common Reporting platforms aim to solve these problems. In such kind of a platform, all the organizational groups connect to a single platform for all their reporting needs. There’s much less maintenance cost of such kind of a solution. Usually 1 or 2 admins with reporting and DB skills would be enough to run such kind of a platform.

Removing the need for reporting from the OSS/BSS tools will reduce the license costs of the solutions. Also, some machines that are procured with these solutions just for reporting purposes would return to the free inventory.
Implementing a common reporting platform, starts with investing in a BI reporting solution. Cognos, Business Objects like products will be good fit for such kind of a platform.

There are several implementation strategies for these platforms.

First one is to take the data directly, on the fly, from the operational data sources and combine under a common logical data model that will be used for reporting. This is a low-cost implementation as it requires only the reporting platform licenses and hardware. The drawback of this solution is it may degrade the operational data sources, thus the OSS/BSS platforms’ performance. A detailed analysis is required to see the effects of the reporting load on the platforms. (It is a common act to over-size the hardware at the presales phases)

The second approach is to include a staging database in between and use this database for reporting purposes. An ETL process will also be required to take the data from underlying operational data sources to this staging DB. This brings additional performance both in reports and the operational databases. The drawback is obviously the need for a separate database and an ETL tool which will bring extra costs.

The second approach could also be used for a phased strategy to move to a network datawarehouse. Common reporting platforms could easily migrate to network datawarehouse
platforms. This way, It will be more easy for the operational teams to justify the next NW datawarehouse investment to the business.