US20070112847A1

US20070112847A1 - Modeling IT operations/policies

Info

Publication number: US20070112847A1
Application number: US11/266,156
Authority: US
Inventors: Pratul Dublish; Bassam Tabbara; Geoffrey Outhred; Jeffrey Parham; Kevin Grealish; Praerit Garg
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2005-11-02
Filing date: 2005-11-02
Publication date: 2007-05-17
Also published as: WO2007055839A1; CN101297293A; JP5671207B2; US7941309B2; JP2009515252A; EP1949275A4; KR20080057288A; EP1949275A1

Abstract

Modeling operational policies of operating a business's or institution's actual or planned IT system. The IT system may include components such as applications, application hosts, one or more networks or components thereof, hardware, and interrelationships between the components. The IT system is to be operated in accordance with operational policies that govern existence or numerosity of components, how the components are interrelated, how the components and interrelationships are configured, and/or manual or automated processes for managing and maintaining the IT system. The modeling may involve generating code that conforms to a language by declaring abstractions using types that correspond to the components of the IT system, by declaring types of interrelationships that correspond to the interrelationships of the IT system, and by defining constraints upon and between the abstract types, where the constraints correspond to operational policies of operating the IT system.

Description

BACKGROUND

The IT (Information Technology) systems owned and operated by various businesses and institutions can be highly complex. A typical IT system may entail multiple computers with numerous pieces of interconnected software on each computer. The deployment, configuration, and management of these IT systems is manually intensive and is accomplished through ad-hoc combinations of human experience, communal knowledge, a collection of unrelated software tools, and documents that are often incomplete, out of date, hard to locate when needed, or difficult to understand. The manually intense operation of IT systems is often the cause of malfunctions and sub-optimally performing systems. Changes to IT systems are also typically managed informally, for example through email messages. If an IT system has, for example, a 3-tier application and a fix or change needs to be applied, there is no convenient way to determine whether the fix or change is valid or whether it will break the IT system. Such changes may be preceded by extensive testing. As an IT system becomes more complex, the ad hoc approach breaks down; information is not fully shared or becomes stale, inefficiencies and mistakes increase, etc. In sum, modern complex IT systems are managed using techniques that have changed slowly and have not improved with the increases in complexity of IT systems. There is no way to standardize the configuration of IT systems. This lack of standardization and lack of improvement in IT system management continues to expose businesses, institutions, and other enterprises to substantial risks and costs.
Absent standardized configuration tools and models, there is no sure or easy way to check whether the operational policies and preferences of an IT system are being met. There is no flexibility; changes and extensions of the IT system are difficult to validate. There are no systems by which some predefined components can be “programmed” to model or capture operational policy. Many of the problems mentioned above could be alleviated if there were ways to capture and formalize the operational knowledge of an IT system, that is, the knowledge associated with the desired configuration environment and operation of an IT system.

SUMMARY

The following summary is included only to introduce some concepts discussed in the Detailed Description below. This summary is not comprehensive and is not intended to delineate the scope of protectable subject matter, which is set forth by the claims presented at the end.
Operational policies for operating a business's or institution's actual or planned IT system may be modeled. The IT system may include components such as applications, application hosts, one or more networks or components thereof, hardware, and interrelationships between the components. The IT system is to be operated in accordance with operational policies that govern existence or numerosity of components, how the components are interrelated, how the components and interrelationships are configured, and/or manual or automated processes for managing and maintaining the IT system. The modeling may involve generating code that conforms to a language by declaring abstractions using types that correspond to the components of the IT system, by declaring types of interrelationships that correspond to the interrelationships of the IT system, and by defining constraints upon and between the types, where the constraints correspond to policies of operating the IT system.
Many of the attendant features will be more readily appreciated by referring to the following detailed description considered in connection with the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

Like reference numerals are used to designate like parts in the accompanying Drawings.
FIG. 1 shows a community having operational knowledge, a model, and an IT system.
FIG. 2 shows layers representable by a model.
FIG. 3 shows one use of a model of an IT system.
FIG. 4 shows a process for declaring a model.
FIG. 5 shows a declarative model.
FIG. 6 shows another representation of a model.
FIG. 7 shows code defining various relationship types and class types used in the example in FIG. 6.
FIGS. 8-10 show code declaring a complex class type that captures operational knowledge of an e-commerce web site.
FIG. 11 shows examples of operational policies in the form of rules or constraints.
FIG. 12 shows examples of derivation by restriction or extension.

