Category: Architecture Consulting

Digital Transformation: When It Makes Sense and When It Doesn’t

Posted on | by Jeff Eveland
TxMQ DIgital Transformation

This isn’t the first time I’ve written about digital transformation, nor is it likely to be the last.

Digital transformation has become a “must use” catchphrase for investor and analyst briefings and annual reports. Heaven help the foolish Fortune 500 company that fails to use the buzzword in their quarterly briefing. It’s the “keto diet” of the technology world.

It’s a popular term, but what does digital transformation really mean? 

Legacy debt. 

In a world of enterprises that have been around for longer than a few years, there is significant investment in legacy processes and technical systems (together what we like to call legacy debt) that can inhibit rapid decision making.  This is a combination of not just core systems, but also decades-old processes and decision-making cycles…bureaucracy in other words.

So why do we care about rapid decision making? Simply put, in years past, decisions were less consumer-driven and more company-driven, or dare I say it, focus-group driven.

Companies could afford to take their time making decisions because no one expected overnight change. Good things used to take a long time. 

We now live in a world where consumers demand rapid change and improvement to not just technology, but also processes. On a basic level, this makes sense. After all, who hasn’t had enough of poorly designed AI-driven, voice-activated phone trees when we just want to ask the pharmacist a question about our prescription refill? 

Too often, however, legacy debt leads to rapid implementations to meet customer demands – often with unintended (and catastrophic) consequences.  Often this is the result of rapid, poorly built (or bought) point solutions. This is where disruptors (aka startup companies) often pop up with quick, neat, point solutions of their own to solve a specific problem: a better AI-driven phone solution, a cuter user interface for web banking, sometimes even a new business model entirely. Your CIO sees this in an article or at a conference and wonders, “why can’t we build this stuff in-house?”

Chasing the latest greatest feature set is not digital transformation. Rather, digital transformation begins with recognizing that legacy debt must be considered when evaluating what needs changing, then figuring out how to bring about said change, and how to enable future rapid decision making. If legacy systems and processes are so rigid or outdated that a company cannot implement change quickly enough to stay competitive, then, by all means, rapid external help must be sought. Things must change.

However, in many cases what passes for transformation is really just evolution. Legacy systems, while sometimes truly needing a redo, do not always need to be tossed away overnight in favor of the hottest new app. Rather, they need to be continually evaluated for better integration or modernization options. Usually by better exposing back end systems. Transformation is just another word for solving a problem that needs solving, not introducing a shiny object no one has asked for. Do our systems and processes, both new and old, allow us to operate as nimbly as we must, to continue to grow, thrive and meet our customer demands today and tomorrow?

The Steve Jobs effect

Steve Jobs once famously stated (it’s captured on video, so apparently it really happened), when asked why he wasn’t running focus groups to evaluate the iPod, “How would people know if they need it, love it or want it if I haven’t invented it yet?”

Many corporate decision-makers think they are capable of emulating Steve Jobs. Dare I say it, they are not, nor are most people. Innovating in a vacuum is a very tricky business. It’s best to let the market and our customers drive innovation decisions. Certainly, I advocate for healthy investment in research and development, yet too often innovation-minus-customers equals wasted dollars. Unless one is funding R&D for its own sake, certainly a worthy cause, one needs some relative measure of the value and outcomes around these efforts. Which usually translates to marketability and ultimately profits.

Measurement

Perhaps the most often forgotten reality of our technology investments is understanding what the end goal, or end-state, is, and measuring whether or not we accomplished what we set out to do. Identifying a problem and setting a budget to solve that problem makes sense. But failing to measure the effectiveness after the fact is a lost opportunity. Just getting to the end goal isn’t enough, if in the end the problem we sought to solve remains. Or worse yet we created other more onerous unintended consequences.

Digital transformation isn’t about buzzwords or “moving faster” or outpacing the competition. It’s all of that, and none of that at the same time. It’s having IT processes and systems that allow a firm to react to customer-driven needs and wants, in a measured, appropriate, and timely way. And yes, occasionally to try to innovate toward anticipated future needs.
Technology is just the set of tools we use to solve problems.

Does it answer the business case?

“IT” is never — or at least shouldn’t be — an end-in-itself: it must always answer to the business case. What I’ve been describing here is an approach to IT that treats technology as a means to an end. Call it “digital transformation,” call it whatever you want — I have no use for buzz words. If market research informs you that customers need faster web applications, or employees tell you they need more data integration, then it’s IT’s job to make it happen. The point is that none of that necessitates ripping and replacing your incumbent solution. 

