Abstract:
Modeling operational policies of operating a business&#39;s or institution&#39;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&#39;s or institution&#39;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&#39;s resources. A composite type may contain connectors of any relationship type, to represent relationships between the composite&#39;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 &lt;operator&gt; 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&#39;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&#39;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.