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?"
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:
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).
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).
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:
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.
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.
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.
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.
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:
Add a new ETL tool to PeopleTools
Tree Manager and Query
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.
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:
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.
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).