How to track System Dependencies?

Question

Introduction

In my current organisation, we have many desktop and web applications all feeding into each other at some point. When looking after older applications or creating new applications, it's proving very difficult to try and remember which system rely on other systems in order to work. I'm not talking about software dependencies like DLL's and images, I'm talking about entire systems like a Finance system dependant on the HR system etc.

My Question

Which is the one best way to track how one entire system is dependant on another?

_{The answer can suggest either a method of doing the above, a software package or documentation techniques.}

_{In my particular case, Many means over 20 web and desktop application over a dozen servers.}

Answer 1

I would say to clearly state that on your architecture design document. There are some good tools for this like Enterprise Architect. This tool allows you to create diagrams using the UML standard for describing these dependencies in a clear and visual way.

Answer 2

The best source of information is usually found in Config files. This typically has the connection strings, web service urls etc which will give a good idea on the external dependencies.

Another technique is by using profiling or tracing and applying filters, we can easily track any external calls. Most of the cases, the dependency is in the database layer, and checking for linked servers and tracking their dependencies can unearth lots of info.

I am not sure if there is any automatic way to get this info especially if the systems are on multiple platforms. Lot of manual work will be involved to document all that.

Answer 3

This is the kind of application we produce at Tideway Systems, and which many large organizations use for just this purpose. You can use the product to discover your estate, and use the modeling capabilities to describe your business apps (which typically consist of more than one piece of software and span servers).

It sounds like you qualify to use the free Community Edition of Foundation, which you can use on up to 30 servers - just download it and check it out. Then let us know what you think please!

Disclaimer: I run the development group at Tideway. The product is very cool IMO, although I haven't written any of it myself directly :)

Answer 4

Turn off each machine one by one and see what breaks.. ;p

Seriously though, there is no simple answer to this question. With a collection of systems you could create a diagram showing the basic dependencies, but it wouldn't have a great deal of meaning unless you had an idea of what the dependency was. Usually your goal is to determine what you need to "revalidate" when you change another system, not which machines you can turn off at random. But that kind of information requires a large amount of detail and is hard to accumulate in the first place.

All this eventually ends up in a situation where you're systems are ahead of your automation. You'll never find a shrink wrapped automation tool that keeps up. On the other hand with so much detail necessary anything that can take care of half or even a third of the workload is going to be valuable.

Answer 5

This is a good question -- we struggle with this every time, it seems.

What we've tried to do over the last year or so is be "ruthless" on two things:

1. automation -- if you automate it and build/deploy often, then the automation process will tend to get things right most of the times (config settings, etc)

2. wiki, wiki, wiki -- we try to be hard-core on keeping the team and project wiki up-to-date.

Curious to see other responses.

Answer 6

Sounds like a job for an enterprise discovery that is automated as far as it can go. Depending on the size of your organization and the environment there are different solutions. For big landscapes you'll need a CMDB (Configuration Management Database) anyway. Products like HP Universal CMDB can discover and track dependencies in large scale environments.

E.g. it can discover the relations between a SAP system and it's related databases and the hosts on which the distributed systems are running and show you the dependencies. More important it can warn you in case some unauthorized changes are done to the actual environment.

So the answer depends on what you consider as 'many'.

Answer 7

Two sorts of problems involved:

a.) for those who want to know how to determine dependencies for each component

b.) for those who want to track inter-dependencies and their priorities in a system of components. (as in, which component gets installed into a test environment first etc...)

If what you have is a series of components, for each of which you know dependencies, and you want a dependency order for the entire list of components, you may find a Perl module called Algorithm::Dependency::Ordered to be of some value. There are other related modules that can work with databases records of components etc, or even simple file records. But a warning: I've had problems getting this to work.

Alternatively, a graphing tool may be of value.

Answer 8

This is function of a "Configuration Management" group. To get started, you'll have to talk to the "experts" at your company and create a map/graph of applications. Use graphviz/dot to generate a diagram, it won't be pretty, but it will give you a visual representation of the dependencies.

Here is an example:

digraph g {
 rankdir=LR;
 app1->app2->db1;
 app1->app3;
}

Hope this helps,

Answer 9

System dependency mapping is one thing. True environmental settings, uid's, passwords, impersonation settings, database names, and other data which change from development to qa to uat to production is the real challenge.

Who stores/remembers them all?

The developer knows not which production server(s) his application will reside on. He only documents the name of his development database, uid's, pwd's and describes his database tables, conn strings, etc.

Once it's checked into the code repository, and migrated to the QA environment, who is the keeper of the data required to update those config file with the proper values?

Again when migrated to QA and UAT, who?

Who's responsibility is it to inform the next migration group of what needs to be changed?

In my company, this is what causes us the most headache. By the time it gets approved by the internal change control process and a migration request is created to migrate the application into the production environment, all it takes is one config setting to be forgotten to ruin the whole implementation, and it happens all the time because clear lines of responsibility are not drawn (in my opnion).

Beyond responsibility I think is a central repository for this information.

ie. A system that stores all configuration settings for all projects/applications, and based on your "role" you can/can't see the actual values.

The developer finishes his build, and creates a migration request in the "system". The QA person receives notification that build ### is ready. The QA person logs into the "system" and retrieves the migration instructions. Now they clearly know what needs to be done, and they beging the code-check out and migration process.

Repeat for UAT and ultimately prod.

When someone builds this Migration system let me know, because THAT will help many people.

Maybe I'll build it myself... Who wants to contract me?

Answer 10

I was new to a job, and it was suggested as a first task that I go identify the system dependencies. It turns out that what my boss meant was to go talk to people - that way I would learn who was who. I thought my boss wanted me to write a computer program to do that. And so I did. My assumption was that if a program was a client of another program (a service or a server), then netstat -pant and netstat -panu then grep for ESTABLISHED would give you that. You can identify the services by grepping the output for LISTENING.

This is only a partial solution. Yes, it tells you what applications talk to which applications, but there are other dependencies. So, for example, some applications use DNS to find their servers, while others are hard coded or in configuration files. Anything that uses TCP or UDP is dependent on IP. In most places, IP is dependent on ARP and either Ethernet or WiFi. Anything dependent on a service on another LAN is dependent on at least one router.

If you have a load balancer or some sort of cluster, then the problem becomes more interesting. If I a service that comes out of a load balancer, and either "real" server behind the firewall goes down, then the service is degraded but is still up.

It gets even more interesting because services (programs) depend on servers (hardware). Servers, in turn, depend on power and air conditioning.

So as my thinking spiraled out of control, things got more horribly complicated, and I thought about creating a domain specific language (DSL) to capture all of these dependencies. I thought that, for example, server_1, server_3, and server_5 are on power phase 1; server_2, server_4 and server_6 are on power phase 2. Server_1, Server_3 and server_5 all fail at about the same time: probably phase 1 has failed. I still haven't quite figured that out. Obviously, the situation can be represented by a directed graph, I just haven't worked out the details.