Method and system for a reference model for an enterprise architecture

Systems and methods for a reference model for the representation of an arbitrarily complex enterprise architecture are disclosed. These systems and methods provide a reference model composed of component types and relationship types useful in modeling an enterprise architecture. The reference model may be constructed according to a set of domains. A set of component types associated with each of these domains may be defined and relationship types defined for these component types. A data model of a particular enterprise architecture may then be instantiated using this reference model.

RELATED APPLICATIONS

This application is related to U.S. patent application Ser. Nos. 10/802,304, entitled “Method and System for A Generic Data Model” by Miller et al., filed on Mar. 17, 2004; 10/803,133, entitled “Method and System for Querying an Applied Data Model” by Miller et al., filed on Mar. 17, 2004 and 10/802,178, entitled “Method and System for Discovering Relationships” by Miller et al., filed on Mar. 17, 2004. All applications cited within this paragraph are assigned to the current assignee hereof and are fully incorporated herein by reference.

TECHNICAL FIELD OF THE INVENTION

The invention relates in general to data modeling, and more particularly, to a reference model for modeling an arbitrarily complex enterprise architecture.

BACKGROUND OF THE INVENTION

The world is comprised of a wide and varied assortment of environments and subsystems. Akin to the proverbial butterfly flapping its wings in China and causing a hurricane over Texas, miniscule changes to one part of an environment may have catastrophic ripple effects in a distant part of the same environment. To anticipate these effects, it is helpful to study the ramifications of a change before it occurs, and to study these ramifications it is useful to create a model of the environment. This model can then be used to discover the consequences of a change, and the combinatorial effects of multiple alterations to the environment. Additional benefits of such a model are rationalization of the technology portfolio, and assessment and management of various regulatory and business continuity risks.

However, because of the varied nature of their composition, many types of environments do not lend themselves to modeling. A microcosm of this problem occurs in many enterprise architectures. These enterprise architectures may be intended to have a wide variety of uses: disseminating information about goods and services offered through a site on the World Wide Web, achieving objectives related to a business concern, providing a programming infrastructure for development of software, or keeping track of sales and sales force information.

Consequently, these enterprise architectures grow organically, sewn together in a Frankenstinian manner from a variety of heterogeneous machines and applications. Predicting the effects of business initiatives process and organization, the interaction of application, infrastructure and data organization within an IT environment etc. on these enterprise architecture is almost an exercise in futility without some sort of model. However, modeling these types of enterprise architectures is a daunting prospect.

Typically, there are two approaches to creating models for these enterprise architectures. The first is to create a diagram or a spreadsheet based inventory of the items of interest. This approach is problematic, creating these models requires an in depth evaluation of an enterprise architecture and manual creation of the documents, and whole document retention systems must be kept in place to version and store the documents associated with these types of models. Additionally, changes to the enterprise architecture wreak havoc on these models. The effects from these changes must be manually traced through each of the diagrams, which are not only particularly prone to errors, but time consuming as well. Other problems with storing these models in documents include that there may be a large number of users who need to be able to access and modify these documents, and documents of this type don't lend themselves to concurrent modification, and that it is very difficult to cross-reference information across these documents.

The second approach, equally problematic, is to store items of interest within an enterprise architecture in a relational database. Models created with these relational database tables, however, are particularly susceptible to changes in the enterprise architecture itself. Adding layers, applications, dependencies, projects, geographical locations etc. to an enterprise architecture may require changes to the table schema implementing the model, which may in turn may entail revising all the SQL statements used to implement the database.

Thus, a need exists for methods and systems for a data model which can model an arbitrarily complex enterprise architecture, and which is easily extensible to allow the representation of any desired logical or physical entity and the associations and dependencies between these entities.

SUMMARY OF THE INVENTION

Systems and methods for a reference model for the modeling of an enterprise architecture are disclosed. These systems and methods may provide a reference model composed of a logically structured taxonomy of component types, relationship types and property types with which to create a data model. In addition, the cardinality of the relationships between the component types may be defined as a constraint on the model. The reference model may be based on logical or physical groupings or associations of entities within an enterprise architecture and provide the ability to capture the state of any enterprise architecture, represent this enterprise architecture, and dynamically accommodate changes to the environment with a minimum of impact on the model of the environment, the underlying data structures themselves or the way these data structures are stored and represented.

In one embodiment, the enterprise architecture is segmented into a set of domains, a set of component types is defined for each domain and a set of relationship types is defined.

In another embodiment, each set of component types comprises subtypes of a generic component.

In yet another embodiment, each set of component types comprises a domain component which is a subtype of the generic component and a parent of the other component types in the set.

In still another embodiment, the set of component types contains an abstract component type.

In other embodiments, the domain component is associated with properties characteristic of the domain.

In still other embodiments, the domains are determined based on empirical analysis of the enterprise architecture.

In yet other embodiments, the set of domains comprises process, initiative, organization, application, location, infrastructure, data and policy.

In some embodiments, the set of relationship types comprises intradomain and interdomain

DESCRIPTION OF PREFERRED EMBODIMENTS

The invention and the various features and advantageous details thereof are explained more fully with reference to the nonlimiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well known starting materials, processing techniques, components and equipment are omitted so as not to unnecessarily obscure the invention in detail. Skilled artisans should understand, however, that the detailed description and the specific examples, while disclosing preferred embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions or rearrangements within the scope of the underlying inventive concept(s) will become apparent to those skilled in the art after reading this disclosure.

A few terms are defined or clarified to aid in an understanding of the terms as used throughout the specification. The term “component” is intended to mean a representation of any definable, logical or physical entity. A component may have a group of properties. In an IT environment, an entity may be any portion of the environment desired to be represented, including hardware, such as a server or database, applications which may reside on one or more actual machines, virtual data repositories, firmware and the like. Many levels of abstraction are possible. For example, a network may be represented as a component, a subnetwork of that network may be represented as a component, a server on the subnetwork may also be represented as a component, an application running across that server and other servers may also be represented as a component, a table within that application may be represented as a component, etc.

The term “relationship” is intended to mean a representation of an association or dependency between two or more components. This association may be based on the property values of the components.

The term “set”, when used in the mathematical sense as in “a set of” is intended to mean a collection of zero or more elements.

The term “check” is intended to mean a determination whether a relationship is valid, or a determination regarding the value or validity of a property of a component. Checks may be associated with components or relationships. In some cases a check is a piece of software which may be associated with a relationship or component. A check may have an output event, such as an email or notification.