IT leaders who chase trends or always want the latest platform just for the sake of being cool are wasting money, plain and simple. Instead, IT leaders must recognize legacy debt as the investment it is. In my experience, if you plug this into the decision-making calculus, you’ll find that the infrastructure you already have can do a lot more than you might think. Leverage your legacy debt, and you’ll not only save time delivering new products or services, but you’ll also minimize business interruption — and reduce risk in the process. 

That’s the kind of digital transformation I can get behind.
—

Which of these MQ mistakes are you making?

Posted on | by Jeff Eveland
IBM MQ Logo

IBM MQ Tips Straight From TxMQ Subject Matter Experts

At TxMQ we have extensive experience helping clients with their IBM MQ deployments including planning, integrations, management, upgrades, & enhancements. Throughout the years we’ve seen just about everything, and we have found there are some common mistakes that are easy to stay away from with a little insight. Here are some a few tips to keep you up and running:IBM MQ is a powerful tool that makes a huge difference in your life every day, but for most of us you only notice it when it’s not working. One small mistake can cause havoc to your entire system.

1. Don’t use MQ as a database. MQ is for moving messages from one application or system to another. Databases are the data repository of choice. MQ resources are most optimized when considering data throughput and message delivery efficiency. IBM MQ is optimized when messages are kept small.

2. Don’t expect assured delivery if you didn’t design for it! Assured one-time message delivery is provided by IBM MQ through setting message persistence and advanced planning in the application integration design process. This plans for poisoned message handling that could otherwise cause issues and failures or worse, unexpected results. Know your business requirements for quality of service for message delivery and make sure your integration design accommodates advanced settings and features as appropriate.

3. Don’t give every application their own Queue Manager! Sometimes yes, sometimes no. Understand how to analyze what is best for your needs. Optimize your messaging architecture for shared messaging to control infrastructure costs and optimize operational support resources.

4. Don’t fall out of support. While TxMQ can offer support for OUT of support products, it’s costly to let support lapse on current projects, and even more so if you have to play catch up!

5. Don’t forget monitoring! MQ is powerful and stable, but if a problem occurs, you want to know about it right away. Don’t wait until your XMITQs and application queues fill up and bring the Queue Manager down before you respond!

In the cloud, on mobile, on-prem or in the IoT, IBM MQ simplifies, accelerates, and facilitates security-rich data exchange. Keep your MQ running smoothly, reach out to talk with one of our Subject Matter Experts today!

If you like our content and would like to keep up to date with TxMQ don’t forget to sign up for our monthly newsletter.

 

Contemplations of Modernizing Legacy Enterprise Technology

Posted on | by Jeff Eveland

What should you think about when modernizing your legacy systems?

Updating and replacing legacy technology takes a lot of planning and consideration. It can take years for a plan to become fully realized. Often poor choices during the initial planning process can destabilize your entire system, and it’s not unheard of for shoddy strategic technology planning to put an entire organization out of business.

At TxMQ we play a major role in helping our clients plan, integrate, and maintain legacy and hybrid systems. I’ve outlined a few areas to think about in the course of planning, (or in some cases re-planning) your modernization of legacy systems.

1.The true and total cost of maintenance
2.Utilize technology that integrates well with other technologies and systems
3. Take your customer’s journey into consideration
4. Ensure that Technical Debt doesn’t become compounded
5. Focus on fixing substantiated validated issues
6. Avoid technology lock-in

1. The true and total cost of maintenance

Your ultimate goal may be to replace the entire system but taking that first step typically means making the move to a hybrid environment.

Hybrid Environments utilize multiple systems and technologies for various processes, and can be extremely effective, but difficult to manage by yourself. If you are a large corporation with seemingly endless resources and have an agile staff with an array of skill sets, then you may be prepared. However, the reality is most IT departments are on a tight budget, people are multitasking and working far more than 40 hours a week just to maintain current systems.

These days most IT Departments just don’t have the resources. This is why so many organizations are moving to Managed IT Services to help mitigate the costs, take back some time, and are becoming more agile in the process.

When you’re deciding to modernize your old legacy systems you have to take into consideration the actual cost of maintaining multiple technologies. As new tech enters the marketplace, and older technologies and applications are moving towards retirement, so are the people who historically managed those technologies for you. It’s nearly impossible today to find a person willing to put time into learning technology that’s on it’s last leg. It’s a waste of time for them, and will be a huge drain on time and economical resources for you. It’s like learning how to fix a steam engine over learning more modern electric engines. I’m sure it’s a fun hobby but it it will probably never pay the bills.

