Client overview
Our client is a large commercial bank in Vietnam operating a complex hybrid IT environment. Their infrastructure spans on-premise data centers, private cloud systems, and public cloud platforms, including GCP, Azure, and AWS. The bank relies on OpenText™ Universal Discovery and CMDB as a central system to track IT assets, configurations, and dependencies.
Despite having UCMDB in place, the bank faced several issues:
– Incomplete discovery, leading to missing or outdated asset information
– Duplicate and inconsistent configuration items (CIs), reducing trust in CMDB data
– Low application performance, affecting reporting and daily operations
– An ineffective application operations team, struggling to handle incidents, tuning, and improvements
These issues impacted compliance reporting, incident analysis, and overall IT service reliability. The bank needed a focused AMS partner to take ownership of UCMDB operations and continuously improve system quality.
What the client needs
The client required structured 1st-line and 2nd-line Application Management Services for OpenText™ UCMDB.
1st-Line Support
– Monitor UCMDB services, probes, and discovery jobs
– Check system performance, backups, and integrations
– Restart failed components and handle routine operational tasks
– Escalate technical issues to 2nd-line support
2nd-Line Support
– Maintain discovery configurations and credentials
– Fix discovery errors and data inconsistencies
– Optimize performance and system integrations
– Apply patches, upgrades, and automation improvements
How we did it
To meet these needs, we followed a structured five-step AMS delivery process.
1. Discover the client’s needs
– Assessed the existing UCMDB environment and operational challenges.
– Reviewed the UCMDB architecture, deployment model, and integrations
– Analyzed discovery coverage, data quality issues, and performance bottlenecks
– Assessed operational workflows and incident handling processes
– Defined clear responsibilities for 1st-line and 2nd-line support
2. Transfer the knowledge
LTS GDS focused on a structured knowledge transfer:
– Collected and reviewed documentation, configurations, and discovery patterns
– Studied existing probes, jobs, credentials, and integrations
– Understood dependencies across Windows Server, RHEL, databases, LDAP, and cloud platforms
– Prepared internal tools and access, including Jira and remote administration methods
– Ran trial operations to validate monitoring, ticket handling, and escalation flows
3. Operate the system
After onboarding, a dedicated 2-member AMS team took over day-to-day operations.
– Monitored UCMDB services, probes, and discovery jobs
– Checked system performance, backups, and integration health
– Restarted failed components and resolved routine issues
– Handled incidents and requests through Jira
– Escalated complex issues from 1st line to 2nd line when needed
For 2nd-line support, the team:
– Maintained discovery configurations and credentials
– Fixed data inconsistencies and discovery failures
– Tuned performance and optimized integrations
– Applied patches, upgrades, and automation improvements
4. Maintain and update
To ensure long-term stability, we focused on maintenance and continuous improvement. LTS GDS followes these steps:
– Updated internal runbooks and operational guidelines
– Consolidated configuration data and procedures into centralized repositories
– Reviewed discovery patterns and CI models regularly to ensure accuracy
5. Report and improve
– Provided regular service and SLA reports
– Reviewed ticket trends, discovery coverage, and data quality metrics
– Discussed performance issues and improvement opportunities with stakeholders
What the results have
The project is still progressing. Some accomplishments of the project:
– 2 dedicated AMS engineers supporting UCMDB operations
– Average 37 tickets handled per month
– Asset coverage increased from 75% to 92%
– Configuration item (CI) consistency improved by 30%
– CPU and memory utilization reduced by 15%
– 12% faster resolution time for OpenText-related tickets
– Consistent SLA compliance, with response times maintained at:
- Critical: ≤ 30 minutes
- High: ≤ 1 hour
- Medium: ≤ 2 hours
- Low: ≤ 4 hours
