In our last post, we discussed WSRP and web services as PeopleSoft to SharePoint integration techniques.  Based on the limitations inherent in WSRP, we don’t consider it a viable integration technique so we won’t be spending much time discussing it in the future. In this post, we’re providing you with a way to realistically ballpark the level of effort required to achieve PeopleSoft to SharePoint integration using web services.

Where We’re Coming From:

This analysis is based not only on our own experience, but that of a PeopleSoft customer who shall remain nameless (don’t even ask, we’re not telling). Our analysis isn’t perfect, but we think it’s fairly representative of the true costs of web services as a PeopleSoft to SharePoint integration technique. We’ve also vetted it past at lest two other customers, both of whom confirmed that the spreadsheet was accurate, even perhaps low-balling the costs a bit. In any case, if you’re considering integrating PeopleSoft and SharePoint using web services, this might give you some added things to think about.

What we offer here is a spreadsheet that calculates a per-component estimated cost to integrate PeopleSoft components into SharePoint using web services.

You can download the spreadsheet here, but before using doing so read on. It’s best to understand how it works so here’s a breakdown.

Member Pages:

First, note that each PeopleSoft component has been presented in terms of how many “member pages”, or pages full of fields, comprise each component within the PeopleSoft web interface. For example, the “View Paycheck” component presents content across two pages; a summary page listing all paychecks that are available for viewing, and a detail page for each paycheck.

While your organization may choose to combine this information on a single page if creating its own custom UI, the number of member pages within the delivered PeopleSoft UI is offered as a fairly objective measure of each component’s inherent complexity. You plug in the number of member pages for the PeopleSoft component you’re considering integrating into SharePoint with web services, the rest of the columns are automatically calculated based on the variable assumptions table. We’ve pre-populated the member pages for a handful of the most common PeopleSoft components.

 

Variable Assumptions

Second, you will note that we’ve made several assumptions. These come in the form of variables that influence the calculations. These variables are as follows:

  • Development Time
  • Development Cost
  • Security Configuration
  • Error Handling
  • Quality Assurance (QA)
  • Expected Annual Maintenance
  • Product Lifetime

We’ve base-lined these values for you according to our experience as well as the hard costs a PeopleSoft client actually incurred to integrate PeopleSoft components into SharePoint using web services.

Below is a brief explanation of each variable and our justification for having set the threshold at its current level.

Development Time (Dev Time):

The 5 week development time per page is based not on our estimates, but on the actual development time of a PeopleSoft customer. Based on our own development experience, we feel this 5 week development time per page is reasonable. If you feel differently, please, join the conversation and let us know!

The bulk of the dev time would be spent trying to bring PeopleSoft data in and present it within the SharePoint framework. On the whole, we feel five weeks per component member page in PeopleSoft data is a reasonable estimate – especially when you consider that in many cases an organization will be intent on doing more than just present data, it will also endeavor to modify it and write back to the database.

This number is derived from experience. In one example, a PeopleSoft customer endeavored to bring one page of PeopleSoft data into SharePoint.  This actually took 10 weeks. They developed one page of W-4 integration. We estimated 5 days instead of 10 based on projected economies-of-scale as well as having surmounted the “learning curve”.

Development Cost:

Development cost is a fairly straightforward calculation of $50 per hour X 40 hours per week = $2,000. Feel free to plug in your own dev costs!

Security Configuration:

Security configuration will add between 10% and 50% onto the development costs.

The assumption is that you will have to perform lookups on the data, behind the scenes, against PeopleSoft. This would need to take place in the form of a web service that goes out and fetches the data.

Next, there’s a separate call that you have to make in order to determine that the current user is actually allowed to see the data that the system was being asked to present.

If you could pass the user name and password you could attach those to the web service if you can get them out of SharePoint.  However, you can’t contact PeopleSoft directly out of SharePoint. There has to be an intermediary wrapper that takes the information out of PeopleSoft and repackages it in a way that SharePoint can understand it.

In order to bring forward a relatively simple PeopleSoft component such as View Paycheck, you will most certainly need to enforce PeopleSoft row-level security and permissions.

This is one area where we would recommend you exercise caution. In other words, don’t move the needle down on this one unless you really have a good reason for doing so. Maintaining the same role and permission-based security that PeopleSoft delivers through its UI (particularly if row-level security is involved) requires you to effectively recreate the PeopleSoft security stack. The level of effort required to achieve this is substantial.

That said, if Digital Certificates can be used to impersonate your end users (instead of using a generic / service account to call the web services) then move the security configuration adjustment to 10%. Likewise, if an external DB can store PeopleSoft UserIDs AND passwords then reset the security configuration adjustment to 20%.

Error Handling:

Error handling and validation will also need to be accounted for because PeopleSoft will not accept certain types of data and will return an error messages that are cryptic to end users when improper data is received. If you pursue an in-house solution it will need to accommodate error handling and validation to have a properly functioning PeopleSoft SharePoint integration solution.

Quality Assurance (QA):

You should expect to allocate time to QA an internally developed solution because PeopleSoft does have a tendency to behave differently through its native pages than it does through its web services. We played it relatively safe with a 20% incremental cost based on the weekly dev costs, but feel free to modify this a few degrees in either direction.

Expected Annual Maintenance:

PeopleSoft 9.2 is coming in 2013 as is PeopleTools 8.53 and SharePoint 2013. Think you’ll upgrade any of these at any point in the next couple of years? Web services integrations aren’t upgrade proof so expect to have to go in and rejigger them if you upgrade. We’ve amortized the cost over 5 years at 15% a year.

Product Lifetime:

To give you a better picture of the total cost of a web services based PeopleSoft to SharePoint integration, we’ve assume an integration lifetime of 5 years, but don’t hesitate to modify this based on your organizational culture and personal experience.

Wrap up:

In the above example, we’ve illustrated that integrating the PeopleSoft ‘View Paycheck’ component into SharePoint could reasonably cost (we think) nearly $60,000. You can noodle the variables to suit your preferences in our web services costs calculation spreadsheet to your heart’s content. You can also see our projected costs based on the number of member pages for the following PeopleSoft components: View Paycheck, Direct Deposit, Time Reporting, Monthly Schedule, Absence Balances, Personal Information, Benefits, W4 Information, and Manager Self-Service.

Get it now:

This spreadsheet can be downloaded and used to calculate the estimated cost to integrate any PeopleSoft component into SharePoint simply by modifying some of the corresponding variables – in particular, the number of ‘member pages’. To download our web services cost calculator click here. If you use it, please let us know by posting a comment back on this blog post. Was it an accurate predictor of costs? Did you just use it for budgetary purposes? We’d really like to hear back from you so we can further refine our projected estimates and variables. Also, below is a 3 minute video that explains the differences between web services based approaches and InFlight.

 

One response to “Web Services Integration Cost Analysis

Leave a Reply

Copy link