The term “property” is intended to mean a characteristic associated with a component or a relationship. This property may have a name and a value associated with it, and components of the same type may have different values for the same property.

The term “type” is intended to mean a category of a relationship or a component. All relationships or components of the same type will have the same properties, though each instance of a component or a relationship may have different values for those properties. For example, a component type named “ComputerType” may be defined, having the properties of “RAM” and “OSType”. Each instance of component type “ComputerType” will have the properties “RAM” and “OSType”, however in one instance the value of “RAM” may be 4 megabytes, while in another instance the value of “RAM” may be 8 megabytes.

The term “data model” is intended to mean a model for representing anything in the physical world, coupled with logic pertaining to that representation.

The term “reference model” is a structure or taxonomy of component types, relationship types, the cardinality constraints of those relationships or property types for use in modeling a particular environment to which the reference data model pertains.

The term “domain” refers to a grouping. This grouping may be according to any criteria, including a physical, logical or operational association. These groups may be abstract types with a set of common characteristics.

The term “subtype” is intended to mean a specialization of a particular type of component or relationship. For example, a component type “computer” may be defined with certain properties. A more specialized version of the “computer” type may be represented as a subtype of “computer” called “server computer”. The subtype “server computer” will inherit all the properties of its parent type “computer”. A subtype is also a type; consequently subtypes may themselves be parents of subtypes.

The term “enterprise architecture” is intended to mean the elements of an enterprise, the design of these elements, their relationships and how they support the objectives of that enterprise.

Before discussing embodiments of the present invention, a non-limiting, simple IT environment used in depicting embodiments and examples is briefly described. After reading this specification, skilled artisans will appreciate that many other more complicated environments may be utilized with embodiments of the present invention.

FIG. 1includes a diagram of a simple IT environment100. IT environment100includes a server computer110. Server computer110may comprise a central processing unit (“CPU”), a read-only memory (“ROM”), a random access memory (“RAM”), a hard drive (“HD”) or storage memory, and I/Os. ROM, RAM, HD and storage memory are exemplary forms of computer readable storage media. I/Os can include a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, etc.), or the like. Server computer110may also be executing an operating system as is commonly known in the art. Server computer110may have a set of attributes112, such as the type of operating system executing on server computer110, amount of RAM, amount of free storage space and the like.

IT environment100may further contain database server application120and web server application130. Database server application120and web server application130may have certain attributes122,132which pertain to their particular implementation. For example, each may utilize certain storage resources, have a certain filesystem structure, require a certain operating environment, and have a certain footprint. Other attributes will be readily apparent to those of ordinary skill in the art. Each of these software applications120,130may be executing on server computer110. Additionally each of the computers inFIG. 1may have more than one CPU, ROM, RAM, HD, I/O, or other hardware components. Note thatFIG. 1is a simplification of an exemplary hardware configuration. Many other alternative hardware configurations are possible and known to skilled artisans.

Attention is now directed to methods and systems for a reference model for the modeling of an enterprise architecture, and how this reference model may be utilized to represent an arbitrarily complex enterprise architecture. These systems and methods may provide a reference model composed of a logically structured taxonomy of component types, relationship types and property types with which to create a data model. An enterprise architecture may then be modeled utilizing component types, components, relationship types, relationships and properties based on this reference data model. The reference model (and structures instantiated from the reference model) may be based on logical or physical groupings or associations and provide the ability to capture the state of any enterprise architecture, represent this enterprise architecture, and dynamically accommodate changes to the environment with a minimum of impact on the model of the environment, the underlying data structures themselves or the way these data structures are stored and represented. Though various simple example environments will be used to demonstrate the power and flexibility of the reference data model, after reading this disclosure it will be apparent to those of ordinary skill in the art that a reference data model of this type may be utilized to model any arbitrarily complex enterprise architecture.

In an illustrative embodiment of the invention, the computer-executable instructions may be lines of assembly code or compiled C++, Java, or other language code. Other architectures may be used. Additionally, a computer program or its software components with such code may be embodied in more than one data processing system readable medium in more than one computer.

Turning now toFIG. 2, a graphical representation of a component data structure is presented. Component200is a generic component which may be used to represent a logical or physical entity within an environment. Component200may have a set of fields210which contain information relating to the entity associated with component200. Fields210may include a field for name220, description230, properties240and checks250. Various other fields210may be included to further define component200. Name field220may be used to particularly associate component220with a specific physical or logical entity. Description field230may further identify component200, associate component200with a particular entity, or allow component200to be associated with a particular component type (as explained below).

Property field240may be used to represent the attributes or characteristics of the physical or logical entity represented by component200, or with which component200is associated.

Property field240may be associated with one or more properties, a property may consist of a property name which may be associated with a value. This value in turn may correspond to an attribute of the physical or logical entity represented by component200. A property may be a string, boolean, decimal number, date/time, or an enumerated type, which describes the category of values a particular property may have. In one embodiment, a property may in turn be a data structure which has a name, a description, and a value. This data structure may then be given values based on an attribute of the entity represented by component200.

Component200may also be related to a set of checks250. A check may be a piece of logic which performs operations based on a certain set of conditions. These operations may consist of checking on the status of certain relationships associated with the component200(as described below), checking the status of certain properties240, and other operations which will be readily apparent. These pieces of logic may be configured to operate automatically at certain time intervals, or may be applied at any point according to a variety of different triggering conditions which will be apparent to one of ordinary skill in the art after reading this disclosure.

Referring briefly back toFIG. 1, component200may be used to represent any object in IT environment100. To represent server computer110, name field220may be set to “server1”, description230may be set to “server computer”, property field240may contain three properties “OSType”, “RAM”, and “FreeStorage”, which may be assigned the values corresponding to attributes112of server computer110, “Solaris”, “8 MB” and “6 MB” respectively.

Similarly, component200may represent database server120; name field220may be set to “DB1”, description230may be set to “database server application”, property field240may contain three properties “OSType”, “Footprint”, and “Listen Port”, which may be assigned the values corresponding to attributes122of database server120, “Solaris”, “12 MB” and “2100” respectively. As can be seen, component200may represent any entity, whether logical or physical equally well.

