In honor of Oracle finally completing the BEA acquisition, I asked one of my old bosses, Peter Gassner, to write a guest post on some of BEA memories.

Peter actually came to PeopleSoft to fix up the old 2 tier client/server architecture and BEA played a big role in that. But I'll let Peter tell the story.

---------

Oracle finally owns TUXEDO. You can read it here. Sure, it does not mention TUXEDO, but it is in there, and it started it all.

The TUXEDO middleware product played a big part in PeopleSoft's technical history, starting from the release of PeopleSoft 7 in 1997. It is kind of interesting to trace the history of TUXEDO as it passed on from company to company and became involved with PeopleTools.

It started inside AT&T in the early 1983 and found it's way to Novell in 1993 (by way of Unix System Laboratories). It was there in early 1996 that PeopleSoft and TUXEDO met. I still remember the very small conference room (no windows) in New Jersey where Baer Tierkel, Rick Bergquist and I met with some of the core inventors of TUXEDO, including Mark Carges and Randy McBlane. We liked the software and the people. We liked it better than Tibco, MQseries, or the various other things we saw. We really did not feel like building middleware ourselves (very hard work!), so we thought OEMing TUXEDO would be good.

But, before we could complete an OEM deal, TUXEDO was snapped up again, by a tiny company that was just forming called "BEA", which stood for Bill, Ed, and Alfred. What was this BEA, we thought? Rick, Baer and I met with Bill, Ed, and Alfred, and decided "still good people, still good software, lets go ahead". That became a great partnership for BEA and PeopleSoft. It made PeopleTools more robust, and it had some not small hand in the OEM success that BEA had with TUXEDO and later with Weblogic.

Over the years BEA grow. BEA acquired WebLogic in 1998 and PeopleSoft OEMed that as well. I still remember talking to Alfred over lunch one day in 1998 after the weblogic purchase. He made a small comment that I always remember. He said with a very straight face: "That weblogic stuff is just flying off the shelves." I probably should have bought some BEA stock at that point:-) TUXEDO meanwhile was alive and ticking inside PeopleTools. Sure, it was all wrapped up in "psadmin" so that the quite unsightly configuration files were not seen, but it was there.

And now, TUXEDO finally comes home to roost in the great enterprise software roosting ground, Oracle

Congratulations, TUXEDO old boy, you have done well.


Peter Gassner
CEO
Verticals onDemand
PeopleTools Alumni (1995-2003)

Labels: 2008, History

Oracle is going to make life easy for the PeopleTools product managers if they keep acquiring all of the 3rd party products that PeopleTools embeds :-)

Joking aside, an Oracle acquisition of BEA would mostly be a non-event for PeopleSoft customers. Sure, there's potential for some of BEA's middleware to become of the Fusion stack down the road, but purely for the purposes of running current PeopleSoft applications, nothing would be likely to change (except for the logos on the installers!).

As was the case with Crystal and other 3rd party products that PeopleSoft used, there were long term contracts in place for Tuxedo and WebLogic. These contracts always included language that dealt with acquisition scenarios, including scenarios where the acquirer was hostile to PeopleSoft. Fairly standard stuff in terms of protecting yourself from the unexpected (or maybe these days you'd call it the expected).

Of course, even long term contracts do come to an end. Since Oracle is going to support PeopleSoft for some lengthy period of time, how to handle 3rd party products over the long haul still is an interesting question. When a contract comes up for renewal, there's always the chance that negotiations won't go well. As a product manager, you always have to have a backup plan ready in case you suddenly need a replacement.

I had an interesting lesson in this one time when my boss at the time, Peter Gassner, drug me and Tressa Novak, who ran the Business Development group for PeopleTools, into an extraordinarily long meeting with a vendor that believed that they had PeopleSoft over a barrel at contract renegotiation time. I won't mention their name (but I will tell you that they haven't been mentioned at all on this blog), but they brought in a few high level folks that had barely contained smiles on their faces. The anticipation of a giant payday must have been pretty strong.

