Middleware/SOA documentation solution

[Sinbad]

Right.
So I look after a stack which has probably 500 different integration components/processes running in it - providing comms between many source and target systems.
It's becoming quite onerous debugging issues when system A can't talk to system B because of whatever reason, given the sheer number of possible components that could be the issue.

SO I'm looking for a tool in which we can model each business or technical process, with drill-down ability into various touchpoints/interfaces to see where they run, whether they are in fact subprocesses, what THEIR touch points are, etc.
I can't be the first person with this issue... so does anyone have any ideas or suggestions please? It should be easily maintained as well, so that update of the "documentation" can be done without too much beating of developers required, before their code goes into production...

 

[semaphore]

Newrelic.

 

[Sinbad]

Not really looking for monitoring at this point. More documentation to point operations staff at where to look for the problem when "deal x didn't reach system y"

 

[Cheens]

Try Enterprise Architect.

 

[semaphore]

Try Enterprise Architect.

Yeah that would work. But at the end of the day the stack should be automatically reporting issues.

 

[Sinbad]

Yeah that would work. But at the end of the day the stack should be automatically reporting issues.

Baby steps

We do have exception management in place, but even so, sometimes it's hard to trace the fault. We're not talking resource/performance issues here, more like business exceptions, or something else that needs someone to eyeball a logfile or bounce a service. There is a LOT of legacy stuff here... rewriting it to conform to our new exception management service is not really an option.

Would also be needed for incident impact analysis - ie - if service X (example a date calculation service) goes down, what other processes use it and are likely to fail... etc...

 

[semaphore]

Baby steps

We do have exception management in place, but even so, sometimes it's hard to trace the fault. We're not talking resource/performance issues here, more like business exceptions, or something else that needs someone to eyeball a logfile or bounce a service. There is a LOT of legacy stuff here... rewriting it to conform to our new exception management service is not really an option.

Would also be needed for incident impact analysis - ie - if service X (example a date calculation service) goes down, what other processes use it and are likely to fail... etc...

Then EA might help, but its going to be a massive manual process to sketch it out and do the impact analysis. Perhaps it does it for you, i don't know.

 

[Sinbad]

Then EA might help, but its going to be a massive manual process to sketch it out and do the impact analysis. Perhaps it does it for you, i don't know.

I guess we need some kind of central SOA registry, and the tool needs to allow a process flow to "subscribe" to one of the services in the registry, etc...

 

[semaphore]

I guess we need some kind of central SOA registry, and the tool needs to allow a process flow to "subscribe" to one of the services in the registry, etc...

Our services send out heart beats to a central service, this service collates all the data for us. We have setup rules to determine that if x goes down it will slow down a,b,c,d,e,f,g,h. Some of our services are extremely time critical if they're down for more than 2minutes the business comes to a screaming halt. If its a catastrophic failure (i.e. server) a new server instance spools up and we reroute messages there.

 

[sn3rd]

CentraSite