Turning now toFIG. 3, a graphic representation of a relationship is depicted. Relationship300may be used to represent an association or dependency between two or more components200. Relationship300may have a set of fields310which contain information pertinent to an association or dependency between two components. Fields310may include a field for name320, description330, property340, and checks350as described above with respect to component200. Name field320may be used to particularly associate relationship300with two or more physical or logical entities. In one embodiment, the name associated with name field320may be built programmatically based on the relationship type name and the names of the two components it is connecting. So, a “runs on” relationship type exists between components “app1” and “server1”, the relationship name may be built automatically as “app1runs on server1”. That way, if either of the components' names changes, the relationship name may automatically changes to reflect this. Description field230may further distinguish relationship300, associate relationship300with components, or allow relationship300to be associated with a particular relationship type (as explained below). Property field340may allow attributes of the relationships, dependencies between the relationships, or associations between the relationships, to be represented by a name and value pair. Checks350may contain one or more pieces of logic which perform operations based on certain set of conditions, as described above with respect to relationship300. In a particular embodiment, fields310include fields360,370to identify components200to which relationship300corresponds. Various other fields310may be included to further define relationship300. In one embodiment, a relationship may have cardinality, such that a relationship may only represent an association or dependency between particular types or particular number of components.

Returning for a moment toFIG. 1, relationship300may be used to represent any association between the logical or physical entities in IT environment100. Component200may be used to represent database server120and server computer110, as described above. Continuing with the above example, relationship300may be used to represent that database server120executes on server computer110. Description330may be set to “runs on”, property field340may contain a property “StartDate” which may be assigned the values corresponding to the date on which database server120began executing on server computer110. To identify the components associated by relationship300, FirstComponentID field360may be set to a name corresponding to server computer110, in this example “server1”; likewise, SecondComponentID field370may be associated with component200representing database server120. In one embodiment, row ids in a table are used to associate components with a relationship, thus, if a component is renamed relationships referencing this component do not have to be altered. As can be seen, relationship300may represent any association or dependency between any two or more logical or physical entities equally well.

However, as can be readily imagined, instantiation and definition of components and relationships for a complex environment may be a manually intensive process. To alleviate these concerns, in one embodiment, a typing system is included to allow the ability to define a hierarchy of component and relationship types which may serve as templates to instantiate components or relationships of these different types.

A hierarchy400of component types410,420,430is depicted inFIG. 4. Types410,420,430may provide different templates for instantiation of different components. Types,420,430may have additional fields depending on the intended use of a component instantiated from the type. A component may be instantiated from a type and values assigned to the fields of the component based upon the physical or logical entity represented by the component.

Generic component type410may have a set of fields as described above. These fields may include a name and description412, a set of properties414, and a set of checks416. A generic component may be instantiated from generic component type410, and used to represent an atomic entity. For example, in order to represent server computer110, a user may instantiate component200from generic component type410, name component200, define the list of properties pertinent to server computer110, give these properties values based on the attributes of server computer110, define checks pertinent to server computer110, etc. In this manner, component200can be created which represents server110accurately. However, representing a complex environment in this manner becomes labor intensive, as a component to represent each atomic entity within the environment may have to be created manually.

To remedy this problem, more specific component types may be defined which serve as templates to instantiate components which represent specific entities in an environment. For example, a computer component type420may be defined to serve as a template for components which represent computers. This computer component type420may contain properties424or checks426which are designed to represent a generic computer. A property within the set of properties424may contain a name and enumerated type corresponding to the values which that property may have. As expressed above, a property within the set of properties424may itself be a data structure; in this case a property may contain a name and a reference to a data structure. Examples of property names and their corresponding enumerated types are depicted in properties424of computer component type420. Properties424and checks426will be common to all components instantiated from computer component type420; in other words, all components instantiated from computer component type420will contain properties424and checks426of computer component type420. This computer component type420may be used to instantiate component200to represent a computer in an environment, this component's200properties can then be assigned values based on the attributes of the computer which component200is intended to represent.

FIG. 5is a depiction of component500which has been instantiated from computer component type420to represent server computer110. Component500has fields510corresponding to the fields defined by computer component type420, including properties504and checks506contained in the type definition of computer component type420. The values514of properties504of component500may correspond to characteristics or attributes112of server computer110. If server computer110has 8 megabytes of RAM, the property named “RAM” of component500may be set to 8. If the operating system implemented on web server is Solaris, the value of the “OSType” property in component500may be Solaris, etc. In this manner, component500models server computer110by representing attributes112of server computer110with the properties504of component500.

Returning now toFIG. 4, in many cases computers in an environment may perform a specialized function, such as server computer110. To represent these specialized machines, it may be desirable to have additional properties in the components representing these specialized machines which are not present in computer component type420. This discrepancy may be remedied manually; a component of type “computer” may be instantiated from computer component type420to represent server computer110, and any specialized properties desired, but not contained, in this component may be added. Again, however, this process quickly becomes manually intensive when many specialized machines are present.

In some embodiments, a component subtype may be defined with respect to a parent component type. This component subtype represents a specialized subgroup of the respective parent component type. A component instantiated from a component subtype may inherit all the properties and checks corresponding to its respective parent component type. Consequently, when component200is instantiated from a component subtype, component200contains all the properties and checks contained in the definition of the component subtype plus all the properties and checks contained in the definition of the parent component type.

For example, computer component type420may be defined to serve as a template for components which represent computers. This computer component type420will contain checks426or properties424which correspond to a generic computer, and will be common to all components instantiated from computer type420. A server computer component subtype430may be defined with respect to parent computer component type420. This definition may include only properties434and checks436specific to server computer component subtype430. Consequently, when a component is instantiated from server computer component subtype430this component will contain all the properties424,434and checks426,436contained in both the parent computer component type420and the server computer component subtype430. For example, if component200were instantiated from server computer component subtype430, component200would contain the properties named “OSType”, “RAM”, and “CPU” contained in parent computer component type420, and the property “FreeStorage” contained in server computer component subtype430. These properties may then be assigned values.

It will be apparent to those of ordinary skill in the art the recursive nature of this type/subtype correlation and the inheritance characteristics that accompany these correlations. For example, a subtype may be the parent type of a second subtype. In addition to containing the checks and properties defined in the second subtype, a component instantiated from the second subtype will contain the checks and properties defined in both the first subtype and the original parent. The power and flexibility of such a system will also be apparent, a component hierarchy specifically tailored to any environment can be defined from a generic component type.

As described above, relationships are used in tandem with components to model arbitrary systems and environments by representing an association or dependencies between two components. As will be readily apparent, the same reasoning that applies to components with respect to a hierarchy of types may be applied equally well to relationships. Manual instantiation of relationships may be time consuming if the representation of many dependencies or associations is necessary. Consequently, types and subtypes corresponding to a particular category of these dependencies or associations may also be defined for relationships, and relationships instantiated from these defined types and subtypes. Each relationship type may also have cardinality, such that a relationship instantiated from this relationship type may only represent an association or dependency between two particular component types or subtypes. For example, a “runs on” relationship type may be defined to exist between one component of type “application” and one component of type “server”.