DETAILED DESCRIPTION

Embodiments discussed herein relate to capturing operational knowledge of an IT system in a model by using a formal language. More specifically, a declarative model captures the operational knowledge of an IT system—information pertaining to the configuration environment, the policies, and the ongoing operation and management of an IT system. Such a knowledge-capturing declarative model is formed using the typing system of a formal language, such as XML (or a modeling schema based thereon), UML, C#, and so on (the particular language is not important).
Once established, such a model can have many uses. A model unambiguously communicates the operational knowledge of the IT system to all interested parties, such as IT administrators, system operators, system architects, developers, testers, etc. It can be used as a basis to drive an agreement about what an IT system should do and how it should function. Different stakeholders can review the model and agree or disagree with expectations for the IT system. Such a model can be used to actually configure a system in the real world. Furthermore, a well declared model can be used to periodically check whether the real world system is in compliance with the model and various invariants that it may capture. Also, proposed changes to the IT system can be validated against the model (and therefore the knowledge and policies that the model embodies) before they are applied to the IT system. Being based on a language, a model can be easily interpreted, compiled, manipulated, richly visualized, and so on.
FIG. 1 shows a community 50 having operational knowledge, a model 52, and an IT system 54. The operational knowledge is embodied or captured in a model 52. The model 52 can be used to configure, validate, understand, etc., the IT system 54. Notably, the model 52 is separate from and independent of the IT system 54 itself. The model 52 reflects the desired or preferred state of the IT system 54. In other words, although the model 52 is independent of the real world, it may model types of information found in the real world IT system 54 (e.g., servers, applications, etc.), and it may model that information not necessarily as it is, but rather as it should be. In sum, the model 52 captures a desired state of configuration and can allow a correlation between what the IT system 54 is and what it should be.
As mentioned, a language is used to declare a model of an IT System in a way that includes information pertinent to deployment and/or ongoing operations. The model is like a blueprint of an IT system. As seen in FIG. 2, a model 52/68 can capture the structure of an IT system, that is, the various pieces of the IT system, and how they relate to each other (e.g., a web application communicates with a catalog DB, a catalog DB is hosted on SQL, etc.). Model 68 may model any or all layers of an IT system. A model such as model 68 may declare any types of applications 70, application hosts 72, network components and operating systems 74, and even hardware 76. Applications 70 might be data access clients, or information worker productivity tools, or network-type applications coded in Java or ASP.NET. Application hosts 72 might be any web servers, or Internet Information Server in worker process isolation mode, to name a few examples. Network components 74 might be as simple as a data network, but can be any component for networking. Operating systems 74 might be Windows based, Unix based, virtualized operating systems, or others. Hardware 76 is also unlimited, but might include typical computer components such as peripheral devices, memory, CPUs, storage, RAID configurations, etc.
A model of an IT system also captures constraints or invariants—a set of rules or policies that should or must remain true for the system to be considered optimal or operational (e.g., a host customer transaction DB must be on an SQL cluster, each DFS instance must have at least three servers, at least two targets must exist for each link, the targets for a link should be hosted on distinct file servers, etc.).
FIG. 3 shows one use of a model of an IT system. A system administrator 90 might submit a model update request 92 against a model 94. The request 92 can be validated 96 against the model 94, and if all of the rules, constraints, or invariants of the model 94 remain satisfied, the model 94 may be updated with the request 92. An updated model 98 can then be used, for example, to drive adapters 100 that provide a bridge between the updated model 98 and a real world IT system 102. For example, there might be an adapter for SQL servers, and that adapter might implement a policy or constraint in the updated model 98 by changing configuration parameters of an SQL server in the real world IT system 102. As mentioned, a model can have many other uses.
FIG. 4 shows a process for declaring a model. First, a person generating the model defines 120 types for the components/classes, relationships, and constraints of an IT system. Then the person tailors 122 the types to model or mirror the knowledge of policies or aspects of operating the IT system. The types are stored 124 in the typing syntax of a language being used to declare the model. Further details follow.
FIG. 5 shows a declarative model 140. The model 140 can be generated as with the process of FIG. 4. A designer generating the model 140 may start by choosing some particular language 142. The language 142 should have a type system 144 including rules and syntax 144 for declaring and using types and a type checking algorithm 146 (a typechecker) for ensuring that source code has no typing violations. A type system is the component of a typed language that keeps track of the types of variables and, in general, the types of expressions in the language. A type system can describe whether a program or code is well behaved or well formed. A type system may involve other aspects such as scoping rules, type equivalence, and so on. Finally, a type system should be enforceable; type declarations should be capable of being statically checked to some extent. A type system is useful for modeling operational knowledge of an IT system because types express static (as opposed to algorithmic) knowledge about things. It should be noted that a typechecker or type checking algorithm 146 is helpful for using a declarative model in various ways, it is not necessary for actually building a declarative model.
Returning to FIG. 5, the human designer may gather all of the available operational knowledge 148 that is desired to be modeled. This might involve obtaining knowledge from people 150, or from documents 152, 154. Document 152 might be an informal document such as an email, a loosely maintained “operation policies” document, etc. Document 154 might be a more formal document, such as an IBM Redbook, an ITIL (IT Infrastructure Library) publication, some manual of institutional IT policies, a document from a software publisher indicating preferred ways of configuring or installing an application, and so on.
Having chosen a language 142 and gathered operational knowledge 148, the designer may proceed by declaring or defining 120 types for the components/classes, relationships, and constraints of an IT system.
Types of classes/components and relationships form the software and hardware building blocks for models of IT systems. Some types may be value types, which are predefined types such as Integers, strings, booleans, enumerations, etc. Class or component types typically represent basic systems and resources and may have properties that capture invariant state that is to be modeled and maintained. Constraint types operate on or between properties that capture invariant requirements.
A relationship type represents a semantic relationship between two or more classes. A relationship type can represent any arbitrary relationship including “communication between”, “reference to”, “hosting of/on”, “delegation”, “interaction of a particular kind”, “what objects another object can contain”, “which endpoints can be connected together”, “what environments can host a particular object”, and so on. Containment types of relationships can be used as a basic building block to define the containment structure of a model. A relationship type may have properties to represent invariant state associated with the relationship, and a relationship may be constrained.
Composite or complex types may be used to build complex, multipart types. A composite type may be convenient to model real-world systems (or sub-systems) and may typically (but not always) include details regarding scale and deployment of a system. A composite type may contain (by reference or value) objects of any class type, to represent the system's resources. A composite type may contain connectors of any relationship type, to represent relationships between the composite's objects. A composite type may also contain constraints or rules on or between objects that capture the invariant requirements (or preferences) of the composite. In sum, a composite type is a contextualized composition of classes and relationships along with desired state, structure, constraints, and behavior.
Types of constraints may also be defined. A constraint represents an invariant for instances (objects) of a given class or relationship (connection) type. Constraints can constrain values or structure. A constraint is typically a boolean expression that has access to properties/roles/ . . . etc. A constraint can usually be evaluated as being either true or false, where an evaluation of false indicates that the constraint is violated or its recommendation is not satisfied.
Given the types that can be defined 120 by a person designing the model 140, and given the language 142 and operational knowledge 148, the designer defines the types of classes, relationships, constraints, and/or composites that will be needed to model an IT system. The designer tailors 122 the types to model or capture the operational knowledge 148. Details of how this is performed will become more apparent as examples are discussed with reference to FIGS. 6-12. The process to this point is a design process; types can be defined 120 and tailored 122 any number of ways; pencil and paper, modeling tools, etc. However, when the types are finalized they are stored 124, in the typing syntax 144 of the language 142, as declarations of types of classes (or components or values) 156, declarations of types of relationships 158, declarations of constraints 160 that constrain the model 140, and declarations of composite types 162. The model 140 and its type definitions or declarations 156-162 may be stored 124 as one or more electronic files or documents in any computer readable media such as magnetic media, optical media, volatile or non-volatile memory, and so on. Furthermore, the model 140 might be transformed, for example by compilation, into machine code, byte code, intermediary code, or the like.
FIG. 6 shows another representation of a model. Coded definitions of model 180 will be discussed with reference to FIGS. 7-12. Model 180 represents a desired e-commerce web system. Some of the class types are: web application 182, worker process isolation 184, customer transaction database 186, SQL server (cluster) 188, catalog database 190, and SQL server (standard) 192. Some of the relationship types are: host dependency 194, 196, 198, and communication 200, 202. As will be discussed, a number of operational constraints 204 are also captured by the model 180.
Some of the relationships may have numerosity invariants. For example, communication relationship 200 has a numerosity invariant 206 that one entity must be at each end of the relationship 200. Some of the classes also have numerosity invariants (see the upper right hand corners of the boxes representing classes 182-192). For example, SQL server (standard) 192 may be one or more occurrences (“[1 . . . *]”) of the same.
FIG. 7 shows code 220 defining various relationship types and class types used in the example in FIG. 6. Regardless of the language chosen for modeling, the type declarations have some construct or information indicating that they are type declarations and indicating the kind of type that is being declared, e.g., “RelationshipType”, which indicates a type of relationship is being declared, or “ClassType”, which indicates a type of class is being declared. Most of the types and properties thereof declared in the FIG. 7 are self-explanatory. As will be seen, these base types can serve as parts of more complex composite types.
FIGS. 8-10 show code 222, 224, 226 declaring a complex class type that captures operational knowledge of an e-commerce web site. The parts and relations declared as parts and connections of the eCommerceSite complex class are types defined in FIG. 7. The eCommerceSite captures several operational aspects or policies. It specifies numerosities of its constituents. It also specifies connectors between parts, as well as end points and roles. FIG. 10 shows some other operational knowledge in the form of constraints of the eCommerceSite type. A constraint named WorkerProcessMustBeEnabled is defined to require that all IIS6 webserver parts (see FIG. 8) must have their WorkerProcessEnabled property set to true. This does not actually set the properties of webserver members of e-commerce instances, rather it declares a desired constraint on the e-commerce type; that instances of e-commerce types will not be valid if all of their worker processes are not enabled. Another constraint specifies that all transactionSqlServers must have their authentication mode (AuthenticationMode) set to “Windows”.
FIG. 11 shows example 228, 230 of operational policies in the form of rules or constraints. In example 228, webapp objects of the eCommerceSite class are defined to have no more than 1,000 users per application. In example 230, the constraint is categorized as being recommended for performance.
Constraints or rules can be fashioned from almost any piece of information. Furthermore, constraints can be built up as boolean expressions that can be evaluated as being true or false. Logical operators such as “all of”, “none of”, and the like may be used to construct these expressions. Complex multi-operator expressions can be constructed. A set of boolean expressions can be in the universe of expressions defined roughly by: expression=expression <operator> expression, or expression=term; where operators are things such as math operators, boolean operators, and so on, where terms can be any of the types defined in the model (e.g. relationships, classes, etc.), or properties of the types, or constants, or even global information such as dates, times, or settings of the main model itself. See C#, .Net, or Java for similar definitions of boolean expressions. Thus, almost any type of operational constraint of an IT system can be modeled. Constraints can be typed as either strict constraints or advisory constraints, however, the constraints are otherwise declared in the same way. Other types of constraints or invariants can also be defined, so, for example, constraints can be validated based on their type.
In view of the discussion and examples above, it should be clear that policies of a desired IT system being modeled (an e-commerce web system) are able to be established using declarative constructs and without requiring the construction of algorithmic or behavioral code. Furthermore, although the examples are coded in XML, other languages can be used. For example, declarations in the style of C# could as easily be used, and even if behavior in the form of executable statements is included in such code, the declarative code (type declarations) can be considered logically separate from such behavioral code. In other words, the model's validity can be tested (using type checking, rule testing, invariant testing, etc.) without regard for any behavior that might incidentally be included in the model's code.
FIG. 12 shows examples 232, 234 of derivation by restriction or extension. The operational knowledge captured in a model can be reused and refined through derivation. Derivation by restriction can be used to specialize the knowledge captured in an existing model. As seen in example 232, in the case of the model for the eCommerce site, the model can be reused (restrictively derived) to define a model for a fault-tolerant eCommerce site that has at least two web servers and at least two catalog servers, so that it is resilient against the failure of one web server or one catalog database server. A base model can also be derived by extension. Derivation by extension can be used to extend the knowledge captured in a model. As seen in example 234, the eCommerce site model can be extended to define the model for an online music store that has media servers in addition to web servers and database servers.
In conclusion, those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively the local computer may download pieces of the software as needed, or distributively process by executing some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art, all or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.
All of the embodiments and features discussed above can be realized in the form of information stored in volatile or non-volatile computer or device readable medium. This is deemed to include at least media such as CD-ROM, magnetic media, flash ROM, etc., storing machine executable instructions, or source code, or any other information that can be used to enable a computing device to perform the various embodiments. This is also deemed to include at least volatile memory such as RAM storing information such as CPU instructions during execution of a program carrying out an embodiment.

