The present invention relates to a method and system for developing a conceptual model to facilitate generating a business-aligned information technology solution and more particularly to a technique for defining a conceptual structure that includes representations of business-aligned conceptual components and for describing operational concepts based on the conceptual structure to translate business intent into an information technology solution.
Conventional techniques for developing information technology (IT) solutions fail to adequately address the need for business stakeholders to understand the organization and structure of IT solutions to facilitate the maintenance of a business-IT alignment (i.e., ensuring that the IT solutions meets overall business intent throughout the life of the IT solution). These known IT solution development techniques are oriented toward specific technologies, applications and versions of software, thereby hindering the capture and active maintenance of an overall solution context for requirements and changes. Other deficiencies and limitations of conventional IT development techniques include making details of the overall business intent unclear to IT development teams, failing to map IT architecture and design rationale back to business intent adequately, not allowing business stakeholders to fully understand how IT solutions are structured and organized in order to make business decisions that minimize required IT solution changes while maximizing business innovation, hindering the engagement of business stakeholders in lifecycle processes for IT solutions and the effective collaboration of business stakeholders with IT stakeholders. Conventional IT development methods include, for example, Structured Design and Programming, Object Oriented Analysis and Design, Component Based Design, Model Driven Architecture, Rational Unified Process, and Service Oriented Modeling and Architecture (SOMA). These examples of conventional IT development methods primarily serve the IT stakeholders, such as IT architects, IT managers and programmers, while impeding a collaborative use of the known development methods that includes business stakeholders. Business stakeholders find the tools and notations used by these known methods to be intimidating and difficult to understand, thereby hindering the business stakeholders from playing a more effective role in architecting IT solutions to meet business needs. Business stakeholders provide input to these known methods, but do not actively participate in the use of these methods. Thus, there exists a need to overcome at least one of the preceding deficiencies and limitations of the related art.
The present invention provides a method of developing an information technology solution via development of a conceptual model, the method comprising:
defining, by one or more business stakeholders associated with a business, a plurality of requirements of an information technology (IT) solution owned by the business;
developing a conceptual model by the one or more business stakeholders and one or more IT stakeholders associated with the business, the conceptual model providing a representation of a design of the IT solution, the conceptual model including a plurality of conceptual components and a plurality of operational concepts, the plurality of conceptual components representing one or more IT systems, one or more hardware components of the one or more IT systems and one or more software components of the one or more IT systems, and the plurality of operational concepts indicating interactions among the plurality of conceptual components to perform a plurality of functions of the business;
generating, via a computing system, a documentation of the conceptual model, the documentation being available and accessible to the one or more business stakeholders and the one or more IT stakeholders, wherein the generating the documentation of the conceptual model includes documenting the plurality of operational concepts;
developing an architecture and a design of the IT solution by the one or more IT stakeholders; and
generating, by the one or more IT stakeholders, a documentation of the architecture and the design of the IT solution.
A system, computer program product, and a process for supporting computing infrastructure that provides at least one support service corresponding to the above-summarized method are also described and claimed herein.
Advantageously, the present invention provides a technique for developing a conceptual model that facilitates the development of IT solutions that are business-aligned throughout the lifecycle of the IT solution. The present invention also significantly improves IT project efficiency, enhances productivity and quality related to IT projects, and produces enormous savings on IT spending by businesses in any type of industry. Further, the conceptual model provided by the present invention promotes a common understanding of IT solutions that facilitates collaboration between business stakeholders and IT stakeholders. Still further, no special training in any IT method is needed to read and understand the operational concepts included in the conceptual model. Common software tools and applications can be used to access and read a description of the operational concepts. Moreover, the conceptual model provides a stable view of an IT solution to all stakeholders regardless of technology decisions and upgrades made to different parts of the IT solution at various times during the lifecycle of the IT solution.
The present invention provides a method and system for developing a conceptual model that facilitates the generation of a business-aligned information technology (IT) solution. The conceptual model includes a conceptual structure and operational concepts documentation that are designed to be utilized by both IT stakeholders and business stakeholders. A technology agnostic principle guides the development of the conceptual model in the present invention so that documentation associated with the conceptual model includes descriptions of operational concepts presented at a level of specification that does not include implementation-specific details.
The below-listed terms are used herein and are defined as follows:
Information technology solution or IT solution: A collection of IT systems that support activities of a business, where each IT system in the collection is implemented by one or more hardware components and/or one or more software components.
Conceptual model: A high-level abstraction of the design of an IT solution. A conceptual model provides a stable reference for IT solution development and includes a conceptual structure and a description (i.e., documentation) of operational concepts. A conceptual model is owned and understood by both business stakeholders and IT stakeholders.
Conceptual structure: A representation of the basic building blocks of an IT solution. The building blocks represented by the conceptual structure are conceptual components.
Conceptual component: A technology agnostic, modular representation that is one of the building blocks represented by a conceptual structure. A conceptual component is represented as an icon or a form, shape or figure determined by outlines (e.g., a closed plane figure or curve such as a rectangle or circle). When an IT solution is implemented, conceptual components are manifested as software components, hardware components or a combination thereof.
Operational concepts: Descriptions, using a conceptual structure as a basis, of how each conceptual component interacts with one or more other conceptual components to support and perform business functions that an IT solution is meant to support.
Business stakeholders: Non-technical personnel who have an interest in the outcome of an IT solution.
IT stakeholders: Technical personnel who have an interest in the outcome of an IT solution.
Conceptual modeler 102 also includes other analyzers whose analysis activities refine initial versions of the conceptual structure and operational concepts. These other analyzers included in conceptual modeler 102 include a user and external interaction analyzer 116, a business model analyzer 118, a business operational model analyzer 120, an internal process and algorithm analyzer 122, a communication analyzer 124, an information needs analyzer 126 and a non-functional requirements analyzer 128. The functionality of analyzers 104 and 116-128 are described below relative to
Conceptual modeler 102 also includes a conceptual structure designer 130 and an operational concepts designer 132. Conceptual structure designer 130 develops and updates the conceptual structure of the conceptual model being developed by conceptual modeler 102. Operational concepts designer 132 develops and updates the set of operational concepts of the conceptual model being developed by conceptual modeler 102. Input to conceptual structure designer 130 and operational concepts designer 132 include the analysis provided by analyzers 104 and 116-128. Conceptual structure designer 130 iteratively outputs visual representations of the conceptual structure that includes a modular representation of conceptual components. Operational concepts designer 132 iteratively outputs textual descriptions and/or diagrammatic descriptions of the operation of the conceptual components and textual and/or diagrammatic descriptions of how the conceptual components interact with each other. As used herein, textual descriptions refer to verbal descriptions and diagrammatic descriptions include diagrams such as flow charts, sequence diagrams, activity diagrams, etc.
Conceptual modeler 102 also includes an information manager 134, a conceptual structure repository 136, an operational concepts repository 138 and a conceptual components repository 140. Conceptual structure designer 130 stores the conceptual structure and conceptual components in repositories 136 and 140, respectively, by utilizing information manager 134 as an interface. Similarly, operational concepts designer stores the operational concepts in repository 138 by utilizing information manager 134 as an interface. Furthermore, information manager 134 provides operations such as finding, retrieving, capturing, modifying, deleting, and organizing various types of information relevant to the operation of each conceptual component.
In one embodiment, a service oriented architecture is utilized to define the services supported by information manager 134 so that other components such as functional analyzer 104 can invoke the services and access information relevant to the IT solution being developed.
In one embodiment, system 100 is modified so that information manager 134 and repositories 136, 138 and 140 are external to conceptual modeler 102.
Conceptual modeller 102 also includes exporter components 142, 144, 146, 148 and 150 that export information retrieved by information manager 134 to various software tools which are described below. User & external interface model exporter 142 exports to one or more user interface and external system interface design tools 152 information related to how a user and/or other external elements interact with the IT solution being developed. For example, user interface and external system interface design tool 152 includes a tool used to define a storyboard and to design screens for a user interface to the IT solution being developed.
Conceptual model exporter 144 exports modular representations of the conceptual structure to one or more application design and service oriented architecture (SOA) design tools 154. Performing the export of the conceptual structure to design tools 154 ensures that subsequent development of a technical design to implement the IT solution is compliant with the conceptual model throughout the lifecycle of the IT solution.
Information model exporter 146 exports the different types of information required by the IT solution being developed to information modelling & data modelling tools 156, thereby providing a template for information model or data model design. For example, a database that is developed for the IT solution according to the template provided by the export to tools 156 is in compliance with the conceptual model provided by conceptual modeller 102.
Business process model exporter 148 exports to process modeling tools 158 the business processes that are incorporated into the conceptual model. For example, the exported business processes are used as the starting point for process design using Websphere® Business Modeler.
Operational concepts documentation generator 150 exports operational concepts documentation 160. For example, documentation generator 150 causes an operational concepts document 160 to be printed at a printer as a hard copy or electronically transmitted to an authoring software tool.
In one embodiment, the functionalities of all the components of system 100 which are described herein are automated and/or integrated in a software application. In another embodiment, a proper subset of the functionalities of all the components of system 100 which are described herein are automated and/or integrated in a software application.
The IT solution development process begins at step 200. In step 202, one or more business stakeholders in a business domain 201 define business requirements related to the IT solution. In step 204, the one or more business stakeholders and one or more IT stakeholders of a business-IT domain 203 develop or update a conceptual model for the IT solution whose requirements are defined in step 202. As used herein, a business-IT domain is defined as a domain of activities whose ownership is shared by both business and IT stakeholders. The output of step 204 is a newly developed or updated conceptual model 205. In step 206, the one or more IT stakeholders of an IT domain 205 develop or update the architecture and design of the IT solution being developed. The output of step 206 includes infrastructure architecture and design 208, application architecture and design 210, database architecture and design 212 and/or other architecture and design 214 associated with the IT solution being developed. Relative to
The conceptual model development process begins at step 300. In step 302, business and IT stakeholders define a conceptual structure based on a functional analysis. In each of steps 304-316, business and IT stakeholders refine the conceptual structure defined in step 302 based on one of the following analyses: a user and other external interaction analysis (see step 304), a business model analysis (see step 306), a business operational model analysis (see step 308), an internal process and algorithm analysis (see step 310), a communication needs analysis (see step 312), an information needs analysis (see step 314), or a non-functional requirements analysis (see step 316). In one embodiment, any combination of steps 304-316 is performed in parallel. In another embodiment, steps 304-316 are performed in any sequence.
When following step 302, step 318 includes generating a description of the operational concepts based on the conceptual structure defined in step 302. When following one of steps 304-316, step 318 includes describing the operational concepts based on the conceptual structure, as refined by the step (i.e., step 304, 306, 308, 310, 312, 314 or 316) that immediately precedes step 318. In one embodiment, the description of the operational concepts is generated manually by business and IT stakeholders in step 318. In another embodiment, the description of the operational concepts is included in documentation that is generated automatically in a pre-defined format in step 318 by using the conceptual structure and the results of the analyses in steps 302-316 as input. Any aspect of automatically generated operational concept documentation can be overridden and modified via manual controls. The conceptual model development process ends at step 320.
Steps 302-318 are described in more detail below.
Functional analysis (step 302): The functional analysis of step 302 includes an analysis of the business functions to be supported by the IT solution. This analysis of business functions reveals an initial, basic set of conceptual components that are needed in the IT solution. The goal at this initial stage of conceptual component identification is to be comprehensive in the coverage of the needed functions. Other considerations such as how the conceptual components are aggregated or partitioned to optimize and accommodate various other business and technical requirements are addressed by steps 304-316. The collection of conceptual components identified at step 302 represents an IT solution (hereinafter, also referred to as “the solution”). The operational concepts description of step 318 is started during and/or after the functional analysis of step 302.
User and other external interaction analysis (step 304): Analysis of the interactions that one or more users and other elements external to the solution (i.e., the solution identified by step 302) are to have with the solution determines whether additional systems (a.k.a. IT systems), subsystems, and/or conceptual components are needed in the solution. If step 304 determines a need for such conceptual components systems and/or subsystems, then step 304 also identifies the specific conceptual components systems and/or subsystems that are to be added. The one or more added systems or subsystems are, for example, partitioned into conceptual components needed to support the systems' or subsystems' functions and operations. In step 304, the conceptual components in the systems and subsystems are identified based on a need to support the external interactions that the solution must have. For example, Web 2.0 and Enterprise 2.0 are tag names that are used to refer to a variety of interactions and collaborations enabled by emerging technologies. These emerging technologies include instant messaging, collaborative content tools, integrated search tools, unified communications, wikis, mashups, RSS feeds, blogs among employees, partners or customers, presence awareness, business social networks, and click-to-call communication. During and/or after step 304, the operational concepts description is updated in step 318 to capture the changes made to the conceptual structure and descriptions of the aforementioned analyzed interactions.
Business model analysis (step 306): The conceptual structure of the IT solution must align with the business model for the client (i.e., the business) who will own and use the IT solution (hereinafter referred to as “the client”). In step 306, the implications of the client's business model to the conceptual structure are examined and the conceptual structure is updated accordingly. Considerations in step 306 include software or system licensing models, software or system usage fee structures, technology development joint ventures, monitoring and tracking requirements to meet regulatory and other business policy mandates, and governance requirements. These considerations must be applied to the solution and all of its systems and subsystems. As a result of the analysis of step 306, new conceptual components are added and/or existing conceptual components are modified by partitioning or aggregating the conceptual components. In some cases, new systems, subsystems and conceptual components that were not apparent in the earlier analyses are identified at step 306.
Business operational model analysis (step 308): The conceptual structure of the IT solution being developed must enable and support the execution of the business operational model for the client. Given the conceptual components of the IT solution, the analysis of step 308 determines how these conceptual components need to interact with each other in order to support the business operational model. As used herein, a business operational model is defined as a description, by business stakeholders, of how a business operates to meet business operational goals. While automating business operations, IT solutions must preserve and enable the operational behaviors intended by the business. Design constraints in an IT solution must not require the business to behave in unintended ways. The analysis of step 308 includes describing how the different conceptual components in the solution interact with each other to perform the business functions and confirming that these interactions are consistent with the business operational model. In one embodiment, aggregation and/or partitioning of conceptual components to enable required interactions among conceptual components results from the analysis of step 308. In some cases, new conceptual components are identified to allow certain interactions to be described at a more detailed level. During the analysis of step 308, the operational concepts description is updated to capture the descriptions of the aforementioned interactions among the conceptual components, the IT solution and its systems and subsystems, and external entities including users.
Internal process and algorithm analysis (step 310): At the time of initiating step 310, most conceptual components that make up the IT solution and its systems and subsystems have been identified. The operational concepts description provided by step 318 includes descriptions of these conceptual components and how the conceptual components interact to perform pre-specified business functions. As the operational concepts are developed in detail by step 318, attention is drawn to the internal processes and algorithms of the IT solution that require detailed analysis of the operation of specific conceptual components and their interactions. As used herein, an internal process is a method by which computing structures (e.g., data structures) and algorithms internal to a conceptual component are utilized to perform a required function. In one embodiment, such analysis in step 310 leads to further partitioning of conceptual components and/or aggregation of conceptual components. In some cases, new conceptual components need to be defined to enable the description of specific internal processes or the business logic behind specific algorithms. The internal processes and the algorithms developed in step 310 are captured within the operational concepts description of step 318.
Communication needs analysis (step 312): The conceptual structure defined up to step 312 consists of conceptual components that were identified through a variety of analyses. Such analyses included examining functional requirements (see step 302), external interactions such as with users and external systems (see step 304), a business model (see step 306), a business operational model (see step 308), and internal processes and algorithms (see step 310). Communication requirements among the various conceptual components, among the solution and its one or more systems and one or more subsystems, as well as among the solution and various systems external to the solution are examined closely in step 312. The examination of communication requirements in step 312 identifies conceptual components and subcomponents that are to be added to the system to support a variety of communication needs, including filesharing, file transfer, web services, web browser, and other Internet, intranet, and local area network communications. The intent of step 312 is to identify new communication-specific conceptual components and subcomponents needed to support the required communication capabilities in the system. In step 318 that follows step 312, the operational concepts description is extended to include the operation of the different communication-specific conceptual components and subcomponents identified in step 312, as well as the interactions of the identified communication-specific conceptual components and subcomponents with the rest of the solution, the one or more systems, the one or more subsystems and external systems.
Information needs analysis (step 314): As the conceptual structure and the corresponding operational concepts are developed (e.g., developed via steps 302-312 and 318), a variety of information needs to support the operational concepts emerges. The information needs are captured and represented in the conceptual model through descriptions of information manager 134 (see
Description of information manager 134 (see
In one embodiment, the system and the system's one or more subsystems have one or more information repositories depending upon the need to model the information repositories at a conceptual level at an adequate level of detail while not overly complicating the description of the operational concepts.
Non-functional requirements analysis (step 316): Non-functional requirements specify additional quality constraints that a solution must meet in addition to the requirements described above relative to steps 302-314. Non-functional requirements include, for example, one or more of the following considerations:
Quality of Service: The ability of the solution to detect and compensate for potential overload situations.
In step 316, the conceptual structure is examined closely from the perspective of the non-functional requirements of the solution. The analysis of step 316 identifies whether there is a need for new conceptual components and/or determines whether partitioning and/or aggregation of already identified conceptual components is needed in order to enable the solution and the solution's systems and subsystems to meet the non-functional requirements. The non-functional requirements considered and the operational implications to impacted conceptual components are described in the operational concepts description that results from step 318 that follows step 316. Thus, steps 316 and 318 ensure that the conceptual structure of the solution is adequately detailed to be able to describe the concepts behind how the non-functional requirements are satisfied by the solution.
Describing the operational concepts based on the conceptual structure (step 318): The description of the operational concepts resulting from step 318 describes an IT solution and how the IT solution serves the needs of a business. This description of the operational concepts is understood by both business stakeholders and IT stakeholders of the IT solution. This understanding shared by both business and IT stakeholders enables a continuous alignment between the business domain and the IT domain, regardless of changes in technologies, applications, and software products that constitute the IT solution. The operational concepts description provided by step 318 is technology agnostic and provides a stable view of an IT solution that is only modified through governance processes jointly owned by business and IT stakeholders. The operational concepts are captured in sufficient detail in step 318, but not any more than that, in order to improve the clarity, to both business and IT stakeholders, regarding how the IT solution serves the business needs by describing the various components of the IT solution at a conceptual level, how the components interact with one another, and the components' internal processes and algorithms. The operational concepts description provides an end-to-end view of the IT solution, including all of the IT solution's systems and subsystems. Thus, the operational concepts description is a stable reference to the IT solution that facilitates the making of more informed business decisions by business stakeholders that minimize changes to IT solution while leveraging the IT solution for maximum business innovation. The operational concepts description is also useful to IT stakeholders by being a stable reference to the IT solution that provides an end-to-end view of the solution and that explains how the different components of the IT solution together support the business. The process of developing the operational concepts description and how this description is organized is described below relative to
As used herein, a description “at a conceptual level” (e.g., “describing the various components of the IT solution at a conceptual level” as presented above) is defined as a description based on conceptual components and is therefore a high-level or abstract-level description and not a low-level or concrete-level description of an actual implementation of an IT solution. The description at a conceptual level (i.e., the high-level description based on conceptual components) is also called a conceptual description of an IT solution. Any implementation of the conceptual description of the IT solution is an instantiation of the solution. When an IT solution is implemented in compliance with the conceptual model of the IT solution, the structure and operational behavior of every instance of the IT solution can be validated against the conceptual structure and the operational concepts provided by the conceptual model, regardless of variations in the choice of technologies, applications, and software products to implement the IT solution or any part thereof.
As used herein, an instance of the IT solution is validated against the conceptual structure and operational concepts provided by a conceptual model if the following criteria are satisfied:
1. the structural elements of the instance of the IT solution can be mapped readily to conceptual components in the conceptual structure, even though the mapping does not have to be one-to-one mapping;
2. the structural elements of the instance of the IT solution, from the viewpoint of the conceptual components, behave as described in the operational concepts;
3. functions (or services) implemented in the instance of the IT solution can be mapped readily to the functions described by the operational concepts; and
4. functions (or services) implemented in the instance of the IT solution, from the viewpoint of the functions described in the operational concepts, behave as described by the operational concepts.
The process of describing operational concepts starts at step 400. In an initial performance of step 402 which immediately follows step 400, the business and IT stakeholders create a high-level overview of the conceptual structure to develop an end-to-end view of the solution. Step 402 is also iteratively performed as a follow-up step to any of steps 404-414 for the conceptual component currently being processed or for a subsequent conceptual component. When step 402 is performed as a follow-up to step 404, 406, 408, 410, 412 or 414, the business and IT stakeholders update the high-level overview of the conceptual structure that is created in the initial performance of step 402. The update of the high-level overview generated by step 402 is based on one of the specific descriptions provided by the step that immediately precedes step 402 (i.e., one of steps 404-414). These specific descriptions are described below relative to steps 404-414. In one embodiment, any combination of steps 404-414 is performed in parallel. In another embodiment, steps 404-414 are performed in any sequence.
For large and complex solutions, it may be necessary to aggregate the conceptual components into fewer top-level conceptual components in order to be able to produce a simplified end-to-end view of the solution that reduces clutter. The overview provided by step 402 is comprehensive and accurate, but is not detailed.
The high-level overview of step 402 must consist of at least one overall (a.k.a. overview) diagram that shows the end-to-end solution. Significant systems and significant subsystems in the solution are identified at this overall diagram level as needed to provide a high-level description of the conceptual structure and the operational concepts, while avoiding the detail and clutter of low-level descriptions, where the aforementioned description of the conceptual structure is characterized as high-level rather than low-level based on pre-defined criteria. As many additional diagrams as are needed are added to provide further drill-down details of the solution, systems, sub-systems, and components.
Operation of the solution is described using the overall diagram as well as the more detailed drill-down diagrams. The operational descriptions help business and IT stakeholders to understand the business goals for the IT solution and how the IT solution and its systems and subsystems together operate to deliver on the business goals.
Any number of illustrative techniques are used to communicate important concepts in step 402. Such techniques include, for example, sequence diagrams, component interaction diagrams, state diagrams, and collaboration diagrams. In one embodiment, usage of standard IT conventions is avoided in order to make the operational concepts description non-threatening to non-technical business stakeholders. However, the exact notations and conventions that are acceptable depend on the degree of familiarity among the business and IT stakeholder community that use the documentation resulting from step 402.
Non-functional requirements that are significant at the system level are described in the high-level overview created or updated in step 402.
Again, the high-level overview is developed iteratively. As the activities described below relative to steps 404-414 are completed for each conceptual component, the high-level overview evolves toward final completion via updates performed in repeated applications of step 402.
Steps 402 through 414, inclusive, are performed by business and IT stakeholders and are repeated for each conceptual component in the conceptual structure.
In step 404, the business purpose of a conceptual component is documented in the operational concepts description. Step 404 describes the unique value of the conceptual component to the solution, system or subsystem and how the conceptual component is used with regard to the overall operation of the solution.
In step 406, the functions and internal processes for the conceptual component are identified, described and included in the operational concepts description. The activity in step 406 closely examines the functions of a conceptual component. Major functions that are supported by a conceptual component are identified and described in detail, although at a conceptual level only. Functions identified and described in step 406 include those functions needed to enable conceptual component-level interactions. A conceptual component-level interaction is an interaction between a conceptual component and another conceptual component. Conceptual component-level interactions occur only through the functions intended for such interactions and supported by the respective conceptual components. The activity of step 406 is described in more detail below relative to
In step 408, the information management needs of the conceptual component are described and included in the operational concepts description. All information-related functions that must be supported through information manager 134 (see
In step 410, the operation of the conceptual component is described and included in the operational concepts description, focusing on the dynamic interactions between the conceptual component and other conceptual components. The activity of step 410 involves describing the interactions that a conceptual component has with the rest of the solution and the solution's systems, subsystems and components in performing the conceptual component's functions. The interactions are observed from the point-of-view of the conceptual component and described as such. As described above relative to step 406, conceptual component-level interactions occur only through the functions intended for such interactions and supported by the respective conceptual components. Thus, when complete, the description provided by step 410 provides a holistic view of all the interactions of the conceptual component with regard to the solution.
In step 412, the appropriate business model implications for the conceptual component are described and included in the operational concepts description. Prior to step 412, conceptual components were identified through several types of analyses as described in steps 302-316 of
In step 414, the non-functional requirements for the conceptual component are described and included in the operational concepts description. Different non-functional requirements that are significant at the level of the conceptual component being examined are described through the activity of step 414. The non-functional requirements analysis was described above relative to step 316 (see
In step 502, the business purpose of a function associated with the conceptual component is described. The unique value that the function adds to the conceptual component is also documented in step 502. Given that the activity of step 502 is nested within step 318 (see
In step 504, the inputs and outputs of the function are described. The different input and output information related to the function is documented at a conceptual level in step 504. The focus of the step 504 activity is on clarifying how the function can be invoked to obtain pre-defined business value from the function.
In step 506, the steps involved in the internal process that performs the function is described. Step 506 provides a conceptual description of the algorithms and internal process steps that perform the function. The steps involved in executing the function are described at a conceptual level. Significant computing structures internal to the conceptual component that play a key role in the operation of the function are referenced appropriately in the description provided by step 506. The activity of step 506 constrains implementation designs for the function as needed to maintain stability of the operation and behavior of the function, but only to the extent that is essential to meet the business objectives, by describing in adequate detail how the function is expected to operate by relying on computing structures and processes internal to the conceptual component. The aforementioned conceptual description of the algorithms and internal process steps that perform the function provides a stable view of the function, the function's operation, and the function's relationships to key computing structures, regardless of specific technology and design details that can vary from one implementation of the function to another.
In step 508, the information management needs of the function are described. All information-related functions that must be supported through information manager 134 (see
In step 510, the operation of the function in terms of the dynamic interactions with other conceptual components is described. The interactions with other conceptual components that are needed for the proper operation of the function are described in the activity of step 510. Step 506 describes how the function relies on computing structures within the conceptual component. The focus of the activity of step 510 is on higher-level interactions, namely, conceptual component-level interactions involved in the operation of the function. Descriptions of conceptual component-level interactions may refer to functions supported by other conceptual components, as well as to computing structures within those other conceptual components. However, conceptual component-level interactions occur only through the functions intended for such interactions and supported by the respective conceptual components. The aforementioned conceptual description of the algorithms and internal process steps that perform the function provides a stable view of the function, the function's operation, and the function's relationships to other conceptual components, regardless of specific technology and design details that can vary for conceptual components from one implementation to another.
In the example (a.k.a. the learning solution example) provided in this section, there is a need to build an online learning solution for a client. The requirements of the online learning solution are expressed in six categories as described below:
The remaining portions of the learning solution example section develop a conceptual model for the learning solution example using the steps described above relative to
Step 302 (see
Analysis of the operational model presented above identifies the need for a security control component. Thus, step 308 (see
Using the exemplary business operational model steps presented above, several functions needed within an updated student system 904 are identified in step 308 (see
The functions identified as being needed by updated student system 904, as a result of an analysis of the business operational model for a scenario that involves a student accessing a learning content from the list of assigned learning content, are listed below:
Using a similar analysis of the operational model for instructor access, functions needed within updated instructor system 906 are identified along with corresponding conceptual components. These corresponding conceptual components are added to system 906 and include: access learning content 918, author new learning content 920, enroll students 922, search for learning content 924, create reports 926 and security control 928. Similar to system 904, a description of each function in system 906 includes, for example, text, block diagrams, flow charts, sequence diagrams, state diagrams, and other forms of illustration and description as appropriate.
The aforementioned functions relative to systems 904 and 906 must be added to the operational concepts description created in step 318 (see
As applied to the learning solution example, step 310 (see
As applied to the learning solution example, step 312 (see
As applied to the learning solution example, in step 314 (see
In step 316 (see
Conceptual structure 1300 identifies the conceptual components in the learning solution. Conceptual structure 1300 also identifies the systems (e.g., systems 1302, 1304 and 1306) and the systems' conceptual components. Conceptual structure 1300 is a business-aligned description of the structure and components in the learning solution. The conceptual components included in conceptual structure 1300 must interact in a pre-specified way to support the business purposes of the learning solution. Using step 318 (see
In step 402 (see
Instructor system 1306 allows instructors to perform various functions such as:
Instructors connect to learning system 1302 over the Internet 1402 and perform the different functions identified above.
Student system 1304 allows students to access and utilize learning content for learning purposes. The different functions supported for students include:
Instructors and students access learning system 1302 from anywhere as long as they have connectivity to the Internet 1402. Specific bandwidth requirements apply for the Internet connections, depending upon specific implementations of learning system 1302 and specific needs of the learning content used. While the learning solution requires instructors to access and utilize the learning solution using a web browser application on a desktop or laptop computer, students can also use PDAs and mobile telephones to access and utilize the learning solution. The rest of the operational concepts documentation provides a conceptual description of the different parts (i.e., components) of the learning solution and how they interact with one another to perform the necessary functions. The operational concepts also describe important non-functional aspects of the learning solution that are essential to support pre-specified uses of the solution.
Steps 404-414 (see
In step 404 (see
In step 406 (see
Each of the functions listed above is described using the process of
This subsection describes the outcome of step 502 (see
This subsection describes the outcome of step 504 (see
The output from the Learning Content function is one or more files delivered to the requestor. The files that can be returned to the requestor and the conditions under which the files are returned are described in a corresponding section of the operational concepts document.
This subsection describes the outcome of step 506 (see
As one example, the steps listed above are included in the Fetch Learning Content flow diagram in
Returning to inquiry step 1506, if it is determined that the requested learning content is not in an internal content repository, then the requested learning content resides in learning partner system 1404 (see
Following step 1512, the process of
7.9.3.4 Describe the Information Management Needs of the Function
This subsection describes the outcome of step 508 (see
This subsection describes the outcome of step 510 (see
7.9.4 Describe the Information Management Needs of the Conceptual Component
In step 408 (see
Access learning content conceptual component 1004 (see
In step 410 (see
Student-initiated request for learning content: In step 1702, access learning content conceptual component 1004 receives a request for learning content from student access learning content conceptual component 910. If the learning content files corresponding to the requested learning content is located in an internal content repository (e.g., repository 1206 of
If the learning content files are instead located in a partner system (e.g., partner learning system 1404 of
Steps 1712 and 1714 are described in subsection 7.9.6. In step 1720, access learning content conceptual component 1004 returns the requested learning content files to student access learning content conceptual component 910.
Instructor-initiated request for learning content: In step 1704, access learning content conceptual component 1004 receives a request for learning content from instructor access learning content conceptual component 918. As indicated above relative to the student-initiated learning content request, either steps 1706-1708 or steps 1710-1712 are performed to request and retrieve the learning content files corresponding to the requested learning content. Again, steps 1712 and 1716 are described below in subsection 7.9.6. In step 1718, access learning content conceptual component 1004 returns the requested learning content files to instructor access learning content conceptual component 918.
In step 412 (see
The business model specified indicates via business rules that access to learning content may incur a charge depending upon whether the learning content is instructor-created, from a third-party learning system, etc. These business rules are managed by usage tracking and billing conceptual component 804. The business model, however, requires that access learning content conceptual component 1004 reports all learning content returned to requester 1602 (see
In step 414 (see
The non-functional requirement specified in the learning solution example states that the solution must be customizable for private-labelling purposes. If there are specific customization capabilities within access learning content conceptual component 1004, these are described in step 414. The actual customization functions are performed by configuration manager system 1308 (see
Memory 1804 may comprise any known type of data storage and/or transmission media, including bulk storage, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), a data cache, a data object, etc. Cache memory elements of memory 1804 provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. Storage unit 1812 is, for example, a magnetic disk drive or an optical disk drive that stores data. Moreover, similar to CPU 1802, memory 1804 may reside at a single physical location, comprising one or more types of data storage, or be distributed across a plurality of physical systems in various forms. Further, memory 1804 can include data distributed across, for example, a LAN, WAN or storage area network (SAN) (not shown).
I/O interface 1806 comprises any system for exchanging information to or from an external source. I/O devices 1810 comprise any known type of external device, including a display monitor, keyboard, mouse, printer, speakers, handheld device, printer, facsimile, etc. Bus 1808 provides a communication link between each of the components in computing unit 1800, and may comprise any type of transmission link, including electrical, optical, wireless, etc.
I/O interface 1806 also allows computing unit 1800 to store and retrieve information (e.g., program instructions or data) from an auxiliary storage device (e.g., storage unit 1812). The auxiliary storage device may be a non-volatile storage device (e.g., a CD-ROM drive which receives a CD-ROM disk). Computing unit 1800 can store and retrieve information from other auxiliary storage devices (not shown), which can include a direct access storage device (DASD) (e.g., hard disk or floppy diskette), a magneto-optical disk drive, a tape drive, or a wireless communication device.
Memory 1804 includes computer program code 1814 for the conceptual model development process disclosed herein. Further, memory 1804 may include other systems not shown in
The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code 1814 for use by or in connection with a computing unit 1800 or any instruction execution system to provide and facilitate the capabilities of the present invention. For the purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, RAM 1804, ROM, a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read-only memory (CD-ROM), compact disk—read/write (CD-R/W) and DVD.
Any of the components of the present invention can be deployed, managed, serviced, etc. by a service provider that offers to deploy or integrate computing infrastructure with respect to the method of developing a conceptual model to facilitate generating a business-aligned information technology system. Thus, the present invention discloses a process for supporting computer infrastructure, comprising integrating, hosting, maintaining and deploying computer-readable code into a computing system (e.g., computing unit 1800), wherein the code in combination with the computing unit is capable of performing a method of developing a conceptual model to facilitate generating a business-aligned information technology solution.
In another embodiment, the invention provides a business method that performs the process steps of the invention on a subscription, advertising and/or fee basis. That is, a service provider, such as a Solution Integrator, can offer to create, maintain, support, etc. a method of developing a conceptual model to facilitate generating a business-aligned information technology solution. In this case, the service provider can create, maintain, support, etc. a computer infrastructure that performs the process steps of the invention for one or more customers. In return, the service provider can receive payment from the customer(s) under a subscription and/or fee agreement, and/or the service provider can receive payment from the sale of advertising content to one or more third parties.
The flow diagrams depicted herein are provided by way of example. There may be variations to these diagrams or the steps (or operations) described herein without departing from the spirit of the invention. For instance, in certain cases, the steps may be performed in differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the present invention as recited in the appended claims.
While embodiments of the present invention have been described herein for purposes of illustration, many modifications and changes will become apparent to those skilled in the art. Accordingly, the appended claims are intended to encompass all such modifications and changes as fall within the true spirit and scope of this invention. For example, the references to a business disclosed herein may be replaced with any organizational entity, regardless of whether the entity is a for-profit or a non-profit enterprise.