All principles described with respect to types and subtypes in the context of components are equally applicable to relationships, including the principle of inheritance.

In one embodiment, a relationship may have cardinality, such that a relationship may only represent an association or dependency between particular types or particular number of components. For example, a “runs on” relationship type may be defined to only exist between one component of type “application” and one component of type “server”.

Moving on toFIG. 6, a representation600of using components and relationships to model a portion of IT environment inFIG. 1is depicted. Component610represents the physical entity server computer110and has properties with values corresponding to attributes112of server computer110. Components620and630represent logical entities database server120and web server130respectively. Properties of components620,630may have values corresponding with attributes122,132of database server120and web server130.

Database server120executes on server computer110. To represent this association, relationship640may be named “runs on”, FirstComponentID field360of relationship740may be linked to component620representing database server120, while SecondComponentID370may be linked with component610corresponding to server computer110, and properties of relationship640may be defined accordingly. In this manner, the fact that database server120executes on server computer110may be modeled by relationship640. Likewise, the fact that web server130also executes on server computer110may also be modeled. Relationship650, also of type “runs on”, may be instantiated, given properties, and associated with components610,630representing web server130and server computer110using FirstComponentID field360and SecondComponentID field370. This type of data model allows changes to an environment to be accommodated with a minimum of disturbance to the model of that environment. In particular embodiments, a blueprint may be used to contain the entire representation600of the IT environment.

Suppose that the IT environment depicted inFIG. 1is altered to the IT environment depicted inFIG. 7. IT environment100now includes second server computer140, with web server130executing on second server computer140. Server computer110, database server120, and web server130remain unaltered, with exactly the same attributes112,122,132. To represent the IT environment inFIG. 7minimal changes to the model represented inFIG. 6are necessary.

FIG. 8is a representation800of an application of embodiments of the data model to the IT environment depicted inFIG. 7. Component810, representing second server computer140, has been added to the model. Properties of component810have values corresponding to attributes142of second server computer140. Components610,620,630remain unaltered, as the entities which they represent remain unchanged. Relationship640also remains unaltered, as database server120still executes on server computer110. Relationship650, representing the association between web server130and the entity on which web server130executes, must be altered to accurately represent that web server130now executes on second server computer140. This alteration may be accomplished simply by changing SecondComponentID field370of relationship650to an association with component810representing server computer140. Relationship650now accurately depicts the association between web server130and second server computer140. As can be seen, changes to a particular environment can be easily accommodated by the data model with a minimum of change to the actual data structures which represent the environment.

Often times while modeling a particular environment logical divisions, layers or domains become apparent within that environment. These divisions or domains, which may become apparent through theoretical or empirical analysis, provide rational basis for a conceptual separation of various portions of a particular environment and therefore may serve as a solid foundation for constructing a reference model for that environment. A reference model may be defined by identifying a set of domains which suitably encompass the physical or logical entities of an environment. Components or component types with characteristic properties may be defined to represent each of these domains. Within these domains, hierarchies of component types and relationship types may then be defined which are designed to adequately represent the components and relationships of an arbitrary environment. This reference model can then be conveniently used to model multiple discrete instances of a type of environment, while still allowing the reference model to be extensible in response to any quirks, perturbations, or variations in a particular environment, without altering the underlying schema.

One glaring example of the usefulness of such approach occurs in the realm of enterprise architecture.FIG. 9represents a high level view of one particular set of domains which may encompass an enterprise architecture and may consequently be used as a baseline or guideline to further define a reference model for an enterprise architecture. Domains910,920,930,940,950,960and970may be conceptual or logical divisions which generically encompass any particular enterprise architecture990. A domain component type may be defined for each of domains910,920,930,940,950,960and970, and may contain properties characteristic of the domain for which the domain component type is defined. This domain component type may in turn be a subtype of a generic object or component type. Within each of these domains910,920,930,940,950,960and970this domain component type may be used to define additional component subtypes with properties pertaining to the realm of enterprise architecture990encompassed by the respective domain910,920,930,940,950,960and970to which the component type belongs. These component types may be abstract components, intended to organize the hierarchy of components. Relationship types may then be defined between the component types of the domain, these defined relationship types may be both intradomain and interdomain relationships. Collectively, the component types and relationship types associated with each of domains910,920,930,940,950,960and970serve as a framework for instantiating components and relationships to model an arbitrarily complex enterprise architecture990. In one particular embodiment, the component types associated with initiative domain910, organization domain920, process domain930, application domain940, infrastructure domain950, location domain960and data domain970are all subtypes of a generic component.

Initiative domain910may consist of component type and relationship type definitions that are intended to be used to instantiate components that represent business initiatives or objectives. Component types and subtypes belonging to initiative domain910may be instrumental in modeling projects in enterprise architecture990down to the individual task level.

FIG. 10represents one possible hierarchy of component types and relationship types associated with initiative domain910. This hierarchy of component types may provide different templates for representing initiatives within an enterprise architecture and for creating other component and relationship types which may be specifically tailored to an individual enterprise architecture. Component types1010,1020,1030,1040and1050may have different fields depending on the intended use of a component instantiated from the type. A component may be instantiated from a component type and values assigned to the fields of the component based upon the physical or logical entity represented by the component. Relationship types1012,1014may also be associated with component types1010,1020,1030,1040and1050and relationships instantiated from these relationship types1010,1012may then be used to represent an association between components. As mentioned before these relationships may be intradomain relationships, or interdomain relationships between component types which are subtypes of two different domains.

In one embodiment, “initiative domain” component1040is defined from generic component type1050, in turn “goal” component type1010, “project” component type1020, and “task” component type1030are defined from parent “initiative domain” component type1040. “Consists of” relationship type1014may be defined between “project” component type1020and “task” component type1030to represent a connection between a project in enterprise architecture990and the various tasks that may comprise that project. “Supported by” relationship type1012may be defined between “project” component type1020and “goal” component type1010to represent the connection between projects and goals related to that project that usually manifest in an enterprise architecture. Relationship types1012,1014may also be defined between component types1010,1020,1020,1040and1050in initiative domain910and component types1330,1420belonging to other domains. For example, an “affects” relationship type1016may be defined between “project” component type1020in initiative domain910and “application” component type1420belonging to application domain940, while a “supported by” relationship type1018may defined between “goal” component type1010in initiative domain910and “process” component type1330in process domain940. Other embodiments of component types and relationship types associated with initiative domain are explained more fully in Appendix A.