You can’t expect newer IT talent to accept work that means refining and utilizing skills that will soon no longer be needed, unless you’re willing to pay them a hefty sum not to care. Even then, it’s just a short term answer and don’t expect them to stick around for long, always have a back up plan. Also, it’s always good to have someone on call that can help in a pinch and provide needed fractional IT Support.

2. Utilize technology that integrates well with other technologies and systems.

Unless you’re looking to rip and replace your entire system, you need to ensure that the new plays well with the old. Spoiler alert!, different technologies and systems often don’t play well together.

When you thought you’ve found that missing piece of software that seems to fix all the problems your business leaders insist they need, you will find that integrating it into your existing technology stack is much more complicated than you expected. If you’re going at this alone please take into consideration when planning a project, two disparate pieces of technology often act like two only children playing together. Sure they might get along for a bit but as soon as you turn your back there’s going to be a miscommunication and they start fighting.

Take time in finding someone with expertise in integrations, preferably a consultant or partner with plenty of resources and experience in integrating heterogeneous systems.

3. Take your customer’s journey into consideration

The principal reason any business should contemplate upgrading legacy technology is that it improves on the customer experience. Many organizations make decisions based on how it will increase profit and revenue without taking into consideration how profit and revenue are made.

If you have an established customer base, improving their experience should be a top priority because they require minimal effort to retain. However, no matter how superior your services or products are if there is a process with a smoother customer experience you can be sure that your long time customer will move on. As humans, we almost always take the path of least resistance. If you can improve even one aspect of a customer’s journey you have chosen wisely.

4. Ensure that Technical Debt doesn’t become compounded


Technical Debt is the idea that choosing the simple low cost solution will most certainly ensure you pay a higher price in the long run. The more you choose this option, the more likely you are to increase this debt, and in the long run you will be paying more, with interest.

Unfortunately, this is one of the most common mistakes when undertaking a legacy upgrade project. This is where being frugal will not pay off. If you can convince the decision makers and powers that be of one thing, it should be to not choose exclusively based on lower upfront costs. You must take into account the total cost of ownership. If you’re going to take time and considerable effort to do something you should always make sure it’s done right the first time, or it could end up costing a lot more.

5. Focus on fixing substantiated validated issues

It’s not often, but sometimes when a new technology comes along, like blockchain for instance, we become so enamored by the possibilities that we forget to ask, do we need it?

It’s like having a hammer in hand and running around looking for something to nail. Great you have the tool, but if there’s not an obvious problem to fix it with then it’s just a status symbol and that doesn’t get you very far in business. There is no cure-all technology. You need outline what problems you have, then prioritize to find the right technology that best suits your needs. Problem first, then Solution.

6. Avoid technology and Vendor lock-in

After you’ve defined what processes you need to modernize be very mindful when choosing the right technology and vendor to fix that problem. Vendor lock-in is serious and has been the bane of many technology leaders. If you make the wrong choice here, it could end up costing you substantially to make a switch. Even more than the initial project itself.

A good tip here is to look into what competitors are doing. You don’t have to copy what everyone else is doing, but to remain competitive you have to at least be as good as your competitors. Take the time to understand and research all of the technologies and vendors available to you, and ensure your consultant has a good grasp on how to plan your project taking vendor lock-in into account.

Next Steps:

Modernizing a major legacy system may be one of the biggest projects your IT department has ever taken on. There are many aspects to consider and no two environments are exactly the same, but it’s by no means an impossible task. It has been done before, and thankfully you can draw from these experiences.

The best suggestion I can give, is to have experience available to help guide you through this process. If that’s not accessible within your current team, find a consultant or partner that has the needed experience so you don’t have to worry about making the wrong choices and end up creating a bigger issue than you had in the first place.

At TxMQ we’ve been helping businesses assess, plan, implement, and manage desperate systems for 39 years. If you need any help or have any question please reach-out today. We would love to hear from you.

Why ETL Tools Might Hobble Your Real-Time Reporting & Analytics

Posted on | by admin

Companies report large investments in their data warehousing (DW) or Business Intelligence (BI) systems with a large portion of the software budget spent on extract, transformation and load (ETL) tools that provide ease of populating such warehouses, and the ability to manipulate data to map to the new schemas and data structures.

