Your address will show here +12 34 56 78
2021 Blog, Blog, Feature Blog, Featured

Many AWS customers either integrate ServiceNow into their existing AWS services or set up both ServiceNow and AWS services for simultaneous use. Customers need a near real-time view of their infrastructure and applications spread across their distributed accounts.

Commonly referred to as the “Dynamic Application Configuration Management Database (CMDB) or Dynamic Assets” view, it allows customers to gain integrated visibility into their infrastructures to break down silos and facilitate better decision making. From an end-user perspective as well, there is a need for an “Application Centric” view rather than an “Infrastructure/Assets” view as better visibility ultimately enhances their experience.

An “Application Centric” View provides the following insights.

  • Application master for the enterprise
  • Application linked infrastructure currently deployed and in use
  • Cost allocation at application levels (useful for chargebacks)
  • Current health, issues, and vulnerability with application context for better management
  • Better aligned with existing enterprise context of business units, projects, costs codes for budget planning and tracking

Use Case benefits for ServiceNow customers
Near real-time view of AWS applications & Infrastructure workloads across multiple AWS accounts in ServiceNow. Customer is enabling self-service for their Managed Service Provider (MSP) and their Developers to:

  • Maintain established ITSM policies & processes
  • Enforce Consistency
  • Ensure Compliance
  • Ensure Security
  • Eliminate IAM access to underlying services

Use Case benefits for AWS customers
Enabling application self-service for general & technical Users. The customer would like service owners (e.g. HR, Finance, Security & Facilities) to view AWS infrastructure-enabled applications via self-service while ensuring:

  • Compliance
  • Security
  • Reduce application onboarding time
  • Optical consistency across all businesses

RLCatalyst SmartView Solution – Built on AppRegistry
Working closely with AWS partnership groups in addressing the key needs of customers, RLCatalyst SmartView Solution provides a “Dynamic CMDB” solution that is Application Centric with the following highlights:

  • Built on “AWS AppRegistry” and tightly integrated with AWS products
  • Combines information from the following Data Sources:
    • AWS AppRegistry
    • AWS Accounts
      • Design time Data (Definitions – Resources, Templates, Costs, Health, etc.)
      • Run time Data (Dynamic Information – Resources, Templates, Costs, Health, etc.)
    • SmartView Additional Functionality
      • Service Registry Insights
      • Aggregated Data (Lake) with Dynamic CMDB/Asset View
      • UI Interaction Engine with appropriate backend logic

A well-defined Dynamic Application CMDB is mandatory in cloud infrastructure to track assets effectively and serves as the basis for effective Governance360.

To learn more about RLCatalyst SmartView Solution Build on AWS AppRegistry click here.

AWS recently released a new feature called AppRegistry to help customers natively build an AWS resources inventory that has insights into uses across applications. AWS Service Catalog AppRegistry allows creating a repository of your applications and associated resources. Customers can define and manage their application metadata. This allows understanding the context of their applications and resources across their environments. These capabilities enable enterprise stakeholders to obtain the information they require for informed strategic and tactical decisions about cloud resources. Using AppRegisty as a base product, we have created a Dynamic Application CMDB solution SmartView to benefit AWS and ServiceNow customers as explained in the figure below.

Modeling a common customer use case
Most customers have multiple applications deployed in different regions constituting sub-applications, underlying web services, and related infrastructure as explained in the figure below. The dynamic nature of cloud assets and automated provisioning with Infrastructure as a Code makes the discovery process and keeping CMDB up to date a non-trivial problem.

As explained above, a typical customer setup would consist of different business units deploying applications in different market regions across a complex and hybrid infrastructure. Most existing CMDB applications provide a static assets view that is incomplete and not well aligned to growing needs for real-time application-centric analysis, costs allocation, and application health insights. This problem has been solved by the SmartView solution leveraging existing investments of customers on ITSM licenses of ServiceNow and pre-existing solutions from AWS like ServiceManagement connector that are available for no additional costs. The missing piece till recently was an Application-centric meta data linking applications to infrastructure templates.

Customers need to be able to see the information across their AWS accounts with details of Application, Infrastructure, and Costs in a simple and elegant manner, as shown below. The basic KPIs tracked in the dashboard are following:

  • Dashboard per AWS Account provided (later aggregated information across accounts to be also added)
  • Ability to track an Application View with Active Application Instances, AWS Active Resources and Associated Costs
  • Trend Charts for Application, Infrastructure and Cost Details
  • Drill-down ability to view all applications and associated active instances what are updated dynamically using a period sync option or on-demand use based

The ability to get a Dynamic Application CMDB is possible by leveraging the AWS Well Architected best practices of “Infrastructure as a Code” relying on AWS Service Catalog, AWS Service Management Connector, AWS CloudFormation Templates, AWS Costs & Budgets, AWS AppRegistry. The application is built as a scoped application inside ServiceNow and leverages the standard ITSM licenses making it easy for customers to adopt and share this solution to business users without the need for having AWS Console access.

Workflow steps for adoption of RLCatalyst SmartView are explained below. The solution provided is based on standard AWS and ServiceNow products commonly use in enterprises and build on existing best practices, processes and collaboration models.