Suppose, now, that a project within enterprise architecture990is to release a product. This product release project is composed of a number of tasks associated with the product release including a build and a first customer shipment. The target date for the build is Sep. 7, 2004 and the target date for the first customer shipment and the product release is Mar. 7, 2005.

FIG. 11is a representation of an application of embodiments of initiative domain hierarchy1000depicted with respect toFIG. 10applied to the example described above. Component1120may be instantiated from the “project” component type1020and represent the product release initiative, while instantiated components1180,1190represent the tasks of a build and a first customer shipment, respectively. The product release goal date of Mar. 7, 2005 is represented by component1140, while the goal target date for the build of Sep. 7, 2004 is represented by component1150. The dependencies that exist between components1120,1140,1150,1180,1190are represented by relationships1110,1130,1160and1170.

Relationships1130,1170may be instantiated from “consists of” relationship type1014, indicating that project component1120depends on “task” components1130,1170representing the separate tasks of a build and a first customer shipment. “Project” component1120may be tied to “goal” components1140,1150by “supports” relationships1160,1170, indicating that the project of a product release is supported by the goal dates of Sep. 7, 2004 and Mar. 7, 2005.

Returning for a moment toFIG. 9, other domains920,930,940,950,960, and970may be implemented in a similar vein to initiative domain910.FIGS. 12-17represent various embodiments of hierarchies of component types and relationship types associated with domains920-970. Other embodiments for these domains are expounded upon in Appendix A, and still others embodiments, component and relationship types and subtypes will be apparent to those of skill in the art.

FIG. 12represents a hierarchy of component types and relationship types associated with organization domain920. “Organization domain” component type1210may be a subtype of generic component type950and be the basis for subtypes that represent people and organizations within enterprise architecture990. These subtypes may include “organization” component type1220, “business unit” component type1230, “function” component type1240and “role” component type1250. Relationship types between components associated with organization domain920include “supported by” relationship type1212, “administers” relationship type1214, “consists of” relationship type1216and “funded by” relationship type1218.

A hierarchy of component types and relationship types associated with process domain930is represented inFIG. 13. “Process domain” component type1310may be the basis for subtypes that represent business processes within enterprise architecture990. These subtypes may include “process step” component type1320, “process” component type1330and “process decision” component type1340. Relationship types between components associated with process domain930include “consists of” relationship type1312, “precedes” relationship type1314, “requires” relationship type1316and “funded by” relationship type1318.

Moving on,FIG. 14represents a hierarchy of component types and relationship types associated with application domain940. “Application domain” component type1410may be the basis for subtypes that represent application or modules of an application within enterprise architecture990. These subtypes may include “application” component type1420, “database server” component type1430and “commercial module” component type1440. Relationship types between components associated with application domain940include “administers” relationship type1412, “consists of” relationship type1414, “runs on” relationship type1416and “affects” relationship type1418.

FIG. 15represents a hierarchy of component types and relationship types associated with infrastructure domain950. “Infrastructure domain” component type1510may be the basis for subtypes that represent portions of an information technology environment within enterprise architecture990which is dedicated to infrastructure assets, such as physical hardware. These subtypes may include “computer” component type1520, “desktop” component type1530and “network” component type1540. Relationship types between component types associated with infrastructure domain950include “consists of” relationship type1512, “contains” relationship type1514, “runs on” relationship type1516and “located in” relationship type1518.

Looking now atFIG. 16, a hierarchy of component types and relationship types associated with location domain960is represented. “Location domain” component type1610may be the basis for subtypes that represent locations of various information technology entities within enterprise architecture990. These component subtypes may include “data center” component type1620, “geography” component type1630, region” component type1640and “country” component type1650. Relationship types between component types associated with infrastructure domain960include “consists of” relationship type1612and “located in” relationship type1614.

FIG. 17represents a hierarchy of component types and relationship types associated with data domain970. “Data domain” component type1710may be the basis for subtypes that represent information assets within an enterprise. These component subtypes may include “data base” component type1720, “data object” component type1730and “table” component type1740. Relationship types between component types associated with data domain970include “consists of” relationship type1712and “references” relationship type1714.

It is important to note that a reference model of the type depicted inFIGS. 10-17is almost infinitely extensible. Suppose, for instance, that after further analysis of enterprise architecture990it is determined that it is desirable to model the management structure of enterprise architecture990.FIG. 18represents a high level view of one embodiment of a group of domains910-980which may encompasses the management structure of enterprise architecture990and may consequently be used as a baseline to further define a reference model. These domains include domains910-970previously expounded upon above, and policy domain980intended to encompass a management structure of enterprise architecture990.

An embodiment of a hierarchy of component types and relationship types that may be associated with policy domain980is represented inFIG. 19. “Policy domain” component type1910may be the basis for subtypes that represent the plans, principles, obligations, agreements, contracts and requirements which guide the management of enterprise architecture990. These component subtypes may include “application plan” component type1920and “support agreement” component type1930. Relationship types between component types associated with policy domain980include “covers” relationship type1912and “instantiated” relationship type1914. In this manner, the management structure of enterprise architecture990may now be accommodated when creating a data model of an enterprise environment using a reference data model.

Note that not all of the domains, components, component types, relationships, relationship types, properties, or property types are necessary, that domains, components, component types, relationships, relationship types, properties, or property types may be added in addition to those illustrated. Additionally, the order in which each of the activities is listed is not necessarily the order in which they are performed. After reading this specification, a person of ordinary skill in the art will be capable of determining which domains, components, component types, relationships, relationship types, properties, or property types and orderings best suit any particular objective. For example, domains such as time and finance may be added to the domains described above.

APPENDIX A

This Appendix depicts an exemplary embodiment of a reference model for use in modeling arbitrarily complex enterprise architectures. In this Appendix, the properties and property categories for a component type are shown in a table. Only the non-inherited properties are shown. The table looks like this:

In this Appendix, relationship types are defined for each component type in a table following the property definitions. The relationship table will appear with a header as follows:

Relationship TypeLabelTarget Component Types

The Relationship Type identifies the name of a valid relationship type.

The Label identifies the direction-sensitive phrase that describes how this component type is related to the Target Component Type. Note that the same relationship has a different Label when viewed from the Target Component Type.

The TargetComponentTypes refers to the valid destination of the relationship. Unless otherwise stated, the relationship may be associated with all subtypes of the specified Target Component Type.

In the following two tables, a relationship, of type Runs On, is declared to be valid between a Module and a Server.