Companies do need DW or BI for analytics on sales, forecasting, stock management and so much more, and they certainly wouldn’t want to run the additional analytics workloads on top of already taxed core systems, so keeping them isolated is a good idea and a solid architectural decision. Considering, however, the extended infrastructure and support costs involved with managing a new ETL layer, it’s not just the building of them that demands effort. There’s the ongoing scheduling of jobs, on-call support (when jobs fail), the challenge of an ever-shrinking batch window when such jobs are able to run without affecting other production workloads, and other such considerations which make the initial warehouse implementation expense look like penny candy.

So not only do such systems come with extravagant cost, but to make matters worse, the vast majority of jobs run overnight. That means, in most cases, the best possible scenario is that you’re looking at yesterday’s data (not today’s). All your expensive reports and analytics are at least a day later than what you require. What happened to the promised near-realtime information you were expecting?
Contrast the typical BI/DW architecture to the better option of building out your analytics and report processing using realtime routing and transformation with tools such as IBM MQ, DataPower and Integration Bus. Most of the application stacks that process this data in realtime have all the related keys in memory –customer number or ids, order numbers, account details, etc. – and are using them to create or update the core systems. Why duplicate all of that again in your BI/DW ETL layer? If you do, you’re dependent on ETLs going into the core systems to find what happened during that period and extracting all that data again to put it somewhere else.

Alongside this, most organizations are already running application messaging and notifications between applications. lf you have all the data keys in memory, use a DW object, method, function or macro to drop the data as an application message into your messaging layer. The message can then be routed to your DW or BI environment for Transformation and Loading there, no Extraction needed, and you can get rid of your ETL tools.

Simplify your environments and lower the cost of operation. If you have multiple DW or BI environments, use the Pub/Sub capabilities of IBM MQ to distribute the message. You may be exchanging a nominal increase in CPU for eliminating problems, headaches and costs to your DW or BI.

Rethinking your strategy in terms of EAI while removing the whole process and overhead of ETL may indeed bring your whole business analytics to the near-realtime reporting and analytics you expected. Consider that your strategic payoff. Best regards in your architecture endeavors!
Image by Mark Morgan.

Oracle Announces End of Support For JD Edwards EnterpriseONE Technology Foundation

Posted on | by Jeff Eveland

Long title. What’s this about?
In short, back in 2010, Oracle announced the withdrawal of JDE EnterpriseOne Technology Foundation. The final nail in this coffin comes on September 30, 2016, when technical support officially ends.
What this means is that for many customers (and I’ll get into particulars shortly) there’s a requirement to make a critical decision to either move to Oracle’s Red Stack, or procure new IBM licenses in order to remain on IBM’s Blue Stack.
There’s a variety of customers running the stack, and nearly as wide a variety of options for how companies may have deployed their JDE solution. WebSphere with DB2 is the original and most common. WebSphere with Oracle as the backend is another common combo. And there’s a variety of other blends of supported web/application servers, database servers and related middleware.
Regardless of the configuration, in most cases, these products were part of the bundled solution that customers licensed from Oracle, and now a decision point’s been reached.
This doesn’t mean Oracle’s dropping support for IBM products. This does mean there’s a change in the way they’re licensed.
So what is “Technology Foundation”?
To quote from Oracle’s documents verbatim: Technology Foundation is an Oracle product that provides license for the following components:

  • JD Edwards EnterpriseOne Core Tools and Infrastructure, the native design time and runtime tools required to run JD Edwards EnterpriseOne application modules
  • IBM DB2 for Linux, Unix, and Windows, limited to use with JD Edwards EnterpriseOne programs
  • IBM WebSphere Application Server, limited to use with JD Edwards EnterpriseOne programs
  • IBM WebSphere Portal, as contained in JD Edwards EnterpriseOne Collaborative Portal

Technology Foundation is also referred to by the nickname “Blue Stack.”
If your license for JD Edwards EnterpriseOne applications includes an item called “Technology Foundation” or “Technology Foundation Upgrade,” this affects you.
If there are any other terms like “Oracle Technology Foundation,” then this change does NOT affect you. This is also different then the foundation for JD Edwards World.
So what now? In short, if you have Blue Stack, you should contact TxMQ or IBM immediately to acquire your own licensed products to continue to run your Oracle solution. TxMQ can offer aggressive discounts to Oracle customers subject to certain terms and conditions. Contact us for pricing details. We can help with pricing, as well as with any needed migration planning and implementation support.
Contact chuck@txmq.com for immediate price quotes and migration planning today.
Image from Håkan Dahlström.

