On-Demand Applications - What I did not say?

It has been sometime since my last post, I was a bit busy with the Re-Implementation Strategies (Actually I wanted it to be the first post on my blog for sometime so that I could get some more ideas!). I was going through the success story of Salesforce.com and found out that it can be attributed to hosting applications. The mid-sized companies which need an IT solution to their business are quick to realize the cost benefits of this On-Demand version of software applications. Remember the post titled “Past, Present and Future of Applications”, I did discuss about the future of ERP industry will most likely be the hosted applications. On-Demand is how we call it! Would you believe it if I told you that I did not know On-Demand was what I was referring to? I’m disappointed at myself! I was under the assumption that, I’ve come up with a brilliant idea. But the reality is I’m not reading all the news! I hate myself for doing that.

But the idea already in existence does not ward me off. After I made the post I knew how to achieve On-Demand (to a certain extent!) but the problem that I knew and did not let know is what I’m going to discuss in this post (Probably, I should have been in marketing!). When a Customer chooses a XYZ’s On-Demand services, his entire IT infrastructure is with XYZ, this makes a move from XYZ to ABC almost impossible. If ABC after certain years comes up with the best possible application architecture and business process the Customer might regret his choice of XYZ applications. This problem is most similar to the one faced by Bigger Customers who have chosen an application (ORACLE/SAP/PeopleSoft/Siebel) which suited their requirements when they bought the applications. I hate this inflexibility, but this is what drives the business of the product vendors (Customers watch out!).

The second issue in choosing an On-Demand service is this, if a large number of Customers are being hosted with a single infrastructure, the Customer looses his freedom of upgrade at HIS pace. Although the architecture change which the On-Demand vendor wants to make to his existing systems would definitely add value to my application, I’ll not enjoy the constraint of moving to the new release at a time when I have my own business issues to take care of. Additional cost which must be incurred might bring my business down.

I’m still searching for answers to these questions in the World Wide Web, will let you know if I find one.

Today morning my friend called me up and told me that Oracle has extended the development plans of PeopleSoft. Read more. I hope my predictions will come true!

Re-Implementing PeopleSoft Data Conversion Strategies

Although I strongly believe that my current Customer should not have opted for a re-implementation, I do not intend to squeeze every penny out of his pocket. Now it is my responsibility to reduce the amount of effort required in this project. The effort required in data conversion will define the project and I badly wish that I pull it off. Today I started documenting the various strategies which could be followed for data conversion and I look forward to your valuable suggestions to choose the best out of these. The complexity with this project seems to be never ending - The customer has a single 7.5 instance and he wants to split the single instance into two different 8.9 instances (X and Y). The amount of customer data amounts to approximately 300GB.


Re-Implementation - Data Conversion Strategies

The purpose of this post is to analyze the various data conversion strategies that can be adapted during a PeopleSoft Re-Implementation when the Customer intends to move from PeopleSoft version 7.5 to 8.9. The biggest challenge in a PeopleSoft implementation is data conversion and the right strategy adopted at this stage marks the early success of the project. Let us look into the various data conversion strategies available in brief.

Upgrade-Like Approach
In this approach, data conversion is achieved by using the PeopleSoft delivered Application Engine programs customized to suit our requirement. To achieve our objective of migrating the application data from the Old PeopleSoft system (7.5) to our new system (8.9) we must first upgrade the PeopleTools release of our 7.5 system to 8.46 and then copy the records, fields and record fields from our newly implemented 8.9 (We must have applied the customizations to the new system) system to the 7.5 system. After this we run “Alter without deletes”. Copy the application engine programs delivered by PeopleSoft for data conversion into the 7.5 system. Customize the conversion programs to suit our requirements. Run data conversion programs and then “Alters with Deletes”. The application data in our 7.5 system can now be migrated directly to our new system using database tools for export and import. Finally we can purge the data not required by X and Y in the X and Y systems respectively.
Pros
The effort required to create the data conversion scripts can be greatly reduced.
The delivered data conversion scripts can be used with slight modifications (Modifications are required to handle data conversion programs specific to the upgrade path 7.5 to 8.8 as these programs will be expecting the records to have structures of 7.5+8.8, what we have in our database is 7.5+8.9)
The data conversion process is handled efficiently in this approach and hence the time required for conversion and migration is reduced greatly.
Cons
The PeopleSoft delivered data conversion scripts are path specific, hence effort required to merge the two sets of conversion programs (7.5 to 8.8 and 8.8 to 8.9) into a single program must be taken into account.
During the final move to production there is an added overhead which requires us to perform the PeopleTools upgrade of the 7.5 system.
PeopleTools upgrade will also require database migration from an older release of Oracle to the supported Oracle database release.

