I recently had the experience of completing an end to end C2M implementation project. Got good experience and working knowledge of C2M product. On completion of the project, did an evaluation of the product from an implementor/developer point of view and have shared my views of the same.
For people who do not have an idea of working with C2M, this new product of Oracle is a combination of different existing products of Oracle Utilities. These existing products include CC&B (Customer care and Billing), MDM (Meter Data Management), SOA (Service Order Management), ODM (Operational Device Management) and SGG (Smart Grid Gateway). A new layer of C2M has been built over these products to help these different underlying products interact seamlessly with each other.
Technically speaking this integration of different products has been done by adding new algorithms on Audit plugin spots, synchronization objects and building common UI for common entities across products. Just to give an example, service point is common in CC&B, MDM and ODM. In C2M, on the backend, the database tables for service point is different corresponding to each product (CCB – CI_SP, MDM – D1_SP, ODM – W1_NODE). All tables are populated with the same data of a service point even if it increases redundant data. Algorithms are attached on Maintenance object audit spot to update the corresponding data in other product’s table whenever the data in one table is updated. Synchronization objects are also created to aid in this data synchronization across tables. Only one common UI map is made accessible to the user for service point. Any updates made on the UI map are synced to all the tables in the backend.
Things I was happy with in the new C2M product:
- I have worked on both CC&B and MDM before. So my learning curve was less for C2M. I can easily pop into working directly on C2M knowing the underlying working of each product. So I would say someone who has worked before in CC&B or MDM would not face much difficulty in learning corresponding module in C2M as the underlying functionality is same.
- Reduction in synchronization integration and usage (bill determinant) integration points. These points generally involve a middleware to convert the requests, configuration of JMS queues and lot of testing to ensure the entire integration is working properly. Lot of integration and testing effort was reduced in this area as CC&B and MDM are present in the same product.
- New products/modules like SOA (Field work management) and ODM (Operational device or Asset management) were easy to pick up and work on as they were based on OUAF Business lifecycle objects and not Cobol to Java converted Service programs like in CC&B. The learning curve is less if you have worked on pure OUAF java products like MDM, MWM etc. People coming from a pure CC&B side might face some difficulty here if they did not have much exposure on the OUAF java framework.
Things I wish were better in the product:
- Too much redundant data present on the system. Merging of all these products by just adding a new layer on the top of multiple products has the big disadvantage of adding on redundant data in the system. Might be better if Oracle integrates these products at a database level instead of just adding an application layer at the top. This would improve performance of the system and also enable the system to scale up for an implementation having a large customer base.
- Lot off unnecessary synchronization calls happening in the system just to sync of the data between different products. This increase the load on the system and creates lot of unnecessary algorithm calls in the system.
- Synchronization errors cause data to be just updated in one module and not in the other. E.g. Field activity got created in CC&B but did not get created in SOA due to some synchronization error. But took some time to identify that corresponding counterpart object in other module was not getting updated. This is not a one off error. Have seen this kind of synchronization errors coming up on multiple modules. These kind of errors are not easily identifiable as on the front end we see updated data. This is another disadvantage of having multiple synchronization happening in the system, just for updating an entity. One way to identify issues would be to monitor all synchronization objects getting created in the system and monitor any sync objects going to error status. Since there are lot of synchronization objects getting created, this would also be a cumbersome task.
- There are some unexpected errors coming up during working of the product primarily because these are different products stitched up to work together rather than one coherent product built from scratch.
- One thing I would like to see is replacement of entire Cobol to Java converted code in CC&B module to pure Java code. Even though oracle has removed the entire Cobol runtime from the framework, lot of out of box code are Cobol2Java converted codes. These codes are more like machine converted code and is not readable for a developer after decompiling. On the other hand, if it was just new Java code (not converted from Cobol) created from scratch it would be easier for a developer to understand how the out of box code works. This would need Oracle to completely rebuild the CC&B part of the product from scratch in Java and has a good chance of introducing new defects in the product. But I feel it would be advantageous in the long run.
- Redesign the entire CC&B part of the product and convert all plugins to business object lifecycle plugins like other newer modules. Currently there are lot of plugin spots which are just present at adhoc locations on the product. Only someone with a lot of experience in CC&B would have knowledge of all plugin spots. For a new person, this increases the learning curve as you need to go through Oracle documentation to understand functionality of each plugin spot. Also CC&B has lot of objects which cannot be converted into business objects as they support only legacy services for update. This causes lot of difficulty in extending the product. Due to no business object layer, customizations generally go down to Java changehandler for out of box entities. Also changes to front end is very difficult as they don't utilize UI maps. This puts restrictions on the developer for customizing the product.
I understand that Oracle would have some limitations and reasons for the ways the product has been designed currently. These might be business reasons and also practical reasons for avoiding drastic changes in product from existing products that might prevent someone invested in CC&B for a long time in going for a new product.
Possibly Oracle can think of redesigning the whole C2M product as a new product built purely in OUAF framework instead of it being an extension of existing products. This might impact existing CC&B developers who have vast experience in the CC&B product. But in the longer run, it would be better for everyone. The learning curve would be faster even if it is for a new product as it would be based on pure OUAF framework guidelines. This would also help it in adding new features to the product that might be limited by current legacy code.
