Hi all - I'm looking for any guidance that folks might have around the deployment life-cycle of your Maximo installation. When we have a re-compile of the application, it requires an 8-9 hour downtime. When we are migrating configuration (through packages), it's taking anywhere between 1-3 hours of downtime, depending on what we are doing. Are these sort of down-times inevitable with the product, or is there something we can be doing with our deployment life-cycle to create smaller windows by introducing more dev-ops and automation into our workflow.

------------------------------
Kasey Clark
------------------------------

#Maximo
#AssetandFacilitiesManagement

Hi Kasey,

First of all the deployment downtime sole depends on the amount of customization and configuration getting deployed. It also depends on external systems if it is a org level scheduled release.
Having said that 8-9 hours downtime still seems to be way more than standard deployment timelines.
DevOps if the best the way forward in this new world of IT. Maximo has all the feature to mold into a DevOps process of development and Deployment.
Which version of Maximo are you using?
There are a number of things which you can start analyzing:
1. How much customization is done in your environment? If you are using Maximo 7.6 and above then  almost all the java customization can be avoid using automation scripts. This will decrease your downtime significantly. It can go to as low as 1 hour of deployment time from 8 hour which is also subject to the fact that you have a very complex architecture and requires bringing down all the clusters and integration specs.
2. Is your EAR deployment process taking too long? 
3. What is causing the Migration package deployment taking 3-4 hours? Normally a package deployment should be as fast as couple minute. Migration manager is very powerful tool.
There are ways to decreased the Maximo downtime during deployment and an experienced consulting service provider can easily do an initial analysis of your system. 

But, yes It will interesting to know what deployment contents, measures and process leads to 8 hours downtime.

------------------------------
Biplab Choudhury
Maximo Consultant
Tata Consultancy Services
Melbourne
------------------------------

Original Message:
Sent: Tue July 07, 2020 06:29 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Hi all - I'm looking for any guidance that folks might have around the deployment life-cycle of your Maximo installation. When we have a re-compile of the application, it requires an 8-9 hour downtime. When we are migrating configuration (through packages), it's taking anywhere between 1-3 hours of downtime, depending on what we are doing. Are these sort of down-times inevitable with the product, or is there something we can be doing with our deployment life-cycle to create smaller windows by introducing more dev-ops and automation into our workflow.

------------------------------
Kasey Clark
------------------------------

#AssetandFacilitiesManagement
#Maximo

Which version of Maximo are you using?
There are a number of things which you can start analyzing:
1. How much customization is done in your environment? If you are using Maximo 7.6 and above then  almost all the java customization can be avoid using automation scripts. This will decrease your downtime significantly. It can go to as low as 1 hour of deployment time from 8 hour which is also subject to the fact that you have a very complex architecture and requires bringing down all the clusters and integration specs.
--- We're running OOTB Java files, nearly all our customization are in automation scripts.
2. Is your EAR deployment process taking too long?
---- Yeah - that seems what takes the longest, the build and deploy of all our EAR files (NINJA EDIT - currently 5 (not 16) ) takes the bulk of the time to complete.
3. What is causing the Migration package deployment taking 3-4 hours? Normally a package deployment should be as fast as couple minute. Migration manager is very powerful tool. 
--- You are correct, when it's just a package in migration manager our downtime is 1-2 hours. 
There are ways to decreased the Maximo downtime during deployment and an experienced consulting service provider can easily do an initial analysis of your system. 

------------------------------
Kasey Clark
------------------------------

Original Message:
Sent: Wed July 08, 2020 03:26 AM
From: Biplab Choudhury
Subject: Maximo CI/CD discussion

Hi Kasey,

First of all the deployment downtime sole depends on the amount of customization and configuration getting deployed. It also depends on external systems if it is a org level scheduled release.
Having said that 8-9 hours downtime still seems to be way more than standard deployment timelines.
DevOps if the best the way forward in this new world of IT. Maximo has all the feature to mold into a DevOps process of development and Deployment.
Which version of Maximo are you using?
There are a number of things which you can start analyzing:
1. How much customization is done in your environment? If you are using Maximo 7.6 and above then  almost all the java customization can be avoid using automation scripts. This will decrease your downtime significantly. It can go to as low as 1 hour of deployment time from 8 hour which is also subject to the fact that you have a very complex architecture and requires bringing down all the clusters and integration specs.
2. Is your EAR deployment process taking too long? 
3. What is causing the Migration package deployment taking 3-4 hours? Normally a package deployment should be as fast as couple minute. Migration manager is very powerful tool.
There are ways to decreased the Maximo downtime during deployment and an experienced consulting service provider can easily do an initial analysis of your system. 