‘RE’-Implementation Approach
In this approach we develop SQL scripts which will convert the data in the 7.5 system to the data format required by the 8.9 system. The SQL scripts will convert data by a series of CREATE, ALTER, UPDATE and INSERT statements depending on the data format required by 8.9. The data conversion happens within the 7.5 system and hence it is very efficient. These scripts are created with the help of the PeopleSoft delivered data conversion programs. Once data conversion is complete we can migrate the data from the old system into our new system using data migration tools. Data segregation between the X and Y systems can be achieved by purging the data that is not required in each of these systems (Scripts must be developed for this purpose, these are simple DELETE statements with conditions specific to purge X and Y data).
Pros
The overhead of upgrading the PeopleTools release of the 7.5 system during final move to production is removed.
The data conversion process is optimized by directly migrating the data from 7.5 to 8.9 system after conversion within 7.5 system.
Cons
The effort required to develop the conversion scripts is huge.
The reliability of the conversion scripts cannot be assured until we obtain the comprehensive test results.

DBLinks Approach
Data conversion programs delivered by PeopleSoft for the upgrade paths of 7.5 to 8.8 and 8.8 to 8.9 are analyzed and merged to create a single Data conversion application engine program. The data conversion programs are customized to read data from the old release database using DBLinks and insert the data into our new release systems. Data segregation for X and Y specific data is achieved by customizing these programs to suit our requirements. The tables which are not handled by the conversion programs can be directly migrated from the old release database to the new release database.
Pros
The overhead of upgrading the PeopleTools release of the 7.5 system during final move to production is removed.
Data segregation between the X and Y systems are achieved in a single step.
Cons
The migration of data between databases using DBLinks is not desirable for large amounts of data as this may require a large amount of CACHE to hold the selected data from the old release database.
DBLinks in Application Engine programs is not recommended by PeopleSoft.
Migrating data from the old release database could be time consuming if the Servers are in different locations, this would be the scenario with X and Y systems.

Database Schema Approach
The application data is migrated from Copy of Production to a new schema in the database server containing the new release database. The delivered data conversion scripts must be customized to read data from the tables that exist on the database schema for copy of production and insert the data into the tables present in the new release database schema. This would increase the efficiency of data migration. Data segregation for X and Y specific data is achieved by customizing the delivered programs to suit our requirements.
Pros
The overhead of upgrading the PeopleTools release of the 7.5 system during final move to production is removed.
Data segregation between the X and Y systems are achieved in a single step.
Cons
Although this sounds logically feasible, the complexity involved can only be addressed by a PeopleSoft DBA.
The conversion programs must be tediously analyzed and the schema names must be added to each of the conversion scripts.

Pure Implementation Approach
Data conversion and migration are achieved in this approach by developing Application Engine programs in the 8.9 system to migrate and convert data from the 7.5 system. The migration and conversion can be achieved by developing Component Interfaces. Separation of X and Y data can be handled from within these conversion programs.
Pros
The overhead of upgrading the PeopleTools release of the 7.5 system during final move to production is removed.
Data segregation between the X and Y systems are achieved in a single step.
Cons
Migration and conversion can be achieved using Component Interfaces or Application Engines only if application data is present in a flat file format, hence during final move to production all the data in the 7.5 system must be converted to flat file format.
Cut off time required during final move to production is considerably increased due to the requirement of converting the data into flat file.
The conversion process will not be as efficient as the conversion within the database as in the previous case.

Partial Implementation Approach
In this approach we identify all the tables which do not require any structural changes for data migration (Customer created tables are the best examples to this class of tables). Migrate all these tables from 7.5 to 8.9 using database migration tools. For the tables requiring conversion we develop the conversion programs as described in the Pure Implementation Approach. Data segregation for X and Y systems can be achieved in the conversion scripts for tables that have a structure change between the old and new releases. For the tables which do not have structural modifications, data segregation can only be achieved by purging the data that is not required in each individual system.
Pros
The overhead of upgrading the PeopleTools release of the 7.5 system during final move to production is removed.
The data conversion process is optimized by directly migrating the data which do not need conversion.
Cons
Although data conversion is optimized by directly migrating data from tables which do not need any data conversion, ideally the amount of data within these tables will only amount to a small percentage of the entire application data in the system.
Cut off time required during final move to production is considerably increased due to the requirement of converting the data into flat file.
The conversion process will not be as efficient as the conversion within the database.

