Do you know Pre-upgrade system cataloging is a very crucial step of Allegro Horizon upgrade?
Let me walk through you what is Pre-upgrade system cataloging is but before starting, We would like to give you a high-level idea about why Allegro Horizon Upgrade.
Why upgrade to Allegro Horizon?
E/CTRM markets experience a myriad of changes every day. Successful organizations need more from their E/CTRM management systems like deeper trading insights, more critical, risk management, improved logistics, and compliance, as well as support for new deployment and cloud technologies. Allegro Horizon is built to meet these needs, and it’s built for the cloud. Horizon is the next generation of Allegro, taking full advantage of native cloud capabilities that increase performance, improve agility and allow you to do more with less. Being built for the cloud means you see value in weeks, a significant reduction in your capital expenditures, and an increased focus on your core business, not the care and feeding of a CTRM system.
What is Pre-upgrade cataloging and Why do we need it?
Allegro Horizon is the next generation software of Allegro, and due to that Allegro made a lot of changes to their core schemas, metadata & API. Those changes are unpredictable and will impact a lot on existing custom functionalities during the Allegro Horizon upgrade process. Pre-upgrade cataloging plays a very crucial role in the Allegro Horizon upgrade process as it provides the current landscape of existing systems to stakeholders and helps them to make decisions about how to properly plan, and execute an upgrade project without engaging substantial testing efforts.
Who will do the Pre upgrade cataloging?
It will be a team of Allegro Infrastructure SME, Allegro Technical SME, and Allegro Functional SME.
Role of Allegro Infrastructure SME:
Infrastructure SME will review existing System IT policies, Firewall configurations, Port Configurations, User Access Group Policy, Backup, and Recovery Settings, Fail-over settings, Allegro Application configurations & Settings, Allegro Database configurations & Settings, Allegro Interface configurations & settings and will generate a detailed report which provides the current landscape of existing system and suggest the new required changes (if any) for Horizon.
Role of Allegro Technical & Functional SME:
Technical SME will review each individual object of Allegro application i.e. Class, Class Methods, Class Events, Database Views, Database Functions, Message Events, Stored Procedures, SQL Server Reporting Services (SSRS), or Crystal Reports along with the help of Functional SME and categorize them on the basis of below columns in the individual excel sheet:
Existing State Purpose: This is used to categorize existing Allegro objects according to their current usage/purpose. Below are the possible categories:
- Integration: It defines whether the existing Allegro object belongs to Interfaces or any third-party integration.
- Functional Gap: It defines whether the existing Allegro object was created due to any functionality missing in the Allegro which is needed by businesses.
- Process Efficiency: It defines whether the existing Allegro objects were created due to improvement in the existing functionality.
Check if the Business requirement is Still Valid: is used to categorize whether the created object is still in use by the business, if not we can exclude them for the upgrade Process.
Functionality Available in Horizon?: is used to categorize whether the existing Allegro custom object is already available in the Horizon version, If Yes we can exclude them for the upgrade Process.
Future State Priority: This is used to categorize whether the existing Allegro object will be needed in the future by the business, if not we can exclude them for the upgrade Process.
Functional Area Group: This is used to define who is the functional owner of an existing Allegro object. Below are the possible groups
- Allegro: It defines the custom code or patches which are provided by Team allegro to fix their Core application issues.
- Back Office: It defines whether the existing custom Allegro object functionality belongs to the Back office.
- Front Office: It defines whether the existing custom Allegro object functionality belongs to the Front office.
- Middle Office: It defines whether the existing custom Allegro object functionality belongs to the Middle office.
- IT Administration: It defines whether the existing custom Allegro object functionality belongs to IT or Administration.
- Interface: It defines whether the existing custom Allegro object functionality belongs to Interface or third-party integration.
Functional Area: This is used to define that the custom Allegro object belongs to which area of the application. Below are the possible area
- Market & Price
- Trade Capture
- Settlement
- Position & Risk
- Scheduling
- Logistics
- Valuation
- Credit
- Configuration
Complexity: is used to define the complexity of existing custom Allegro objects. The complexity is further divided into 4 categories based on the estimated level of effort required to fix the Allegro objects, Below are the possible complexities:
- Low: complexity means the required extension needs 1 day of effort to fix.
- Medium: complexity means the required extension needs 2-5 days of effort to fix.
- Moderate: complexity means the required extension needs 6-14 days of effort to fix.
- High: complexity means the required extension needs 15-30 days of effort to fix.
Reference & Credit : https://www.allegrodev.com/