But, yes It will interesting to know what deployment contents, measures and process leads to 8 hours downtime.

------------------------------
Biplab Choudhury
Maximo Consultant
Tata Consultancy Services
Melbourne

Original Message:
Sent: Tue July 07, 2020 06:29 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Hi all - I'm looking for any guidance that folks might have around the deployment life-cycle of your Maximo installation. When we have a re-compile of the application, it requires an 8-9 hour downtime. When we are migrating configuration (through packages), it's taking anywhere between 1-3 hours of downtime, depending on what we are doing. Are these sort of down-times inevitable with the product, or is there something we can be doing with our deployment life-cycle to create smaller windows by introducing more dev-ops and automation into our workflow.

------------------------------
Kasey Clark
------------------------------
#Maximo
#AssetandFacilitiesManagement

Kasey,

Why do you have 16 EAR files? At 30 minutes a pop for deployment, yeah.. 8 hours is normal for deploying 16 Maximo EARs on WebSphere. Have you investigated using clusters in WebSphere or Instance (server/JVM-specific) System Properties?

------------------------------
Blessings,
Jason Uppenborn
Sr. Technical Maximo Consultant
Ontracks Consulting
------------------------------

Original Message:
Sent: Wed July 08, 2020 10:59 AM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Which version of Maximo are you using?
There are a number of things which you can start analyzing:
1. How much customization is done in your environment? If you are using Maximo 7.6 and above then  almost all the java customization can be avoid using automation scripts. This will decrease your downtime significantly. It can go to as low as 1 hour of deployment time from 8 hour which is also subject to the fact that you have a very complex architecture and requires bringing down all the clusters and integration specs.
--- We're running OOTB Java files, nearly all our customization are in automation scripts.
2. Is your EAR deployment process taking too long?
---- Yeah - that seems what takes the longest, the build and deploy of all our EAR files (currently 16) takes the bulk of the time to complete.
3. What is causing the Migration package deployment taking 3-4 hours? Normally a package deployment should be as fast as couple minute. Migration manager is very powerful tool. 
--- You are correct, when it's just a package in migration manager our downtime is 1-2 hours. 
There are ways to decreased the Maximo downtime during deployment and an experienced consulting service provider can easily do an initial analysis of your system. 

------------------------------
Kasey Clark

Original Message:
Sent: Wed July 08, 2020 03:26 AM
From: Biplab Choudhury
Subject: Maximo CI/CD discussion

Hi Kasey,

First of all the deployment downtime sole depends on the amount of customization and configuration getting deployed. It also depends on external systems if it is a org level scheduled release.
Having said that 8-9 hours downtime still seems to be way more than standard deployment timelines.
DevOps if the best the way forward in this new world of IT. Maximo has all the feature to mold into a DevOps process of development and Deployment.
Which version of Maximo are you using?
There are a number of things which you can start analyzing:
1. How much customization is done in your environment? If you are using Maximo 7.6 and above then  almost all the java customization can be avoid using automation scripts. This will decrease your downtime significantly. It can go to as low as 1 hour of deployment time from 8 hour which is also subject to the fact that you have a very complex architecture and requires bringing down all the clusters and integration specs.
2. Is your EAR deployment process taking too long? 
3. What is causing the Migration package deployment taking 3-4 hours? Normally a package deployment should be as fast as couple minute. Migration manager is very powerful tool.
There are ways to decreased the Maximo downtime during deployment and an experienced consulting service provider can easily do an initial analysis of your system. 

But, yes It will interesting to know what deployment contents, measures and process leads to 8 hours downtime.

------------------------------
Biplab Choudhury
Maximo Consultant
Tata Consultancy Services
Melbourne

Original Message:
Sent: Tue July 07, 2020 06:29 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Hi all - I'm looking for any guidance that folks might have around the deployment life-cycle of your Maximo installation. When we have a re-compile of the application, it requires an 8-9 hour downtime. When we are migrating configuration (through packages), it's taking anywhere between 1-3 hours of downtime, depending on what we are doing. Are these sort of down-times inevitable with the product, or is there something we can be doing with our deployment life-cycle to create smaller windows by introducing more dev-ops and automation into our workflow.