Module Relationship Types

When looking at a Server within TBS during presentation time, the user will be presented with the text:“Server x Hosts Module y.”

However, when looking at a Module during presentation time, the user will be presented with the text:“Module y Runs On Server x.”
The Reference Model

The example reference model is engineered for modeling entities found within an enterprise IT environment. 8 major domains of entities may be utilized:Initiative DomainOrganization DomainProcess DomainApplication DomainInfrastructure DomainLocation DomainData DomainPolicy Domain

Collectively, these domains encompass a whole corporate IT environment. Within each domain, the TRM provides further classification by identifying a hierarchy of types, and the relationships between them.

The reference model also provides the means by which cross-domain relationships can be represented. This is arguably one of the most important aspects of the TRM. It is through these cross-domain associations that alignments between IT operational resources and strategic initiatives can be formed.

Component Types

Generic Component

The Generic Component type is an abstract component type from which all types may be derived. Each component type in the model is ultimately a descendant of this type and therefore inherits the properties defined in the Generic Component.

Generally, no component of this type should ever be created. Instead, choose one of the component types identified within one of the domains.

TABLE 1Generic Component PropertiesNameDescriptionTypeCommentsThese are comments that are not necessarily aNotepart of the component's description.TrouxTRM VersionThis property is reserved for use by Troux. Itstringcontains the version of the TRM that createdthe instance of the component type.
Initiative Domain

The Initiative Domain is the abstract base for component types representing the entities that describe business initiatives. The component types in this domain are used to model projects down to the task level.

Goal is a subtype of Initiative Domain.

This component type describes a goal or an objective.

TABLE 3Goal PropertiesNameDescriptionTypeGoal InformationTarget Date ofThe date that this goal is expecteddatetimeCompletionto be completed.Risks of Targeting theA list of business risks associatedstring listGoalwith pursuing this business goal.Risks of Not TargetingA list of business risks associatedstring listthe Goalwith not pursuing this businessgoal.

Project is a subtype of Initiative Domain.

The Project component type is used to represent a project.

TABLE 5Project PropertiesNameDescriptionTypeProject InformationStart DateThe projected start date of this project.datetimeFinish DateThe projected finish date of this project.datetimeActual Start DateThe day this project actually started.datetimeActual Finish DateThe day this project actually finished.datetimeProject StatusThe current status of this project.ProjectPhase Type

Task is a subtype of Initiative Domain.

Describes an element of work that is part of a Project.

The Organization Domain is the abstract base for component types representing the entities that describe the people and organizations that a business is constructed of.

Enterprise

Enterprise is a subtype of Organization Domain.

An Enterprise is comprised of all the establishments that operate under the ownership or control of a single organization.

TABLE 9Enterprise PropertiesNameDecriptionTypeAdministrative InformationURLURL of the enterprisestringNotesDescription of the Enterprise and other notesNote
Manufacturer

Manufacturer is a subtype of Enterprise.

A Manufacturer is an organization that produces and supports software and or hardware products.

Business Unit is a subtype of Organization Domain.

A Business Unit describes a business area or organization within a larger corporate entity.

TABLE 11Business Unit PropertiesNameDescriptionTypeAdministrative InformationBusiness Owner Contact NameThe primary business contact'sstringname.Business Owner Contact PhoneThis property describes thestringprimary business contact'sphone.Business Owner Contact EmailThe primary businessstringcontact's email address.

Group is a subtype of Organization Domain.

The Group component type is used to represent a group of people.

Person is a subtype of Group. That is, a person is a group of one.

Use this component type to represent a person.

Privilege is a subtype of Organization Domain.

The Privilege component type is used to describe a particular authorization given to a person.

Role is a subtype of Organization Domain.

The Role component type is used to describe a particular set of responsibilities, privileges, or functions assigned to a person.

Skill is a subtype of Organization Domain.

The Skill component type is used to describe a particular ability possessed by a person.

The Process Domain is the abstract base for component types representing the entities that can be used to represent business processes.

Process

Process is a subtype of Process Domain.

This component type is used to represent processes.

Process Step is a subtype of Process Domain.

A Process Step component type is used to represent a step in a process.

TABLE 21Process Step PropertiesNameDescriptionTypeProcess Step InformationExpected DurationThe time this process stepnumericis expected to take tocomplete.Duration UnitsDays, weeks, or minutes ofIntervalduration.TypeProcess Step TypeThe type of process step.Process(manual or automated).Step TypeStart ConditionsA list of conditions thatstring listmust be met before thisstep can begin.Termination ConditionsA list of conditions thatstring listmust be met before thisstep can end.Scheduling ConstraintsA list of schedulingstring listconstraints that must beadhered to while this stepis underway. For example,the step can only beworked on during normalbusiness hours.

Process Decision is a subtype of Process Step.

A Process Decision component type is used to represent a condition for determining the next action in a process.

TABLE 23Process Decision PropertiesNameDescriptionTypeProcess Decision InformationConditionA condition forstringdetermining the nextaction in a process.
Application Domain

The Application Domain is the abstract base type for component types representing the entities that are used to classify software assets.

Deployed Instance

Deployed Instance is a subtype of Application Domain.

Deployed Instance is an abstract base type for types that are deployed (e.g. installed software).

TABLE 24Deployed Instance PropertiesNameDescriptionTypePerformance InformationOpen Incident CountThe number of incidentsnumericcurrently open for thiscomponent.Service Man HoursThe number of service man-numerichours currently loggedagainst this component.
Application

Application is a subtype of Deployed Instance.

Application is a logical grouping of one or more instances of executable software that fulfill a set of requirements.

Database is a subtype of Deployed Instance.

A Database component type is used to represent a physical data store that serves one or more applications. This subtype has been deprecated.

Data Warehouse is a subtype of Database.

The Data Warehouse component type is used to represent the physical data store used as a Data Warehouse. This subtype has been deprecated.

Module

Module is a subtype of Deployed Instance.

A Module component type is used to describe an instance of installed software that implements single or multiple functional capabilities.

Commercial Module is a subtype of Module.

A Commercial Module component type is used to describe an instance of an installed commercial software

Commercial Software Server is a subtype of Commercial Module.

A Commercial Software Server component type is used to describe a network-addressable module that runs on a physical server. Various subtypes of software servers include database servers, application servers, web servers, etc.

Application Server

Application Server is a subtype of Software Server.

The Application Server component type is used to represent the Application Server class of Software Servers. Examples of Application Servers include WebLogic and Web Sphere.

Web Server

Web Server is a subtype of Software Server.