Why Should I Use An IBM Business Partner?

Posted on | by Jeff Eveland

Wouldn’t it make more sense to deal directly with IBM?

This is a topic of much discussion around the TxMQ office these days, as it is at other solutions providers. Prospective customers often ask us: If my company’s able to go direct with my manufacturer/vendor (be it IBM, Microsoft, Oracle, or whomever), why shouldn’t we?
It’s a fair question. Companies, especially large ones, oftentimes have multilayered supply-chain relationships for acquiring software, hardware, and talent.
On the one hand, long-standing, embedded relationships often dictate the way a company acquires technical solutions. A friendship nurtured through years of trusted business dealings – sometimes called a “trusted advisor” relationship – may be the perfectly legitimate and ideal way of solving technical challenges. Yet sometimes things change. What happens when your salesperson – the same salesperson who’s covered your company for years – resigns?
Back to the broader topic of direct or business partner: As software and hardware companies like IBM and the other majors evolve over time, their business models push more sales through channel partners. Business partners are inevitably smaller companies, and are typically far better equipped to build and maintain longstanding, deep customer relationships. Sales teams at the major vendors change, oftentimes annually, leading to spotty coverage of accounts, and occasionally even leaving some companies with no direct coverage at all.
Business partners typically offer more consistency and stability of coverage. In addition, as IBM and the majors continue to add layers of complexity to their brands, and shift products in their portfolios, it’s very difficult for companies (and even their field salespeople), to keep products straight.
Surprisingly, this is a knowledge area in which partners tend to excel. Most of the leadership at business partners were themselves former employees of the majors. They left the majors to explore greater freedom to engage with customers, and to build deeper, better relationships over longer periods of time without the bureaucracy that comes with working in a large shop, or the threat of annual account “realignment.”
Also, as solutions offered to customers become more complex and cross over traditional brand borders, business partners are better able to navigate these tricky waters.
Recently IBM, along with other majors, went through internal realignments that left salespeople covering products new to them, and others were shifted to entirely new lines of business. Not so with business partners, who are free to engage as they always have.
What about software and hardware sales? Logic says it must be cheaper to buy direct. No indeed. IBM, as one example, has dramatically shifted internal teams, and reduced field and inside sales coverage to better align their resources with today’s market. What does this mean? It means it’s usually cheaper to order software and hardware from a partner. IBM knows it’s very expensive to have a large, geographically dispersed sales team, and far more cost-effective to let IBM business partners sell more and more software, services and hardware for them.
Partners therefore have full access to special bid requests, discounting, plus any and all sales tools a direct seller has in the arsenal. In addition, it goes without saying that a business partner’s services rates are nearly always below IBM direct rates.
Conclusion
In the end, each company must decide what’s best for itself, but don’t presume that the way you engaged with IBM and others in the past is the best way to engage in the future. A business partner can be your best ally to stay current with technology, and enable the nimble, robust infrastructure your company needs to compete and win in today’s marketplace.
Let’s take this conversation a bit further – email me at chuck@txmq.com.
(Image by Flazingo Photos)
 
 

What The x86 Deal Delivers To Lenovo, IBM And Users

Posted on | by admin

The Lenovo purchase of IBM’s low-end x86 server business closed about a month ago. Now that all the smoke has cleared, it’s time to examine a few of the angles about why the sale went down, what it delivers to both Lenovo and IBM, and how it affects current users of IBM-branded x86 equipment.
First, the easy question: Why the sale?
Think back to 2005 when Lenovo bought IBM’s PC business. Lenovo instantly became the third-largest PC supplier in the world and is now the largest (ahead of HP and Dell, based on unit sales). The ThinkPad that Lenovo bought from IBM is the most successful and most durable everyman’s laptop in the word, and it continues to endure with top and near-top worldwide marketshares.
Lenovo wants to replicate that success with its purchase of IBM’s everyman server technology. And when the deal closed, and Lenovo finally became the owner of IBM’s profitable x86 server business, Lenovo immediately went from 6th to 3rd in marketshare in the x86 market (behind, yep, HP and Dell).
Sure, the x86 stuff is pretty unsexy. It’s a commodity. Sort of like Lego blocks. But the historic low cost of the product means that x86 stuff is still a major core infrastructure component for red-hot market segments like big data and cloud deployments. And remember that Lenovo will also acquire Motorola Mobility – the smartphone business that Google bought from Motorola in 2011 – by the end of the year. Mobile data’s one of the main drivers of the growth in large-scale commodity-server deployment. So it’s a proper marriage for Lenovo.
For reference, here’s the formal list of the x86 product that Lenovo bought from IBM:

  • System x racks and towers
  • x86 BladeCenter
  • x86 Flex System blade servers and integrated systems
  • Associated software, switching and maintenance operations