------------------------------
Kasey Clark
------------------------------

#AssetandFacilitiesManagement
#Maximo

Hi Kasey,

We have successfully implemented CI/CD in our project using tools like Jenkins ,BitBucket and Ansible. Although the downtimes are inevitable with the product, we have been able to streamline and automate the process thus reducing a lot of manual effort and ensuing safe deployments. We have only one step in our release process and rest is automated.

Please reach out to me if you have any specific questions.

Thanks
Arun

------------------------------
Arun Kumar Ravindranath
------------------------------

Original Message:
Sent: Tue July 07, 2020 06:29 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Hi all - I'm looking for any guidance that folks might have around the deployment life-cycle of your Maximo installation. When we have a re-compile of the application, it requires an 8-9 hour downtime. When we are migrating configuration (through packages), it's taking anywhere between 1-3 hours of downtime, depending on what we are doing. Are these sort of down-times inevitable with the product, or is there something we can be doing with our deployment life-cycle to create smaller windows by introducing more dev-ops and automation into our workflow.

------------------------------
Kasey Clark
------------------------------

#AssetandFacilitiesManagement
#Maximo

My current customer is on Maximo 7.6.0 with a number of Industry Solutions installed and 4 clusters spread over 6 machines.

EAR deployment on WebSphere takes 20 minutes of WebSphere doing its thing plus 5 minutes of clicking through the screens -- so if we need an EAR deploy, we estimate a little high and say 4 clusters times 30 minutes is 2 hours.

Building the EAR takes 5 to 10 minutes per EAR. We have 4 of them (one per cluster) so that's possibly 40 minutes. However, the first one usually takes 7 or 8 minutes and the next ones might only take 4.5 minutes. But we build the EARs a couple hours before the outage starts. Building EARs takes MUCH longer if antivirus is turned on; I think it was about an hour.

We have Spatial installed. This Technote is for Maximo 7.5, but we were told by support to follow it for 7.6, and it has dramatically reduced our EAR build and deploy times.

Big tables (hundreds of columns and millions of rows) like WORKORDER take a long time to add new required attributes to, because after the new column has been added, all existing records need to be updated with the default value. (Attributes of type YORN are particularly bad for this.) This can take an hour per attribute. So, we try to make alternate solutions work.

Other than that, promoting changes to Prod doesn't normally take very long -- normally under half an hour. And we normally carry on with our Migration Manager and other changes using the first EAR/cluster deployed while the next EARs are being deployed, meaning that the non-EAR work doesn't actually add anything to the downtime / outage window.

------------------------------
Blessings,
Jason Uppenborn
Sr. Technical Maximo Consultant
Ontracks Consulting
------------------------------

Original Message:
Sent: Tue July 07, 2020 06:29 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Hi all - I'm looking for any guidance that folks might have around the deployment life-cycle of your Maximo installation. When we have a re-compile of the application, it requires an 8-9 hour downtime. When we are migrating configuration (through packages), it's taking anywhere between 1-3 hours of downtime, depending on what we are doing. Are these sort of down-times inevitable with the product, or is there something we can be doing with our deployment life-cycle to create smaller windows by introducing more dev-ops and automation into our workflow.

------------------------------
Kasey Clark
------------------------------
#AssetandFacilitiesManagement
#Maximo

Your info was really good stuff - do you know what ejbdeploy settings you have set? 


------------------------------
Kasey Clark
------------------------------

Original Message:
Sent: Wed July 08, 2020 11:49 AM
From: Jason Uppenborn
Subject: Maximo CI/CD discussion

My current customer is on Maximo 7.6.0 with a number of Industry Solutions installed and 4 clusters spread over 6 machines.

EAR deployment on WebSphere takes 20 minutes of WebSphere doing its thing plus 5 minutes of clicking through the screens -- so if we need an EAR deploy, we estimate a little high and say 4 clusters times 30 minutes is 2 hours.

Building the EAR takes 5 to 10 minutes per EAR. We have 4 of them (one per cluster) so that's possibly 40 minutes. However, the first one usually takes 7 or 8 minutes and the next ones might only take 4.5 minutes. But we build the EARs a couple hours before the outage starts. Building EARs takes MUCH longer if antivirus is turned on; I think it was about an hour.