The Web Server component type is used to represent the Web Server class of Software Servers. Examples of Web Servers include IIS and Apache.

File Server

File Server is a subtype of Software Server.

The File Server component type is used to represent the File Server class of Software Servers.

Database Server

Database Server is a subtype of Software Server.

The Database Server component type is used to represent the Database Server class of Software Servers. Examples of Database Servers include Oracle and Microsoft SQL Server.

TABLE 31Database Server Relationship TypesRelationship TypeLabelTarget Component TypesManagesManagesDatabase
Custom Module

Custom Module is a subtype of Module.

A Custom Module component type is used to describe an instance of a custom written software-based component that is used as a part of an Application.

Software Product

Software Product is a subtype of Application Domain.

It describes a particular kind of software (e.g. a software product) that is either offered commercially or custom developed. This subtype is not intended to represent a particular deployment of the software product, but rather represents the product in general as a class (e.g. Microsoft produces Word where Word is an instance of the type Software Product.)

TABLE 32Software Product PropertiesNameDescriptionTypeApplication InformationSoftware TypeThe type of softwarestringShort nameA short name of productstringDescriptionDescription of softwarenoteproductCommercial productIs this a commercialYes/noproduct?

Software Product Version is a subtype of Application Domain.

A Software Product Version represents a particular version of a kind of Software Product (e.g. a version of a software product) that is either offered commercially or custom developed. This subtype is not intended to represent a particular deployment of the software product, but rather represents the product version in general as a class (e.g. Microsoft produces Word 2000 where Word 2000 is an instance of the type Software Product Version.)

Software Patch is a subtype of Application Domain.

It describes a modification to software that corrects an error or weakness. This subtype is not intended to represent a specific deployment of the software patch,

The Infrastructure Domain is the abstract base type for component types representing the portion of the IT environment dedicated to infrastructure assets such as physical hardware.

Hardware Product

Hardware Product is a subtype of the Hardware Domain.

Hardware Product describes a particular kind of hardware that is either offered commercially or custom developed. This subtype is not intended to represent a particular deployment of the hardware product, but rather represents the product as a class (e.g. Dell produces the Latitude C600 where Latitude C600 is an instance of the subtype Hardware Product.)

Hardware is a subtype of Infrastructure Domain.

The Hardware Subtype represents the physical deployed instance of a hardware product.

Cabinet is a subtype of Hardware.

Use the Cabinet component type to represent server cabinets.

TABLE 43Cabinet Relationship TypesRelationship TypeLabelTarget Component TypesStoresStoresComputing Hardware
Computing Hardware

Computing Hardware is a subtype of Hardware.

The Computing Hardware component type represents a class of components that is based on computing capabilities.

Network Device is a subtype of Computing Hardware.

Use the Network Device component type to describe a device that is directly connected to a network.

Storage Device is a subtype Network Device.

Use the Storage Device component type to represent a stand-alone device that stores data.

Disk Array

Disk Array is a subtype of Storage Device.

Use the Disk Array component type to describe a storage device that stores data on disk drives.

Backup Device is a subtype of Storage Device.

Use the Backup Device component type to describe a storage device that uses removable media to archive data.

Tape Backup

Tape Backup is a subtype of Backup Device.

Use the Tape Backup component type to describe a backup device that stores data onto a tape for archival.

Firewall

Firewall is a subtype of Network Device.

Use the Firewall component type to describe a network device that provides filtered network access.

Load Balancer

Load Balancer is a subtype of Network Device.

Use the Load Balancer component type to describe a network device that provides load-balancing services.

Router

Router is a subtype of Network Device.

Use the Router component type to describe a network device that connects one or more networks.

Switch

Switch is a subtype of Network Device.

Use the Switch component type to describe a network device that manages one or more networks and/or network data types.

SAN Switch

SAN Switch is a subtype of Switch.

Use the SAN Switch component type to describe a device that manages a set of SANs.

Computer

Computer is a subtype of Computing Hardware.

Use the Computer component type to describe a general-purpose computing device.

Server is a subtype of Computer.

Use the Server component type to describe a computing device that hosts one more software services.

Mainframe

Mainframe is a subtype of Server.

Use the Mainframe component type to represent a legacy computing device that hosts many software services.

Desktop

Desktop is a subtype of Computer.

A Desktop component type is used to describe a computing device that performs work for an individual and is typically installed in a fixed location.

Laptop

Laptop is a subtype of Computer.

A Laptop component type is used to describe a computing device that performs work for an individual and is typically considered to be portable. It contains a display device and keyboard in an integrated unit.

Network

Network is a subtype of Infrastructure Domain.

Use the Network component type to describe a set of devices that enable communication via TCP/IP, NetBios, or other network protocol.

SAN is a subtype of Network.

Use the SAN component type to describe a storage area network.

Network Interface

Network Interface is a subtype of Infrastructure Domain.

A Network Interface is used to represent the physical connection point onto a network. A likely subtype of Network Interface would be a Network Interface Card, or NIC.

The location Domain is the abstract base type for component types representing the place where components are located.

Location

Location is a subtype of Location Domain.

Use the Location component type to describe a physical location with an address.

TABLE 55Location PropertiesNameDescriptionTypeAddress InformationStreet Address 1The street address of thestringlocation.Street Address 2The street address of thestringlocation.CityThe city of the location.stringStateThe state of the location.U.S. StateZIPThe ZIP code of thestringlocation.

Data Center is a subtype of Location.

Use the Data Center component type to describe a building where computing devices are physically located.

Geography

Geography is a subtype of Location Domain.

Use the Geography component type to describe general properties applicable to both Regions and Countries.

Region is a subtype of Geography.

Use the Region component type to represent a geographic region containing one or more states or countries.

Country is a subtype of Geography.

Use the Country component type to represent a geographic country.

Data Domain

The component types that are descendants of the Data Domain are used to describe any entity that represents an information asset of the enterprise.

Datastore is a subtype of Data Domain.

Describes the logical media on which information assets are stored.

Database is a subtype of Datastore.

A Database component type is used to represent a physical data store that serves one or more applications.

Data Warehouse is a subtype of Database.

The Data Warehouse component type is used to represent a subject-oriented, integrated, time-variant, non-volatile store of data collected from other systems that becomes the foundation for decision support and data analysis.

VSAM is a subtype of Datastore.

A VSAM component type is used to represent an IBM VSAM data store that serves one or more applications.

Partitioned Dataset a subtype of Datastore.

A Partitioned Dataset component type is used to represent an IBM PDS data store that serves one or more applications.

