When it comes to modernization projects, whether IBM MQ related or not, my planning and strategy always rest on the WHY? Attempt at change usually indicates ‘new’ ‘newer’ or ‘more modern approaches. However, its’ rarely done without impetus or reason. The first thing to consider is WHY are we doing this? What is the current environment vs. what is the goal for the environment after modernization? Perpetuating this perspective helps with knowing what to avoid, what to consider, and what choices to make.
There are many reasons for a modernization initiative but typically, in enterprise environments, there are three: cost containment, necessary versioning to stay within support windows for the components involved, and capacity; the ability to achieve performance and reliability.
Upgrading or modernizing components typically isn’t a difficult thing to do. The difficulty comes with integration. All these components must work together. There are OS considerations which may affect hardware requirements, there are security considerations in order to prevent vulnerabilities, and there are integration considerations so that your environment can integrate with other components, such as LDAP or Cert management, database or logging, in-house applications, or 3rd party solutions.
Let’s consider the initial topic; WHY are you modernizing? Is it cost containment or are you simply modernizing your servers to keep up with performance, versioning, etc.? If it’s the latter case … then, the prior arguments all stand. And since you made this decision it must be because of some reason. If that reason was performance degradation, it can be due to a variety of issues, hopefully related to growth. This is why it’s good to keep metrics of performance and usage on all the above environments and components. Not only so that you can make your case for modernizing, but that you have the statistics to see what you had vs what you need (need is not want!). Can you show memory or CPU or network thresholds being exceeded? Did you ascertain the real cause of those thresholds being hit?
Even if you don’t have a years’ worth of statistics, START collecting as much as you can so that you can at least compare, week to week, month to month, or a specifically high traffic day in the past with one more recent.
Avoid false positives. Your company would not want a dramatic, nay expensive, modernization effort if the reality is that performance degradation was not due to memory/CPU/network/storage needs, but to poorly written and configured applications causing the performance issues! Applications can, and often do, have a huge effect on performance. Just look at a simple example of read, process, write. For example, if your application opens and closes 1 record at a time vs processing all the records in 1 open and 1 close (or 1 get and 1 put), etc. Suppose the application is dependent on a response from another component before it can complete or move forward? That would statistically show delay, even if it was purposeful.
In this case the major issue to avoid is NOT avoiding proper homework on the core reasons for performance. The last thing you want is to complete a modernization effort and the end result be no improvement. That doesn’t end well for anyone involved. And, as you modernize avoid creating a modernized environment that lacks the observability to continue to collect these metrics for future evaluation (which really wouldn’t be a modernized environment at all as defined by conventional wisdom).
One of the issues in the bigger picture of modernizing for the reasons of performance is still that of interrelated compatibilities. For instance, an OS upgrade may require a CPU or memory upgrade. An IBM MQ upgrade may require an OS version upgrade. An OS version upgrade may require a database upgrade or vice versa. A database upgrade many require that applications be updated.
The reality is: while you may want to modernize ONE of these areas or components within your environment, there may be a butterfly effect to other necessary components or areas. It’s well known that if an IT person is going to upgrade one of these areas, then they typically upgrade others, especially if it is also close to being a deprecated version, just to be ‘up to date’. Avoid overlooking these in your planning. The part to look at here is how far ahead your timeframe is until another modernization effort. If you expect your upgrade to last 3 years or 5 years etc., then you must look at the support levels of all the pieces involved and make sure they are ALL at those same timelines; OS, MQ, DBs, LDAP, and Application libraries like java (struts, springs, angular, REST, GIT, etc.).
If part of this performance effort leads to a recommendation to use 3rd party host or cloud environments, then the variables change considerably. Because when moving in that direction, having experience in those environments moves that up the list as much as it does security considerations.
There needs to be different deployment mechanisms and a means to stage a replica environment for development and testing before moving to the new hosted environment. Lastly, will that new environment support the same integrations for DB, LDAP, business applications, and 3rd party integrations? Avoid surprises with deployments into this modernized environment by having and using this cloned dev/testing environment. We’ll talk more about this in a future article.
In summary, the primary consideration about your modernization effort is WHY? When you understand why, then gather statistics to back that up. Those will be necessary to benchmark the newer approach. The next step is to look at the platforms and components that can best handle where you want to be along with how you want to manage those areas. Will those platforms & components allow you to keep the same integrations you have now? Once there, can you keep the same SMEs you have now? If not, what would be the choices and the timeline to learn new platforms and integrations? Will your team need to grow because of that or do you already know that won’t be in the cards in order to achieve those ends?
#IBMMQ