The use case involves changing a definition, table definition, table space definition, or index definition. BMC AMI DevOps for Db2 with Change Manager provides functionality where the developer can input the desired state, meaning the desired state of the table, and internally this tool performs impact analysis. It identifies what changes will be needed, then performs the changes and makes the target system look like the desired state.
Schema comparison has improved automated impact analysis and now needs native mainframe deployment
What is our primary use case?
What is most valuable?
Schema Comparison is a game-changer feature. Several options are available, including catalog-to-catalog comparison. If you have a definition in your notepad file and a target system, you can perform the comparison to see what all things can go wrong or what all things will be changed. You get a work list, an impact analysis report, and a change definition upfront before even making changes to the target system. BMC AMI DevOps for Db2 does a kind of dry run and gives an impression of how changes will look in production or on the target system, the impacts, and whether it will result in a drop and create situation.
When performing actual executions, there are two important features of this tool called Migration Profiles. There are static changes and dynamic changes. When you have a test environment, acceptance environment, and production environment, the naming convention differs per environment and some parameters differ because in production, you can have large storage allocated to the table, but you would not do the same in the acceptance environment and certainly would not allocate the same space in a test environment. This tool has a facility called Migration Profile where you can define that if the changes are to be done, then make the changes in such a way that in the target environment, the predefined unit of storage is allocated.
Regarding auditing capabilities of this solution, it logs enough information and has guardrails all over the place. It logs all the changes that are made and manages authentication in two ways: user ID password-based and certificate-based. All the actions performed using these users are logged inside the process so that it is always possible to figure out who made the change and when it was made. Track and trace mechanisms are good and functioning well.
What needs improvement?
There is an area in this product that I would like to see improved or enhanced in the future. This product is a containerized product, which is good news and a very good part. However, the product can run on Linux and I think it can also run in Windows, but what I am looking for is that if this product is to cater to mainframe-based database changes, then the product should also be deployable on mainframe. Containerization is not new in mainframe and is possible, with an offering called ZCX, a containerization offering already available on the mainframe. Rather than hosting on a Linux machine, I could host it in the mainframe natively and make the changes in the mainframe.
First, from an architectural standpoint, I want to see containerization running natively on the mainframe rather than deploying on Linux and then making a connection to the mainframe to make the changes in the mainframe. Second, the entire ecosystem of Db2 includes a product called Command Center, and the user interface of the Command Center looks a bit traditional in nature. With today's emerging UI frameworks, that interface is extremely traditional. There is improvement opportunity in that area.
From the demonstration, I learned that having those things pre-recorded on YouTube or somewhere already hosted would be helpful. There is a playlist on YouTube, but it is more for Jenkins, while my shop uses Azure DevOps and they also have an offering on Azure DevOps, but there is no video for that. If we would not have had that demonstration from their side, we would have struggled. The improvement that I suggest is that the things people generally struggle with is the starting point and the demonstration of how to use the product. This can be very well documented upfront, or in today's date, documentation is not something that one looks for. One directly looks for a demonstration. If there is something ready to use, something one can just see, observe, and understand, then it will reduce the number of questions from the user side.
For how long have I used the solution?
It has been nearly nine months since I have been working with BMC AMI DevOps for Db2. It is not live yet because live for my customers means my customers are the developer community, the mainframe developer community within my organization. I am designing the solution and also implementing the solution. I have been working with this product for nine months and developing it, but in between there were some other priorities. This represents a sizable time of using this product.
What do I think about the stability of the solution?
With every new version coming up with this product, the product is becoming more stable and more reliable. With the kind of use case that I have, I have not experienced much problem nowadays. When I started, there were some problems, but now that is not the case.
What do I think about the scalability of the solution?
It is a containerized solution, so as many instances as wanted can be rolled out. Scalability is not a problem.
How are customer service and support?
Regarding the technical support, I rate them from one to ten as seven.
What about the implementation team?
I have been involved in the solution. Although not in the installation part, once it is installed, it is a part of my solution. From day one, I am there with the solution.
What other advice do I have?
The term automated testing does not quite resonate with me because for automated testing, in Schema Comparison, it helps to do the dry run. When implementing the change, verification is done, and not all changes are directly implemented on production. Generally, the organization first implements in test, then acceptance, and then production. A dry run gives a good impression, but I do not think there is a test feature in this product.
This product has good integration. I would say that it is not deeply integrated, but it can be in my pipeline. I have a dedicated pipeline, but I still manage the DevEx, meaning the SCM. Whenever deployments are made, some changes are also made on the SCM front so that both remain in sync. There is a possibility of integration, but that is on how it is integrated. There is no integration directly with a DevEx-kind of product, but it internally uses the Catalog Manager, Change Manager, and Command Center.
It can be deployed both on cloud and on-premises. I would rate this review as a seven overall.
Which deployment model are you using for this solution?
Hybrid Cloud
