Modeling application dependencies

 

One of the assets that you would expect to find in any enterprise is an inventory of all of the applications developed/bought by the enterprise as well as the cross dependencies between those applications. Although it sounds reasonable most of the enterprises that I saw have some inventory of their applications but nothing (written) about cross relations between applications. Usually each application manager had the map of his application(s) in his head, but you can’t find all the dependencies in one place.

Although it’s pretty obvious what are the drawbacks of this common approach, I want to mention the top three most common issue that an IT organization might experience in a absence of such data (application cross dependencies).

1)      Unstable production environment

2)      waste of time and resources

3)      lack in planning and estimations (of IT projects)

What to collect and model?

Collection can start from high level to low level of details. Usually there are three levels of complexity. Collection of application (and their dependencies), application’s component (as well as dependencies) and collection of all the interfaces exposed by each application components.  I tend to start my work from the high level approach for two reasons. It takes less time and efforts, while it enables me to show the advantage of having this data.  

For the application dependencies I’m always collect all the IT assets that a given application is depend on. That list includes other applications, Databases, Technologies and Servers (usually for C/S apps). When collecting and modeling dependencies between applications I also collect the type of dependencies. My type of application dependencies include: COM/EJB (tightly coupled)  , Web service, HTTP (passing parameters), routing (HTTP, in house interfaces to navigate from legacy systems [Main Frame, AS/400] to open systems and vice versa), using of Queue, File transfer, Direct access to the other app database and copy of data (duplication of data management).

For collection application attributes I’m following the minimize approach and I’m focusing on attributes that are necessary for my work. Usually this list of attributes contains (Unique number, Name, Description, IT owner, List of users, DRP level, Application architecture (C/S, WEB ,MF ,etc’), Develop language, transactions per day, Version as well as all of the mentioned dependencies above.

How do I do it?

If I have an existing application catalogue, I’m starting for it. If not I’m doing the work by following a list of IT workers. Taking in account that there are different points of views (especially for dependencies) I’m doing my work following this sequence:

1)      Meeting with the application owner and modeling all of his input as one view.

2)      If one application relation is mentioned in other application gathering meeting, but it wasn’t mentioned previously, I depict this relation just in the view of the guy who mentions this dependency. In the end of my work I have different views of different owners, with collisions that need to be resolved

3)      Using EA tool to get collisions for each owner and resolving collision by collision

 

In the end of the work I have an update application catalogue, views for each application owner with his application dependencies and one repository (EA tool) that holds all of the application relations. Usually I’m creating one view that depicts all of the application and their dependencies.

What can be done with this data?

Wait for next post :-)

 

1 Comment

Comments have been disabled for this content.