Kindly vote for the approach that you would be following or if you have a better approach do let me know.

PeopleSoft Missing Key

I’m back from my vacation! It was a wonderful trekking experience – People who came along with me were shocked at my stamina, which I think is at its worst! Back to blogging. This is something that I always wanted to write, and the attribution comes in the beginning – this story is a brain child of one of my friend kartick (He works for ORACLE Corporation - not me!). He doesn’t write Technical stuff, so don’t be disappointed after reaching his blog.

Most of you know that I enjoy working with the application directly from the back-end. I’ve used Meta-Data manipulation more than PeopleTools. The most interesting part was when I created a page using SQL INSERT statements. It was a wonderful sight. All this backend playing was totally alright when you are developing objects, but manipulating application data requires you to be extra cautious. The reason as we all know is that data integrity is maintained in PeopleSoft by the Application Server code. When we insert a parent record and a child record in a PeopleSoft page, it is the responsibility of the internal code to maintain data integrity. A few months back my friend was given the task of uploading some data into the PeopleSoft Test environment, with absolutely no Functional knowledge (Just like me!) he uploaded the data into the child without taking the parent into account. This I think could have been prevented had PeopleSoft provided the capability of Foreign Keys.

Foreign keys, this is what I intend to discuss in some length. PeopleSoft used almost all the delivered capabilities of the database world, why did they miss this? The reason could go something like this – Development training for a record creation is very simple in PeopleSoft, had they implemented Foreign keys then the training will require the consultant to clearly understand the parent-child relation at the very beginning instead of the normal page creation part of it, I don’t think this to be a valid reason for somebody to overlook Foreign keys. The other reason could be that PeopleSoft does not recommend users to update data directly from the backend. What has just happened is that PeopleSoft had to build their integrity code; I strongly feel that we could have used the database delivered integrity to achieve our goal - Efficiency.

The tough times keep coming! This is what I currently do for identifying the all the parents of a given record, I do “Find All Definition References” and then manually try identifying the parent. This could have been easily simplified had integrity been enforced at the database level – Makes life simpler for a technical consultant.

To conclude, Foreign keys must have been provided in the application. All delivered business processes having a clear link between the parent and child record at the database level could have proved valuable. I don’t like being pessimistic, but is there something that I’m missing? I’ll leave the question to be answered by the readers.

I’m currently learning NA Payroll from PeopleBooks (trying hard to be a Functional Consultant). My first impression is – The complexity of the PeopleSoft is not at its development environment level, it is more so at the Business process level. The Enterprise product packages all the requirements and provides a lot of flexibility to the customer, but the amount of flexibility is the problem (not really Customers want more flexibility!). Trying to build flexibility into the application has resulted in expecting parameters for each simple process to manipulate it differently. If I find more time to actually become a Functional Consultant, probably this blog will move into its next domain – Functional Needs of a Customer ;)

God save Customers!

God save Customers! I am currently on a vacation and today morning got an emergency mail from my organization. I thought I’ll share it with all the PeopleSoft experts and ask them their advice on this. The current project we are on is a 7.5 to 8.9 HRMS upgrade, the Customer wants us to perform a re-implementation of HRMS 8.9 and then migrate and convert the data from their 7.5 system to the newly implemented 8.9 system. The reason being stated is that a 7.5 to 8.9 upgrade will take two hops to reach 8.9 and the customer is worried about the RISK involved in the two hops (calls it cumulative risk!). The customer wants us to implement HRMS 8.9 and then migrate and convert the data from 7.5 to 8.9. Now the biggest dilemma that I face is, I think a vendor (I mean a service provider!) conversion from 7.5 to 8.9 will have more risk involved in it than the delivered conversion from 7.5 to 8.9. The customer calls it less riskier because he says we can test the application after we convert our data to 8.9, rather than hop from 7.5 to 8.8 and then from 8.8 to 8.9 and finally test the errors and figure out the exact place where our conversion got screwed (Could be between 7.5 to 8.8 or 8.8 to 8.9). My God! I think he is missing another vital piece of it, migrating and converting all the data is going to take at least twice the time compared to what two data conversions from 7.5 to 8.9. This in turn results in double the down-time. The amount of effort required in writing the conversion scripts is going to be huge. Implementation time required for applying the required customizations to the system can be reduced to a certain extent, but it still is going to be higher. The effort required in making the setup is going to be high. I do not see any benefit to this approach.

I’m looking forward to your valuable suggestions. I’ll post more once I’m back from my vacation on Monday, hopefully. You can mail me at nextrevolutioninerp@yahoo.com