Cindy Gregorie

by Natalie Miller • @natalieatWIS

A model for support, integration, and ROI on middleware management

A Q&A with Cindy Gregorie, Practice Manager, Middleware & Application Integration, at TxMQ

Published July 15, 2014


For many organizations, managing a vast middleware environment is a daunting task, especially in terms of building and maintaining a dynamic, cost-effective, and secure infrastructure. TxMQ, Inc. an IBM Premier Business Partner located in Buffalo, NY, assists its clients with technical support and setting up their middleware environments to achieve a better return on investment and prepare for success.

Insights Magazine recently sat down with Cindy Gregoire, Practice Manager, Middleware & Application Integration at TxMQ, who has been in the middleware space for more than 15 years, supplying technical support to clients and assisting them with setting up their middleware environments. In this Q&A, Gregoire explains the top four infrastructure vulnerabilities organizations should look out for, the challenges clients face in middleware management and operational IT planning, the importance of embracing a 21st century information management and how to do it on a tight budget, and the benefits of developing a technology roadmap.

Insights Magazine: You’ve worked with hundreds of clients. What's a common challenge that they face?

Cindy Gregoire: Many of our short-term engagements involve customers who have hit a brick wall and can’t move a project forward, or they’re running into a performance problem and the system is not behaving correctly, and the current staff is evaluating the problem, but are unsure of how to proceed. The problem or resource need is beginning to escalate, and the company now needs to go outside of their house talent for some external help. We start by talking through what the particular pain point is, what the resource need is, and we take the next step and put together a proposal and get that in front of the customer. Then we even put the consultant on the phone and coordinate activities.

Get insights delivered to your inbox every week. Subscribe to our free newsletter.

IM: What’s unique about the approach?

Gregoire: [This is] fairly common in consulting practices at large, but our niche is mainframe integration middleware, where you have this infrastructure software that is somewhat nebulous and it’s having problems — but the folks that are supporting it or part of that IT shop are looking at this going, “I don’t know what the problem is; it’s Greek to me. Let’s bring in a middleware specialist; they should be able to tell us what’s going on with this system.”

So we do a lot of system healthchecks, where we take a look at the various system and application logs, we take a look at the operating system, and we look at the statistics that the operating system is producing. Knowing what we know about middleware, we compile our findings and analysis and develop some recommendations on what could be done. We’re able to dive deep into the technology and look for other sources of configuration correction — other than just potentially throwing more memory at a server for upgrading processors, which then allows the application to just consume more memory. So rather than fixing the root cause, you’ve actually exacerbated the problem, and that’s very typical. We see that quite a bit. In the systems healthcheck, we’ll take a look at what’s going on middleware and system wide, we’ll create a list of recommendations and work with their technical staff to get those recommendations implemented. We free up the resources to really help customers achieve a better return on investment in their middleware infrastructure.

IM: What considerations should organizations make in terms of their operational IT planning and conditions of employment and security standards?

Gregoire: Especially in 2013, we saw more than 1,000 breaches of company data over the Internet. Not all breaches are reported in a timely manner or even get publicity. Clearly the Target [Corporation] breach was the one that received the most attention, probably because it hit at the peak holiday season, and Target did a good job of notifying its customers and, of course, they are nationwide. So a lot of people heard about it and many people were affected. Customers are wary. The way you lay out your security standards and how you manage your e-commerce across the Internet is obviously a different animal than it was 10 years ago.

IM: What industries are modeling the right way to secure transactions?

Gregoire: Ten years ago, the portion of e-commerce that was done over the Internet was so much smaller than it is today. But most businesses — for example, retailers and smaller financial management companies — can really learn a lot from the financial services industry, because banking standards in general have always been subject to very rigid security standards. Many of our retail and SMB customers suffer gaps in their understanding of the width and breadth of security topics, why things are done a certain way or the importance of security policies and governance on a project management level to ensure each new project is incorporating the appropriate security practices subject to the type of data being handled.  Each industry has its own specific regulatory practices that have guidelines around the “right way” to secure transactions, like PCI compliance or HIPAA, and a lot depends on where that data exchange is occurring.  A lot of the consulting we do with customers, before they even engage with us, is just talking about some of these security standards.

For example, when you look at network topology, it’s important to evaluate how you are breaking out your network IPs, subnets, etc. and isolating which incoming connections can actually be established with your application servers within your trusted network. You have your internal network and then you should have these tiers of protection and a firewall between those systems and the Internet.