Claims

1. A method, the method comprising:

generating a model of an IT system that models policies for deploying, configuring, and operating the IT system, the model comprising type declarations in the typing syntax of a declarative language, where the type declarations together model the policies for configuring and operating the IT system, and where the type declarations declare types of classes/components of the IT system, types of relationships between classes/components of the IT system, and constraints of the IT system; and

storing the model in computer readable medium.

2. A method according to claim 1, wherein the constraints comprise expressions comprising operators operating on components of the IT system and/or relationships of the IT system, where the expressions can be evaluated for truth to determine whether the constraint is satisfied.

3. A method according to claim 2, where the declarative language has an expression syntax for constructing expressions, and the expressions that comprise the constraints are in a form complying with the expression syntax.

4. A method according to claim 1, wherein the constraints model constraints of operating, deploying, and configuring the IT system.

5. A method according to claim 1, further comprising:

passing an instance of the stored model to an implementation of the language that comprises at least a type checking algorithm and that verifies whether the instance satisfies the policies of the model.

6. A method according to claim 1, wherein the types of classes/components comprise types of hosts, types of servers, and types of applications, and wherein the types of relationships comprise hosting relationships, dependency relationships, delegation relationships, and communications relationships.

7. A method according to claim 1, wherein a new model is derived from the model by adding a declaration that either extends the model with a new declaration or that restricts the model by restricting a type declared in the model.

