Hi,
Looking at Hardware_instance it seems like the right place to hold info about specific deployed hardware. Some of that information which is useful to know is where the hardware situated and (in the case of desktop hardware), who it is assigned to.
Obviously in a lot of situations this information may be contained in a CMDB of some description, but I was wondering if it was worthwhile having the ability to hold this information in the Essential Architecture model as well. Particularly as up in the physical layer of the business model there is the ability to capture both Site and Actor, so it would seem like a logical extension to allow these to be linked to Technology hardware. Is it possible to do this at the moment? (I can't see where at the moment if it is) If not, is this something worth doing?
Regards
Michael
Linking Technology Hardware Instance to Actor & Site
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Hi Michael,
This is something that I spent quite some time working with an organisation doing. We built some synchronised integrations with their CMDB to bring in new hardware as it was discovered and over time Essential became the most accurate view of their physical landscape - in terms of the servers that they had and the software that was running on them.
So yes, definitely possible and I've personally spent quite some time doing this sort of thing.
The ideas behind the Physical Technology classes work like this:
A Technology Node is used to define an identifiable item on the network. Anything with an IP address for example, so this can be a physical or a virtual server. There are a number of Attributes that you can define for each node, e.g. IP Address, RAM, CPUs - whatever you need. Typically, you name the Node using its hostname or IP address if the hostname is not available.
A node can also be things like network devices and all that sort of thing and in the case of virtual servers, Technology Nodes can be contained in other Technology Nodes. (I've set up integration with VMWare configuration exports to import the host/guest setup to manage the correct containment in the past).
Technology_Nodes have the relationship to a Site (and remember that Sites can contain other Sites - I've used this to go right down to specific rooms in a building and you could even have a Site for a specific cabinet/desk) that tells you where to find it.
So, that's the node itself. We then 'deploy' Technology Instances to the node to describe more about the Node. A Technology Instance can be one of:
Infrastructure_Software_Instances define all the non-application software that is installed on the Technology Node, e.g. the Operating System, and database management systems, application servers, integration middleware and so on. Again, each of these is then deployed to the Technology Node. Additionally, the specific relationships - at the instance level - between this software on the node can be captured. e.g. that the database depends on the operating system or that the application server depends on the Java runtime, which itself depends on the operating system. Of course, depending on your technology deployment architecture, this software could depend on infrastructure software that is running on other Nodes and you can define these dependencies, too. e.g. that the database on Node 1 is dependent on the database on Node 2 as part of a cluster.
Application_Software_Instances are where the Application Layer of the architecture meets the Technology at the sharp end from the Application_Deployment class. These are used to represent the packages of application software that are deployed to a particular node. This might be a Java EAR that then depends on the application server instance that you've already deployed to the node.
As with the Infrastructure Instances, you can capture all the dependencies on infrastructure software, other application software on this or any other Technology Node, to accurately show how your physical technology architecture is set up. Note this each Application_Software_Instance represents a instance of a particular deployment of an application, e.g. an instance of the application software for the Production deployment of the application (as opposed to the Test or Development deployments, which would have their own instances, deployed to the Test or Development server Nodes).
Information_Store_Instances are used to capture specific instances of a store of Information that 'resides' in a particular instance of, e.g. a database server. So, this is Information_Store_X deployed into Oracle RAC on server ABC. As with the other Technology_Instances, you can define all the specific dependencies that this particular instance has on other Technology Instances that you might need to capture - e.g. the Information Store depends on Oracle and on an Enterprise Storage Array setup.
Hopefully, that gives you a taste of what's possible. Creating the deployments of the Application_Software and Information_Store instances is best done from the Application_Deployment and Information_Store end of things, respectively. It's really just a case of saying "create a new deployment of this on that Node".
The Infrastructure Software Instances can be a bit more fiddly but I found that the best way to do this is to start from a Technology Product Build, which defines a re-useable (possibly standard) technology architecture for particular purposes. These can be solution-by-solution but also, you might have things like "Standard Web Application Build" which could cover the Browser, Application Server, Database, Operating Systems (and even recommended hardware).
The Technology Product Build is a Logical View thing which has a Technology Product Architecture / Provider Architecture that describes (logically) all the infrastructure software products and relevant hardware and the logical dependencies between them.
To create the deployed Infrastructure Software Instances, select each Technology Provider on the architecture and open its specification. About half-way down that form is the 'Deployed Technology Instances' relationship. This is the best place to start creating your deployments as you can see the logical architecture to help you and keep track of what you've deployed. Driving it down from the logical 'plan' of the architecture really makes this process quite straightforward.
There are some examples of all this in the sample repository, which will hopefully make much of what I've described here clearer. If not, don't hesitate to post back.
Jonathan
This is something that I spent quite some time working with an organisation doing. We built some synchronised integrations with their CMDB to bring in new hardware as it was discovered and over time Essential became the most accurate view of their physical landscape - in terms of the servers that they had and the software that was running on them.
So yes, definitely possible and I've personally spent quite some time doing this sort of thing.
The ideas behind the Physical Technology classes work like this:
A Technology Node is used to define an identifiable item on the network. Anything with an IP address for example, so this can be a physical or a virtual server. There are a number of Attributes that you can define for each node, e.g. IP Address, RAM, CPUs - whatever you need. Typically, you name the Node using its hostname or IP address if the hostname is not available.
A node can also be things like network devices and all that sort of thing and in the case of virtual servers, Technology Nodes can be contained in other Technology Nodes. (I've set up integration with VMWare configuration exports to import the host/guest setup to manage the correct containment in the past).
Technology_Nodes have the relationship to a Site (and remember that Sites can contain other Sites - I've used this to go right down to specific rooms in a building and you could even have a Site for a specific cabinet/desk) that tells you where to find it.
So, that's the node itself. We then 'deploy' Technology Instances to the node to describe more about the Node. A Technology Instance can be one of:
- Hardware_Instance
- Infrastructure_Software_Instance
- Application_Software_Instance
- Information_Store_Instance
Infrastructure_Software_Instances define all the non-application software that is installed on the Technology Node, e.g. the Operating System, and database management systems, application servers, integration middleware and so on. Again, each of these is then deployed to the Technology Node. Additionally, the specific relationships - at the instance level - between this software on the node can be captured. e.g. that the database depends on the operating system or that the application server depends on the Java runtime, which itself depends on the operating system. Of course, depending on your technology deployment architecture, this software could depend on infrastructure software that is running on other Nodes and you can define these dependencies, too. e.g. that the database on Node 1 is dependent on the database on Node 2 as part of a cluster.
Application_Software_Instances are where the Application Layer of the architecture meets the Technology at the sharp end from the Application_Deployment class. These are used to represent the packages of application software that are deployed to a particular node. This might be a Java EAR that then depends on the application server instance that you've already deployed to the node.
As with the Infrastructure Instances, you can capture all the dependencies on infrastructure software, other application software on this or any other Technology Node, to accurately show how your physical technology architecture is set up. Note this each Application_Software_Instance represents a instance of a particular deployment of an application, e.g. an instance of the application software for the Production deployment of the application (as opposed to the Test or Development deployments, which would have their own instances, deployed to the Test or Development server Nodes).
Information_Store_Instances are used to capture specific instances of a store of Information that 'resides' in a particular instance of, e.g. a database server. So, this is Information_Store_X deployed into Oracle RAC on server ABC. As with the other Technology_Instances, you can define all the specific dependencies that this particular instance has on other Technology Instances that you might need to capture - e.g. the Information Store depends on Oracle and on an Enterprise Storage Array setup.
Hopefully, that gives you a taste of what's possible. Creating the deployments of the Application_Software and Information_Store instances is best done from the Application_Deployment and Information_Store end of things, respectively. It's really just a case of saying "create a new deployment of this on that Node".
The Infrastructure Software Instances can be a bit more fiddly but I found that the best way to do this is to start from a Technology Product Build, which defines a re-useable (possibly standard) technology architecture for particular purposes. These can be solution-by-solution but also, you might have things like "Standard Web Application Build" which could cover the Browser, Application Server, Database, Operating Systems (and even recommended hardware).
The Technology Product Build is a Logical View thing which has a Technology Product Architecture / Provider Architecture that describes (logically) all the infrastructure software products and relevant hardware and the logical dependencies between them.
To create the deployed Infrastructure Software Instances, select each Technology Provider on the architecture and open its specification. About half-way down that form is the 'Deployed Technology Instances' relationship. This is the best place to start creating your deployments as you can see the logical architecture to help you and keep track of what you've deployed. Driving it down from the logical 'plan' of the architecture really makes this process quite straightforward.
There are some examples of all this in the sample repository, which will hopefully make much of what I've described here clearer. If not, don't hesitate to post back.
Jonathan
Essential Project Team
