Taking the Profile 7.x Plunge? What You Need to Know Before You Jump!
Mozaic Group Partners has helped institutions around the globe with their Profile upgrades going back to early 5.x versions, so it comes as no surprise that we are frequently asked by Profile client institutions, “Should I upgrade?”
The risk involved with a software version upgrade of any sort evokes fear and loathing among the best IT and operations people. Many things have to go right with an upgrade for it to be successful, but it only takes a few things to go wrong to make it a costly failure and expensive cleanup. Profile institutions are not immune. In fact, given the level of complex customization in practically every Profile implementation, the risk is inherently high.
The best answer depends heavily on information gleaned from an honest assessment of three items: the amount of Profile customization, the quality of pre-upgrade research and preparation work and the knowledge, expertise and capabilities of staff. Before jumping into the deep end of the Profile 7.x upgrade pool, an upgrade audit should be conducted. Unlike a game of horseshoes where “close” is a measure of success, close in a Profile upgrade means failure. A properly conducted upgrade audit requires quality research, good analysis and tough evaluation—not simple tasks for certain, but efforts that will prevent you from drowning in the murky and sometimes perilous waters of a Profile upgrade.
What’s in the Release? Quantify to Justify
Are there items in the new Profile version that fills a business need or solves an operational issue? How critical are the new items to the success of your operations? What is the overlap between your customization and the version upgrade? What is the impact—positive and negative—to your operating environment? For starters, you need to look beyond the vendor’s release notes. An upgrade audit uncovers the details and provides a map to evaluate the new version against your current system. Gaps, conflicts and solutions are revealed under your light and not the vendor’s. The impact of each “discovery” must be weighed against the institution’s operations and business goals. The result of the process provides an institution with vetted information and clear options, which eliminates costly guesswork and stands as a bulwark against unsubstantiated claims and other bias.
Cautionary note: a perfunctory audit rarely suffices. The task requires serious investigation, analysis and evaluation. You’ve heard the axiom, “Garbage in, garbage out.” It most assuredly applies to Profile upgrade audits.
I’m Upgrading Because the Vendor Says I Should
Upgrading to the latest, greatest Profile version does set you on a path that is easier for the vendor to support—at least from a core system perspective. But that doesn’t mean it’s the best path for your institution to take at this moment or in relationship to your operating requirements, budget and business goals. To the contrary, your audit might reveal the opposite. With little question, there are very good reasons to upgrade if you’re still operating on a 5.x version of Profile. However, an upgrade audit will provide you with the information you need to make the best decision. In our experience, upgrade ignorance increases risk and manifests itself in errors that are costly to correct after the fact. Complete an upgrade audit and you’ll have the information you need to make intelligent choices.
Option: The Retro Upgrade
Every institution running Profile in-house customizes the application. After more than three decades, customization remains the product’s single greatest strength and most attractive attribute, but also its curse. Even with best precautions, Profile core version upgrades can be problematic for an institution’s custom code, procedural processes and operating environment. So, are you damned if you do and damned if you don’t? No.
Armed with good comparative intelligence from an upgrade audit, some Profile institutions choose to reverse engineer the process and retrofit select portions of Profile 7.x back into their existing version. The main reasons for doing a retro upgrade generally fall into three buckets—reduced risk, less cost and greater success. Because Profile clients operate in highly customized environments, removing items you’ve identified in 7.x as high risk, or solving for them ahead of the retro upgrade, increases the probability for success. Retro upgrades also significantly reduce the threat of incurring budget-blowing, “fix it” costs when upgrades fail.
The Devil is in the Details
As any Profile IT and operations person knows, a version upgrade is about more than functions and features. Upgrades have a devilish way of crushing performance in customized Profile systems and playing havoc with items such as reporting. Performed properly, an upgrade audit will unveil performance threats, show conflicts and also spotlight areas where the upgrade enhances your operation.
Let’s take a look at several specific things you need to know about upgrading to Profile 7.x.
The Conundrum of Custom Code (M and PSL)
How much custom M and custom PSL (Profile Scripting Language) procedural code do you have operating in your current version of Profile? The larger amount of custom code, the greater the effort it will take to upgrade that code, which increases the risk posed to the overall success of the upgrade. It is not uncommon for Profile version upgrades to contain similar, if not the same functionality in its new “core” version for items you operate with custom code. In those cases, audit results will show whether or not you should replace your custom code with the vendor’s new core code. Upgrading to the vendor’s core code removes your responsibility and the cost for maintaining and supporting what was once custom functionality and places it on the vendor.
Additionally, an audit provides you with an opportunity to reduce custom clutter by removing items that are no longer used or have been made irrelevant by the version upgrade. A properly executed upgrade audit will reveal the customization you need to keep and what you can trash.
Complicating the code conundrum is a cultural clash that exists inside Profile client institutions between those who develop in M code versus those who use PSL. In our opinion, the release of 7.x not only reaffirms, but also emphasizes the vendor’s commitment to PSL going forward. As a result, upgrades will become more challenging for those institutions that do not become fully trained and mentored in how to write and optimize PSL. Given our experience with 7.x upgrades, we believe there is a pronounced need for Profile institutions to invest and improve their PSL capabilities.
The Rub of Reports
Reports created in Profile versions 6.x and earlier must be manually converted during an upgrade to a 7.x version. The underlying data structures in earlier versions of Profile are much different than those used in 7.x versions. As a result, there is no automated conversion process for reports. Manual conversions add cost and time. An upgrade audit should include a full report list. A review of that list will allow you to remove unwanted, antiquated or extraneous reports.
Data’s New Mandate
Have an alpha in that numeric field? In Profile 7.x, that will generate an error. The data cops got serious about having clean data in the latest Profile versions. If the data type is numeric and you have text characters or symbols in that column, Profile’s filers will throw that out as an error. The same will happen with field lengths and required fields. A Profile integrity check will show areas of non-compliance, but the burden to correct the errors falls on the institution. Earlier versions of Profile did not flag such items during an integrity check. A stringent, surgical scrub of data is now required before upgrading.
After the analysis is conducted on the upgrade audit, institutions will need to ensure that every custom table is mapped to Data Qwik. Earlier versions of Profile (6.x and earlier) supported M code where a developer could simply specify a global, a node and a piece. Today, you are required to have a table or file definition associated with every global. In essence, the old M code maps, which relied on global references, are no longer supported by PSL. Upgrade errors occur when the contents of a custom global cannot be deciphered or read properly because the global is not mapped to Data Qwik. While M development is less pronounced in later 6.x Profile versions, during upgrade efforts, we continue to find globals not mapped to Data Qwik.
Profile’s Brave New World of Transaction Processing
Perhaps the biggest change in 7.x versions of Profile is the transaction processing metaphor. In pre-7.x versions, record locking was used in transaction processing to maintain serialization, which prevents two or more processes from simultaneously updating the same record and corrupting account integrity. In Profile 7.x releases, record locks, or M locks as they are more commonly referenced, are no longer used. In place of record locking, Profile 7.x uses a transaction processing mechanism where transaction start and commit commands are wrapped around a transaction set. If one process attempts to read or write data to a data block that has already been updated, then one of the processes will be put in a wait stage and will restart after the other completes.
This change becomes an upgrade issue because the old and the new methods of transaction processing are not interchangeable. Custom Profile processes that use pre-7.x record locking cannot be migrated during an upgrade, which means older, custom transaction posting programs must be re-engineered to work in the 7.x environment. An upgrade audit highlights the affected custom programs, but a pre-upgrade engineering effort will be required to remove the old record locking and replace it with the new processing metaphor. Profile clients should note that such an undertaking usually requires the expertise and experience established in senior Profile developers.
Visibility of TTX Objects – Now You See Them, Now You Don’t
In pre-7.x Profile institutions, it was common for transaction processing programs to provide a view of transactions on a screen that included associated transactions. For example, in pre-7.x versions of Profile, transactions were presented to the posting driver as a set of credit and debit transactions. The scope of information (TTX objects) was visible for the entire transaction set. In Profile 7.x, only the specific transaction object being processed is visible to the associated posting program. This creates issues for custom programs that have been developed to update one or more related TTX objects in the transaction set. Ultimately, this issue manifests as an ugly business problem when customers and bank staff need to view information generated by one transaction in a related transaction record in history. In an age where dissatisfied customers do not hesitate to attack institutional shortcomings in social media for all to see, the visibility of TTX objects is an issue that requires attention.
For institutions that want and need this feature, it can be re-implemented, but changes must be made to the core 7.x version of Profile to make it happen. Mozaic Group Partners has done this work for clients, but this is information that should be noted and evaluated as part of the upgrade audit. Mozaic Group Partners has helped Profile clients re-engineer their custom posting programs to work within the core Profile transaction processing metaphor.
Know the Capabilities & Limitations of Automated Tools
As we described throughout this article, the bane of all Profile version upgrade projects is converting custom programming. To help upgrade custom code, there has been at least one tool developed that reads custom procedural code and attempts to convert it to PSL code that works in Profile version 7.5.
Please note that it is our experience that no tool offers a panacea for upgrading custom code. We think Profile clients need to learn and understand the capabilities and limits of any upgrade tool that might be proffered and adjust their expectations and efforts accordingly.
For example, the most-often used tool has a design flaw that limits its usefulness. When the tool fails to upgrade a line of code, the tool does not always provide sufficient informational help or direction as to why the failure occurred. When the tool fails to convert code, a flag alerts people that manual intervention is required, but the tool’s role ends there.
An unintended, but performance injuring consequence of the same tool is its propensity to add overhead to converted code. This happens particularly when the tool struggles to convert a client’s complex, custom procedural code. The resulting new code adds overhead and can disrupt or degrade performance in a module where no issue previously existed. When this occurs, manual research and development intervention is required, which can be costly. In one particular instance, a client’s expectations were not met after the tool failed multiple times during almost a year’s worth of effort. The institution engaged Mozaic Group Partners to “re-do” the upgrade and remedy the performance issues. While the tool can provide rudimentary help, our experience is such that the tool is neither efficient nor proficient enough to satisfy most clients’ upgrade expectations.
Where Did My Green Screens Go?
In some form or fashion, many client Profile developers depend on the use of green screen technology for custom development efforts. In Profile version 7.5, developers must use Workbench to develop their schema (file definitions). They can no longer create and maintain their schema through the use of “green screens” because the Profile driver interface has been removed in version 7.5. We believe Workbench is a great tool, but clients need to be aware of this change, and it should be evaluated as part of their upgrade audit.
The Mandate for Comparative Version Testing
After helping dozens of Profile institutions with conversion upgrades, we’ve found that comparative version testing (version vs. version) is one the best tactics you can use to prevent upgrade chaos. We don’t mean testing as it pertains to an end user, but rather testing to ensure that processes work properly between the versions. For example, during one of our recent client upgrade engagements, comparative testing uncovered defects with computed data items—in both versions! Had we not used comparative testing, significant customer account issues would have resulted from the undiscovered and uncorrected defects.
So, Am I Ready for Upgrade Success?
If you complete an honest audit, analysis and evaluation of your institution’s Profile operation side-by-side with Profile version 7.x, you will have created a path to success. Our advice? Upgrades are like water. No matter how shallow the pool or deep the ocean, a plunge can be dangerous if you do not fully understand the conditions, take the necessary precautions and know how to get help should you need it.
If you found this article helpful, please share it with someone that could also benefit from its content.