We have Spatial installed. This Technote is for Maximo 7.5, but we were told by support to follow it for 7.6, and it has dramatically reduced our EAR build and deploy times.

Big tables (hundreds of columns and millions of rows) like WORKORDER take a long time to add new required attributes to, because after the new column has been added, all existing records need to be updated with the default value. (Attributes of type YORN are particularly bad for this.) This can take an hour per attribute. So, we try to make alternate solutions work.

Other than that, promoting changes to Prod doesn't normally take very long -- normally under half an hour. And we normally carry on with our Migration Manager and other changes using the first EAR/cluster deployed while the next EARs are being deployed, meaning that the non-EAR work doesn't actually add anything to the downtime / outage window.

------------------------------
Blessings,
Jason Uppenborn
Sr. Technical Maximo Consultant
Ontracks Consulting

Original Message:
Sent: Tue July 07, 2020 06:29 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Hi all - I'm looking for any guidance that folks might have around the deployment life-cycle of your Maximo installation. When we have a re-compile of the application, it requires an 8-9 hour downtime. When we are migrating configuration (through packages), it's taking anywhere between 1-3 hours of downtime, depending on what we are doing. Are these sort of down-times inevitable with the product, or is there something we can be doing with our deployment life-cycle to create smaller windows by introducing more dev-ops and automation into our workflow.

------------------------------
Kasey Clark
------------------------------
#Maximo
#AssetandFacilitiesManagement

If we (my customer) changed ejbdeploy settings, I have no memory of it. We're on WAS 8.5.5.11 on Windows 2012 R2, too.

Deployment taking 50 minutes just for white-screen-of-waiting sounds like how long it was taking us before we split out the Spatial stuff, as I mentioned earlier. So, if you only need the local ArcGIS libraries for your UI cluster, save yourself 30 minutes per RPT, OSLC, MIF and CRON deploy and implement a solution around the link I provided earlier -- probably by editing the buildmaximoear.bat or .xml. If you need help with that, like several other popular posters on this forum, I can hook you up with some consultants who could give you a hand.

If the advice to split out the ArcGIS libraries isn't helpful, I suggest raising a Support Case (nee PMR). Maybe do that anyway to make it better for the next guy -- to give the IBM Maximo and WebSphere development teams more reason to work on making deploys faster -- and maybe get help shortening your deployment time in the process.

------------------------------
Blessings,
Jason Uppenborn
Sr. Technical Maximo Consultant
Ontracks Consulting
------------------------------

Original Message:
Sent: Thu July 09, 2020 12:14 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Your info was really good stuff - do you know what ejbdeploy settings you have set? 

We only have 5 ear files (21 jvms). It takes 10 - 15 minutes per ear build and 1 (+) hour per ear to deploy spread across 3 windows servers with the recommended amount of RAM. Our ear files are UI, RPT, OSLC, MIF, CRON. The fastest we have seen our deploy run is 50 minutes, and we're running IBM WebSphere Application Server 8.5.5.13 on Windows Server 2012 R2. 

------------------------------
Kasey Clark

Original Message:
Sent: Wed July 08, 2020 11:49 AM
From: Jason Uppenborn
Subject: Maximo CI/CD discussion

My current customer is on Maximo 7.6.0 with a number of Industry Solutions installed and 4 clusters spread over 6 machines.

EAR deployment on WebSphere takes 20 minutes of WebSphere doing its thing plus 5 minutes of clicking through the screens -- so if we need an EAR deploy, we estimate a little high and say 4 clusters times 30 minutes is 2 hours.

Building the EAR takes 5 to 10 minutes per EAR. We have 4 of them (one per cluster) so that's possibly 40 minutes. However, the first one usually takes 7 or 8 minutes and the next ones might only take 4.5 minutes. But we build the EARs a couple hours before the outage starts. Building EARs takes MUCH longer if antivirus is turned on; I think it was about an hour.

We have Spatial installed. This Technote is for Maximo 7.5, but we were told by support to follow it for 7.6, and it has dramatically reduced our EAR build and deploy times.

Big tables (hundreds of columns and millions of rows) like WORKORDER take a long time to add new required attributes to, because after the new column has been added, all existing records need to be updated with the default value. (Attributes of type YORN are particularly bad for this.) This can take an hour per attribute. So, we try to make alternate solutions work.