File is a subtype of Datastore.

A File component type is used to represent a physical data store that represents a single sequential file.

QSAM is a subtype of File.

A QSAM component type is used to represent a physical data store that represents a single QSAM sequential file.

XML File

XML File is a subtype of File.

A XML File component type is used to represent a physical data store that represents a single sequential file containing XML data.

Record Oriented File

Record Oriented File is a subtype of File.

A Record Oriented File component type is used to represent a physical data store that represents a single sequential file containing records with fields.

Data Object

Data Object is a subtype of Data Domain.

A Data Object component type is used to represent a data elements of a database.

TABLE 68Data Object PropertiesNameDescriptionTypeCommentsThese are comments thatnoteare not necessarily a partof the component'sdescription.Data InformationObject nameName of Data Objectstring listPurposePurpose of Data ObjectNoteCreation DateDate created onDatetimeOwnerName of ownerStringLast modified dateDate of last modificationDatetimeof definitionStatusCurrent statusStringSQL SourceCopy of SQL SourcenoteCommentsCommentsNote

Table is a subtype of Data Object.

The Table component type is used to represent a named set of rows in a database.

View is a subtype of Data Object.

The View component type is used to represent a named set of rows in a database.

TABLE 72View PropertiesNameDescriptionTypeCatalogA named group of schemasstringSchemaSchema containing thestringtableTypeView typestringRemarksRemarksstringPrimary Key NameName of primary keystringPrimary Key ColumnColumn location of primaryStingkey

A Stored Procedure is a subtype of Data Object.

The Stored Procedure component type is used to represent function or procedure stored in a schema

A Trigger is a subtype of Data Object.

The Trigger component type is used to represent a named rule in a schema

An Index is a subtype of Data Object.

The Index component type is used to represent a cross references into a table or a views in a schema

A Synonym is a subtype of Data Object.

The Synonym component type is used to alias data objects in a schema

A Type is a subtype of Data Object.

The Type component type is used to represent classes of data in a schema

TABLE 81Type PropertiesNameDescriptionTypeAttributesAttributes of the typestringMethodsMethods of the typestringFinal or InstantiateFinal or instantiatestring

Oracle Data Object is a subtype of Data Object.

An Oracle Data Object component type is used to represent a data objects specific to Oracle databases

SQL Server Data Object

SQL Server Data Object is a subtype of Data Object.

A SQL Server Data Object component type is used to represent a data objects specific to Microsoft SQL Server databases

DB2Server Data Object

DB2Data Object is a subtype of Data Object.

A DB2Data Object component type is used to represent a data objects specific to Microsoft SQL Server databases

Schema

Schema is a subtype of Data Domain.

A schema component type is used to represent a named group of data.

Data Grant is a subtype of Data Domain.

A data grant component type is used to represent the authorization to execute a given operation n a Data Object.

Data Role is a subtype of Data Domain.

A data role component type is used to represent a named user (person or program) who accesses data.

Data Login is a subtype of Data Domain.

A Data Login component type is used to represent the name used to gain access to data.

Tablespace is a subtype of Data Domain.

A Tablespace component type is used to represent a logical group of data files.

Column is a subtype of Data Domain.

A Column component type is used to represent columns in a relational database.

Record is a subtype of Data Domain.

A Record component type is used to represent records in a Record Oriented File.

Field is a subtype of Data Domain.

A Field component type is used to represent records in a Record Oriented File.

Constraint is a subtype of Data Domain.

A Constraint component type is used to represent the named rule that identifies sets of valid data values.

Unique Key Constraint is a subtype of Constraint.

A Unique Key Constraint component type is used to represent the named rule that identifies sets of valid data values.

Primary Key Constraint

Primary Key Constraint is a subtype of Constraint.

A Primary Key Constraint component type is used to represent the named rule that identifies sets of valid data values.

Foreign Key Constraint

Foreign Key Constraint is a subtype of Constraint.

A Foreign Key Constraint component type is used to represent the named rule that identifies sets of valid data values.

TABLE 101Foreign Key Constraint Relationship TypesRelationship TypeLabelTarget Component TypesConstrainedReferencesTableconstraint
Check Constraint

Check Constraint is a subtype of Constraint.

A Check Constraint component type is used to represent the named rule that identifies sets of valid data values.

TABLE 102Check Constraint Relationship TypesRelationship TypeLabelTarget Component TypesConstrainedConstrainsView
Set of Values

Set of Values is a subtype of Constraint.

A Set of Values component type is used to represent the set of valid data values. It is recommended that subtypes be created from this subtype to define specifics of the set of valid values that apply.

TABLE 104Set of Values Relationship TypesRelationship TypeLabelTarget Component TypesConstrainedConstrainsColumnConstrainedConstrainsField
Policy Domain

The component types within the Policy Domain are used to describe the plans, principles, obligations, agreements, contracts, and requirements which guide the management of the enterprise.

Property Types

Custom property types may be created to be utilized with the reference model. For example:

Property TypeValid ValuesAirflow Type1U (32-36 CFM/U)Describes the type of airflow used by a cabinet.2U (39-45 CFM/U)4U (38-40 CFM/U)5U (45-50 CFM/U)7U (25-43 CFM/U)Application Lifecycle Phase TypeVisionApplication lifecycle phases.PlanningDevelopmentTestingStabilizationDeployingSupportingRetiringCabinet Type4-Post (Enclosed)This describes the type of cabinet.2-Post (Open Air)Capacity Unit TypeKilobytesUnits of capacity.MegabytesGigabytesTerabytesPetabytesCPU Clock Speed Unit TypeKilohertz (KHz)Units of CPU clock speed.Megahertz (MHz)Gigahertz (GHz)Employee Status TypeFull TimeEmployee status.Part TimeLeave of AbsenceTerminatedFan Location TypeTopLocation of fan(s) on a server cabinet.FrontBackBottomLeft SideRight SideNone or N/AInterval TypeDaysGranularity of intervals.HoursMinutesMounting Hole TypeSquareThe types of mounting holes in a cabinet.RoundTappedOS Name TypeMicrosoft Windows 2000ServerThe name of the operating system.Process Step TypeManualThe type of process step.AutomatedProject Phase TypePlanningThe phase of a project.Requirements Gatheringand AnalysisConstruction PhaseTransition PhaseDeployment PhaseTask Status TypeProposedStatus values for a task.Pending ApprovalIn ProgressOn HoldCompleteU.S. State TypeAny valid abbreviation oftheState of the United States of AmericaUnited States of America.YesNo TypeYesYes or No value.No