Compiled, Containerized, and Shipped by Bob Richardson & Kelly Nimmo
Welcome to the first entry in our series on administering IBM Maximo Application Suite (MAS) 9 on OpenShift. If you’re coming from Maximo 7.6 or earlier versions running on WebSphere Application Server, congratulations you are about to experience quite an adventure. Think of it as moving from a comfortable (if slightly dated) ranch house to a sleek smart home. Sure, you might spend the first week trying to figure out where the light switches are, but once you get the hang of it, you’ll wonder how you ever lived without voice-activated everything.
In your Maximo 7.6 days, life was all about monolithic deployments, WAR files, JVM configurations, and the occasional late-night wrestling match with manual clustering on WebSphere. MAS 9, built on Red Hat OpenShift Container Platform (OCP), is a whole different animal with Kubernetes-based orchestration and operators that do a lot of the work for you along with a suite of integrated applications that play nicely together. This post will give you the jet-aircraft view of MAS 9 architecture, with enough references to your WebSphere experience that you won’t feel totally lost. We will cover key components, deployment models, and why this modern setup might actually make your job easier! Future posts will get into the nitty-gritty details like installation and user management.
By the end of this, you’ll understand how MAS 9’s architecture promotes scalability, resilience, and efficiency which, historically, qualities that were often more “aspirational” than “actual” in traditional setups. Let’s dive in, shall we?
Understanding the Core Shift: From Monolithic to Containerized
In Maximo 7.6, your environment typically looked like something like this: a single or clustered WebSphere server hosting the Maximo application, connected to a database (Oracle or Microsoft SQL Server, depending on which vendor you lost the coin flip to), with configurations managed through the WebSphere Admin Console or properties files. Upgrades meant applying fix packs and crossing your fingers. Scaling required manually adding nodes and explaining to management why you needed more hardware.
MAS 9? It’s not just an upgrade version, it is a completely new re-architecture into a modular suite running on OpenShift, which is basically Kubernetes with enterprise enhancements from Red Hat. OpenShift handles container orchestration, which means your MAS instance runs as pods which can be thought of as lightweight, isolated containers rather than those bloated JVMs you used to babysit. Automation comes via operators, which are like really smart robots that manage application lifecycles. It is similar to how WebSphere managed deployments, but with the key difference being that it mostly just works.
Key Differences
Deployment Model
- WebSphere used EAR/WAR files deployed to servers.
- MAS uses YAML manifests and operators to deploy pods dynamically.
You will need to learn YAML, but it is less painful than XML, so there is that.
Scaling
- Manual in WebSphere (add servers, tune heaps, sacrifice chickens).
- Automatic in OpenShift via horizontal pod autoscaling. The chickens can actually retire to that big farm you tell your kids about.
High Availability
- WebSphere relied on clustering and load balancers.
- OpenShift provides built-in redundancy with replicas, self-healing pods, and multi-zone support. It is like having a team of tiny repair robots.
Management
- WebSphere Admin Console for configs.
- OpenShift Console plus MAS Suite Administration UI for holistic oversight. Multiple dashboards might seem redundant until you realize they each have their own superpowers.
This containerized approach allows MAS 9 to run anywhere OpenShift does: on-premises, hybrid cloud, or public clouds like AWS, Azure, or IBM Cloud. It is the kind of portability that WebSphere environments could only dream about while being locked to specific hardware configurations.
High-Level Architecture of MAS 9 on OpenShift
MAS 9 is an integrated platform comprising a core foundation and specialized applications for asset management. It leverages OpenShift’s cluster architecture, which includes:
Control Plane (Master Nodes): Manages the cluster, scheduling pods, and enforcing policies. Think of this as the “brain”, similar to WebSphere’s Deployment Manager in a cell configuration, but less prone to existential crises.
Worker Nodes: Where your MAS applications actually run as pods. These are VMs or bare metal boxes, provisioned via IaaS providers (VMware, AWS EC2) or managed services (Azure Red Hat OpenShift). This is where the magic happens, or where things break, depends on your day.
Storage: Persistent volumes (PVs) for data durability, using providers like OpenShift Data Foundation (ODF), Azure Files, or IBM Storage Fusion. This replaces those file system shares you had in WebSphere setups, but with better reliability and fewer “disk full” panic attacks.
Networking and Load Balancing: OpenShift Routes expose services externally, similar to WebSphere’s HTTP servers but more automated.
Identity and Security: Integrates with LDAP or SAML, much like WebSphere, but with pod-level security contexts. Security is still a problem, but at least the tools are better.
At the heart of everything is the MAS Core, a control plane installed first via the MAS Operator. It manages user registries, licensing, and shared services. On top of this foundation, you can install applications like:
- Maximo Manage: The core EAM app, evolved from Maximo 7.6
- Maximo Health: Asset health scoring using IoT data
- Maximo Predict: AI-driven failure predictions
- Maximo Monitor: Remote asset monitoring
- Maximo Visual Inspection: Computer vision for defect detection
- Maximo Assist: AI-assisted troubleshooting
These apps share foundational services from IBM Cloud Pak for Data (CP4D), including Db2 Warehouse, Watson Discovery, and Kafka for event streaming all installed within the same OpenShift namespace or cluster. It is like a well-organized tech community where everyone shares resources and nobody fights over the remote desktop connections.
How it all fits together:
- Top layer: External users accessing via browser or mobile (the front door).
- Middle layer: OpenShift Cluster with MAS Core Pod, Application Pods (Manage, Health, etc.), and Shared Services Pods (Db2, MongoDB, Kafka)—this is where all the action happens.
- Bottom layer: Persistent Storage, Databases, and Integration with external systems like ERP via App Connect (the foundation that keeps everything from falling apart).
For admins, the MAS Suite Administration page (accessed post-install) is your new command center, replacing much of Maximo’s System Configuration module. It is actually pretty nice once you get used to it.
Comparison Table: WebSphere/Maximo 7.6 vs. OpenShift/MAS 9
| Item | WebSphere/Maximo 7.6 | OpenShift/MAS 9 |
| Core Platform | WebSphere Application Server (monolithic) | Red Hat OpenShift (Kubernetes-based containers) |
| Deployment | Install via wizards, deploy WAR/EAR files | Use MAS CLI or Operator for YAML-based installs |
| Components | Single Maximo app with add-ons | Integrated suite (Manage, Health, Predict, etc.) |
| Database | External DB2/Oracle/SQL Server | Embedded Db2 Warehouse or MongoDB in pods |
| Scaling | Add JVMs or nodes manually | Auto-scale pods horizontally |
| High Availability | Clustering with Deployment Manager | Pod replicas, node failover, multi-AZ support |
| Monitoring | WebSphere logs, Tivoli tools | Built-in Prometheus, Grafana, Elasticsearch |
| Upgrades | Fix packs, manual testing | Operator-driven, rolling updates |
| Licensing | Per-user or CPU-based | AppPoints (flexible, suite-wide) |
| Admin Tools | WebSphere Console, Maximo Admin apps | OpenShift Console, MAS Suite Admin UI |
This table highlights how MAS 9 reduces manual overhead by using operators to handle what used to require custom scripts, Console tweaks, and occasionally, prayer.
Key Benefits for Administrators
New MAS 9 admins will appreciate these advantages:
Automation and Efficiency: Operators automate installs, configs, and upgrades. For example, the MAS Operator ensures dependencies like CP4D are met, unlike the manual “prereq scavenger hunt” of WebSphere days. You might actually leave work on time.
Resiliency: Pods self-heal; if one crashes, OpenShift restarts it automatically. High availability is baked in, supporting failover across zones which goes far beyond WebSphere’s basic clustering.
Hybrid Flexibility: Deploy on-premises (like your old setup) or in the cloud, with single-node options for smaller environments. You can even run Single Node OpenShift on AWS for cost savings.
Reduced Footprint: Containers use resources more efficiently than full VMs, lowering costs. MAS 9 supports disconnected (air-gapped) installs, ideal for those paranoid secure sites where the internet is “optional.”
Enhanced Security: Pod isolation, role-based access control (RBAC), and integration with enterprise identity providers mirror WebSphere security but add container-specific features.
However, let’s be real. You should expect a learning curve. YAML files replace GUI configs (sorry, point-and-click fans), and troubleshooting involves kubectl commands or OpenShift logs instead of heap dumps. But once you get the hang of it, you’ll feel like a command-line wizard.
Conclusion
MAS 9 on OpenShift represents a significant leap forward from WebSphere-based Maximo 7.6, trading traditional setups for a cloud-native, operator-driven architecture that’s more scalable, more automated, and frankly, more fun to work with once you get past the “where did everything go?” phase. While the components differ for example pods instead of servers, operators instead of manual deploys, YAML instead of XML, the core goal remains the same: efficient asset management that doesn’t make you want to update your résumé.
This overview sets the stage for what is coming. In our next entry, we will tackle installation and deployment, complete with actual commands you can copy-paste and enough detail that you won’t feel lost. If you’re planning a migration, start by assessing your OpenShift readiness (hint: you’ll want at least 3 workers with 16 cores and 64GB each for production, or more).
Resources worth bookmarking: IBM’s MAS documentation, Red Hat’s OpenShift guides, and maybe a good stress ball. Stay tuned for more hands-on tips, fewer buzzwords, and the occasional dad joke!
About
A3J Group is a leading solutions and consulting firm based in Tampa, Florida, specializing in Enterprise Asset Management (EAM) with a focus on fully developed Computerized Maintenance Management System (CMMS) solutions like IBM Maximo.
In addition to our suite of proprietary products—including MxMobile, our powerful mobile solution for Maximo—we provide traditional consulting services that help organizations plan, implement, optimize, and support their EAM strategies. Whether clients need hands-on configuration, strategic guidance, or ongoing system support, our team delivers the expertise to drive long-term success.
With over 50 years of combined experience, our specialized team is dedicated to our core mission: to serve as excellent stewards of our clients’ trust and investments, while driving measurable results through tailored, high-impact solutions and intelligent consulting.
Visit us at www.a3jgroup.com. Or drop us a line at info@a3jgroup.com.