The next few hours were spent with Peter slowly, but surely, convincing them of exactly how PeopleSoft could move away from being dependent on them, what the effort would take, what the problems would be and how they would be dealt with, etc. It was interesting to watch their smiles very slowly turn into frowns as they realized that they didn't have quite the leverage that they thought they did. They left the meeting room without the smiles, but still as a PeopleSoft partner. Without the detailed backup plan in place, then the negotiations surely would have turned out much differently (probably with them making Sales Club for the next few years!)

It would have been pretty funny if we had just said that we were going to buy them instead :-)

As for backup plans for WebLogic and Tuxedo, those are taken care of as well. Replacing WebLogic if absolutely necessary would be easy to do since Oracle's own J2EE server as well as IBM WebSphere are already supported choices.

Tuxedo would definitely be a harder effort, but PeopleSoft actually doesn't leverage Tuxedo so deeply that it wouldn't be possible. In fact, most of what PeopleSoft gets from Tuxedo is also supplied by leading J2EE containers these days. The bigger headache is that the PeopleTools code that runs as Tuxedo services is written in C++. Using JNI to make that work inside of a J2EE container wouldn't be pretty, but PeopleTools already uses JNI extensively for all of the Java/PeopleCode integration. Not a pretty solution, but as a backup plan, it's manageable. Certainly more so than porting all of the PeopleTools C++ code to Java, which was bandied about on a few different occasions.

Labels: 2007, Business, History

Upon reflection, I decided it was important to give credit to many of the folks that were involved in tree manager other than the heads of the teams involed in its creation, development, enhancement.

Based on my experience with the product, here are several of the folks who deserve credit other than Dana Quitsulnd, John Malatesta, and Baer Tierkel.