What does the sale deliver to both companies? For IBM, it allows Big Blue to continue to divest itself of commodity-hardware manufacturing and to continue its trend of crafting strategic partnerships with hardware manufacturers. Lenovo’s a big partner, but don’t forget IBM’s historic alliance with Apple, announced in July. There’s a different type of hardware integration happening right now, where workplace functionality and process is no longer desktop-specific. IBM has a lot to gain by selling a solid hardware business like the x86 line to Lenovo, because Lenovo can deliver legendary efficiency and scalability to gain more share for the servers and thus benefit IBM process software and platforms far into the future.
Does anybody really think IBM should still be making and selling PCs? Ask that same question about low-grade servers 2 years from now.
But the question looms: Where does all this leave current IBM x86 customers? Not much should change, according to both Lenovo and IBM. Former IBM server chief Adalio Sanchez – who led the x86 server business at IBM – is now senior vice-president of enterprise systems, reporting to Gerry Smith, Lenovo’s president for the North America region.
There’s talk that the entire x86 business might suddenly be more approachable – both from an IBM and Lenovo standpoint. There’s also speculation, likely grounded in truths, that strong incentives will emerge to align Lenovo PC users with x86 servers. That’s a bit of good news for firms and customers who want incentives to scale and align at the same time.

IBM WAS Enhancements Deliver Internet-Scale Clustering For Applications

Posted on | by admin

IBM recently announced enhancements to its WebSphere Application Server (IBM WAS) version 8.5.5 that deliver more functionality and services to the Liberty and full profiles. The enhancements are geared toward both development and production environments and are said to provide “significant enhancements in terms of developer experience and high-end resiliency.”
The features can largely be installed optionally from the WebSphere Liberty Repository and used in conjunction with features previously available and active.
Developers now have new programming models and tools. The result: A better developer climate that should result in a more rapid pace of application deployments. Administrators and businesses can leverage new Intelligent Management and security features to lower the administrative overhead of managing, scaling, and securing servers.
WAS in general is gearing itself more and more toward cloud and mobile development and deployment, hence the rollout of these new features.
Specific enhancements to WebSphere Liberty include:

  • Java EE 7-compliant programming model support for WebSockets 1.0 (JSR 356) and Servlet 3.1 (JSR 340) to enrich applications with responsive dynamic content
  • Additional Java EE 7 components in support of APIs for processing JSON (JavaScript] Object Notation) data (JSR 353) and Concurrency utilities (JSR 236)
  • Auto-scaling capabilities to dynamically adjust the number of Java virtual machines (JVMs) that are based on workload and auto-routing to intelligently manage your workload
  • Improved operational efficiency of large-scale, clustered deployments of tens of thousands of Java virtual machines (JVMs) in a Liberty Collective
  • Configurable, global Web Service handlers for extending and customizing payloads to Web Service applications
  • REST connector for non-Java clients to extend client access to Java Management Extensions (JMX) administration infrastructure through a RESTful API.
  • Simplified configuration processing for feature developers to enable customization of WebSphere Application Server Liberty profile capabilities
  • Enhancement to the distributed security model using OpenID and OpenID Connect to simplify the task of authenticating users across multiple trust domains
  • Enhancement to WebSphere Liberty Administrative Center for usability and management of large collectives of application servers
  • Enhancement to WebSphere Application Server Migration Toolkit – Liberty Tech
  • Preview includes new binary scanning capability to quickly evaluate applications for rapid deployment on WebSphere Liberty.

TxMQ is an IBM Premier Business Partner and we specialize in WebSphere. For additional information about IBM WAS and all WebSphere-related matters, contact president Chuck Fried: 716-636-0070 x222, chuck@TxMQ.com.
TxMQ recently introduced its MQ Capacity Planner – a new solution developed for performance-metrics analysis of enterprise-wide WebSphere MQ (now IBM MQ) infrastructure. TxMQ’s innovative technology enables MQ administrators to measure usage and capacity of an entire MQ infrastructure with one comprehensive tool. Visit our MQ Capacity Planner product page.