Skip to Main Content

This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace App Connect
Created by Guest
Created on Mar 2, 2022

Current documentation of internal services in ACE container architecture

Containerized ACE installations are, of course, composed of microservices. The dependencies between these microservices are not obvious to the customer's eye. This results in confusion about the impact of changes. IBM makes efforts to have all the dependencies resolved automatically; but that cleverness backfires when there is a gap, because the internal infrastructure is so opaque.

Documenting the purpose of the internal features would help orient the customer, assist them in understanding that, if my problem is -here-, it's possible that microservice -thus- is implicated.

Here is the specific experience I had that led to this idea:

We had a problem whose resolution eventually reqired the shipping of a patch.

Applying the patch caused a restart of some of the services, but not of all of them. This seemed reasonable; only the things that needed to be cycled, should be. Microservices FTW.

But the map of what needed to be recycled was incomplete, and the behavior change that was the intent of the patch did not happen. In the event, it was the presence of an option in the catalog of connectors I could configure.

Here's the key: I had no sense of where that list of options came from, no basis for understanding which parts of the system might, in malfunction, have contributed to the list. I was flying blind, all I could do was turn back to support and say "It no work!".

If I knew that the 'cas' was the 'connector auth service', there would have been a snowball's chance in warm places that I could have determined that a problem with the list of connections might be related to it.

I recognize that maintaining documentation for a fast-moving product is a challenge. But I claim it is -more- important that you be transparent in that case, not less. If you in fact have rapidly evolving internal architecture, you are necessarily invalidating whatever cargo-cult knowledge your customers have accumulated about system behavior. If you invalidate that experience and fail to tell them, it's a problem.

The microservice architecture of your app is open to inspection by your users. You can't hide it from them, so avoiding documentation because it might change doesn't really win you anything. Seems to me you just need lots of versions of the docs, which your site seems to be getting better and better at doing.

Idea priority Medium
  • Guest
    Mar 15, 2022

    Thanks for your consideration. I agree that having this information
    in the hands of support, to be imparted at need, would have avoided the
    initial problem I encountered.

    - Allen S. Rout

  • Admin
    Ben Thompson
    Mar 15, 2022

    RFE Review. Thank you for taking the time to submit this idea for enhancement but unfortunately on this occasion we do not intend to take this idea forward. We appreciate the feedback and explanation of the situation you ended up in, and we realise that it can be frustrating for our users when parts of our internal architecture are exposed without clear documentation. Your submission caused us a deep discussion between Level 3 service, architecture and product management weighing up the pros and cons of greater documentation of "internals" which could rapidly become out of date but in conflict might offer value to deeply technical users in the interim. Having gone back and forth on the topic we are reluctantly closing the suggestion on the grounds that the "right" thing to have done in this instance was to provide you correct and clear guidance about which components required recycling. Having our users "guess" at potential other things to try in order to get things to work based on internals poking up through error messages could in some circumstances lead to making problems worse or harder to track down, so we're keen to maintain the position of only documenting permanent externals of the product. In the spirit of as much openness as possible on this topic, I'm also including a picture below which provides a view of some of the microservices underpinning the product which we've used on occasion in external conference presentations describing some of our architectural approaches. We debated whether a diagram like this could have been placed in to docs in response to this request but given that to provide value we would need to go significantly deeper and show a sequence of interactions between components and we really felt this is taking us in an uncomfortable direction for future maintenance and freedom of movement.