8. One or more computer-readable medium storing a definition of a model of an IT system, the definition comprising:

source or compiled code of a declarative language, the source or compiled code comprising:

declarations of types software and hardware components, where the types of components are declared to have properties that model policies of operating the IT system;

declarations of types of relationships between components, where the types of relationships are declared to have properties that model policies of operating the IT system; and

declarations of constraints on the relationships and components, where the constraints constrain combinations of relationships and components in a way that models policies of operating the IT system.

9. One or more computer-readable medium according to claim 8, where the definition further comprises restrictive derivations of that extend or refine the policies of operating the IT system.

10. One or more computer-readable medium according to claim 8, where the definition specifies invariant aspects of the IT system that must be satisfied for the IT system.

11. One or more computer-readable medium according to 8, further storing:

information indicating a state of the IT system; and

a component for using the definition to determine whether changes to the state of the IT system would violate the policies of operating the IT system.

12. One or more computer-readable medium according to claim 8, wherein some of the constraints further comprise information indicating classifications of the constraints.

13. One or more computer-readable medium according to claim 8, further storing a definition of a second model derived from the model by adding a declaration that either extends the model with a new declaration or that restricts the model by restricting a type declared in the model.

14. One or more computer-readable medium according to claim 8, wherein the declarations of the constraints comprise expressions comprising operators operating on components and/or relationships, where the expressions are susceptible to truth evaluation.

15. A method of modeling operational policies of operating a business's or institution's actual or planned IT system, where the IT system comprises components comprising applications, application hosts, one or more networks or components thereof, hardware, and interrelationships between the components, and the IT system is to be operated in accordance with operational policies that govern existence or numerosity of components, how the components are interrelated, how the components and interrelationships are configured, and manual or automated processes for managing and maintaining the IT system, the method comprising:

generating code that conforms to a language by:

declaring types of classes that correspond to the components of the IT system;

declaring types of interrelationships that correspond to the interrelationships of the IT system; and

defining constraints upon and between the types, where the constraints correspond to the operational policies of operating the IT system; and

wherein the code is independent of the IT system.

16. A method according to claim 15, wherein the types are declared with portions of declarative code in accordance with syntax and semantics of a typing system of the language.

17. A method according to claim 16, wherein the constraints comprise expressions that are within the universe of boolean expressions defined by the language.

18. A method according to claim 17, wherein the constraints constrain some of the abstract types such that instances of the abstract types can be validated against the constraints.

19. A method according to claim 15, further comprising automatically determining whether instances of the declared types satisfy operational policies modeled by the types.

20. A method according to claim 15, further comprising automatically determining whether a proposed modification to an instance of one of the types would violate the operational policies.