views:

680

answers:

7

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.

+2  A: 

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.

smink
+2  A: 

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.

Gulzar
+1  A: 

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'.

Yaba
In my particular case, Many means over 20 web and desktop application over a dozen servers.
GateKiller
Well, in that case the Universal CMDB would be way too expensive for you.
Yaba
+2  A: 

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.

Dustin
+2  A: 

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 :)

Allan Mertner
So will this software essentially scan my source code and decide which systems the application is dependent on?
GateKiller
No, it doesn't look at the source code but looks at running systems. From process lists, config files, network connections, etc, it infers the presence of things and their dependencies.
Allan Mertner
+2  A: 

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.

nedruod
A: 

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?

itrealist