Answers: <p>Considering your first paragraph, the organization you're describing is a highly siloed org, which is exactly what a DevOps organization tend to avoid.</p>
  
  <blockquote>
    <p>Considering this challenge, within DevOps there is a requirement to
    define and document all the components that constitute the various
    technology stacks within an IT environment. Traditionally this might
    have been accomplished with a propriety CMDB solution.</p>
  </blockquote>
  
  <p>What you're describing here could be ITIL, which is a management system requiring documentation and you mix it with the fact a DevOps team will usually define the underlying layers as code, as such it gets back to any development documentation with the caveats of <a href="https://www.scrumalliance.org/community/articles/2013/august/the-code-is-the-documentation" rel="noreferrer">Code is Documentation</a> often seen in Scrum methodology for an agile methodology of development (quick and short iterations aiming at minimal working solution at end of the iteration)</p>
  
  <p>Disclaimer for the rest of this answer: I know more of chef and inspec and that's why I take them as exemple here; but they are not the only tools existing on the market, I won't open a debate on them as the better one is the one you're more comfortable with.</p>
  
  <p>As such the rest of the question is a little biased and I, personally, didn't encounter an organization documenting the layer relation you describe more than the infrastructure as code and configuration management system code documentation. (Again, this doesn't mean no-one does it, I just never heard of it).<br>
  To illustrate from my company in a chef environment, an application cookbook will declare its dependencies (tomcat, jboss, nginx/php and on which OS, needed mount points for some shared datas and its DB schema name mostly) and expose its services URIs to be consumed by chef for other applications configuration, this sound like defining your 'Finance System' and the documentation for it is on this application cookbook README, with some more files if really needed.</p>
  
  <p>Configuration management systems usually have a central reporting place, "chef-server" for datas an "manage UI" for presentation in chef world "ansible tower" for ansible world to name two of them, but they usually aim more at giving an oversight of the overall managed system than graphing the dependencies. </p>
  
  <p>That said, for chef, the chef-server also act as a CMDB you can query with various tools (it return JSON datas from HTTP requests), the inter applications dependencies can be expressed in various way and there's no 'out of the box' method, each company will have its own way to declare them in the system for configuration purposes and as such you may leverage this to build your graph, but that's on your side.</p>
  
  <p>In an infrastructure as code point of view, the infrastructure needs would be kept with the application, it is still the application who know what it needs under as middle-ware, which OS, with which locale, what are other services dependencies and what services this application offer).</p>
  
  <p>Last thing I can think of if you want to manage those dependencies for documentation only are tools like <a href="http://glpi-project.org/" rel="noreferrer">glpi</a> which is mainly a CMDB and a ticketing system, it takes advantage of documenting assets and their relation to be able to tell what is impacted when you open a ticket saying an application is down. coupled with ng-inventory it allows to query system states and as such can fulfill your query for patch needs, but in my opinion this is an audit system task, like could do inspect integrated within a chef run for exemple, as the next phase would be to fix the outdated systems by updating/patching them.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-25T12:53:50.550Z
Answers: 2017-08-25T12:53:50.550Z
Answers: Tensibai
Body: <p>Working for a large company with over 500 IT staff and over a 1,000 servers, with each server running its own business applications, we have a tremendous information and co-ordination challenge in knowing which IT staff member to contact for which server. The problem of co-ordination is compounded with different IT staff being responsible for different layers of the IT stack. E.g., there are different teams who are responsible for hardware, virtualization, operating systems, application servers and the applications themselves.</p>
  
  <p>Considering this challenge, within DevOps there is a requirement to define and document all the components that constitute the various technology stacks within an IT environment. Traditionally this might have been accomplished with a propriety CMDB solution.</p>
  
  <p>I've investigated typical CMDB solutions such as <a href="http://www.bmcsoftware.co.za/it-solutions/atrium-cmdb.html" rel="noreferrer">BMC Atrium</a> and others for this purpose, the problem however is that they stop at the level of documenting IT assets themselves, at a high level, as per the ITIL framework, but to do not address documentation of the IT Technology Stack in detail. I have also investigated tools such as <a href="https://puppet.com/" rel="noreferrer">Puppet</a>, <a href="https://www.ansible.com/" rel="noreferrer">Ansible</a> and <a href="https://saltstack.com/" rel="noreferrer">Salt</a>, but these tools focus more on software deployment and configuration, and not on the people co-ordination around software.</p>
  
  <p>A workable solution for example, would define the various concepts, along with the key attributes important to these concepts:</p>
  
  <ul>
  <li>Hardware</li>
  <li>Virtualisation</li>
  <li>Operating Systems</li>
  <li>Application servers</li>
  <li>Applications</li>
  </ul>
  
  <p>These concepts would then be associated with one another in terms of their relationships in order to form solutions. E.g., an application would depend on an application server, which would depend on an operating system, etc., Together this solution would be defined at the "Finance System". Having defined a system, all the metadata associated with these systems would be captured in order to facilitate co-ordination for each layer in the stack. I.e. the co-ordination of the technical support staff for each layer.</p>
  
  <p>The purpose of such a solution would to do various queries against technology stacks, such as:</p>
  
  <ul>
  <li>To determine who supports which components</li>
  <li>Which components are out of date</li>
  <li>Which components need to be patched</li>
  </ul>
  
  <p>With this in mind, what open source tools exist to define all the components of an IT technology stack, including their relationship to one another, in a graph database such as Neo4J?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-08-21T21:35:01.730Z
