Scribd Logo
Importer

Bienvenue sur Scribd !

  • Application Dependency Mapping

    Transféré par

    Lady_Valtieri
    106 vues7 pages
    Dependency mapping gives us our first visualization of the complexity of the it environment we manage. Dependency mapping is a meta relationship between it objects. A needs B. We don't say why a needs B.

    Description originale:

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Formats disponibles

    PDF, TXT ou lisez en ligne sur Scribd

    Avez-vous trouvé ce document utile ?

    Ce contenu est-il inapproprié ?

    Signaler ce document
    Dependency mapping gives us our first visualization of the complexity of the it environment we manage. Dependency mapping is a meta relationship between it objects. A needs B. We don't say why a needs B.

    Droits d'auteur :

    Attribution Non-Commercial (BY-NC)
    Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
    Signaler comme contenu inapproprié
    106 vues7 pages

    Application Dependency Mapping

    Transféré par

    Lady_Valtieri
    Dependency mapping gives us our first visualization of the complexity of the it environment we manage. Dependency mapping is a meta relationship between it objects. A needs B. We don't say why a needs B.

    Droits d'auteur :

    Attribution Non-Commercial (BY-NC)
    Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
    Signaler comme contenu inapproprié
    sur 7
    [Search - Application Dependency Mapping Connecting Business Processes to IT Systems © Home © About Application Dependency Mapping Comments (0) By Daniel Evenson, April 7, 2011 5:50 pm One of the more popular goals of dependency mapping is to map out all your applications’ dependencies. I guess they don’t call it application dependency mapping for nothing! Certainly that’s not the only thing we do with dependency mapping but it’s a great place to start. Why? Because it gives us our first visualization of the complexity of the IT environment we manage. The results can be amazing at first, like a blind man gaining sight for the first time. See the following set for an example: fig Application Dependency Mapping Blueprint Why do dependency maps shed more light than the typical IT systems or network diagrams we've been using all along? Let's consider that for a moment. What is a typical IT systems diagram? I don’t think ther I’ve worked in IT for about 20 years, and still don’t understand half the works of art I see. I know I’m not alone. UML (Unified Modeling Language) is an effort to standardize IT modeling babel into a common pictorial language that we can all speak. But it appears to have jumped the shark-it’s overkill for most IT folks who are not in large professional development teams. is one, That’s where dependency mapping comes in. It’s ridiculously simple, but produces grand results. It’s a meta relationship between IT objects A needs 2B We don’t say why a aceds This is the secret to why this works so well; there’s danger in getting too detailed with the information you document, If you want to sce the big picture, you must stay high above the landscape. For example, pethaps your timekeeping app needs database tracker001, Maybe simekeeping writes data there. Maybe it reads data instead. Maybe one object just uses another, or hosts it. There can be many reasons for a dependency but by keeping most of that lower level information out of the dependency map, it keeps our model high-level and consistent. IT configurations are diverse, and difficult to model in part because innovation is constantly changing the archetypes we use to represent our systems. Fortunately, the notion of dependency between resources is timeless and relevant to everything from people to processes, to hardware and software. Tell me what you rely on, and who relies on you and I'll understand your job, your risks, and how you fit into the big picture, whether you are a person, a database, or a SaaS service. Model the needs and quickly move on. As you apply this documentation method across the board, your systems will come into focus. You'll see why some applications (or IT services) fail more than others. Why one costs more, or why one is so hard to shutdown, replace, upgrade, consolidate, explain, etc. In other words, the visual application dependency map supports much of the routine work we do in IT, whether we're troubleshooting a problem, moving datacenters, funding upgrades, or analyzing impact of natural disaster scenarios. If the dependency maps are indexed with references to each object in a map, you can use the maps from top-down or bottom-up. Did you just inherit responsibility to support a legacy app? Refer to the applications dependency map to gauge the work ahead. Planning hardware maintenance on a server? Look up that server in the index, and see what depends upon it. Hurricane expected in Tampa? Look up your dependencies upon Tampa, The value derived from dependency mapping your IT environment produces immediate visibility and understanding, but the best part is that it pays off over time if you make this sort of meta-documentation a central artifact of your operations. By maintaining and using such models, you re-enforce attention on tracking your resources and their critical dependencies, reducing risks that an obscure dependency will catch you off guard when something fails. Having worked for years as a Unix consultant, I sure wished more of my customers had dependency maps available before I dove into many uncertain projects booby trapped with dangerous, unseen dependencies. But it was that market need that drove the development of our Blueprints product which helps you build and use dependency maps. No matter how you do it, dependency mapping is a great starting point for gaining control of what you currently manage and establishes effective systems documentation for moving forward, Comments (0) Uncategorized, dependency mapping | ‘y, application dependency mapping Dependency Maps are not Dataflow Diagrams Comments (0) By Daniel Evenson, July 28, 2010 1:29 pm In this post I'd like to go over a point made in a previous post, that dependency maps are not dataflow diagrams. The most typical IT diagram you find is some variation of the dataflow diagram. How information flows within a system is typically shown with something like the following, Here we see data flows as email is delivered. It’s routed from the external mail server, through the spam filter, and into the internal mail server. IT staff envision their world like this. Its a conceptual model that facilitates troubleshooting of email problems, But it doesn’t clearly show how email services might be impacted by various system failures. By adding dependency relations it will. Cesena) eral) sever sence = pelexange’ (externa) sence emai cener = ‘Spam-titer!* We sorsce We've added a high level object to represent all email service, and also two intermediate objects to distinguish internal functionality from external. We can now see that an external email server failure will impact only external email functionality leaving internal services unaffected. Lose the intemal email server however, and both external and intemal email functionality is lost. To simplify the diagram, remove the dataflow information to get the following: internal server (

    Vous aimerez peut-être aussi