• Jack Whitney - From my understanding, Jack was involved in much of the early development of Tree Manager, and from personal experience, he was able to help me through several customer issues when I was consulting on it. As far as I know, Jack's still at Oracle.
• Cregg Lund - Again from my understanding, Cregg was one of the folks who was responsible for making tree manager work for both HR and Financials. He also was one of the first people to recognize that the use of tree manager was moving beyond the limitations of the original code that was developed (and that tree manager needed a major re-architecture back in PeopleTools 3). As far as I know, Cregg is an independent consultant doing PeopleSoft work.
• Nathan Vause - Nathan was what one would call the utility innfielder for the reporting development team (he was involved an practically every early reporting inititiative at PeopleSoft, tree manager included. He is one of those geniuses who can develop practically anything (and was Dana Quitslund's right-hand man in the early development stages of nVision). I believe Nathan is at SalesForce.com (as one of the many PeopleTools developers who left to go there).
• Kathy Fong - Kathy was one of the first developers tasked with fixing many of the issues created by the addition of tree branches to the product. At the time that I joined the tools team, she was diligently working through the customer issues and addressing them.
• Cynthia Share - Although I hired Cindy to work on Crystal's integration with Crystal, I recognized that the issues with tree manager required additional resources to address. I ended up moving Cindy to work with Kathy on re-architecting much of tree manager, which was a great fit because the two of them worked extremely well together and Cindy's experience as a developer with Primavera was perfect for what we needed to do with Tree Manager (albeit much later than Cregg Lund's original set of requests). This also paved the way for me to hire Brian Sparling to complete the Crystal integration (in case you don't know who Brian is, check out the following link. Cindy is still at Oracle working in the Tools Team.
• Brian Thill - I think I mentioned Brian in my original posting. Originally, Brian was hired at PeopleSoft to do the Financial Services work in EPM, but we were lucky enough to get him to do the Tree Manager port to the web from the windows client (PSTED.EXE). He then moved to do the same thing for PS/Query. He was the visionary for Data Objects, which Rick Bergquist demonstrated in the 2004 PeopleSoft Users Conference. Eventually Brian took over the whole PeopleSoft Internet Architecture development. Brian is an independent consultant working in the Portland area on different business intellige nce initiatives.
• Mikhail Dumay - Mikhail came to PeopleSoft with the acquisition of Intrepdid Software (there's a history of ingenious web developers from russia in the PeopleTools team). Mikhail took Brian's development one step further with drag and drop support. He also did much of the prototyping of the release 9 version of nVision that never made it out the door. Mikhail is still working in the PeopleTools team at Oracle.

I'm sure there are several other folks that I'm missing in this post and I'll apologize for missing them here (although I'll do my best to give them credit when I'm made aware of it).

Labels: History, Tree_Manager

Preface

Readers should note that this post is about PeopleTools 9, not PeopleSoft 9 applications. PeopleSoft 9 has shipped to customers. PeopleSoft 9 applications are based on the PeopleTools 8.4x codeline.

Take One

When I was reading Larry's post about the history of Tree Manager I said

"Hey Larry, late 1998 wasn't PeopleTools 8. "

"It wasn't?"

"No, it was PeopleTools 9. "

When work first started in late 1998 on what is now known as PeopleTools 8, the code base was originally named PeopleTools 9, but was later renamed to PeopleTools 8.

Part of the problem was that the PeopleTools group was ready to start working on that release before there was much of an applications plan in place. The general thinking at the time was that the release would be too large to have it just be a ".5" release (1).

There were already designs / proof of concept code in place for things like

* Application Messaging (using this new fangled thing called XML)
* Component Interfaces (these were originally known as Business Components, which is why all of the Component Interface tables are prefaced with BC)
* Business Interlinks
* Unicode
* Java in PeopleCode
* LDAP / Roles / Signon PeopleCode

That's quite a bit of stuff for one release, and this is even before the whole "no code on the client" stuff appeared.

As proof of how much work went into the release prior to going completely browser-based, look no further than the "Insert" menu in Application Designer.

Notice that option for inserting ActiveX controls? That was actually built for the Windows client, not the browser. Technically it is still supported with the 8.1x tools, but I would strongly recommend against using it. The menu option should have been removed when 8.4 came out (code cruft is a topic for a separate blog post some day).

I don't remember how the decision to rename it as PeopleTools 8 happened though. There was lots of turmoil inside PeopleSoft then (falling sales, layoffs, new CEO, Vantive acquisition, etc), so it's hard to say. I do know that build managers just love writing scripts to rename everything though. Not!

Take Two

So when did PeopleTools 9 next show up? Believe it or not, in late 2001. We were planning on having a small new version of PeopleTools to clean up a few things in the 8.1x codeline that we wished we had been smart enough to think about before shipping it. This would have been similar in scope to 7.5 PeopleTools; a follow on release after a major technology shift that served to be a long term stable base, while new development continued on. There was even talk of just calling it PeopleTools 8.2 and making it a mandatory release for customers. While that was going on we began working on the Next Big Thing for PeopleTools 9.

A couple of things conspired against that go around for PeopleTools 9. One was that the name "PeopleSoft 8" had some off the chart brand recognition (at least according to our marketing folks), so there was some senior management push to not lose that name right away.

The other was that customers were still wrestling with a lot of the details of running large scale PeopleSoft 8 deployments and there was quite a bit of pressure to make the follow on release deal with a lot of those issues.

So work on PeopleTools 9 was (mostly) halted to put all hands onto what ended up as PeopleTools 8.4. Why 8.4? Mainly to leave room for a potential 8.8 release. That ended up happening for the applications, along with 8.9 releases. Heck, the CRM group almost did an 8.95 release. Talk about asymptotically approaching 9 :-)

Take Three

I'm not sure which customer managed to finally convince PeopleSoft senior management that doing some releases that were focused on making current stuff work instead of The Next Big Thing, but I remember being in several corporate visits where (due to scheduling issues) I ended up sitting through Craig Conway or Ram Gupta's sessions and get to hear the same earful that they were getting.

It's wasn't unusual to hear from people in charge of actually running PeopleSoft at a customer site about things that we could do to improve operational efficiencies. That's one of the main reasons people used to come to Pleasanton for a corporate visit - to get a chance to talk with product strategy and development about their needs. Historically though you wouldn't see the "C-level" discussions get into this sort of thing though.

So that's what led to Total Ownership Experience (TOE). PeopleTools 8.44 was the big TOE release for PeopleTools. Performance Monitor, Change Assistant, etc were all big features, but not really "sexy". Of course, they took a fair amount of development effort, which meant that there wasn't really enough folks left to work on PeopleTools 9.

This was the go-around where there were actual PeopleTools 9 baseball hats created. I'll have to talk Larry into posting a picture of his. I gave mine to a friend at a PeopleSoft customer in Germany awhile ago.

Take Four

The last stab at doing PeopleTools 9 was in the middle of the Oracle acquisition, so it was a little strange to be doing long term project planning. SAP was scoring sex and sizzle points with their NetWeaver story, which shaped some of the internal scoping debates.

This time around, PeopleTools 9 was not being called 9, but rather "X". No one was ready to venture a guess as to what version number it would finally ship as. Which turned out to be rather smart since it didn't ship :-)

Postscript

As it turns out a lot of the ideas for PeopleTools 9 are things that Oracle had already been working on (or would soon acquire).

One was the whole idea of radically extending/re-writing the component processor to make things that are common customizations today into personalizations. Imagine the tab order personalization feature from PeopleTools 8.44 being extended to moving and hiding fields (while still honoring the business logic of course). Check out some of the ADF Faces work for some ideas on what Fusion applications will be capable of.

Another big feature was the idea of re-usable data objects. Oracle got that with the acquisition of Siebel, who in turn had acquired a company called nQuire. This now has the awkward name of Oracle Business Intelligence Enterprise Edition, but it is some really slick stuff. As Larry mentioned in a previous posting, we had brought nQuire in before Siebel bought them, but we didn't move quick enough (historically PeopleSoft didn't do acquisitions that well).

Applications Unlimited

One of the things that we did right after the acquisition was to survey some PeopleSoft customers about what they wanted to see from Oracle in relationship to PeopleTools. To a customer, every single one said in no uncertain terms that they didn't want to see any major new things from PeopleTools - just focus on quality, performance, operational excellence, integration, etc.

This was prior to the announcement of Applications Unlimited, but the sentiment remains.

As it turns out, folks that are looking for something radically new are starting to adopt Fusion Middleware. Oracle seems to be having a decent uptake of that within PeopleSoft customers.


(1) Funnily enough, the comedian that PeopleSoft hired for the PeopleSoft 8 launch party, Greg Proops, actually did some research before the event and made a comment to the effect of "All of this for going from 7.5 to 8? .5? ". Of course, he actually made it sound funny.

On a sad note, that launch party was held in the summer in 2000 at the Windows on the World restaurant, which was destroyed on September 11, 2001.

Labels: 2007, Fusion, History

The inspiration for this posting came while Chris and I were performing a technology review (actually, when we were at dinner with the customer after a long day). Here we were at one of the oldest restaraunts in the USA (which was actually a pub... quite fitting, we thought, since anybody who really knows us also knows that we really like pubs). Anyway, over a couple of beers the customer wanted to know where trees came from, etc. and was fascinated as I spun my tale.

Believe it or not, I started this post almost 2 months ago. However, I felt it important to check my facts with Dana Quitslund (the mastermind behind nVision). It also gave me a great excuse to pick up the phone and catch up with one of my heros (Dana's probably reading this right now, thinking, "Geez, why did he have to go on and say that?"

A Tree is Born

Okay. So, here is where we answer the question: "Which came first, the Ledger or the Tree". Believe it or not, I've had quite a few arguments with folks on the answer to this, because of how well trees are embedded into several of the PeopleSoft application suites. So... Place your bets... The answer is coming up...

Trees were invented for the initial version of General Ledger primarily to support nVision. The vision behind initial vision for Tree Manager came from the following folks:

• Mike Kaiser. He was the person in charge of creating the initial version of Financials, coming from Walker Interactive, where he was instrumental in the architecture of its GL.
• Dana Quitslund. The first developer that Mike Hired for GL. In addition to writing much of the early COBOL in GL, he also created nVision.
• Dan Bulos (AKA "Dan the tree man"). Brother-in-law of long-time PeopleTools developer Linda T.
• John Malatesta. Head of PeopleTools, and architect behind the toolset used by Dave Dufflield's new company, Workday.

PeopleTools 2

So, now you know the players and the reasons behind its creation. I think it makes sense to go on to discuss some the process that went into its creation. You see, even though tree manager was created to support nVision and the first release of financials, it was developed by the PeopleTools group so that all products could take advantage of it (for those interested in the timeline, this was PeopleTools 2, which was the release that Financials 1 shipped on).

Anyway, when John and Dan picked it up, they had the vision that trees should be applicable to HR as well as GL. As Dana put it, John Malatesta wanted to make sure that the initial version of tree manager didn't make HR look bad from a functionality perspective. What did this mean? It meant that winter tree support was included in the first version of tree manager, so that department hierarchies worked properly in HR.

One other concern they had was about performance, which was why Dana Quitslund came up with the tree numbering scheme that allows a single SQL statement to retrieve all of the descendents of a tree node (something that is relatively unique to tree manager).

Therefore, the tools guys developed tree manager in PeopleTools 2, and Dana and Mike used it to create nVision as part of the Financials application (note that in PeopleTools 3, query support was added to nVision, and nVision because a PeopleTool in its own right).

One other interesting note is that the tree selector funcitonality referenced in this blog entry came out of two of the first customers using trees and nVision (actually, I think they were the first because Dana spent a lot of time ironing out the last details of the product). These customers were DB2 shops, which had a quirk in optimizer that affected this design.

After putting together the proof of concept at Andersen Consulting for adding encumberance accounting to GL to create a public sector version of financials, my first involvement in trees and nVision was at one of these initial customers in New York (yes, this is the closest I can get to being involved in the initial creation of it... of course, that also explains why I'm writing a blog entry on it from my bedroom and not sitting on a beach somewhere sipping margaritas).

PeopleTools 3

Tree manager essentially stayed the same in PeopleTools 3. Because the PeopleTools group was project focused, the developers who worked on tree manager in PeopleTools 2 were working on new initiatives in PeopleTools 3 (not the least of which was creating PS/Query and adding support for Crystal Reports).

PeopleTools 5

Between PeopleTools 3 and PeopleTools 5 the PeopleTools group went through a radical shift (for those wondering, there was no PeopleTools 4, even though there was an HRMS 4). Dave Duffield asked John Malatesta and Ken Morris to come up with a radically new toolset for the next generation of business applications (code-named Sonoma). This meant that they were no longer working on PeopleTools.

In the meantime, Baer Tierkel stepped up to become the VP of PeopleTools development and adopted a product-focused organization (in other words, Developers and Development Managers owned their products from release to release, ensuring that there is a consistent investment and strategy for those product). I personally liked the change, because prior to that point, I found it very difficult to get issues looked into and resolved because somebody had to be pulled off of other work to look into it.

So, here we are in PeopleTools 5. Baer Tierkel is running the tools team. Dana Quitslund has a team of folks dedicated to the reporting tools. For the reporting team, there were a couple of key features in PeopleTools 5:

• Adding branching to trees (which allows multiple people to own parts of the tree and also allows them to work on the different parts at the same time).
• Adding Lotus 1-2-3 support (keep in mind that PeopleTools 5 was in 1994-1995, when Excel still hadn't won the spreadsheet wars... Not supporting Lotus was a big issue for a lot of very large PeopleSoft customers).

From a market perspective, the most important PeopleTools 5 feature in the reporting area was 1-2-3 support (there was revenue recognition issues as well as customer satisfaction issues). This was big, important, stuff to a small software company, like PeopleSoft was at the time. Unfortunately, due to the timing of the release and the feature set available in 1-2-3 at the time, we ended up burning through a lot of development cycles without getting the support for that product stable enough to release. A side effect of that was that the branching functionality was more complex than initially anticipated, and it introduced some issues with trees.

PeopleTools 6

After a gruelling release in PeopleTools 5, Dana decided that he preferred being the "nVision guy" and let somebody else deal with all the other things that are part of managing a portfolio of products through the release cycle. His true love was working with customers and figuring out cool ways to solve business problems and really wanted to get back into that. This was how I had the opportunity of a lifetime (and was chosen to do this by one of my biggest heros).

Anyway, here it is. PeopleTools 6. The development team is still focused on cleaning up many of the issues still lingering from PeopleTools 5. For tree manager, that meant agressively focusing on re-working many of the internals of it. There were way too many circumstances where a customer could corrupt their trees (without a good means of fixing them). Therefore PeopleTools 6 was the clean-up release for it.

PeopleTools 7.

For PeopleSoft, PeopleTools 7 was the 3-tier release (no web client yet, but 3-tier access through an application server). We did a lot of work to ensure that the tree internals would run properly with the new infrastructure changes supporting the app server.

Probably the biggest change with trees was adding the tree performance options to them (initially for nVision performance, but later adopted more widely). This was done in PeopleTools 7 and then later backported to PeopleTools 5 and 6.

PeopleTools 7.5.

In PeopleTools 7.5, we re-worked the user interface to use MFC and right-click menus. As part of this, we also did a lot of internal work that ended up improving the stability of tree manager.

PeopleTools 8.

So. This brings us to late 1998. PeopleTools 8. We started scoping the release to make it a brand-new web-based tool, right? WRONG!

PeopleTools 8.0 was initially the EPM release with a lot of other infrastructure things rolled in. Here is what the my scope list looked like in late 1998:

After completing over 80% of what was listed above, we then realized that we needed to move to the web. This initially meant that there was a browser version of the windows client and not the other client tools, such as tree manager, query, and nVision.

PeopleTools 8.14 and 8.4

It took us a while, but we finally created a web version of tree manager. This was a very large and involved project, because we didn't want to make the same mistakes with moving tree manager to the web as we had with PS/Query. This meant that we had to spend a lot more time prototyping different user interfaces (especially with respect to how to take actions on tree nodes). Because AJAX hadn't been invented yet, we were relatively limited in how we could approach the task. We ended up with the icon representation of actions that one uses today.

In addition to re-working the user experience, we also needed to rework the back-end. You see, the original code was written with the user interface code tied pretty tightly to the backend code. This meant that there weren't good services to use when splitting things up between the UI rendering and the backend processing. Because there were a lot of things people wanted to do with trees outside of merely using the user interface, we made the design decision to build a full set of PeopleCode objects to work with trees and then build the user interface in PeopleTools/PeopleCode using those classes/services. Again, this required a lot of development effort.

The end-result is not just the PIA tree manager, but a whole set of new tools to use and work with trees:

• Tree Manager - UI for maintaining trees.
• Tree Viewer - Read-only UI for seeing what's in a tree.
• Tree Viewer Component - Widget that can be embedded into a page to use a tree to pick a value.
• Tree Mover (aka Tree Import and Tree Export). Tool initially created for EPM to allow migration of trees to the warehouse from a source system.
• Tree Audit/Repair Utility. Tool that checks the health of your trees and fixes some common problems.

Fusion

Charles Phillips and Steve Miranda have stated on numerous occasions that Trees will be brought forward from PeopleSoft to Fusion. Although some of the designs details are still being hammered out, it is our understanding that the tree definition itself will be very similar to what you see today (although they seem to be taking my wish list of changes that I never got to do and incorporating them). If you want to talk about this over a beer, I'd be happy to provide my list and we can see in a few years which ones were adopted.

Grey Sparling Tree Enhancements

Since it's on topic, I thought I'd mention where we are with the product we're working on. We're wrapping up development on it and are in the process of packaging it up (which also means creating trial version of it).

Our good friend, Bert Laws, suggested that we finally solve the problem of exporting trees to BI tools. Much of the code we've written for the tree product we've got can be leveraged for this, so we'll be working on that within the next few weeks. If there's a customer trapped on an old version of Cognos or Essbase with Cube Manager (or if you want to get trees into another BI tool and don't want to buy EPM), contact us at info@greysparling.com

Labels: History, Tree_Manager

One of the things that I've had in my list of things to do for awhile now is to help out someone that I know answer the question of SQR vs Application Engine. They have the challenge of having a staff that doesn't know much about SQR or Application Engine (they are just implementing PeopleSoft now), but they do have consultants available that do know SQR.

So, having set the stage of what we're trying to figure out, we're going to step way, way, way back from current day and look out how PeopleSoft even ended up with SQR and Application Engine. Brace yourself, this isn't going to be a short entry :-)

Going back to the early days of PeopleSoft, there were two main batch tools; COBOL and SQR. Both COBOL and SQR had the benefits of working well across the different platforms that PeopleSoft supported. COBOL also had the benefit of being something that most PeopleSoft developers understood; most of them having come from old mainframe players like M&D and Walker. SQR brought a simple, yet powerful, idea to the table: let people write conditional logic as well as output data as part of a SQL statement. Today that's not so strange, but back in the late 80's/early 90's, having your printing logic so tightly integrated (some might say "tied") to your SQL was powerful stuff.

The big unspoken question of course is why didn't PeopleSoft create some sort of batch/reporting tool as part of PeopleTools? The short answer is that, in the beginning, everyone was too busy just making PeopleTools work for online transactions to even think about some sort of batch/reporting tool.

PeopleSoft did add PS/Query and PS/nVision in the PeopleTools 2-3 timeframe, but they were only reporting tools. Batch was not even considered for a higher level development tool at that point (although PeopleTools 3 also marked the delivery of the PeopleTools Process Scheduler). The only thing that PeopleTools provided was the concept of meta-SQL, which helped smooth over some of the differences between database platforms.

As time went on, it wasn't even the PeopleTools team that came up with a good higher level batch development tool. It was a lone coder on the PeopleSoft AR team, Owen O'Neill, who got sick of writing COBOL batch programs and decided to write a higher level tool for developing batch programs. He called it Application Engine, and used PeopleTools for building the frontend, and (of all things) COBOL for the backend.

Application Engine was different than regular batch programs because it wasn't procedural. It focused on set-based SQL logic and it had a much deeper understanding of the underlying application definitions that it was working worth. Describing set-based logic is beyond the scope of this blog post, but suffice to say that set-based logic is more in line with how SQL is supposed to work, but it's not as familiar to developers that have only worked with procedural logic.

To make an already long story short, Application Engine slowly won converts within PeopleSoft, and by the time that PeopleSoft 8 was being developed, Application Engine was adopted by the PeopleTools team. The frontend was converted to being a regular PeopleTool as part of Application Designer, and the backend was re-written in C++ and given the ability to run PeopleCode as well as SQL logic.

Although it took more than a decade for Application Engine to get developed and finally moved into PeopleTools, SQR and COBOL didn't really change that much during that time. PeopleSoft bought the source code for SQR, but that was really just to make our own lives easier for shipping new PeopleSoft versions - it was never made a full part of PeopleTools.

COBOL was even worse since PeopleSoft never actually controlled the COBOL compilers in use. There were some real big headaches that happened because of that - catch me at a conference sometime and I'll tell you some stories that will make you laugh (or cry) about some of our dealings with the various vendors of COBOL compilers that we had to deal with. As for the COBOL language, well, it's COBOL. Nuf said.

Ultimately though, you could dig up an early PeopleSoft developer and they would still feel right at home with the versions of COBOL and SQR that are still in use with PeopleSoft today. On the other hand, Application Engine kept getting new features, both for development and runtime use, and there were big plans for adding something known as PeopleCode Print to App Engine for PeopleTools 9. That probably would have been the end for formal support for SQR within PeopleSoft.

An interesting thing happened on the way to PeopleTools 9 though. Although, it was scoped on 3 separate occasions, for one reason or another, PeopleTools 9 never saw the light of day (other than a few PeopleTools 9 baseball hats that are collector's items now*). But there are a number of PeopleTools developers that are working on the Fusion project, and I expect that you'll see something very similar to Application Engine in Fusion.

Why would Application Engine show up as part of Oracle Fusion? There's a couple of reasons. One is that Oracle really doesn't have a good tool for batch development. If you look at existing Oracle Applications, you'll notice that batch is done by writing raw PL/SQL or Pro*C code. Not the most straightforward thing for a typical application developer to do. The other thing about Application Engine that fits well within Oracle is that it is a set-based tool. Most of the processing is pushed to the database, and that plays well to Oracle's strengths. Oracle themselves list using Application Engine for batch as number 4 in their top 10 things for PeopleSoft Enterprise customers to do today to get ready for Fusion.

Coming back around to the original question of whether it makes sense to train people in SQR or Application Engine for current PeopleSoft customers, the answer is that both have pros and cons. For starters, there aren't many PeopleSoft applications that don't use both SQR and AppEngine, so you need to have some level of skills in both. I think that CRM is the exception here; I know that CRM has no COBOL, and I think that is true for SQR as well.

SQR also has the advantage of being a little bit more independent of the applications. For example, when you want to write an SQR, all you need is a text editor instead of a proprietary tool like Application Designer. You can also run SQRs in any database, not just a PeopleSoft database. Of course, doing so requires that you go license SQR independently of the license that you receive with your PeopleSoft applications, but you could actually do it.

Of course, those pros are also part of the cons of SQR. SQR has zero understanding of the underlying applications that it's working with. Trees, effective dating, setids, row level security, related language records, etc. all have to be coded by hand when you're writing SQR code. Not impossible to do, but it's certainly more costly and error prone to build and maintain it by hand.

Application Engine comes with some cons as well, especially when looking at it from a reporting perspective. Aside from being a very PeopleSoft specific tool, App Engine is lacking any kind of built-in output capability. This was the target of the (never finished) PeopleCode Print project, but there's nothing there today. There have been various efforts to add output (we've done some of this in our products for example), but generally all you can count on App Engine for is data gathering and not any sort of output management.

Of course, Oracle has a great tool called BI Publisher (previously known as XML Publisher) that handles the data formatting and output side very well, and has recently been integrated with PS/Query and PeopleCode (which makes it accessible from App Engine). It's not a big stretch to see how App Engine could be enhanced to use BI Publisher natively as an output tool and effectively get rid of the need to use SQR at all.

Given that SQR is unlikely to get any further investment from Oracle, and Application Engine is, I would recommend that PeopleSoft customers ensure that they have SQR skills available to them (either from internal resources or from consulting augmentation as necessary), but limit their investment in new SQR development.

Of course, I would combine that with a bit of pushing Oracle to finish connecting the dots with the tools at their disposal for having a good batch/reporting story for Fusion applications :-)

Update 3-Mar-2007: A post by Mark Rittman about the Hyperion acquisition just reminded me that SQR, which was owned by Brio, who got acquired by Hyperion, is now owned by Oracle :-)






*) if you're a really weird collector.

Labels: 2007, AppEngine, History, SQR