Comments: What is the size of the organization in terms of systems, personnel, teams etc.?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2017-08-22T07:46:27.310Z
Comments: To give more insight on the reasons for closing, there's too much question here, part of it is about CMDB and the other points are about audit and compliance. There's no silver bullet for this and this highly depend on your actual environment and what you're using. Do you use a configuration manager? Did you look around and didn't find any tool fitting your needs? As is this question is a poll for advice and everyone will have its preferred solution, that's not a good fit for this site, try to have a look at existing tools and to ask something more specific once done.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-08-25T09:16:00.797Z
Comments: this may sound weird but could also a more general but customizable enterprise warehousing solution do as well?
Comments: Ta Mu
Comments: CC BY-SA 3.0
Comments: 2017-08-25T12:23:58.570Z
Comments: Thanks and congrats for the edit, that's a much more answerable question now. I still don't get the urge to have a graph database under it (that's not necessary) but I assume this can be omitted if there's a correct answer.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-08-26T15:26:46.273Z
Comments: @J. Doe An enterprise warehousing solution might work, but are there open source solutions that would solve such a problem. Believe it or not, we have a plethora of tools, none of which are actually able to address this issue. On the server management side we use BMC ADDM, but the key short coming of this tool is that it is server-centric, rather than application-centric. As a consequence when one server hosts many applications there is no easy way to associate multiple application owners because only association at the server level is catered for.
Comments: Grant Durr
Comments: CC BY-SA 3.0
Comments: 2017-08-26T15:32:34.090Z
Comments: @Tensibai Thank you. So the requirement for open source would be to find a solution that could be tweaked assuming that it would not satisfy our requirements 100%. The thinking behind including a graph database into the requirement is that boiled down the key problem is one of individual nodes (with metadata) and their relationship to one another. Graph databases lend themselves to A depends on B depends on C type relationships, and therefore I thought it would be a good fit.
Comments: Grant Durr
Comments: CC BY-SA 3.0
Comments: 2017-08-28T09:16:54.407Z
Comments: @GrantDurr by using the "enterprise" word I did not want to exclude open source solution, rather to point the scalability of a solution. So, an example of an OSS ERP could be ADempiere, or?
Comments: Ta Mu
Tags: <automation><toolchain><dependency-management><open-source>
Title: What is recommended to document an IT technology stack, including their relationship to one another, in a graph database?
UserDisplayName: Grant Durr
ThreadText: # What is recommended to document an IT technology stack, including their relationship to one another, in a graph database?
  
  (Asked by: username_0 on 2017-08-21)
  
  Working for a large company with over 500 IT staff and over a 1,000 servers, with each server running its own business applications, we have a tremendous information and co-ordination challenge in knowing which IT staff member to contact for which server. The problem of co-ordination is compounded with different IT staff being responsible for different layers of the IT stack. E.g., there are different teams who are responsible for hardware, virtualization, operating systems, application servers and the applications themselves.
  
  Considering this challenge, within DevOps there is a requirement to define and document all the components that constitute the various technology stacks within an IT environment. Traditionally this might have been accomplished with a propriety CMDB solution.
  
  I've investigated typical CMDB solutions such as [BMC Atrium](http://www.bmcsoftware.co.za/it-solutions/atrium-cmdb.html) and others for this purpose, the problem however is that they stop at the level of documenting IT assets themselves, at a high level, as per the ITIL framework, but to do not address documentation of the IT Technology Stack in detail. I have also investigated tools such as [Puppet](https://puppet.com/), [Ansible](https://www.ansible.com/) and [Salt](https://saltstack.com/), but these tools focus more on software deployment and configuration, and not on the people co-ordination around software.
  
  A workable solution for example, would define the various concepts, along with the key attributes important to these concepts:
  
  * Hardware
  * Virtualisation
  * Operating Systems
  * Application servers
  * Applications
  
  These concepts would then be associated with one another in terms of their relationships in order to form solutions. E.g., an application would depend on an application server, which would depend on an operating system, etc., Together this solution would be defined at the "Finance System". Having defined a system, all the metadata associated with these systems would be captured in order to facilitate co-ordination for each layer in the stack. I.e. the co-ordination of the technical support staff for each layer.
  
  The purpose of such a solution would to do various queries against technology stacks, such as:
  
  * To determine who supports which components
  * Which components are out of date
  * Which components need to be patched
  
  With this in mind, what open source tools exist to define all the components of an IT technology stack, including their relationship to one another, in a graph database such as Neo4J?
  
  **Tags:** automation, toolchain, dependency-management, open-source
  
  > **Comments:**
  > **username_1**: What is the size of the organization in terms of systems, personnel, teams etc.?  
  > **username_2**: To give more insight on the reasons for closing, there's too much question here, part of it is about CMDB and the other points are about audit and compliance. There's no silver bullet for this and this highly depend on your actual environment and what you're using. Do you use a configuration manager? Did you look around and didn't find any tool fitting your needs? As is this question is a poll for advice and everyone will have its preferred solution, that's not a good fit for this site, try to have a look at existing tools and to ask something more specific once done.  
  > **username_3**: this may sound weird but could also a more general but customizable enterprise warehousing solution do as well?  
  > **username_2**: Thanks and congrats for the edit, that's a much more answerable question now. I still don't get the urge to have a graph database under it (that's not necessary) but I assume this can be omitted if there's a correct answer.  
  > **username_0**: @J. Doe An enterprise warehousing solution might work, but are there open source solutions that would solve such a problem. Believe it or not, we have a plethora of tools, none of which are actually able to address this issue. On the server management side we use BMC ADDM, but the key short coming of this tool is that it is server-centric, rather than application-centric. As a consequence when one server hosts many applications there is no easy way to associate multiple application owners because only association at the server level is catered for.  
  > **username_0**: @username_2 Thank you. So the requirement for open source would be to find a solution that could be tweaked assuming that it would not satisfy our requirements 100%. The thinking behind including a graph database into the requirement is that boiled down the key problem is one of individual nodes (with metadata) and their relationship to one another. Graph databases lend themselves to A depends on B depends on C type relationships, and therefore I thought it would be a good fit.  
  > **username_3**: @username_0 by using the "enterprise" word I did not want to exclude open source solution, rather to point the scalability of a solution. So, an example of an OSS ERP could be ADempiere, or?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-08-25. Score: 5
  
  Considering your first paragraph, the organization you're describing is a highly siloed org, which is exactly what a DevOps organization tend to avoid.
  
  > Considering this challenge, within DevOps there is a requirement to
  > define and document all the components that constitute the various
  > technology stacks within an IT environment. Traditionally this might
  > have been accomplished with a propriety CMDB solution.
  
  What you're describing here could be ITIL, which is a management system requiring documentation and you mix it with the fact a DevOps team will usually define the underlying layers as code, as such it gets back to any development documentation with the caveats of [Code is Documentation](https://www.scrumalliance.org/community/articles/2013/august/the-code-is-the-documentation) often seen in Scrum methodology for an agile methodology of development (quick and short iterations aiming at minimal working solution at end of the iteration)
  
  Disclaimer for the rest of this answer: I know more of chef and inspec and that's why I take them as exemple here; but they are not the only tools existing on the market, I won't open a debate on them as the better one is the one you're more comfortable with.
  
  As such the rest of the question is a little biased and I, personally, didn't encounter an organization documenting the layer relation you describe more than the infrastructure as code and configuration management system code documentation. (Again, this doesn't mean no-one does it, I just never heard of it).  
  To illustrate from my company in a chef environment, an application cookbook will declare its dependencies (tomcat, jboss, nginx/php and on which OS, needed mount points for some shared datas and its DB schema name mostly) and expose its services URIs to be consumed by chef for other applications configuration, this sound like defining your 'Finance System' and the documentation for it is on this application cookbook README, with some more files if really needed.
  
  Configuration management systems usually have a central reporting place, "chef-server" for datas an "manage UI" for presentation in chef world "ansible tower" for ansible world to name two of them, but they usually aim more at giving an oversight of the overall managed system than graphing the dependencies.
  
  That said, for chef, the chef-server also act as a CMDB you can query with various tools (it return JSON datas from HTTP requests), the inter applications dependencies can be expressed in various way and there's no 'out of the box' method, each company will have its own way to declare them in the system for configuration purposes and as such you may leverage this to build your graph, but that's on your side.
  
  In an infrastructure as code point of view, the infrastructure needs would be kept with the application, it is still the application who know what it needs under as middle-ware, which OS, with which locale, what are other services dependencies and what services this application offer).
  
  Last thing I can think of if you want to manage those dependencies for documentation only are tools like [glpi](http://glpi-project.org/) which is mainly a CMDB and a ticketing system, it takes advantage of documenting assets and their relation to be able to tell what is impacted when you open a ticket saying an application is down. coupled with ng-inventory it allows to query system states and as such can fulfill your query for patch needs, but in my opinion this is an audit system task, like could do inspect integrated within a chef run for exemple, as the next phase would be to fix the outdated systems by updating/patching them.
  
  
  ---
  
  