So what does that look like? You have diagrams—have you done your architecture? Have you laid out your network topology? We don’t necessarily do a lot of network consulting, although most companies have done it already themselves because it’s a necessity. They want to enable Internet commerce with their internal applications, and that’s really where the rub is right now. Large companies have many internal backend systems for processing and generating invoicing. EDI [electronic data interchange] has been happening for many years now. Yet this idea of being able to take a credit card, and pass that credit card data to an online internal order processing system is scary. How protected is that transaction throughout the end-to-end lifecycle of business?

So, what other considerations should organizations be making? Number one, in light of the many breaches, you definitely want to be planning for network isolation and internal security as well as external security measures that ensure customer data is protected throughout the life of the transaction. TxMQ can help you with this process and this is where an architecture-review service comes in. We review the transaction lifespan and what topology it’s crossing, and through our security management practice, which is part of our ITIL group, we’ll take a look at what things you’ve done, what things you need to have in place, and where are you in this continuum from minimum security to high security.

So those are areas that we do consult with our customers and help them to develop a plan and start implementing some of the changes that are needed to bring them into that level of security, where they can feel comfortable and customers can feel comfortable that standards are being met and they can feel assured that their transactions are fully secure.

Top 4 vulnerabilities to look out for within your infrastructure>>

  1. Demilitarized Zone Vulnerability. Bulletproof your DMZ. That demilitarized zone is where hackers are typically able to gain access to sensitive information. If you do nothing else, make sure that none of your business logic is running in your DMZ. There should not be any unauthorized data connectivity there, any way to insert rogue type of application logic or malware from the DMZ and/or ability to gain access to any business or customer data.
  2. Lack of encryption and certificate management. Encrypt your end-to-end transactions if they contain sensitive data and make sure you have a plan for your SSL certificate management. Once you start encrypting and setting up SSL and keys all over the place, you can have as many as 400-500 keys to manage. When they expire, those transactions are not going to be able to pass through and you’re going to have an outage. So as you implement your encryption strategy, you need to be aware that you are also implementing a certificate management process as well.
  3. Poor practices around UID and GUI management. Manage your user IDs and groups for those having access to your internal system. In terms of the threat of malware being inserted into your internal system, you need to take a look at who already has access to your internal system. Are those IDs and passwords strong passwords and are they being changed regularly? Most companies are aware that passwords are an inherent risk. For example, when an employee leaves a company, make sure that their ID is removed off of all of the systems. If you have not lock-tightened your general security processes, that can also lend to a vulnerability that would not be there otherwise. 
  4. Not keeping patches and updates current on servers and middleware. To keep your system supported at all levels, you need to be applying hot fixes and patches, and keeping your software and middleware at current levels as often as possible. This update addresses security vulnerability for this particular type of application and component. It may not have an immediate vulnerability, but two weeks from now, when a new application rolls out, there is vulnerability and you didn’t apply the update.

X Close

IM: TxMQ’s website mentions 21st century information management. Can you explain what the concept is and how organizations can benefit from this approach?

Gregoire: We’re talking about is the way IT was done in the 20th century and how information management in the 21st century is different—and clearly there are challenges for organizations to adopt to the new paradigm. If you were starting up a brand new business today, you would implement an environment using new technology. New companies are far better off from the IT perspective working from that paradigm because everything you’re working with is new, it’s going to be integrated, and it’s going to have all the up-to-date standards, etc.

But TxMQ customers, many of whom have been in business for 20 years or more,  are facing challenges including managing the old technology that doesn’t have all of the required capability and trying to introduce all the new bells, whistles, and capabilities, which are also key business drivers in the 21st century, on behalf of the business.

So the question is, what happens when you have all this old technology that works just fine and was designed for applications to run inside a technical environment that was not initially Internet-enabled? In order to compete and relate with customers, suppliers and service providers that are using social media and mobile devices, you have to maintain your old systems and also integrate with all the new security requirements.

The point of talking about 21st century information management is the fact that, number one, there is a whole new way of doing business now because of the Internet and e-commerce. And two, you have all these mature companies that have been in business since before the year 2000 and their systems were never really designed to be able to deliver the types of services that 21st-century systems are delivering without some drastic investment. Not only do established businesses need to maintain existing systems that are working, but they also need to consider their integration and go-forward strategy for embracing the new. That’s the only effective way to compete with companies that are embracing the 21st century information management strategies we are seeing in today’s marketplace.

IM: It’s about anticipating new opportunities.