Step-1 Define AppRegistry Data Use AppRegistry
Step-2 Link App to Infra Templates – CloudFormation Template (CFT) / Service Catalog (SC) AWS Accounts Asset Definitions
Step-3 Ensure all Assets Provisioned have App and Service Tagging (Enforce with Guard Rails) AWS Accounts Asset Runtime Data
Step-4 Register Application Services – Service Registry Service Registry
Step-5 SmartView Data Lake refresh with static and dynamic Updates (Aggregated across accounts) RLCatalyst SmartView
Step-6 Asset, Cost, Health Dashboard RLCatalyst SmartView

A typical implementation of RLCatalyst SmartView can be rolled out for a new customer in 4-6 weeks and can provide significant business benefits for multiple groups enabling better Operations support, Self-service requests, application specific diagnostics, asset usage and cost management. The base solution is built on a flexible architecture allowing for more advanced customization to extend with real time health and vulnerability mappings and achieve AIOps maturity. In future there are plans to extend the Application Centric views to cover more granular “Services” tracking for support of Microservice architectures, container based deployments and integration with other PAAS/SAAS based Service integrations.

Cloud-based dynamic assets create great flexibility but add complexity for near real-time asset and CMDB tracking. While existing solutions using Discovery tools and Service Management connectors provided a partial solution to an Infrastructure centric view of CMDB, a robust Application Centric Dynamic CMDB was a missing solution that is now addressed with RLCatalyst SmartView built on AppRegistry as explained in the above blog.

For more information, feel free to contact

Governance360 – Are you using your AWS Cloud “The Right Way”
ServiceNow CMDB
Increase application visibility and governance using AWS Service Catalog AppRegistry
AWS Security Governance for Enterprises “The Right Way”
Configuration Management in Cloud Environments


2021 Blog, Blog, BOTs Blog, Featured

In large enterprises with complex systems, covering new generation cloud-based platforms while continuing with stable legacy back-end infrastructure usually results in high-friction points at integration layers. These incompatible systems can also slow down enterprise automation efforts to free up humans and have BOTs take over repetitive tasks. Now with RLCatalyst BOTs Server and leveraging common platforms of ServiceNow and UiPath, we provide an intelligent and scalable solution that can also cover legacy infrastructure like AS/400 with terminal interfaces. These applications are commonly found in the supply chain, logistics, warehousing enterprise domains supporting needs for temporary/flexi-staff onboarding & offboarding needs based on the volume of transactions in industries that see spikes in demand across special events powering the need for more automation first solutions.

Integration of a cloud-based ticketing system with a terminal-based system would always require a support engineer, especially with labor-intensive industries. This is true for any legacy system that does not provide an external API for integration. There are diverse issues that occur slowing down business without compromising on security and governance aspects related to such workflows.

With the lack of a stable API system to interface with the AS/400 legacy system, we decided to rely on BOTs simulating the same User behavior as humans dealing with terminal interfaces. RLCatalyst BOTs was extensively used as an IT Automation solutioning platform for ServiceNow, and the same concept was extended to interact with Terminal interfaces commonly used in Robotic Process Automation (RPA) use cases with UiPath. RLCatalyst acts as in “Automation Service Bus” and manages the integration between ServiceNow ITSM platform and UiPath Terminal Interface engine. The solution is extendable and can be used to solve other common problems especially bringing integration between IT and business systems.

Using UiPath to automate processes in legacy systems
Leveraging the capabilities of UiPath to automate terminal-based legacy systems, RLCatalyst interfaces with the service portal to get all the required information to help UiPath’s UiRobot to execute steps defined in the workflow. RLCatalyst’s BOT framework would provide the necessary tools to run/schedule BOT’s with governance, audit trails functionality.

Case Study – Onboarding an AS400 system user
The legacy AS400 system’s user onboarding process used to be multi-staged, with each stage representing a server with its ACL tables. A common profile name would be the link between the servers and, in some cases, independent logins required. A process definition document is the only governing document that helps a CS executive complete the onboarding process.

The design used to automate the process was:

  • Build individual workflows for each stage in the User interaction processes using UiPath.
  • Build an RLCatalyst BOT which:
    • Refers to a template that includes a reference to the stages to run based on the type of user that needs to be onboarded.
    • Based on the template, it would maintain a document of profile names allotted.
    • Validates the profile availability (this helps onboarding outside the automation)
    • Executes the UiPath workflow for each stage in the sequence defined in the template.
    • Once the execution is complete, a summary of the execution with user login details is sent back to the ITSM system.
    • Logs for each stage are maintained for analysis and error corrections.
  • Build the Service Portal approval workflow, which would finally create a task for the automation process for fulfillment.
    • The service portal form captures all the necessary information for onboarding a new user.
    • Based on the account template selected that depicts a work department, a template reference is captured and included in the submitted form.
    • The service portal is used by the SOX compliance team to trace approval and provisioning details.
    • The process trail becomes critical during off-boarding to confirm, access revocation has occurred without delay.

Advantages of Using UI Automation Over Standard API

  • Some of the AS400 servers used for Invoicing/Billing are over 20 years old, and the processes are as old as the servers themselves. The challenge multiplies when the application code is only understood by a small set of IT professionals.
  • UI automation eliminates system testing costs, since it just mimics a user. All user flows would have already been tested.
  • The time taken to build an end-to-end automation would be significantly lesser compared to getting a highly demanding IT professional building the API interface to get it automated.
  • Total automation investment would also significantly be reduced, and ROI’s would be quicker.

Getting Started
Based on our previous experience in integrating and automating processes, our pre-built libraries and BOTs should provide a head start to your automation needs. The framework would ensure that it meets all the necessary security and compliance needs.

For more details, please feel free to reach out to