Other than that, promoting changes to Prod doesn't normally take very long -- normally under half an hour. And we normally carry on with our Migration Manager and other changes using the first EAR/cluster deployed while the next EARs are being deployed, meaning that the non-EAR work doesn't actually add anything to the downtime / outage window.

------------------------------
Blessings,
Jason Uppenborn
Sr. Technical Maximo Consultant
Ontracks Consulting

Original Message:
Sent: Tue July 07, 2020 06:29 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Hi all - I'm looking for any guidance that folks might have around the deployment life-cycle of your Maximo installation. When we have a re-compile of the application, it requires an 8-9 hour downtime. When we are migrating configuration (through packages), it's taking anywhere between 1-3 hours of downtime, depending on what we are doing. Are these sort of down-times inevitable with the product, or is there something we can be doing with our deployment life-cycle to create smaller windows by introducing more dev-ops and automation into our workflow.

------------------------------
Kasey Clark
------------------------------
#Maximo
#AssetandFacilitiesManagement

Hi Kasey,

Please explore the shared libraries functionalities in Web Sphere. It will definitely decrease the build as well as deployment time significantly. With Shared libraries you just need to build 1 EAR and deploy it multiple Clusters. Thus, build time and deployment time is decreased significantly.
Also, Involving Web sphere team will be very good in your scenario. 8 hours of downtime is not good. 
Plus, deployment using shared libraries can be integrated using any CI-CD tool.

Thanks,
Biplab

------------------------------
Biplab Choudhury
Maximo Consultant
Tata Consultancy Services
Melbourne
------------------------------

Original Message:
Sent: Thu July 09, 2020 12:14 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Your info was really good stuff - do you know what ejbdeploy settings you have set? 

We only have 5 ear files (21 jvms). It takes 10 - 15 minutes per ear build and 1 (+) hour per ear to deploy spread across 3 windows servers with the recommended amount of RAM. Our ear files are UI, RPT, OSLC, MIF, CRON. The fastest we have seen our deploy run is 50 minutes, and we're running IBM WebSphere Application Server 8.5.5.13 on Windows Server 2012 R2. 

------------------------------
Kasey Clark

Original Message:
Sent: Wed July 08, 2020 11:49 AM
From: Jason Uppenborn
Subject: Maximo CI/CD discussion

My current customer is on Maximo 7.6.0 with a number of Industry Solutions installed and 4 clusters spread over 6 machines.

EAR deployment on WebSphere takes 20 minutes of WebSphere doing its thing plus 5 minutes of clicking through the screens -- so if we need an EAR deploy, we estimate a little high and say 4 clusters times 30 minutes is 2 hours.

Building the EAR takes 5 to 10 minutes per EAR. We have 4 of them (one per cluster) so that's possibly 40 minutes. However, the first one usually takes 7 or 8 minutes and the next ones might only take 4.5 minutes. But we build the EARs a couple hours before the outage starts. Building EARs takes MUCH longer if antivirus is turned on; I think it was about an hour.

We have Spatial installed. This Technote is for Maximo 7.5, but we were told by support to follow it for 7.6, and it has dramatically reduced our EAR build and deploy times.

Big tables (hundreds of columns and millions of rows) like WORKORDER take a long time to add new required attributes to, because after the new column has been added, all existing records need to be updated with the default value. (Attributes of type YORN are particularly bad for this.) This can take an hour per attribute. So, we try to make alternate solutions work.

Other than that, promoting changes to Prod doesn't normally take very long -- normally under half an hour. And we normally carry on with our Migration Manager and other changes using the first EAR/cluster deployed while the next EARs are being deployed, meaning that the non-EAR work doesn't actually add anything to the downtime / outage window.

------------------------------
Blessings,
Jason Uppenborn
Sr. Technical Maximo Consultant
Ontracks Consulting

Original Message:
Sent: Tue July 07, 2020 06:29 PM
From: Kasey Clark
Subject: Maximo CI/CD discussion

Hi all - I'm looking for any guidance that folks might have around the deployment life-cycle of your Maximo installation. When we have a re-compile of the application, it requires an 8-9 hour downtime. When we are migrating configuration (through packages), it's taking anywhere between 1-3 hours of downtime, depending on what we are doing. Are these sort of down-times inevitable with the product, or is there something we can be doing with our deployment life-cycle to create smaller windows by introducing more dev-ops and automation into our workflow.

------------------------------
Kasey Clark
------------------------------
#Maximo
#AssetandFacilitiesManagement