Gregoire: It’s taking a look at what’s coming up next. For example, big data is hitting everybody. Big data is all about having to house terabytes of data. Twenty years ago, the word terabyte didn’t exist in the common language at all because even the idea of a gigabyte was a phenomenal amount of data. So here we are talking about larger amounts of data and doing analytics in order to determine things like what people are buying right now and which demographics of people are living the longest. All of this really leads into a different mentality than what we had before the turn of the century in terms of our information technology systems and strategy. Are we managing our applications and our systems or are we managing our data as business intelligence or are we able to manage both? In terms of information technology and the management structure, you have all of these new roles—from CTO, CIO, CSO, data managers, etc.—roles that were previously combined into one single role, but are now each fulltime jobs with their own focus that are supported by a number of vendor products, suppliers, and service providers that all require management oversight. Or, how about rolling out a mobile strategy for your business? As a business you want to relate to how to sell things to people. You can’t ignore social media anymore; you can’t ignore smartphones anymore. You have to have a complete plan in order to continue doing business in the 21st century.

IM: A lot of companies have small IT budgets; what tools can they leverage for middleware support and management to combat that?

Gregoire: IT budgets have been flat since somewhere around 2009, maybe as early as 2007, and in much the same way that you might consider patching a roof because you can’t afford a complete replacement, the problems don’t go away just because you don’t have money or budget. It’s a quick fix, which will reoccur until the problem is solved.

When you look at what tools businesses can leverage, especially concerning middle management and support, take a look at what the business requirements are and then sell the need for additional funding to get the tools you require. The reality is that companies that are not putting enough money into their IT spending budgets are not going to survive the next five years. Competition is fierce.

I would have to go on the record and say that more companies are making the mistake of not paying attention to standardizing middleware management and support to help drive down those costs. As a result they are spending a lot more money than needed because of the diversity of their middleware management tools. Companies are spending a lot of time troubleshooting and not getting a lot of results. These are companies who had a few copies of some very expensive tools or perhaps trial copies but no process in place to incorporate the use of these proper tools into the development lifecycle. Anything they do really goes back to their IT planning and being able to justify the need to the business management in terms of outage time and costs to not having the essential tools, resources and processes. We see that across the middleware environment when we’re doing health checks. They say, “We couldn’t get money for that, so we tried to do this instead.”

IM: How does developing a technology roadmap fit into this and what’s the benefit of this approach?

Gregoire: We hear that terminology used all the time. At the technology level, is your infrastructure current? And when you ask what does “current” mean, it means that if you installed software in 1999, have you applied all of the updates, new releases, patches, or even migrated to the latest version?

A technology roadmap places the infrastructure initiative at the same level as other application initiatives. So here are the underlying questions that should be asked when identifying a need for a technology roadmap and determining whether or not business applications are at risk.

  1. Is the infrastructure current?
  2. Most of my customers now have middleware roadmaps. What middleware are we running?
  3. Are the applications running at vendor-supported levels?
  4. Are the operating systems up-to-date?
  5. Do the operating systems have certain security patches applied?
  6. Are the applications connecting through to a database?
  7. Is the database current? Is security-restricted access set up to that database?
  8. Or, was everything installed using admin authority, where if hackers can crack that admin password, they gain access to everything in the network?

This is some of the content included in building out a technology roadmap. Developing a technology roadmap, if you don’t have one, is critical to the survival of your business. Otherwise, your technology is going to lag behind and what may be current now, will put you at risk tomorrow. Without following a roadmap you’re likely going to be more vulnerable, but even more than that, there may be more features and functions you’re not going to be able to offer to your customers. You may even be faced with instability issues.

IM: What are some tips for organizations that want to develop a technology roadmap?

Gregoire: Start with what you have and what you do well, and develop a roadmap for the things that you know are most important to you. Carrying that forward, you can expand a technology roadmap to include some peripheral things. You’ll start off with a very specific technology roadmap and plan, and then start developing a plan for the network, mobile integration, and other components to the business. For every technology roadmap, you’re always going to be talking about how many resources it’s going to take to follow this roadmap, how much money it is going to take, and how much time.

IM: When you are working with clients, how do you prepare them for continued success when your engagement is complete?

Gregoire: We do what’s called a “project closeout.” Prior to that discussion with the customer, I have each consultant complete what’s called a “lessons learned.” Lessons learned is really just a document that helps me understand, from the consultant’s viewpoint, what went well and what didn’t go well.  Then we complete the project closeout with the customer, with the idea of confirming whether we accomplished everything that was outlined in the statement of work and if there is something that should have been included that we didn’t do. What, if anything, could we have done better? The “project closeout” is something that I’ve found helps us identify other opportunities for the client where we might be able to assist or find resources.

For more information about TxMQ visit 



No one has commented on this item.