U.S. patent application number 13/415797 was filed with the patent office on 2012-09-13 for automation of business management processes and assets.
This patent application is currently assigned to Apptio, Inc.. Invention is credited to Tavis Dean Elliott, Paul Damien McLachlan.
Application Number | 20120232947 13/415797 |
Document ID | / |
Family ID | 46796898 |
Filed Date | 2012-09-13 |
United States Patent
Application |
20120232947 |
Kind Code |
A1 |
McLachlan; Paul Damien ; et
al. |
September 13, 2012 |
AUTOMATION OF BUSINESS MANAGEMENT PROCESSES AND ASSETS
Abstract
Various embodiments are directed towards automating business
processes and assets. A generated application may have entity
propagation rules that allocate costs among objects in a model.
Entity propagation rules may define how resources may be allocated
and distributed among objects in a model. In at least one of the
various embodiments, entity propagation rules may be defined to
allocate resources based on formulas. in at least one of the
various embodiments, the formulas used to allocate resources may
include filters and matching rules. Further, in at least one of the
various embodiments, matching rules may be based database
referential matches. Entity propagation rules may distribute
resources using formulas that may have terms based on multiple
properties from the participating objects. In at least one of the
various embodiments, the filter and matching formulas may be used
to select the source items and the destination items if allocating
resources between objects.
Inventors: |
McLachlan; Paul Damien;
(Newcastle, WA) ; Elliott; Tavis Dean; (Bothell,
WA) |
Assignee: |
Apptio, Inc.
Bellevue
WA
|
Family ID: |
46796898 |
Appl. No.: |
13/415797 |
Filed: |
March 8, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61450539 |
Mar 8, 2011 |
|
|
|
Current U.S.
Class: |
705/7.23 |
Current CPC
Class: |
G06Q 10/06 20130101;
Y10S 707/955 20130101; G06F 16/289 20190101 |
Class at
Publication: |
705/7.23 |
International
Class: |
G06Q 10/06 20120101
G06Q010/06 |
Claims
1. A method for allocating resources in an application with a
network device that performs actions, comprising: determining at
least one propagation rule for allocating at least one resource for
at least one of a source object and a destination object in the
application; determining at least one source item for the at least
one source object based on the at least one propagation vile;
determining at least one destination item for the at least one
destination object based on the at least one propagation rule;
employing the propagation rule to generate at least one value for
at least a portion of the at least one resource from the. at least
one source item that is allocated to the at least one destination
item, wherein at least the portion of the at least one resource is
accessible to the destination item; and mediating acceptance of at
least one modification to the at least one propagation rule if it
is submitted to a plurality of stakeholders.
2. The method of claim 1, further comprising updating a user
interface to display at least the allocation of the at least one
resource to the at least one destination item.
3. The method of claim 1, wherein the propagation rule further
comprise at least one distribution rule that determines the portion
of the at least one resource that is allocated from the at least
one source item to the at least one destination item.
4. The method of claim 1, wherein the propagation rule further
comprises at least one filter that enables at least one action,
including: determining the at least one source item; and
determining the at least one destination item.
5. The method of claim 1, wherein employing the propagation rule
further comprises performing actions, including: determining a
plurality of source items that allocate the at least one portion of
the at least one resource to a destination item; generating an
allocation ratio table for the plurality of source items; and
employing the allocation ratio table to allocate the at least one
portion of the at least one resource to the destination item,
6. The method of claim 1, wherein employing the propagation rule
further comprises employing at least one property of the at least
one of the at least one source item and the at least one
destination item to generate the at least one value for the at
least portion of the at least one resource.
7. The method of claim 1, further comprising generating at least
one change entry if the propagation rule is modified.
8. The method of Claim wherein the mediation further comprises:
evaluating the modified propagation rule in an isolated
environment; and validating the modified propagation rule based on
a result of the evaluation in the isolated environment.
9. The method of claim 1, further comprising employing an
externally provided benchmark value to perform at least one action,
including: generating at least one other value from the at least
one propagation rule; and accepting the modified propagation
rule.
10. The method of claim 1, wherein mediating further comprises
modifying at least one propagation rule if an affirmative feed back
threshold for the plurality of stakeholders is met regarding the at
least one modification.
11. A system that is operative for allocating resources in an
application with a network device, comprising: a server device,
including: a transceiver device that is operative to communicate
over the network; a memory device that is operative to store at
least instructions; and a processor device that is operative to
execute instructions that enable actions, including: determining at
least one propagation rule for allocating at least one resource for
at least one of a source object and a destination object in the
application; determining at least one source item for the at least
one source object based on the at least one propagation rule;
determining at least one destination item for the at least one
destination object based on the at least one propagation rule; and
employing the propagation rule to generate at least one value for
at least a portion of the at least one resource from the at least
one source item that is allocated to the at least one destination
item, wherein at least the portion of the at least one resource is
accessible to the destination item.
12. The system of claim 11, further comprising updating a user
interface on a client device to display at least the allocation of
the at least one resource to the at least one destination item.
13. The system of Claim 11, wherein the propagation rule further
comprises at least one distribution rule that determines the
portion of the at least one resource that is allocated from the at
least one source item to the at least one destination item.
14. The system of claim 11, wherein the propagation rule further
comprises at least one filter that enables at least one action,
including: determining the at least one source item; and
determining the at least one destination item.
15. The system of claim 11, wherein employing the propagation rule
further comprises performing actions, including: determining a
plurality of source items that allocate the at least one portion of
the at least one resource to a destination item; generating an
allocation ratio table for the plurality of source items; and
employing the allocation ratio table to allocate the at least one
portion of the at least one resource to the destination item.
16. The system of claim 11, wherein employing the propagation rule
further comprises employing at least one property of the at least
one of the at least one source item and the at least one
destination item to generate the at least one value for the at
least portion of the at least one resource.
17. The system of claim 11, further comprising generating at least
one change entry if the propagation rule is modified.
18. The system of claim 11, wherein the mediation further
comprises: evaluating the modified propagation rule in an isolated
environment; and validating the modified propagation rule based on
a result of the evaluation in the isolated environment.
19. The system of claim 11, further comprising employing an
externally provided benchmark value to perform at least one action,
including: generating at least one other value from the at least
one propagation rule; and accepting the modified propagation
rule.
20. The system of claim 11, wherein mediating further comprises
modifying at least one propagation rule if an affirmative feed back
threshold for the plurality of stakeholders is met regarding the at
least one modification.
21. A processor readable non-transitory storage media that includes
instructions for allocating resources in an application with a
network device, wherein execution of the instructions by a
processor device enables actions, comprising: determining at least
one propagation rule for allocating at least one resource for at
least one of a source object and a destination object in the
application; determining at least one source item for the at least
one source object based on the at least one propagation rule;
determining at least one destination item for the at least one
destination object based on the at least one propagation rule; and
employing the propagation rule to generate at least one value for
at least a portion of the at least one resource from the at least
one source item that is allocated to the at least one destination
item, wherein at least the portion of the at least one resource is
accessible to the destination item.
22. The media of claim 21, further comprising updating a user
interface to display at least the allocation of the at least one
resource to the at least one destination item.
23. The media of claim 21, wherein the propagation rule further
comprise at least one distribution rule that determines the portion
of the at least one resource that is allocated from the at least
one source item to the at least one destination item.
24. The media of claim 21, wherein the propagation rule further
comprises at least one filter that enables at least one action,
including: determining the at least one source item; and
determining the at least one destination item.
25. The media of claim 21, wherein employing the propagation rule
further comprises performing actions, including: determining a
plurality of source items that allocate the at least one portion of
the at least one resource to a destination item; generating an
allocation ratio table for the plurality of source items; and
employing the allocation ratio table to allocate the at least one
portion of the at least one resource to the destination item.
26. The media of claim 21, wherein employing the propagation rule
further comprises employing at least one property of the at least
one of the at least one source item and the at least one
destination item to generate the at least one value for the at
least portion of the at least one resource.
27. The media of claim 21, wherein the mediation further comprises:
evaluating the modified propagation rule in an isolated
environment; and validating the modified propagation rule based on
a result of the evaluation in the isolated environment.
28. The media of claim 21, further comprising employing an
externally provided benchmark value to perform at least one action,
including: generating at least one other value from the at least
one propagation rule; and accepting the modified propagation
rule.
29. The media of claim 21, wherein mediating further comprises
modifying at least one propagation rule if an affirmative feed back
threshold for the plurality of stakeholders is met regarding the at
least one modification.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a utility patent application based on
previously filed U.S. Provisional Patent Application Ser. No.
61/450,539 filed on Mar. 8, 2011, the benefit of which is hereby
claimed under 35 U.S.C. .sctn.119(e) and incorporated herein by
reference.
TECHNICAL FIELD
[0002] The present invention relates generally to computer
automated activity based budgeting, forecasting and cost
accounting, and more particularly, but not exclusively to
automating the business management processes associated with
budgeting and financial modeling.
BACKGROUND
[0003] Businesses that strive to remain viable and successful in
today's competitive commercial environment are required to adopt
accurate and responsive budgeting practices. To improve efficiency,
businesses use financial allocation models that apply modem
budgeting, forecasting and cost accounting techniques. For some
accounting techniques, the complexity of the financial allocation
model increases as the number of tracked activities and elements
increases. Therefore, for larger enterprises, sophisticated
computer programs and computing devices are often required to
assist in generating useful and relevant budgets based on financial
allocation models.
[0004] In some cases, the large number of items and entities
required for financial modeling can make development of modeling
applications difficult. Further, the size and complexity of a
financial allocation models can make it difficult to design
allocation rules for the cost allocations between groups and/or
items within the model. Thus, it is with respect to these
considerations and others that the invention has been made.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] Non limiting and non exhaustive embodiments of the present
invention are described with reference to the following drawings.
In the drawings, like reference numerals refer to like parts
throughout the various figures unless otherwise specified. For a
better understanding of the present invention, reference will be
made to the following Description of the Various Embodiments, which
is to be read in association with the accompanying drawings,
wherein:
[0006] FIG. 1 illustrates a system diagram showing components of an
environment in which at least one of the various embodiments may be
practiced;
[0007] FIG. 2 shows one embodiment of a client device that may be
included in a system in accordance with the embodiments;
[0008] FIG. 3 shows one embodiment of a network device that may be
included in a system implementing at least one of the various
embodiments;
[0009] FIG. 4 illustrates a data processing system adapted to
facilitate the rapid development of a data processing application
in accordance with the various embodiments;
[0010] FIG. 5 shows an architectural structure of a data processing
system configured to facilitate the rapid development of a data
processing application in accordance with the embodiments;
[0011] FIG. 6 shows a flowchart for a process that may be used to
facilitate the rapid development of a software application for at
least one of the various embodiments;
[0012] FIG. 7 shows an overview flowchart for a process for rapidly
development of a data processing application in accordance with at
least one of the various embodiments;
[0013] FIG. 8 shows an overview flowchart for a process for
generating a data processing application in accordance with at
least one of the various embodiments;
[0014] FIG. 9 shows a flowchart for a process for applying a
template to a generated application in accordance with the
embodiments;
[0015] FIG. 10 shows a flowchart for a process to execute or
retrieve the generated data processing application in accordance
with the embodiments;
[0016] FIG. 11 shows a flowchart for a process for executing change
entries in accordance with at least one of the various
embodiments;
[0017] FIG. 12 illustrates a logical schematic of a generated
application in accordance with at least one of the various
embodiments;
[0018] FIG. 13 illustrates an embodiment of a generated data
processing application that at least enables visualization of
financial allocation, model in accordance with the embodiments;
[0019] FIG. 14 illustrates a partial view a work stream that may
include change entries in accordance with at least one of the
various embodiments;
[0020] FIGS. 15-18 illustrate a logical representation of a
generated data processing application in accordance with the
various embodiments;
[0021] FIG. 19 shows a data processing platform arranged to mediate
business-related metrics and entity propagation rules between human
stakeholders and data sources in accordance with at least one of
the various embodiments;
[0022] FIG. 20 illustrates the operation of a logic module that
mediates business related metrics and entity propagation rules in
accordance with at least one of the various embodiments;
[0023] FIG. 21-23 shows an overview flowchart for process to
mediate stakeholder actions on a generated application in
accordance with at least one of the various embodiments;
[0024] FIG. 24 shows an overview flowchart for a process that may
be used to apply entity propagation rules in accordance with the
embodiments;
[0025] FIG. 25 shows an overview flowchart for a process for
executing a entity propagation rule in accordance with at least one
of the embodiments;
[0026] FIG. 26 shows a screenshot of a GUI in a generated
application that may facilitate the definition of an entity
propagation rule in accordance with at least one of the various
embodiments; and
[0027] FIGS. 27-35 show use cases applying various entity
propagation rules between objects in accordance with the
embodiments.
DESCRIPTION OF THE VARIOUS EMBODIMENTS
[0028] The present invention now will be described more fully
hereinafter with reference to the accompanying drawings, which form
a part hereof, and which show, by way of illustration, specific
embodiments by which the invention may be practiced. This invention
may, however, be embodied in many different forms and should not be
construed as limited to the embodiments set forth herein; rather,
these embodiments are provided so that this disclosure will be
thorough and complete, and will fully convey the scope of the
invention to those skilled in the art. Among other things, the
present invention may be embodied as methods or devices.
Accordingly, the present invention may take the form of an entirely
hardware embodiment, an entirely software embodiment or an
embodiment combining software and hardware aspects. The following
detailed description is, therefore, not to be taken in a limiting
sense.
[0029] Throughout the specification and claims, the following terms
take the meanings explicitly associated herein, unless the context
clearly dictates otherwise. The phrase "in one of the embodiments"
or "in at least one of the various embodiments" as used herein does
not necessarily refer to the same embodiment, though it may.
Furthermore, the phrase "in another embodiment" as used herein does
not necessarily refer to a different embodiment, although it may.
Thus, as described below, various embodiments of the invention may
be readily combined, without departing from the scope or spirit of
the invention.
[0030] In addition, as used herein, the term "or" is an inclusive
"or" operator, and is equivalent to the term "and/or," unless the
context clearly dictates otherwise. The term "based on" is not
exclusive and allows for being based on additional factors not
described, unless the context clearly dictates otherwise. In
addition, throughout the specification, the meaning of "a," "an,"
and "the" include plural references. The meaning of "in" includes
"in" and "on."
[0031] As used herein, the term "Financial allocation model,"
refers to a graph based representation of a system of financial
allocation rules that can be used for costing actual expenditures
(for management accounting) or budgeting future expenditures. Nodes
in the model may represent classes of items that may be associated
with costs and/or expenses. The edges of the graph may represent
how the costs and/or expenses may be allocated between the nodes. A
financial allocation model may be a visual rendering of a graph
showing the nodes and the edges connecting the nodes.
[0032] As used herein, the term "Cost line item," refers to a
single line item in a budget (or finance allocation model) and its
associated cost/expense. For example, the costs associated with a
particular computer that is an email server may be a single item
having a particular cost (e.g., the email server may correspond to
a cost line item).
[0033] As used herein, the term "Cost object," refers to a set
and/or class of cost line items that may be grouped together. For
example, a collection of computers performing services such as
email, web serving, enterprise resource planning, may represent
separate cost line items and they may be grouped into the cost
object Servers.
[0034] As used herein, the term "Allocation rules," "entity
propagation rules," or "propagation rules" refers to rules in the
financial allocation model that determine how the costs/expenses
from a cost object are allocated between/among other cost objects.
Also, such rules may be assigned to individual cost line items. For
example, if an email server cost line item has a value of $1000 an
allocation or entity propagation rule may be defined such that 50%
of the expense may be allocated to the Marketing department and 50%
may be allocated to the Engineering department. Also, allocation
rules may be applied at the cost object as well as the cost line
item level.
[0035] As used herein, the term "Assignment ratios," refers to an
allocation rule, or the results of applying one or more rules, of
the distribution ratio of costs to cost line items or cost objects.
For example, if $1000 may be allocated to cost object Servers, and
the cost line item Email Server is allocated $800 and the cost line
item FTP Server is allocation $200, the assignment ratios may be
determined to 80% to budget item line Email Server and 20% to cost
line item FTP Server. Assignment ratios may be explicitly defined
by allocation rules. Or they may be derived from the allocation
tables by converting the values into ratios of the total allocation
to the cost object.
[0036] As used herein, the terms "generated application," and/or
"generated. data processing application," refers to an application
that has been generated using the platform for rapid application
development. Various embodiments disclosed herein may be related to
financial applications. But, one of ordinary skill the art will
appreciate that generated data processing applications are not
limited to financial applications.
[0037] As used herein, the term "Work Stream," refers to preserved
records of the actions and events that may have been taken to
generate a data processing application in accordance with at least
one of the various embodiments. In general, a generated application
may be a combination of an associated work stream and associated
data. In at least one of the various embodiments, a operative data
processing application may be generated from a work stream and
appropriate source data. In at least one of the various
embodiments, a work stream may be implemented as an audit log.
[0038] As used herein, the term "change entry," refers to
individual elements that may be combined and/or collected into a
work stream. Each change entry may be a record of one or more
actions and/or state changes made to a generated data processing
application as part of the application generation process.
[0039] The following briefly describes the embodiments of the
invention in order to provide a basic understanding of some aspects
of the invention. This brief description is not intended as an
extensive overview. It is not intended to identify key or critical
elements, or to delineate or otherwise narrow the scope. Its
purpose is merely to present some concepts in a simplified form as
a prelude to the more detailed description that is presented
later.
[0040] Briefly stated, various embodiments are directed towards
automating business processes and assets. In at least one of the
various embodiments, a generated application may have entity
propagation rules that allocate costs among objects in a model. In
at least one of the various embodiments, entity propagation rules
may define how costs and/or services may be allocated and
distributed among objects in a model. In at least one of the
various embodiments, entity propagation rules may be defined to
allocate resources based on formulas. In at least one of the
various embodiments, the formulas used to allocate resources may
include filters and matching rules. Further, in at least one of the
various embodiments, matching rules may be based on database
referential matches.
[0041] In at least one of the various embodiments, entity
propagation rules may distribute resources using formulas that may
have terms based on multiple fields/properties from the
participating objects. Also, fields/properties from objects not
directly connected to a entity propagation rule may contribute to
matching, filtering, and distribution of the resources.
[0042] In at least one of the various embodiments, the filter and
matching formulas may be used to select the source items and the
destination items if allocating resources between objects.
[0043] Furthermore, in at least one of the various embodiments, a
mediation module may mediate proposals offered by stakeholders
and/or generated application users to modify business-metrics and
values in a generated application. In at least one of the various
embodiments, the mediation module may enable multiple stakeholders
to contribute proposals to modify values in the generated
application. En at least one of the various embodiments, the
mediation module may enable multiple stakeholders to review pending
modifications and provide feedback including, whether to accept or
reject modification proposals.
[0044] Additionally, at least one of the various embodiments
employs a platform or system for rapid development of applications.
In at least one of the various embodiments, a data processing
application may be generated by uploading example data, applying
templates, application architectures, models, work streams, change
entries, and user modifications to generate data processing
applications. In at least one of the various embodiments, the
applications may be generated based on project initial instructions
and by receiving and processing example data in combination with
templates, models, application architectures, change entries, and
work streams. Further, in at least one of the various embodiments,
modifications made to the generated applications may be preserved
as change entries associated with a work stream.
[0045] In at least one of the various embodiments, separate
applications may be generated based on the work streams and/or
change streams of other applications. In at least one of the
various embodiments, if a generated application may be modified a
new revision number may be associated with the modified version of
the application. In at least one of the various embodiments, if a
user begins interacting with an out of date application, this
application may be re-generated based on newer versions of the
relevant work streams.
[0046] In at least one of the various embodiments, if the
application becomes out of date (due to a user making a change,
uploading new data, another precedent application being modified,
etc), a user may continue using the out-of-date application until
the updated application has been generated and completed
initialization.
Illustrative Operating Environment Of Platform For Rapid
Development Of Applications
[0047] FIG. 1 shows components of one embodiment of an environment
in Which at least one of the various embodiments may be practiced.
Not all the of components may be required to practice various
embodiments, and variations in the arrangement and type of the
components may be made. As shown, system 100 of FIG. 1 includes
local area networks ("LANs")/wide area networks ("WANs")-(network)
111, wireless network 110, client devices 101-104, and Data
Processing Platform (DPP) 107.
[0048] Generally, client devices 102-104 may include virtually any
portable computing device capable of receiving and sending a
message over a network, such, as network Ill, wireless network 110,
or the like. Client devices 102-104 may also be described generally
as client devices that are configured to be portable. Thus, client
devices 102-104 may include virtually any portable computing device
capable of connecting to another computing device and receiving
information. Such devices include portable devices such as,
cellular telephones, smart phones, display pagers, radio frequency
(RF) devices, infrared (IR) devices, Personal Digital Assistants
(PDA's), handheld computers, laptop computers, wearable computers,
tablet computers, integrated devices combining one or more of the
preceding devices, or the like. As such, client devices 102-104
typically range widely in terms of capabilities and features. For
example, a cell phone may have a numeric keypad and a few lines of
monochrome Liquid Crystal Display (LCD) on which only text may be
displayed. In another example, a web-enabled mobile device may have
a touch sensitive screen, a stylus, and several lines of color LCD
in which both text and graphics may be displayed.
[0049] Client device 101 may include virtually any computing device
capable of communicating over a network to send and receive
information, including messaging, performing various online
actions, or the like. The set of such devices may include devices
that typically connect using a wired or wireless communications
medium such as personal computers, tablet computers, multiprocessor
systems, microprocessor-based or programmable consumer electronics,
network Personal Computers (PCs), or the like. In at least one of
the various embodiments, at least some of client devices 102-104
may operate over wired and/or wireless network. Today, many of
these devices include a capability to access and/or otherwise
communicate over a network such as network 111 and/or wireless
network 110. Moreover, client devices 102-104 may access various
computing applications, including a browser, or other web-based
application.
[0050] In at least one of the various embodiments, one or more of
client devices 101-104 may be configured to operate within a
business or other entity to perform a variety of services for the
business or other entity. For example, client devices 101-104 may
be configured to operate as a web server, an accounting server, a
production server, an email server, video game server, an inventory
server, or the like. However, client devices 101-104 are not
constrained to these services and may also be employed, for
example, as an end-user computing node, in other embodiments.
Further, it should be recognized that more or less client devices
may be included within a system such as described herein, and
embodiments are therefore not constrained by the number or type of
client devices employed.
[0051] A web-enabled .client device may include a browser
application that is configured to receive and to send web pages,
web-based messages, or the like. The browser application may be
configured to receive and display graphics, text, multimedia, or
the like, employing virtually any web-based language, including a
wireless application protocol messages (WAP), or the like. In at
least one of the various embodiments, the browser application is
enabled to employ
[0052] Handheld Device Markup Language (E-IDML), Wireless Markup
Language (WML), WMLScript, JavaScript, Standard Generalized Markup
Language (SGML), HyperText Markup Language (HTML), eXtensible
Markup Language (XML), HTML5, or the like, to display and send a
message. In at least one of the various embodiments, a user of the
client device may employ the browser application to perform various
actions over a network.
[0053] Client devices 101-104 also may include at least one other
client application that is configured to receive and/or send data,
including budgeting and forecasting information, between another
computing device. Client applications may include a capability to
provide requests and/or receive data relating to the rapid
development of applications including budget projects information.
The client application may initiate and/or receive data
representing change entries, templates, work streams, cost
allocations between or among cost objects that may be part of the
financial allocation model, or the like. In at least one of the
various embodiments, client applications may receive and/or
generate data related to budgeting and financial models and may
generate tables and relationships between and among the data based
on operations that may be performed by a table processor. In at
least one of the various embodiments, client devices 101-104 may
view and/or modify generated data processing applications.
[0054] Wireless network 110 is configured to couple client devices
102-104 and its components with network 111. Wireless network 110
may include any of a variety of wireless sub-networks that may
further overlay stand-alone ad-hoc networks, or the like, to
provide an infrastructure-oriented connection for client devices
102-104. Such sub-networks may include mesh networks, Wireless LAN
(WLAN) networks, cellular networks, or the like.
[0055] Wireless network 110 may further include an autonomous
system of terminals, gateways, routers, or the like connected by
wireless radio links, or the like. These connectors may be
configured to move freely and randomly and organize themselves
arbitrarily, such that the topology of wireless network 110 may
change rapidly.
[0056] Wireless network 110 may further employ a plurality of
access technologies including 2nd (2G), 3rd (3G), 4th (4G), 5th
(5G) generation radio access for cellular systems, WLAN, Wireless
Router (WR) mesh, or the like. Access technologies such as 2G, 3G,
4G, 5G, and future access networks may enable wide area coverage
for mobile devices, such as client devices 102-104 with various
degrees of mobility. For example, wireless network 110 may enable a
radio connection through a radio network access such as Global
System for Mobil communication (GSM), General Packet Radio Services
(GPRS), Enhanced Data GSM Environment (EDGE), Wideband Code
Division Multiple Access (WCDMA), High Speed
[0057] Downlink Packet Access (HSDPA), Long Term Evolution (LTE),
or the like. In essence, wireless network 110 may include virtually
any wireless communication mechanism by which information may
travel between client devices 102-104 and another computing device,
network, or the like.
[0058] Network 111 is configured to couple network devices with
other computing devices, including, DPP 107, client device(s) 101,
and through wireless network 110 to client devices 102-104. Network
111 is enabled to employ any form of computer readable media for
communicating information from one electronic device to another.
Also, network 111 can include the Internet in addition to local
area networks (LANs), wide area networks (WANs), direct
connections, such as through a universal serial bus (USB) port,
other forms, of computer-readable media, or any combination
thereof. On an interconnected set of LANs, including those based on
differing architectures and protocols, a router acts as a link
between LANs, enabling messages to be sent from one to another. In
addition, communication links within LANs typically include twisted
wire pair or coaxial cable, while communication links between
networks may utilize analog telephone lines, full or fractional
dedicated digital lines including T1, T2, T3, and T4, Integrated
Services Digital Networks (ISDNs), Digital Subscriber
[0059] Lines (DSLs), wireless links including satellite links, or
other communications links known to those skilled in the art. For
example, various Internet Protocols (IP), Open Systems
Interconnection (OSI) architectures, and/or other communication
protocols, architectures, models, and/or standards, may also be
employed within network 111 and wireless network 110. Furthermore,
remote computers and other related electronic devices could be
remotely connected to either LANs or WANs via a modem and temporary
telephone link. In essence, network 111 includes any communication
method by which information may travel between computing
devices.
[0060] Additionally, communication media typically embodies
computer-readable instructions, data structures, program modules,
or other transport mechanism and includes any information delivery
media. By way of example, communication media includes wired media
such as twisted pair, coaxial cable, fiber optics, wave guides, and
other wired media and wireless media such as acoustic, RF,
infrared, and other wireless media. Such communication media is
distinct from, however, processor-readable storage devices
described in more detail below.
[0061] DPP 107 may include virtually any network device usable to
perform rapid development and/or generation of data processing
applications, such as network device 200 of FIG. 2. In at least one
of the various embodiments, DPP 107 employs various techniques to
create, define, generate, and/or automated data processing
applications such as budgeting and financial management
applications. DPP 107 may include modules for generating data
processing applications that may apply models that may include
entity propagation rules and/or allocation rules among cost
objects. Furthermore, DPP 107 may include and/or generate data
processing applications for visualizing the generated entity
propagation rules, cost objects, budgets, financial models, or the
like.
[0062] Devices that may operate as DPP 107 include various network
devices, including, but not limited to personal computers, desktop
computers, multiprocessor systems, microprocessor-based or
programmable consumer electronics, network PCs, server devices,
tablet computers, network appliances, or the like. It should be
noted that while DPP 107 is illustrated as a single network device,
the invention is not so limited. Thus, in another embodiment, DPP
107 may represent a plurality of network devices. For example, In
at least one of the various embodiments, DPP 107 may be distributed
over a plurality of network devices and/or implemented using cloud
architecture.
[0063] Moreover, DPP 107 is not limited to a particular
configuration. Rather, DPP 107 may operate using a master/slave
approach over a plurality of network devices, within a cluster, a
peer-to-peer architecture, and/or any of a variety of other
architectures. Thus, DPP 107 is not to be construed as being
limited to a single environment, and other configurations, and
architectures are also envisaged. DPP 107 may employ processes such
as described below in conjunction with FIGS. 4-18 to perform at
least some of its actions.
Illustrative Client Device
[0064] FIG. 2 shows one embodiment of client device 200 that may be
included in a system implementing at least one of the various
embodiments. Client device 200 may include many more or less
components than those shown in FIG. 2. However, the components
shown are sufficient to disclose an illustrative embodiment for
practicing the present invention. Client device 200 may represent,
for example, one embodiment of at least one of client devices
101-104 of FIG. 1.
[0065] As shown in the figure, client device 200 includes a central
processing unit ("CPU") 202 in communication with a mass memory 226
via a bus 234. Client device 200 also includes a. power supply 228,
one or more network interfaces 236, an audio interface 238, a
display 240, a keypad 242, and an input/output interface 248. Power
supply 228 provides power to client device 200. A rechargeable or
non-rechargeable battery may be used to provide power. The power
may also be provided by an external power source, such as an AC
adapter or a powered docking cradle that supplements and/or
recharges a battery.
[0066] Client device 200 may optionally communicate with a base
station (not shown), or directly with another computing device.
Network interface 236 includes circuitry for coupling client device
200 to one or more networks, and is constructed for use with one or
more communication protocols and technologies including, but not
limited to, global system for mobile communication ("GSM"), code
division multiple access ("CDMA"), time division multiple access
("TDMA"), LTE, HSDPA, user datagram protocol ("UDP"), transmission
control protocol/Internet protocol ("TCP/IP"), short message
service ("SMS"), general packet radio service ("GPRS"), WAP, ultra
wide band ("UWB"), IEEE 802.16 Worldwide Interoperability for
Microwave Access ("WiMax"), session initiated protocol/real-time
transport protocol ("SIP/RIP"), or any of a variety of other
wireless communication protocols. Network interface 236 is
sometimes known as a transceiver, transceiving device, or network
interface card ("NIC").
[0067] Audio interface 238 may be arranged to produce and receive
audio signals such as the sound of a human voice. For example,
audio interface 238 may be coupled to a speaker and microphone (not
shown) to enable telecommunication with others and/or generate an
audio acknowledgement for some action. Display 240 may be a liquid
crystal display ("LCD"), gas plasma, light emitting diode ("LED"),
organic LED, electronic ink, or any other type of display used with
a computing device. Display 240 may also include a touch sensitive
screen arranged to receive input from an object such as a stylus or
a digit from a human hand.
[0068] Keypad 242 may comprise any input device arranged to receive
input from a user. For example, keypad 242 may include a push
button numeric dial, or a keyboard. Keypad 242 may also include
command buttons that are associated with selecting and sending
images.
[0069] Client device 200 also comprises input/output interface 248
for communicating with external devices, such as a headset, or
other input or output. devices not shown in FIG. 2.
[0070] Input/output interface 248 can utilize one or more
communication technologies, such as USB, infrared, Bluetooth.TM.,
or the like.
[0071] Mass memory 226 includes a Random Access Memory ("RAM") 204,
a Read-only Memory ("ROM") 222, and other storage means. Mass
memory 226 illustrates an example of computer readable storage
media (devices) for storage of information such as computer
readable instructions, data structures, program modules or other
data. Mass memory 226 stores a basic input/output system ("BIOS")
224 for controlling low-level operation of client device 200. The
mass memory also stores an operating system 206 for controlling the
operation of client device 200. It will be appreciated that this
component may include a general-purpose operating system such as a
version of UNIX, or LINUX.TM., or a specialized client
communication operating system such as Windows Mobile.TM., Google
Android.TM., Apple iOS.TM., or the Symbian.RTM. operating system.
The operating system may include, or interface with a Java virtual
machine module that enables control of hardware components and/or
operating system operations via Java application programs.
[0072] Mass memory 226 further includes one or more data storage
208, which can be utilized by client device 200 to store, among
other things, applications 214 and/or other data. For example, data
storage 208 may also be employed to store information that
describes various capabilities of client device 200. The
information may then be provided to another device based on a
variety of events, including being sent as part of a header during
a communication, sent upon request, or the like. At least a portion
of the information may also be stored on a disk drive or other
computer-readable storage device (not shown) within client device
200. Further, as illustrated, data storage 208 may also store
object relationship data 210. In some embodiments, financial data
210 may include a database, text, spreadsheet, folder, file, or the
like, that may be configured to maintain and store various budget
data, propagation rules, audit logs, change entries, work streams,
application templates, device data, or the like. Such financial
data 210 may also be stored within any of a variety of other
computer-readable storage devices, including, but not limited to a
hard drive, a portable storage device, or the like, such as
illustrated by non-transitory computer-readable storage device 230.
In yet other embodiments, data storage 208 may also store data
associated with financial applications that may be generated in
part by DPP 107.
[0073] Applications 214 may include computer executable
instructions which, when executed by client device 200, transmit,
receive, and/or otherwise process network data. Examples of
application programs include, but are not limited to calendars,
search programs, email clients, IM applications, SMS applications,
voice over Internet Protocol ("VOW") applications, contact
managers, task managers, transcoders, database programs, word
processing programs, security applications, spreadsheet programs,
games, search programs, and so forth. Applications 214 may include,
for example, browser 218 and application development client
application 220.
[0074] Browser 218 may include virtually any application configured
to receive and display graphics, text, multimedia, and the like,
employing virtually any web based language. In at least one of the
various embodiments, the browser application is enabled to employ
HDML, WML, WMLScript, JavaScript, SGML, HTML, XML, and the like, to
display and send a message.
[0075] However, any of a variety of other web-based languages may
be employed. In one embodiment, browser 218 may enable a user of
client device 200 to communicate with another network device, such
as DPP 107 of FIG. 1. In one embodiment, browser 218 may enable a
user to view and/or manipulate generated data processing
applications, budget projects, including creating budgets,
modifying financial allocation models, or the like.
[0076] In at least one of the various embodiments, a user may
employ client device 200 to create and manage data processing
applications including budgeting and finance application, and to
access information stored or otherwise managed through DPP 107. In
at least one of the various embodiments, a user may enter various
types of data related to generating data processing applications,
including for generated budgeting and finance applications that may
be accessible through DPP 107, where the data may be heavily
interrelated as might arise within business systems, spreadsheet
type data, or the like. Also, in at least one of the various
embodiments, the user may be enabled to perform a variety of
actions on the data, including, queries, comparisons, summations,
analysis, or the like. Additionally, in at least one of the various
embodiments, a user may employ client 200 to automate one or more
processes that may be used for generating data processing
application and/or financial modeling applications. In at least one
of the various embodiments, data processing platform client
application 220 may be arranged to enable a user to rapidly
generate data processing applications for creating and/or managing
entity propagation rules, framework models, and financial
allocation models. In at least one of the various embodiments,
application 220 may be arranged to generate and render
visualizations of entity propagations (e.g., allocation rules)
among cost objects in a financial allocation model.
[0077] In any event, data processing platform client application
220 may employ processes similar to those described below and
illustrated in FIGS. 4-18 to perform at least some of its
actions.
Illustrative Network Device
[0078] FIG. 3 shows one embodiment of network device 300 that may
be included in a system implementing at least one of the various
embodiments. Network device 300 may include many more or less
components than those shown. The components shown, however, are
sufficient to disclose an illustrative embodiment for practicing
the invention. Network device 300 may represent, for example, DPP
107 of FIG. 1.
[0079] Network device 300 includes processing unit 312, video
display adapter 314, and a mass memory, all in communication with
each other via bus 322. The mass memory generally includes RAM 316,
ROM 332, and one or more permanent mass storage devices, such as
hard disk drive 328, tape drive, optical drive, flash drive, and/or
floppy disk drive. The mass memory stores operating system 320 for
controlling the operation of network device 300. Any
general-purpose operating system may be employed. Basic
input/output system ("BIOS") 318 is also provided for controlling
the low-level operation of network device 300. As illustrated in
FIG. 3, network device 300 also can communicate with the Internet,
or some other communications network, via network interface unit
310, which is constructed for use with various communication
protocols including the TCP/IP protocol. Network interface unit 310
is sometimes known as a transceiver, transceiving device, or
network interface card (NIC). Network device 300 also includes
input/output interface 324 for communicating with external devices,
such as a headset, or other input or output devices not shown in
FIG. 3. Input/output interface 324 can utilize one or more
communication technologies, such as USB, infrared, Bluetooth.TM.,
or the like.
[0080] The mass memory as described above illustrates another type
of processor -readable storage media. Processor-readable. storage
media (devices) may include volatile, nonvolatile, removable, and
non-removable media implemented in any method or technology for
storage of information, such as computer readable instructions,
data structures, program modules, or other data. Examples of
computer readable storage media include RAM, ROM, Electronically
Erasable
[0081] Programmable Read-Only Memory (EEPROM), flash memory or
other memory technology,
[0082] Compact Disc Read-Only Memory (CD-ROM), digital versatile
disks (DVD), Blu-Ray, or other optical storage, magnetic cassettes,
magnetic tape, magnetic disk storage or other magnetic storage
devices, or any other physical medium which can be used to store
the desired information and which can be accessed by any computing
device.
[0083] As shown, data stores 352 may include a database, text,
spreadsheet, folder, file, or the like, that may be configured to
maintain and store various financial allocation models, budget
data, framework models, entity propagation rules, business metrics,
audit logs, device data, or the like. In at least one of the
various embodiments, data stores 352 may further include program
code, data, algorithms, or the like, for use by a processor, such
as central processing unit (CPU) 312 to execute and perform
actions. In at least one of the various embodiments, at least some
of data and/or instructions stored in data stores 352 might also be
stored on another device of network device 300, including, but not
limited to cd-rom/dvd-rom 326, hard disk drive 328, or other
computer-readable storage device resident on network device 300 or
accessible by network device 300 over, for example, network
interface unit 310.
[0084] The mass memory also stores program code and data. One or
more applications 350 are loaded into mass memory and run on
operating system 320. Examples of application programs may include
transcoders, schedulers, calendars, database programs, word
processing programs, Hypertext Transfer Protocol (HTTP) programs,
customizable user interface programs, IPSec applications,
encryption. programs, security programs, SMS message servers, IM
message servers, email servers, account managers, and so forth.
Mass memory may also include data processing platform 354 web
services 356, work streams 358, application templates 360, change
streams 362, table processor 364, generated applications 366, or
the like.
[0085] Web services 356 represent any of a variety of services that
may be configured to provide content, over a network to another
computing device. Thus, web services 356 include for example, a web
server, a File Transfer Protocol (FTP) server, a database server, a
content server, or the like. Web services 356 may provide the
content over the network using any of a variety of formats,
including, but not limited to WAP, HDML, WML, SGML, HTML, XML,
compact HTML (cHTML), extensible (xHTML), or the like.
[0086] In one embodiment, web services 356 may provide an interface
for accessing and manipulating data in a data store, such as data
stores 352, or the like. In another embodiment, web services 356
may provide for interacting with data processing platform 354 that
may enable a user to generate and/or access data processing
applications that may be provided through network device 300.
[0087] In at least one of the various embodiments, work streams
module 358, may be enabled to preserve changes made to generated
data processing applications. In at least one of the various
embodiments, change entries stored in work streams may be used for
the rapid application development. In at least one of the various
embodiments, a work stream may be implemented and/or referred to as
an audit log.
[0088] In at least one of the various embodiments, data processing
platform 354 may enable a user to generate applications, such as
generated applications 366, that may include financial allocation
models, budget models, cost objects, budget objects, budget items,
allocation rules, establish calculation schedules, or the like.
Also, in at least one of the various embodiments, data processing
platform 354 may enable the automating of processes associated with
the generation and/or use of financial allocation models. In at
least one of the various embodiments, data processing platform 354
may generate data processing applications in accordance with at
least one of the various embodiments.
[0089] Further, in at least one embodiment, templates 360 may
enable the generation of applications where at least portions of
the application may be based on pre-defined templates that may be
processed and/or stored by templates application 360. Also, in at
least one of the various embodiments, templates 360 may enable the
rapid application development platform for generating various
financial applications.
[0090] Moreover, web services 356, data processing platform 354,
work streams 358, templates 360, change streams 362, and/or table
processor 364 may employ processes, or parts of processes, similar
to those described below and shown in FIGS. 4-18 to perform at
least some of its actions.
[0091] Generalized Operation Of Platform For Rapid Development Of
Applications
[0092] FIG. 4 illustrates data processing platform 400 adapted to
facilitate the rapid development of a data processing application
in accordance with at least one of the various embodiments. In at
least one of the various embodiments, data processing platform 400
may be included in data processing platform 354 that may be
operative on network device 300.
[0093] In at least one of the various embodiments, data processing
platform 400 may include a plurality of logical layers, (e.g.,
import layer 402, processing layer 406, model layer 410 and
user-interface design layer 414). In at least one of the various
embodiments, the logical layers of the data processing platform
cooperate to produce the generated application.
[0094] In at least one of the various embodiments, there may be
less or more logic modules in the platform that may be operative to
perform rapid application development. For example, in at least one
of the various embodiments, a single logic module may replace the
functionality of processing layer 406, model layer 410 and
user-interface design layer 414, or the functionality of
user-interface design layer 414 may be performed by a plurality of
logic modules. In at least one of the various embodiments, the
functionality of import layer 402 may be integrated in the
functionality of processing layer 406, and therefore the import
layer 402 may not exist at all, may be temporarily deactivated, or
may simply be bypassed in a specific implementation. In at least
one of the various'embodiments, data processing platform 400 may be
configured dynamically, depending on the specific inputs, outputs
and functionality desired.
[0095] In at least one of the various embodiments import layer 402
may receive example data 450. In at least one of the various
embodiments, example data 450 may include financial or operational
related data, asset lists, activity records (such as trouble
tickets, system transaction logs or utilization/response time
records), process/product/service declarations and descriptions,
the like.
[0096] In at least one of the various embodiments, example data 450
may be in any format as long as the format may be recognized and
may be processed by data processing platform 400. For example, in
at least one of the various embodiments, example data 450 may be
encrypted, compressed, or formatted in a data file that may comply
with a specific file format (e.g., XML, CSV, TSV).
[0097] In at least one of the various embodiments, import layer 402
may be included in data processing platform 354. In at least one of
the various embodiments, import layer 402 may use the human input
interface 248. Further, in at least one of the various embodiments,
import layer 402 may include or utilize the video display adapter
314.
[0098] In at least one of the various embodiments, at least a part
of example data 450 may be received from a user. In at least one of
the various embodiments, if transmitting example data 450 to import
layer 402, a user may upload the example data in a file, input it
through a graphical user interface, create it through a set of
prompts presented to the user via a graphical user interface (e.g.,
via checklists, drop-down menus, input boxes and/or other data
entry fields), email it, direct the platform to retrieve the data
from a local or remote location, otherwise communicate it directly
or indirectly to import layer 402, or through any combination of
the foregoing.
[0099] In at least one of the various embodiments, a user may be
presented with a file upload dialog box (e.g., user-interface
screen or window) for use in uploading a dataset. In at least one
of the various embodiments, the file upload dialog box may be used
for the initial upload, and/or for subsequent updates of data, such
as a table of data or another dataset. in at least one of the
various embodiments, the file upload dialog box may have options
for overwriting or appending to a dataset previously stored in the
platform. In at least one of the various embodiments, a file upload
dialog box may have an option for the time period into which the
upload may take effect (e.g., an effective time period).
[0100] In at least one of the various embodiments, a graphical
user-interface window may provide visual feedback to a user in
connection with the validation of uploaded data. In at least one of
the various embodiments, an update prompt may indicate that data
validation may be in progress. In at least one of the various
embodiments, a user may be notified if a data validation process
has detected differences if compared against a preexisting dataset.
A more detailed discussion of data validation in connection with
embodiments of this invention is found in U.S. patent application
Ser. No. 12/467,120 filed on May 15, 2009, entitled
"Operational-Related Data Computation Engine", which is
incorporated by reference into this patent application in its
entirety.
[0101] In at least one of the various embodiments, during and/or
after the example data may be uploaded into data processing
platform 400, a user may utilize additional user interfaces
elements to selectively edit and/or modify the uploaded example
data as necessary. In at least one of the various embodiments, such
editing may be required to ensure that the uploaded data may
conform to the requirements of the current application. Further, in
at least one of the various embodiments, data items from the
example data may be grouped and classified by a user through
user-interfaces or the operation of rule based policies, custom
scripts, mapping functions, or the like.
[0102] In at least one of the various embodiments, after receiving
example data 450, import layer 402 may process at least part of
example data 450. For example, in at least one of the various
embodiments, import layer 402 may decrypt, decompress, transform
into different formats, or otherwise process all or part of example
data 450. In at least one of the various embodiments, import layer
402 may selectively extract only part of example data 450 and
selectively ignore part of example data 450 (e.g., for example,
import layer 402 may be configured or instructed to use only
specific subsets of example data 450 depending on the specific
types of data processing applications to be generated by data
processing platform 400 or depending on the format of example data
450 and/or other applicable circumstances.
[0103] In at least one of the various embodiments, import layer 402
transmits at least part of example data 450, whether processed or
unprocessed, to processing layer 406.
[0104] In at least one of the various embodiments, processing layer
406 may be adapted to generate transformed data from the imported
example data. In at least one of the various embodiments,
transformation may include hiding columns, adding columns, grouping
columns, applying filters, or like.
[0105] In at least one of the various embodiments, user 480 may
review the operation of processing layer 406 and/or may provide
input to the processing layer 406 regarding the structure of the
transformed data as part of preparing the application architecture
420 and/or the process to be used to produce application
architecture 420. (This type of interaction may be indicated by the
dotted arrows shown in FIG. 4.)
[0106] In at least one of the various embodiments, model layer 410
may be used for generating at least part of application
architecture 420 using data provided by processing layer 406. In at
least one of the various embodiments, model layer 410 may be
further adapted to generate application logic 424 that may be based
on at least part of application architecture 420. In at least one
of the various embodiments, model layer 410 may be used to generate
one or more models representing the data, objects, and rules for
the operation of the generated application.
[0107] In at least one of the various embodiments, application
logic 424 may include logic modules or other structural components,
such as software modules, software routines, references to external
logic modules or data processing systems with the ability to engage
such external logic modules or data processing systems to process
data, references to external logic modules with the ability to
receive data from such logic modules or data processing systems,
application programming interfaces adapted to communicate with
external logic modules or data processing systems, or other data
processing components or systems, or the like.
[0108] Further, in at least one of the various embodiments,
application logic may include rules that determine how other parts
of the model interact and/or relate to each other. In at least one
of the various embodiments, users may use the data processing
platform to create and/or modify these rules that may be of the
application logic.
[0109] In at least one of the various embodiments, as part of
generating application logic 424, model layer 410 may employ
processes as further described in connection with the embodiments
of FIGS. 5 and 6.
[0110] In at least one of the various embodiments, user 480 may
review the operation of model layer 410 and/or may provide input to
the model layer 410 regarding the structure of application logic
424 and/or the application logic 424. (This type of interaction may
be indicated by the dotted arrows shown in FIG. 4.)
[0111] In at least one of the various embodiments, user-interface
design layer 414 may apply at least part of application logic 424
and application architecture from model layer 410. In at least one
of the various embodiments, user-interface design layer 414 may be
adapted to generate user-interface reports and components for use
by users of data processing application 490 based on at least part
of the processed data, application architecture 420, models, and
application logic 424.
[0112] In at least one of the various embodiments, data processing
platform 354 may be used as a platform for rapid generation and/or
rapid development of applications that may be operative singly or
in combination to perform one or more of the following
functions:
[0113] Customized Cost Measurement and Analysis. In at least one of
the various embodiments, a data processing application may have the
capability to build custom financial models for cost distribution
through cost pools, cost drivers and cost objects, and the ability
to run ad-hoc queries on the results of those calculations along
various dimensions, such as time, cost category or tracing how a
particular cost line item flows through the financial model.
[0114] Information Technology Financial Management. In at least one
of the various embodiments, a data processing application may
encompass many aspects of managing the finances of information
technology departments and may include custom financial cost
models, automating a budgeting process, demand
planning/forecasting, billing, vendor/supplier management, or the
like.
[0115] Business Intelligence. and Reporting and Analytics. In at
least one of the various embodiments, a data processing application
may have the capability to produce "Business Intelligence" that may
be in the form of tables, data visualization charts, gauges, or the
like, to aid the analysis of large sets of typically
multi-dimensional data. In the existing and prior art, Business
Intelligence solutions are generally hand-developed by teams of
programmers and database administrators. But, at least one of the
various embodiments may provide a rapid application development
platform that may be used by business analysts to develop
applications without requiring an advanced IT skill set.
[0116] Budgeting. In at least one of the various embodiments, a
data processing application may have the capability to automate the
capture of budget information from budget owners within an
organization and to mediate the multi-phase negotiation process
that may result in an approved and locked budget for subsequent
fiscal periods. In at least one of the various embodiments, data
processing applications may involve one or more of the following:
[0117] (a) one or more custom screens containing editable tables
for budget owners to enter expected expenses in a variety of forms,
including direct line items, new purchases that must be
depreciated, expected labor use, etc. (such data may be entered in
hours, number of full-time-employees or other appropriate
measurement units); and [0118] (b) a customized workflow that may
enable a budget to be submitted, notifying one or more approvers of
the submission, the application may allow the approvers to suggest
changes, notifying one or more budget owners, approving the budget
fully or partially, submitting the budget for additional levels of
approvals, security features, or the like.
[0119] Forecasting. In at least one of the various embodiments, if
a budget may be created for a particular fiscal period (e.g., a
year, quarter, month, or the like), a data processing application
may provide a process for monitoring actual money spent against
that budget as well as changes to the expected financial numbers or
forecast.
[0120] In at least one of the various embodiments, the automation
of such a process may include a cost entry capability, forecast
adjustment capability and analysis, ad-hoc query capabilities, or
the like, that may be used for analyzing the current status of the
forecast against actual spend and budget. In at least one of the
various embodiments, the cost entry capability may include one or
more editable tables that may facilitate entry or adjustment of a
budget, a complex financial model that transforms cost from a
different source format,. or the like. In at least one of the
various embodiments, the source format may be a corporate general.
ledger system, or specific sub-ledgers. In at least one of the
various embodiments, sub-ledgers may be kept within the system
(e.g., the generated data processing application) and may be
updated or changed as editable tables on a screen. In at least one
of the various embodiments, sub-ledgers may be external to the data
processing platform and may be loaded either manually or through an
automated process that may be integrated with an external
accounting/finance system.
[0121] Planning and Demand Forecasting and Management. Budgets for
shared services within companies (such as IT, Telecom or
Facilities) may often be set in financial terms (e.g., "5% increase
in storage costs"). Often, such financial terms are, at best,
educated guesses. Demand Forecasting is a more disciplined approach
that involves consumers of shared services estimate their expected
usage in a subsequent fiscal period, and the estimated figures are
then used to compute the financial ramifications, which impact the
budget requests, for the shared service. For example, instead of
"5% increase in storage cost", with a Demand Forecasting approach,
seventeen different departments may enter information in a form
similar to "Hiring 10 new executives and 90 new knowledge
workers".
[0122] In response to such a Demand Forecasting data entry methods,
in at least one of the various embodiments, a data processing
application may have the capability to use a financial model that
may employ assumptions, policies and historical information to
calculate that one of the services employees will use is email,
that executives generally use 5 GB (gigabytes) of email storage in
their first year, and that knowledge workers generally use 2 GB of
email storage in their first year. In at least one of the various
embodiments, based on such an analysis a data processing
application may calculate the total amount of additional storage
necessary in GB as a result of these expected. personnel additions.
In at least one of the various embodiments, a data processing
application may be able to calculate that the variable unit rate of
Tier 1 storage (such as may be used for email) is currently
$0.33/GB and thus calculate one slice of the additional budget
requirements for storage in the next fiscal period. In at least one
of the various embodiments, these capabilities of data processing
applications may apply to many department services, such as
"email", "CRM", "mobile phone", "laptop", and others. In at least
one of the various embodiments, budgets produced by data processing
applications may be more accurate and more defensible than an
educated "5%" guess.
[0123] Billing, Showback and Chargeback. In at least one of the
various embodiments, a data processing application may include a
capability to produce or "show" a bill for use of shared corporate
services (such as IT or telecom). In at least one of the various
embodiments, both the display of this bill and the production and
review process of the bill may be automated using such an
application. In at least one of the various embodiments, the
display of the bill may be security controlled and redacted so that
each individual can only see that individual's own bill. In at
least one of the various embodiments, the billing process may be
automated by, once the necessary inputs (costs and usage quantities
for a particular billing period) have been entered, notifying the
billing manager (typically someone in the finance group or a
service manager) that the bills are ready for review. In at least
one of the various embodiments, the billing manager may choose to
review each bill, make adjustments or add comments, and then
"publish it", whereby the application can make it available to and
notify the recipient that the bill is ready. In at least one of the
various embodiments, the recipient can "accept" the bill or dispute
it (e.g., initiate an inquiry). In at least one of the various
embodiments, the billing manager may be notified of disputes and a
workflow may be customized for handling any recipient who does not
accept a bill within a certain amount of time. In at least one of
the various embodiments, actions taken in this circumstance may
vary from automatically accepting the bill, initiating a
notification to a manager, entering into any other
designed/customized workflow, or the like. In at least one of the
various embodiments, if bills have been accepted, in a chargeback
scenario, entries may be automatically or manually posted into an
external general ledger (GL) accounting system, or the like.
[0124] Project Portfolio Management. In at least one of the various
embodiments, a data processing application may include the ability
to automate a customizable process of accepting project proposals,
and may run such proposals through a review/approval workflow
(e.g., accepting different input parameters from various
stakeholders along the way). In at least one of the various
embodiments, once a project begins, the automation may include both
the tracking of the project's execution, including progress against
goal and costs incurred (including in terms of labor hours,
capital, and operational and other expenses). In at least one of
the various embodiments, the application presents and enables
analytic/ad-hoc questions against the current "portfolio" of active
and proposed projects along axes such as risk, expected ROI and
investment/cost/effort.
[0125] Time Tracking and Labor Management. In at least one of the
various embodiments, a data processing application may automate the
collection of time tracking information from employees or
contractors of an organization, along with a variety of best
practice management reports about them. In at least one of the
various embodiments, this information may be integrated into other
applications, such as for Project Portfolio Management (to track
incurred costs of a project) or Service Costing to track how much
money is operationally being spent by the department on the various
duties of employees. Many workers, but especially knowledge workers
(as is prevalent in IT) have duties that vary on a day-by-day and
week-by-week basis. Without an automated system to capture relevant
operational data and analyze it, more advanced analytics about the
operational performance of the organization tend to be so
inaccurate as to be invalid.
[0126] In at least one of the various embodiments, a data
processing application may generate advanced analytics by providing
more accurate and relevant underlying data and analytics. Vendor.
Supplier and Cloud Management. Vendor/Supplier management tracks
and improves vendor, and respectively supplier chains. The general
domain of vendor management may include the capture of agreements
with vendors, collection of the ways in which an organization is
using each vendor (including capture of utilization information),
measuring and mediating the relative satisfaction of the
organization with vendors, and associated analytics necessary to
aid with negotiations and decision making with each vendor
(including vendor rationalization, reduction and
simplification).
[0127] In at least one. of the various embodiments, a data
processing application may import vendor pricing information and
may import and calculate cross-industry benchmarks (that is,
aggregates from other organizations) to aid with vendor
negotiations or cost management. As part of the transition to
cloud-based data management, there has been a movement in the IT
industry to a services (often Internet-delivered services) approach
where vendor and supplier management becomes both more critical
(e.g., more money may be involved) and more difficult as the
central IT organization is not always involved by a decentralized
decision making and/or outsourcing process. In such cases, in at
least one of the various embodiments, a data processing application
may provide and integrate additional data capturing and analysis to
capture or audit asset and service usage (for example at the
network layer). Additional areas of vendor, supplier and cloud data
management are described in more detail below.
[0128] Contract Management. In at least one of the various
embodiments, a data processing application may provide a system
that maintains records of active and proposed contracts with third
parties (such as other companies). In at least one of the various
embodiments, details tracked may include the start and end date of
a contract, identity-related data for the vendor who may be a party
to the contract, the total monetary cost of the contract, or the
like. Further, in at least one of the various embodiments,
references into the Service Level Agreement (SLA) for the contract
may also be maintained. In at least one of the various embodiments,
a copy of the actual contract document may also be stored in
electronic form, for reference or comparison purposes. In at least
one of the various embodiments, as multiple stakeholders become
involved in the approval, measurement (e.g., against SLAs) and
ongoing maintenance of the contract, a data processing application
may provide significant advantages for managing and facilitating
this process.
[0129] Service Level Agreements (SLA) & Service Level
Management (SLM). Contracts may often be written to require certain
levels of performance or quality. For example, a particular system
might be contractually required to be available 99.999% of the
time, or respond to requests, on average within 2 seconds. The
calculations sometimes become complex (for example, a simple
99.999% uptime means that roughly 5 minutes of downtime may be
permissible in a year). However, a service might require 99.999%
uptime only during business hours. In such cases, computations may
need to take into account working hours, weekends and locale
specific public holidays, and other specific information in order
to properly compute the percentage uptime achieved.
[0130] In at least one of the various embodiments, a data
processing application may include a function that may be able to
compute downtime duration for working hours. in at least one of the
various embodiments, a data processing application may manage such
details (e.g., what requirements relate to particular systems) and
may calculate and model organization and/or system performance
against SLA and/or SLM requirements, or the like.
[0131] Surveys. In the absence of specific SLA requirements or of
capabilities to capture the raw data for measurement against SLA
requirements, in at least one of the various embodiments, a data
processing application may be used to perform automated or
substantially automated collection of survey forms from various
stakeholders in an organization. In at least one of the various
embodiments, such surveys may include an annual rating by employees
of the performance of the IT department against qualitative goals
such as "responsiveness" and "cost effectiveness" and "quality". In
at least one of the various embodiments, such surveys may also
include collecting specific feedback from internal stakeholders
about particular vendors or suppliers as a part of Vendor/Supplier
management.
[0132] Service Costing, Shared Services Allocations. and Service
Portfolio Management (SPM). In at least one of the various
embodiments, a data processing application may provide an accurate
financial model that transforms relatively-tangible costs (e.g.,
the cost of a new server, rent for a data center, or salary paid to
an employee) into intangible, but more business-aligned services
(e.g., the cost of an email account or a call into the IT helpdesk
because a user forgot their password). In at least one of the
various embodiments, this may be done by accepting the source input
costs. (e.g., in the form of a data from a General Ledger system)
as well as activity allocation information (e.g., a list of all
calls to the helpdesk, or all servers in the datacenter). The
activity information may also include information about the purpose
of the activity. For example, some servers might be used for
servicing email, while others may be used for running helpdesk
software. Some helpdesk calls are requesting password changes,
others are to request help with a broken laptop. The costs may be
broken down from their original source format into a cost per
activity. For example, records may indicate that call #775 from
9:03 am to 9:10 am on 7/3/2010 was a password change request. In at
least one of the various embodiments, by looking at attributes of
an individual call, such as duration or priority, and following
allocation rules, an data processing application may calculate
costs as $5.00 comprised of $0.80 for a portion of the costs to run
the servers supporting the helpdesk, and $4.20 for labor. In at
least one of the various embodiments, if finished all the `password
change` ticket costs may be added together to' calculate the total
cost of the password change "Service". Such a cost translation may
be particularly valuable from a business decision making
standpoint. For example, if $200,000/year is being spent to
manually change users passwords, a business case may be made to
procure an automated system for handling these requests. In at
least one of the various embodiments, a data processing application
may provide or facilitate SPM processes for the proposal, approval
and initiation of entirely new services, benchmarking of service
costs across many companies, and the ability to tag services in a
variety of ways for further analysis, categorization, or the like.
For example, in at least one of the various embodiments, services
may be tagged as "grow" vs. "sustain" or "retire", or "operational"
vs. "strategic". In at least one of the various embodiments, this
may permit executives to understand, communicate and make better
decisions about total spend and future investments.
[0133] In at least one of the various embodiments, in order to
facilitate benchmarking and service rationalization (e.g., ensuring
the same service is not inefficiently provided in multiple ways),
services may also grouped into multiple, customizable categories.
For example, in at least one of the various embodiments, "Email"
and "Cellphone" may be grouped together into "Communications and
Collaboration".
[0134] Profitability Analysis/Customer Profitability Analysis. In
at least one of the various embodiments, a data processing
application may calculate a cost per customer or business unit. In
at least one of the various embodiments, if this cost may be
combined with revenue information, an application may calculate
customer or business unit profitability. In at least one of the
various embodiments, such computations may not be limited to IT
organizations or data, but, in at least one of the various
embodiments, may also be used to judge the effectiveness of
marketing programs against particular customer segments, or, and at
a higher level, may be used for all functions in an entire business
in virtually any industry. For example, in at least one the various
embodiments, an application may assist a travel management company
to calculate the costs of running each of its websites (including
consumer facing websites and websites for particular resellers,
large customers or the government), and combine that cost with the
marketing costs of promoting each website in order to produce total
costs per function:
[0135] In at least one of the various embodiments, by also
measuring the revenue from each website and tracking historical
performance, a data processing application may enable further
strategic business, operational and organizational analysis.
[0136] Request Management. In at least one of the various
embodiments, a data processing application may be used to automate
the capture of requests for services. In at least one of the
various embodiments, such a request for services may take the form
of a "new request" screen that may add a single row into a request
table, where the user may fill out certain data fields.
[0137] In at least one of the various embodiments, the data
received through such a request may then be fed into an "approval
and action" workflow where the change request may be approved and
may be assigned to the individuals or systems that may be
responsible for effecting a related change.
[0138] Service Catalog. In at least one of the various embodiments,
a data processing application may utilize a service catalog
(denoted a "Service Catalog"). In at least one of the various
embodiments, may be configured as a list of services that may be
available for browsing or searching by users. In at least one of
the various embodiments, the Service Catalog may be organized into
multiple category dimensions. In at least one of the various
embodiments, additional information about the respective services
may be included in one or more editable tables, such as a
description, a human owner, related service level or quality
agreements, criticality, status, or the like.
[0139] Asset Management. In at least one of the various
embodiments, a data processing application may provide a system
that may keep track of asset purchases and leases (e.g.,
server/storage/networking hardware, software licenses, etc.), their
financials (e.g. depreciation), operating metrics (e.g., expected
lifespan), where such assets are or will be provisioned in the
organization, or the like. In at least one of the various
embodiments, an application may also track other operational
metrics such as utilization and quality.
[0140] Financial Modeling. In at least one of the various
embodiments, a data processing application may be used far general
purpose .sup.-financial modeling. In at least one of the various
embodiments, the application may provide a financial tool similar
to a traditional spreadsheet, but without most of a spreadsheet's
limitations.
[0141] In a traditional spreadsheet, models may be built a single
cell at a time, and for a large enough set of rules, this may
become both repetitive and difficult to track (e.g., it may be
difficult to track any exceptions to general rules). In at least
one of the various embodiments, a data processing application may
permit building models with a visual, graphical model. In at least
one of the various embodiments, the model may include propagation
rules that apply over multiple (e.g., millions) of cells.
[0142] In a traditional spreadsheet, formulas may be typically
expressed using cell location (such as "A7*$B$9". In at least one
of the various embodiments, a data processing application may
permit more intuitive representation of formulas, such as
"Cost*ExpectedReturn".
[0143] In a traditional spreadsheet, additions or changes to the
dimensions modeled requires a lot of tedious work to rebuild
dependent parts of the model. In at least one of the various
embodiments, a data processing application may use objects and
object-agnostic metric formulas, which may permit building
financial models that may be more resilient. In at least one of the
various embodiments, the notion of "time" may be pre-built into the
application, significantly reducing the effort involved on one of
the most complex dimensions of financial modeling.
[0144] In at least one of the various embodiments, a data
processing application may provide the capability to capture
changes to a project from multiple users and may make such changes
auditable and undoable (e.g., in ease there are problems). In at
least one of the various embodiments, such changes may be
applicable to change entries and change stream processes, as
further described below.
[0145] Collaboration with a traditional spreadsheet typically
involves entailing multiple versions of spreadsheets between users
and normally requires human intervention in merging changes from
multiple users together. In at least one of the various
embodiments, a data processing application may provide a user
interface delivered using a thin client and a backend server
architecture (e.g., over a website, or over a mobile device such as
a smart phone), so changes from multiple users can be merged and
synchronized in substantially real-time.
[0146] In at least one of the various embodiments, a data
processing application may provide Row-level security and
Cell-level security using a set of filter rules.
[0147] In at least one of the various embodiments, user 480 may
review the operation of the user-interface design layer 414 and/or
may provide input to the user-interface design layer 414 regarding
the structure of the data processing application 490 and/or the
process to be used to produce/generate the data processing
application 490. (This type of interaction may be indicated by the
dotted arrows shown in FIG. 4.)
[0148] In at least one of the various embodiments, data processing
application 490 may be hosted on a server and accessible by users
remotely (e.g., in a cloud computing application), or may be
downloadable in whole or in part to a user's personal computer, may
operate in a web browser, or may otherwise run locally or remotely
relative to the user. In at least one of the various embodiments,
data processing application 490 may be specific to a particular
user (e.g., a software application configured to be used by a
single user using specific credentials). Also, in at least one of
the various embodiments, data processing application 490 may be
configured to be used by a plurality of users.
[0149] In at least one of the various embodiments, data processing
application 490 may serve as the basis for a platform-as-a-service
(PAAS) user application environment. In at least one of the various
embodiments, data processing application 490 may be hosted on one
or more servers, or may be offered from a cloud computing system,
and may be accessed by users who may establish connections from
remote data processing systems (e.g., computers, thin clients,
mobile devices, etc.). In at least one of the various embodiments,
the users may use the data processing application 490 to build one
or more applications. In at least one of the various embodiments,
an application built using data processing application 490
configured as a PAAS may itself be offered as software-as-a-service
(SAAS) hosted on one or more servers or deployed in a cloud
computing system.
[0150] In at least one of the various embodiments, data processing
platform 400 and the generation of data processing application 490
may be achieved using a concept engine. An example of a concept
engine that may be used in connection with various embodiments may
be found in U.S. patent application Ser. No. 12/467,120 filed on
May 15, 2009, entitled "Operational-Related Data Computation
Engine," which is incorporated by reference into this patent
application in its entirety. In at least one of the various
embodiments, a concept engine may perform functions associated with
the schema generator 658, fully linked tables 664 and interaction
screens 668 discussed in connection with FIG. 6.
[0151] At least one advantage of generating a data processing
applications using an embodiment similar to the one described in
connection with FIG. 4 may enable a user to develop software
applications using limited or no programming experience or software
development expertise, in an accelerated timeframe.
[0152] FIG. 5 shows an architectural structure of data processing
platform 500 for at least one of the various embodiments,
configured to facilitate the rapid development of a data processing
application 530 in accordance with at least one of the various
embodiments of the invention. In at least one of the various
embodiments, data processing platform 500 may be included in data
processing platform 354 and data processing application 530 may be
substantially similar to data processing application 490 from FIG.
4.
[0153] In at least one of the various embodiments, data processing
platform 500 may include one or more commanders 502 (only one
shown), one or more master modules 504 and 506, and one or more
physical machines 508 and 510, which may collaborate to achieve the
data processing functionality that the data processing platform 500
may employ to generate one or more data processing applications
530.
[0154] In at least one of the various embodiments, commander 502
may be a commander logic module that may accept one or more
incoming requests from humans (e.g., from user 480) or machines and
may route the request to one or more of masters 504 and 506. In at
least one of the various embodiments, the human request may be
formatted in any format suitable for input into a data processing
system (e.g., request may be read from a database populated with
the assistance of a human, may be received from a keyboard or other
input terminal or GUI, or the like.).
[0155] In at least one of the various embodiments, commander 502
may also manage and monitor the available resources of data
processing platform 500 (e.g., spare "space" on physical machines)
and may respond to resourcing requests from one or more of masters
504 and 506 to instruct agents included in physical machines to
launch new slaves.
[0156] In one implementation, each of masters 504 and 506 may be a
master logic module that may hold a meta definition of data
processing application 530 and may coordinate available. processing
resources of data processing platform 500 to generate and/or
execute data processing application 530.
[0157] In at least one of the various embodiments, each of physical
machines 508 and 510 may perform data processing functions at least
in part at the direction of one or more of master 504, master 506,
and commander 502.
[0158] In at least one of the various embodiments, physical
machines 508 and 510 may include, generate, or control, one or more
agents (e.g., agent 512 and agent 514) and one or more slaves
(e.g., slaves 516, 518, 520, and 522). In at least one of the
various embodiments, each of agents 512 and 514 may be configured
to launch slave nodes or processes (e.g., slaves 516 and 518, and
respectively slaves 520 and 522), that may monitor the health of
such slaves, to restart such slaves, and to inform commander 502
and/or master 504 or respectively 506 how busy the slaves are for
load balancing purposes.
[0159] In at least one of the various embodiments, at least one of
slaves 516, 518, 520 and 522 may be configured to generate and/or
execute versions of data processing application 530. in at least
one of the various embodiments, once generated, data processing
application 530 may run on a single or multiple slaves, depending
upon the generated applications size and workload.
[0160] In at least one of the various embodiments, each of
commander 502, masters 504 and 506, physical machines 508 and 510,
agents 512 and 514, and slaves 516, 518, 520 and 522 may be data
processing modules that may be implemented as software applications
or software modules, or as a combination of software and hardware.
In at least one of the various embodiments, the functionality of
two or more of commander 502, masters 504 and 506, physical
machines 508 and 510, agents 512 and 514, and slaves 516, 518, 520
and 522 may be consolidated into a single data processing system or
data processing module.
[0161] FIG. 6 shows a flowchart for process 680 that may be used to
facilitate the rapid development of a generated application for at
least one of the various embodiments. In at least one of the
various embodiments, data processing platform 500 from FIG. 5, data
processing platform 400 from FIG. 4, (also known the platform or
platforms) may be used to run one or more software applications
configured to execute process 680.
[0162] In at least one of the various embodiments, process 680 may
includes at least one work stream 640 that may generate application
650. In at least one of the various embodiments, process 680 may
rely on one or more projects 642, where each project may include a
project definition and other descriptive or characteristic
data.
[0163] In at least one of the various embodiments, each project 642
may include, or may interoperate with one or more change streams.
In at least one of the various embodiments, a change stream may
include a set of changes made by one or more users. In at least one
of the various embodiments, changes may be modifications to
previous data input into the platform and may sometimes be
described as "change entries."
[0164] In at least one of the various embodiments, work stream 640
may be designated as a "master," or "parent" and may be used to
produce application 650, which may be described as a "primary
application," or "parent project," or read and write version of the
produced/generated application. in at least one of the various
embodiments, a read-only version of the primary application can be
made available to one or more users for normal use that are not
granted permission for accessing application development tools. In
at least one of the various embodiments, changes to application 650
may be made, evaluated and tested against a different work stream,
and such changes may be merged back into the master work stream and
deployed as part application 650 if they may have been
approved.
[0165] In at least one of the various embodiments, work streams
record the changes and/or modification that may be associated with
a generated application. In at least one of the various
embodiments, work streams may be comprised of a plurality of
individual change entries that may be preserved in an audit
log.
[0166] In at least one of the various embodiments, as edit and/or
modifications may be made to a generated application the work
stream associated with application received change entries
associated with the edit and/or modifications made to the generated
application.
[0167] In at least one of the various embodiments, a user-interface
may be arranged to be enable the user modify properties of the
generated applications where each user-interface generated
modification may be preserved in the work stream associated with
the generated application.
[0168] In at least one of the various embodiments, an application
may be generated and modified automatically by adding one or more
change entries or modifying existing change entries to generate a
modified or customized application. In at least one of the various
embodiments, new or modified change entries may propagate and may
automatically modify other dependent items, including one or more
of the elements that may be included in application 650. In at
least one of the various embodiments, propagation of new or
modified change entries and subsequent refinement of application
650 may be illustrated in process 680 with the feedback loops that
may be formed by screen components 670 and may feed back into
change entry 644 and state transition 676 and may further feed back
into change entry 644.
[0169] In at least one of the various embodiments, application 650
may receive multiple input datasets from various sources.
[0170] In at least one of the various embodiments, application 650
may comprise a number of logic modules.
[0171] In at least one of the various embodiments, transformation
rule sets may be included that. may affect the input data and may
produce transformed input datasets.
[0172] In at least one of the various embodiments, table processing
subsystem 656 may be configured to annotate, filter, summarize
and/or combine data tables in a variety of ways. In at least one of
the various embodiments, data tables may include raw table 652 and
transformed table 654. In at least one of the various embodiments,
transformed table 654 may be included in raw table 652, or may be
produced by table processor 656 based on raw table 652. In at least
one of the various embodiments, raw table 652 may include input
datasets, and transformed table 654 may include transformed
datasets.
[0173] In at least one of the various embodiments, schema generator
658 may be configured to automatically compute relationships
between transformed input datasets.
[0174] In at least one of the various embodiments, one or more
fully linked tables may be included, which may be generated using
schema generator 658 and may be based on propagation rules 662 and
transformed table 654.
[0175] In at least one of the various embodiments, application 650
may include, a set of metric models 660, which may include one or
more Objects 666 and may include one or more propagation rules
662.
[0176] In at least one of the various embodiments, application 650
may also include, a set of propagation relationships established
between objects 666 that may be based on propagation rules 662.
[0177] In at least one of the various embodiments, application 650
may include, a set of object declarations that may he based on
objects 666 and that may include properties that may be obtained
from the fully linked tables 664.
[0178] In at least one of the various embodiments, application 650
may include, a set of interaction screens 668 that may be related
to one or more instances of objects 666 and that may include one or
more screen components 670. In at least one of the various
embodiments, screen components 670 may have various capabilities
for facilitating user actions, including navigation, data queries,
data changes, or the like.
[0179] Additional discussion of schemas and generation of schemas
(e.g., using the schema generator 658), fully linked tables (e.g.,
such as fully linked tables 664) and interactive screens (e.g.,
such as screen 668) may be found in U.S. patent application Ser.
No. 12/467,120 filed on. May 15, 2009, titled "Operational-Related
Data Computation Engine," which is incorporated by reference into
this patent application in its entirety.
[0180] In at least one of the various embodiments, application 650
may include a set of workflow models that may consist of possible
activities and transitions between the activities.
[0181] In at least one of the various embodiments, application 650
may include a scheduler that may be configured to evaluate and/or
trigger transitions periodically, such as state transitions
676.
[0182] In at least one of the various embodiments, application 650
may include a set of action items that may be arranged to
concurrently execute instantiations of a workflow 672 that may
generate one or more states 674 that may be related to the state
transitions 676. In at least one of the various embodiments, the
results of state transitions 676 may be used in a feedback loop to
produce one or more change entries 644.
[0183] In at least one of the various embodiments, a table
processor (e.g., table processor 656) may accept as input a.
transformation specification and an input table. In at least one of
the various embodiments, the table processor may use at least these
two inputs to produce an output table for further processing in the
platform.
[0184] In at least one of the various embodiments, a table
processor, such as table processor 656, may have one or more of the
following capabilities including, Filtering (e.g., removing rows
from the input table based on some specification, like
"Cost>500), Pivot:/Unpivot (e.g., Converting between two
canonical table forms), Limiting (e.g., only returning the first X
number of rows, or a ranges of as in rows X through Y), or the
like.
[0185] In at least one of the various embodiments, a table
processor, such as table processor 656, may include one or more
transformation types, including, Aggregation (e.g., multi-period,
including awareness, ticket count, and new unit
handling/re-grouping), Trend, Filter, Total/Group, Awareness of
formula components, New Column, including formula syntax
(particularly fully linked table syntax), Pivot/Unpivot, Transpose,
Limit, Sort, Project, or the like.
[0186] FIG. 7 shows an overview flowchart for process 700 for
rapidly developing a data processing application in accordance with
at least one of the various embodiments. After a start block, at
block 702, in at least one of the various embodiments, a project
may be determined for the new application. In at least one of the
various embodiments, projects may be associated with initialization
instructions and/or configuration parameters that may influence
characteristic of the new application. In at least one of the
various embodiments, a project may be associated with particular
application templates, data types, work streams, other
applications, user access level (e.g., user permissions), or the
like. In at least one of the various embodiments, a user may
associate project information used to generate the new application
as required in advance of generating the new application. For
example, in at least one of the various embodiments, a user may
want to associate additional and/or different templates with the
project before generating a new application.
[0187] At block 704, in at least one of the various embodiments, a
new application may be generated based on the information
associated with project. In at least one of the various
embodiments, if the application may be based on previously defined
work streams, such as from a template, the application may have a
operative or semi-operative complex application architecture.
[0188] At block 706, in at least one of the various embodiments, if
the new application may be generated based on the information
associated with the project, a user may begin making modifications
to the new application. In at least one of the various embodiments,
a user may modify the generated application by transforming the
example data, adding objects and relationships, creating models,
generation rules, design user-interfaces and reports, or the
like.
[0189] For example, in at least one of the various embodiments, if
the new application may be a financial modeling application, a user
may add cost objects and propagations rules that may represent
elements of a financial model.
[0190] At block 708, in at least one of the various embodiments,
modifications made to the new application may be preserved as
change entries in a work stream that may be associated with the new
application. In at least one of the various embodiments,
modifications made to an application may cause the application to
be associated with a new revision number.
[0191] At decision block 710, in at least one of the various
embodiments, if additional modifications may be required control
may loop back to block 706. Otherwise, control may move to block
712.
[0192] At block 712, in at least one of the various embodiments, a
user may release the new application to the authorized user
population so authorized users may begin using the application.
Next, control may be returned to the calling process.
[0193] FIG. 8 shows a flowchart. for process 800 for generating a
data processing application in accordance with at least one of the
various embodiments. After a start block, at block 802, in at least
one of the various embodiments, a new project may be generated
based in part on information the may be provided by a user. In at
least one of the various embodiments, project information may
include, project name, owner, description, or the like. In at least
one of the various embodiments, project information may include
associated predefined templates that may be applied if generating a
new project.
[0194] In at least one of the various embodiments, project
information may also include a reference to an existing project
that may be used as template for generating the new project. In at
least one of the various embodiments, project information may
include references and/or association with one or more work streams
and/or change streams that may be applied if generating a new
project.
[0195] At block 804, in at least one of the various embodiments,
process 800 may receive the example data. In at least one of the
various embodiments, the example data may be imported by way of
import layer 402 into process 800 by applying one or more of the
various techniques discussed above. Further, in at least one of the
various embodiments, during and/or after the data may be uploaded a
user may transform, edit and/or modify the imported data. For
example, in at least one of the various embodiments, some data
fields in the uploaded data may be combined together. In at least
one of the various embodiments, some portions of the received data
may be discarded, reformatted, or the like.
[0196] Also, in at least one of the various embodiments, process
800 may report to a user that portions of the received data may be
corrupt, missing, or otherwise unusable. In at least one of the
various embodiments, a user may take corrective action to repair
the received data if required and/or desired.
[0197] At block 806, in at least one of the various embodiments,
the received data may be processed. For example, in at least one of
the various embodiments, the data may be decrypted, decompressed,
transformed into different formats, or the like. In at least one of
the various embodiments, process 800 may selectively extract only
part of the received data and selectively ignore part of the
received data depending on the specific types of data processing
applications to be generated and/or depending on the format of the
received data and/or other applicable circumstances.
[0198] In at least one of the various embodiments, the imported
example data may be stored in a raw data table. In at least one of
the various embodiments, a transform table version of the data may
also be generated. In at least one of the various embodiments, if
the user modifies the imported data such modifications may be
represented by the transform table that may be associated with the
raw data table. For example, in at least one of the various
embodiments, if columns are added, hidden, or combined or if rows
are filtered, deleted, or added such modifications may appear in
the transform table view of the data In at least one of the various
embodiments, the raw data table may remain unchanged if the
transform may be modified.
[0199] In at least one of the various embodiments, the changes and
modifications made to the transform table view of the raw data
table may be stored as change entries in the work stream. Also, in
at least one of the various embodiments, the transform table may be
a view generated by executing recorded change entries against the
raw data table rather that a container of the underlying data.
[0200] At block 808, in at least one of the various embodiments,
process 800 may generate an application architecture based on the
received and processed. In at least one of the various embodiments,
the data processing platform may analyze the imported and
transformed data to suggest objects and relationships to the
user.
[0201] In at least one of the various embodiments, the user may
select objects recommended by the data processing platform and/or
generate new objects and add them to the generated application. In
at least one of the various embodiments, objects may be based on
the imported data. For example, if the imported raw data includes a
list of servers, a user may want to create a Servers object as part
of the application architecture.
[0202] Also, in at least one of the various embodiments, a user may
create generic objects where he properties and contents of this
type of user created object may be created using user-interface.
For example, a "Bank Account" object may be created and a user may
create property named "Balance" and initialize it a value of
$100.
[0203] In at least one of the various embodiments, multiple objects
may be added to a generated applications architecture based on
adding a template to an application's architecture. In at least one
of the various embodiments, templates may be associated with one or
more objects, and if the template is added to an application, all
of the objects associated with the template may be added as
well.
[0204] In at least one of the various embodiments, the steps of
generating an application architecture may contribute to generating
a model that represents the problem space the generated application
may be targeted for, such as financial model.
[0205] At block 810, process 800 may generate application logic
based on the generated application architecture. In at least one of
the various embodiments, application logic may include entity
propagation rules. In at least one of the various embodiments,
entity propagation rules may define how costs from cost object
and/or other entities may be allocated to other cost objects and/or
entities.
[0206] In at least one of the various embodiments, users may
associate propagation rules with objects comprising the application
architecture. In at least one of the various embodiments, each
propagation rule may define how values from one application, object
relate and/or flow to other objects that may be in the generated
application.
[0207] In at least one of the various embodiments, the generated
application logic may be combined with the application
architecture, objects, rules, and processed data to produce a model
representing the problem space targeted by the generated
application.
[0208] At block 812, in at least one of the various embodiments, a
user-interface for the generated application may be generated. In
at least one of the various embodiments, a user may select and
define user interface components that may enable user's to access
and/or interact with objects and data that may be employed in the
generated application.
[0209] In at least one of the various embodiments, user-interface
may include enabling users to add and/or edit data representing in
the model.
[0210] In at least one of the various embodiments, user-interface
and/or report components may be assigned user-level access
conditions/restrictions. This may enable user-interfaces that show
and/or make available user-interface and/or report components to
users based on their individual or group access levels (or
restrictions).
[0211] In at least one of the various embodiments, the
user-interface components may be grouped into views or reports
organized to provide related functionality and/or views to
authorized users. In at least one of the various embodiments, views
or reports may accessible and/or visible to designated users.
[0212] At block 814, in at least one of the various embodiments,
the received and processed data, application architecture, models,
application logic, and user-interfaces/reports may be combined to
generate a data processing application. If the data processing
application may have been generated, control may return to the
calling process.
[0213] In at least one of the various embodiments, the generated
application may be an application for budgeting and financial
modeling, including, but not limited to the application types
discussed above.
[0214] In various embodiments, project 642 and/or application 650
may be subjected to changes and/or modification that may be
initiated by one or more users. In at least one of the various
embodiments, such changes may be represented by change entry 644,
where such changes may affect the states of project 642 and/or
application 650.
[0215] In at least one of the various embodiments, changes to
projects under development, to projects ready to be deployed and
executed, to applications under development and to primary
applications, and the like may be represented by using a change
entry 644.
[0216] In at least one of the various embodiments, an advantage to
having the similar representation for under-development and
in-progress or deployed projects and applications may be that it
may permit application 650 to evolve over time to meet changing
requirements, yet still retain historical states for comparison,
auditing, rollback purposes, and the like.
[0217] In one implementation, a change may be represented by change
entry 644 and may be a fundamental unit of configuration for a
generated application. In at least one of the various embodiments,
there may be many possible types of change entries that may apply
to an application. In at least one of the various embodiments, each
type of change entry may accept a set of parameters and may operate
on the logical structure of the generated application in some way.
Examples, in at least one of the various embodiments, of change
entries represented by change entry 644 may include the following:
[0218] "Bootstrap", in at least one of the various embodiments,
this change may initialize the structure of the generated
application and may often be the first change in a project. [0219]
"Save", in at least one of the various embodiments, change entries
may be configured to directly affect generated application
structure. For example, in at least one of the various embodiments,
change entries may include: SaveObject, SaveTransformedTable,
SavePropagationRule, SaveScreen. In at least one of the various
embodiments, these change entries may be structured as "Saves" that
may create an entity if the entity doesn't already exist in the
generated application, and may edit it otherwise. In at least one
of the various embodiments, a "Create" operation may be distinct
from an "Edit" operation--so a stream of changes during application
development may be "Create X->Edit X->Edit X->Edit X". In
at least one of the various embodiments, if two individuals perform
this work in separate work streams that may be later merged
together, the second create may fails (because the object already
exists), and subsequent edits referencing that particular create
may also fail. In at least one of the various embodiments, a stream
of "Save X->Save X->Save X", may be more useful for merging
since the last save could represent the final state of the object.
[0220] "Delete", in at least one of the various embodiments,
entries may be configured to remove entities (data tables, objects,
models, etc) that may no longer be part of the application. [0221]
"Rename," in at least one of the various embodiments, entries may
be configured to rename entities in a model, possibly together with
other references that refer to them. For example, in at least one
of the various embodiments, if table may be renamed, references to
that table inside a formula included in a model performing cost
analysis on a data set may also be renamed automatically so that
the rest of the application continues to function. In at least one
of the various embodiments, this may allow an application developer
to maintain the conceptual coherence of the generated application
as it may be changed over time. [0222] "Load Table," in at least
one of the various embodiments, entries may be configured to load a
table of raw data into the generated application, including into
raw table such as ray table 652. In at least one of the various
embodiments, a Load Table entry may be configured to override a
table if the table already exists in the platform. [0223] "Edit
Table," in at least one of the various embodiments, entries may be
configured to affect existing tables in the platform, but may not
necessarily completely "overwrite" an existing table. Instead, in
at least one of the various embodiments, an Edit Table entry may be
configured to make smaller, tactical changes to the tables, such as
changing or deleting a particular row.
[0224] In at least one of the various embodiments, an Edit Table
entry may be structured using primary keys to ensure that edits to
different parts of tables handle Undo and work stream merge
operations gracefully. In at least one of the various embodiments,
this may be enables by indexing changes in a table by row numbers.
In at least one of the various embodiments, a work stream may be
configured with commands such as "Delete Row 5" and "Edit Row 6."
If "Delete Row 5" may be subsequently undone, however, what was row
6 if that change was originally logged may become row 7. In at
least one of the various embodiments, a similar situation may occur
if two separate work streams may be merged together using such an
approach where changes are indexed by row numbers. In at least one
of the various embodiments, an improved approach, instead, may
provide a solution by assigning to specific rows in the original
table (whether to only some rows or to all rows of the table), upon
original table upload, a globally unique identifier (GUID). In at
least one of the various embodiments, a combination of user-id and
current time (down to the millisecond) may be used to generate
GUIDs for rows with a sequencing algorithm for conflicts. In at
least one of the various embodiments, a Change Stream command could
be recorded as "Delete Row sdfikk13543280932", "Edit Row
reuidfsjkldsfl38903393". Consequently, in at least one of the
various embodiments, a deletion may not change the primary keys of
other (unrelated) rows. Also, the GUM may be generated using
techniques beyond those describe herein. Generally, a GUID that may
provide at least application level uniqueness may be
sufficient.
[0225] "Apply Object Template," in at least one of the various
embodiments, change entries may be configured to reference a
plurality of changes in different and/or separate applications and
may apply them to a particular generated application.
[0226] In at least one of the various embodiments, templates may be
selected at an object level (e.g., object 666), since such objects
may be configured as central building blocks around which a
generated application may be designed. In at least one of the
various embodiments, a template application that: may be applied to
a particular application may also add integrated content to other
parts of that particular application, including raw tables (such as
raw table 652), propagation rules (such as propagation rule 662),
models (such as model 660), screens (such as screen 668),
components (such as component screen components 670), and the
like.
[0227] In at least one of the various embodiments, a template may
be used to generate and/or further modify an application, such as
application 650.
[0228] In at least one of the various embodiments, it may be
advantageous to apply a template object (e.g., an object or other
item or logic module included in a template) multiple times within
a generated application. In at least one of the various
embodiments, it may be necessary to reuse object templates if there
may be nested hierarchies of the same entity. In at least one of
the various embodiments, an object template may be an "IT Service"
template. In at least one of the various embodiments, an IT service
may have a flexible definition, and this definition may be
comprised of other, more fundamental services.
[0229] For example, in at least one of the various embodiments, one
IT service may be a "Call Center Desk", for $380/month. In at least
one of the various embodiments, a `Call Center Desk` may be defined
as including other (more fundamental) services, such as "1 Desktop
at $200/month", "1 Phone at $100/month", "1 Headset at S30/month",
and "30 GB email package at $50/month". Further, in at least one of
the various embodiments, the full cost of the "Email" IT Service
may be defined in terms of "SAN Storage $3 per gigabyte per month",
"15 Windows Server 2 way blades at $1,500 each per month",
"Microsoft Exchange CAL at $12 per user per month", etc. In at
least one of the various embodiments, we may have three tiers of
the IT Service object with different names: "Business Service"
(such as the call center desk), "Capability" (such as desktops,
headsets, phones, etc) and "Foundational Service" (such as SAN
storage space or windows servers in the datacenter)." In at least
one of the various embodiments, the non-limiting example described
here may apply to Service costing, but may also have other
applications, including budgeting and demand forecasting.
[0230] In one implementation, to apply a template object multiple
times within a generated application, a rename capability may be
used if copying template items into the generated application. In
at least one of the various embodiments, this capability may adjust
external references to items in order to maintain link coherence if
they may be renamed.
[0231] FIG. 9 shows a flowchart for at least one of the various
embodiments, for process 900 that may be used to apply a template
to a generated application, such as application 650.
[0232] After a start block, at block 902, in at least one of the
various embodiments, the template object's meta configuration may
be copied from the template into the generated application. In at
least one of the various embodiments, this may include a set of
name-value pairs. For example, a "Computer" object may have a
"Location" field with a value of "=ServerCMDB.DataCenter",
indicating that the location of a particular computer may be found
in the DataCenter column of the ServerCMDB data table.
[0233] At block 904, in at least one of the various embodiments,
determine objects, models, rules, tables, screens, workflows,
activities required by template and check if they may be present in
generated application.
[0234] At decision block 906, in at least one of the various
embodiments, if the required models (e.g., such as model 660)
associated with the template object are not present in the
generated application, control may move to block 908. Otherwise
control may move to decision block 910.
[0235] At block 908, in at least one of the various embodiments,
generate the missing objects and copy them into the generated
application.
[0236] At decision block 910, in at least one of the various
embodiments, if one or more of the propagation rules may be missing
control may move block 912. Otherwise control moves to decision
block 914.
[0237] At block 912, in at least one of the various embodiments,
missing propagation rules may be copied into the generated
application. In at least one of the various embodiments,
propagations rules may depend on an object(s) and/or a table(s)
that have not been copied and/or installed into the generated
application. In at least one of the various embodiments, missing
objects such as these may be installed before activating
propagation rules that may depend on the missing object.
[0238] At decision block 914, in at least one of the various
embodiments, if raw tables may be missing from the generated
application, control may move to block 916. Otherwise, control may
move to decision block 918.
[0239] At block 916, in at least one of the various embodiments,
the raw tables associated with the template object (such as raw
table 652) and transformation rules for those raw tables that may
be associated with the template object may be copied into the
generated application. In at least one of the various embodiments,
the table may be renamed to use the name of the object inside the
generated application. In at least one of the various embodiments,
references to the original table name may be adjusted to the new
name also--this may include formulas (e.g., inside propagation
rules, screens, components, transitions, activities and other
tables).
[0240] At decision block 918, in at least one of the various
embodiments, if one or more screens (such as screen 668) and screen
components (such as screen components 670) for this template are
absent, control may move to block 920. Otherwise, control may move
to decision block 922.
[0241] At block 918, in at least one of the various embodiments,
screens and screen components may be generated that may be copied
into the generated application to support the operating of the
generated application.
[0242] At decision block 922, in at least one of the various
embodiments, if workflows associated with the template are missing,
control may move to block 924. Otherwise, control may move to
decision block 926.
[0243] At block 924, in at least one of the various embodiments,
workflows (such as workflow 672) associated with this template
object may be copied into the generated application.
[0244] At decision block 926, in at least one of the various
embodiments, if activities and/or a transition(s) associated with
the template object is absent, control may move to block 928.
Otherwise control may be returned a calling process.
[0245] At block 926, in at least one of the various embodiments,
one or more activities and/or transitions (such as state transition
676) associated with the template object may be copied into the
generated application. In at least one of the various embodiments,
the activities and transitions may be renamed using the convention
described for tables in connection with the discussion of change
entries, such as change entry 644.
[0246] In at least one of the various embodiments, additional
components and/or objects associated with a template but not
present in a generated application may be tested for, and installed
into the generated application. In at least one of the various
embodiments, if generation of the application based on the template
is successful, the generated application may be ready for operation
or may require additional configuration and/or control may be
returned to the calling process.
[0247] Further, in at least one of the various embodiments, one or
more templates may be employed with an application at various
points in the application's lifetime. For example, in at least one
of the various embodiments, a template may be employed to initially
create and/or generate an application. Also, in at least one of the
various embodiments, a template may be applied later to modify
and/or extend an existing application.
[0248] In at least one of the various embodiments, an `Apply Object
Template` change entry may record the template name and version to
apply. In at least one of the various embodiments, if the change
entry may be applied to the generated application, the actual
configuration of the template may be read and copied into the
project. In at least one of the various embodiments, the effect of
this organization may be that if the template may be updated, a
generated application may automatically pick up the new template
upon next replay.
[0249] In at least one of the various embodiments, a template may
also be a project. In at least one of the various embodiments, a
template may be built by defining a canonical structure that may be
used as one of the prototypes for generating an application.
[0250] In at least one of the various embodiments, a work stream,
which may include a plurality of change entries that may be
executed together, may be used to execute one or more generated
applications. In at least one of the various embodiments, a work
stream including a set of change entries (such as change entry 644)
that may be executed together may sometimes be described as a
change stream.
[0251] In at least one of the various embodiments, in response to
an attempt by a user to access a generated application such as
application 650 from a particular change stream, the following
algorithm may be used to produce or retrieve the generated
application (such as application 650).
[0252] FIG. 10 shows a flowchart for at least one of the various
embodiments, of process 1000 to execute or retrieve the generated
data processing application. In at least one of the various
embodiments, if an authorized user requires access to a generated
data processing application, the data processing platform may
ensure that the user may be accessing a version of the generated
data processing application that may be synchronized with the
latest change entries that may be associated with the generated
data processing application.
[0253] In at least one of the various embodiments, users may access
(e.g., use) read-only versions of the generated data processing
application. In at least one of the various embodiments, the data
processing platform may determine if the read-only (e.g., user
accessible version of the application) data processing application
incorporates the relevant change entries that may be associated
with the generated data processing application.
[0254] In at least one of the various embodiments, the data, change
entries, work streams, models, application architecture, and
application logic that may be associated with a generated
application may be stored in a read and write version of the
application, also known as a parent project. In at least one of the
various embodiments, the parent project preserves the content and
form of the generated application but it may not generally be
accessible by users. :In at least one of the various embodiments, a
user may access the read and write version of the application
(e.g., the parent project) of a generated application if they may
be "developing" the application which may comprise modifying
portions of the application such as, data, objects, architecture,
logic, models, user-interface component, or the like, of the
generated application.
[0255] In at least one of the various embodiments, a user utilizing
the generated application (e.g., not developing, modifying, or
creating the application) may access the generated application
through a read-only version of the application. In at least one of
the various embodiments, accessing the generated application
through the read only version may restrict the user to accessing
the generated application by using the user-interface/reports
created by the application's creator. Whereas, accessing the
application through the rand and write version (the parent project)
may enable access to all the underlying data, objects, change
entries, models, templates, application development tools, and the
like.
[0256] In at least one of the various embodiments, a read-only
version of the generated application may be located at a read root,
which may be the starting point of the generated application. In at
least one of the various embodiments, from a read root the other
parts of the read-only version generated application may be
accessed by users. (See, Generated Application Root 1502 in FIG.
15).
[0257] In at least one of the various embodiments, a generated
application may have a write root where the read and write version
of the generated application may be located. In at least one of the
various embodiments, the write root may point to a read and write
version of the generated application generated by the data
processing platform during the application development process. In
at least one of the various embodiments, the write root may be
written to by the platform as modifications to the generated
application may be made by the platform (e.g., during the rapid
development process).
[0258] After a start block, at block. 1002, in at least one of the
various embodiments, the memory cache of the data processing
platform may be examined to determine if the read-only version of
the generated application may located at the read root in a cache
or local memory.
[0259] In at least one of the various embodiments, the platform may
generate one or more "executable" instances of the generated
application by compiling the relevant associated change entries to
generate an executable version of the generated application.
[0260] In at least one of the various embodiments, read-only
executable versions of the generated application may be held and/or
cached in memory and located at the read root.
[0261] In at least one of the various embodiments, a read-only
version of generated application may be generated by the data
processing platform if the generated application may be released
for use (usually after the user developing the application is
finished developing the application).
[0262] At decision block 1004, in at least one of the various
embodiments, if the read-only version of the generated application
at the read root may be found in the cache, or other storage,
control may move to block 1006. Otherwise, in at least one of the
various embodiments, control may move to block 1010.
[0263] At block 1006, in at least one of the various embodiments,
determine if the parent application (i.e., the application upon
which this application was based) currently has a newer revision
than the read-only edition of the generated application.
[0264] At decision block 1008, in at least one of the various
embodiments, if the read-only edition of the generated application
has the same version as the parent project application, allow the
user to access (use) the read-only edition of the generated
application and return control to the calling process. Otherwise,
control may move to block 1010.
[0265] At block 1010, in at least one of the various embodiments, a
determination may be made as to the most recent read and write
edition of the application by determining the most recent change
entry. In at least. one of the various embodiments, the read or
write edition of the application may be loaded from an on-disk
checkpoint (this may be done as a performance optimization so that
the change entries in block 1016 may not unnecessarily
re-processed).
[0266] At decision block 1012, if a write edition of the
application may be unavailable, or if a write edition may be stale.
(may not include all change entries, out-of-date edition), control
may move to block 1014. Otherwise control may move to block
1016.
[0267] At block 1014, in at least one of the various embodiments,
the write edition is initialized either blank or, if there may be a
parent application, by taking a copy of the parent application's
non-stale write edition.
[0268] At block 1016, in at least one of the various embodiments, a
write edition of the application may be compiled at least in part
by executing the latest change entries associated with the
generated application. In at least one of the various embodiments,
starting at the current version, each change entry in the
associated work stream is iterated over in chronological order (as
shown in FIG. 11 for at least one of the various embodiments).
[0269] At block 1018, in at least one of the various embodiments, a
copy of the write edition of the generated application is saved to
storage as a checkpoint for future use in step 1010. In at least
one of the various embodiments, saving a write edition to storage
may reduce unnecessary re-processing of change entries.
[0270] At block 1020, in at least one of the various embodiments, a
read edition of the generated application may be made by copying
the write edition. If the read edition of the generated application
may be available for use by authorized users, control may be
returned to the calling process.
[0271] FIG. 11 shows a flowchart for process 1100 for executing
change entries in accordance with at least one of the various
embodiments. After a start block, at block 1102, a change entry may
be received by a data processing platform for processing.
[0272] At block 1104, in at least one of the various embodiments,
determine if the change entry may have been marked as undone. In at
least one of the various embodiments, users may modify work streams
by marking a change entry as undone to reverse the effects of the
operations that may be associated with the change entry. In at
least one of the various embodiments, the effects of the Change
entry may be undone by clearing the generated application and
re-executing all of the "not undone" change entries associated with
the work stream. In at least one of the various embodiments, a
change entry may have a status property that may indicate, among
other things, if the change entry may be `undone`.
[0273] At decision block 1106, in at least one of the various
embodiments, if the change entry may be marked undone, control may
loop back to block 1102. Otherwise, control may move to block
1108.
[0274] At block 1108, in at least one of the various embodiments,
the version of the application is updated based on this change
entry. In at least one of the various embodiments, the current
revision for the application is incremented to a sequence number
that may be associated with this change entry. For example, in at
least one of the various embodiments, if the current revision may
be 32.7.4.0, it may be incremented to become 32.7.4.1.
[0275] At block 1110, in at least one of the various embodiments,
the received change entry is executed against the application. In
at least one of the various embodiments, the actions performed on
the application may depend upon the specific type of change entry
and its parameters.
[0276] In at least one of the various embodiments, executing a
change entry may recreate the step or steps taken during the
development of the generated application. For example, data
transformations, adding objects, modifying objects, establishing
application logic, crafting user-interface view and/or reports, or
the like.
[0277] At decision block 1112, in at least one of the various
embodiments, if more change entries remain to be processed control
may loop back to block 1102. Otherwise, control may be returned to
the calling process.
Use Case illustrations For Platform For Rapid Development of
Applications
[0278] FIG. 12 illustrates a logical schematic of project 1200 in
accordance with at least one of the various embodiments. In at
least one of the various embodiments, budget project 1200 may be a
part of a generated data processing application that may be
generated by a data processing platform.
[0279] In at least one of the various embodiments, a generated data
processing application based on a budget project may have model
layer 1204 that includes the logical representation of all the
entities, services, and items considered to be addressed by the
budget. In at least one of the various embodiments, model layer
1204 may include one or more objects 1206 that may represent the
entities, services, and items, that may be included in the budget.
In at least one of the various embodiments, objects 1206 may
include business centers, business services, business units,
servers, laptops, desktops, mobile devices, storage, projects, work
tickets (such as for a help desk), cost centers, general ledger
transactions, sub-ledger line items, rate cards, or the like. In
most cases, model layer 1204 may be comprised of objects 1206 that
represent the particular items a business intends to manage within
a particular budget. Accordingly, each budget project may include a
set of objects that may be unique for each business.
[0280] In at least one of the various embodiments, objects 1206 may
be implemented using software modules arranged to model objects
1206 in a budget project 1200. One of ordinary skill in the art
will appreciate that such objects may be implemented using one or
more computer programming languages, computer scripting languages,
database stored procedures, or the like. Further, in at least one
of the various embodiments, objects 1206 may be stored and/or
implemented using databases, including, SQL databases, object
oriented databases, column-oriented databases, NoSQL databases,
custom databases, or the like.
[0281] In at least one of the various embodiments, a budget
project's model layer 1204 may include allocation rules 1208 that
may define in part how objects 1206 relate to each other within the
context of a particular budget project. In at least one of the
various embodiments, allocation rules 1208 may be used to define
how one object, such as Storage Services, may be allocated among
other objects. Operators may arrange one or more allocation rules
to match the entities being modeled within the budget. In at least
one of the various embodiments, one or more allocation rules may be
defined in part based on templates, user-interface dialog boxes,
command-line commands, configuration files, policy rules, business
rules, and the like.
[0282] In at least one of the various embodiments, allocation rules
1208 may determine how budget costs may be propagated through the
budget between and among at least the objects that make up the
budget.
[0283] FIG. 13 illustrates an embodiment of a generated data
processing application that at least enables visualization of
financial allocation model 1300. In one of the various embodiments,
the financial allocation model's allocation rules may be
represented as edges (the lines) and the cost objects may be
represented as nodes (including an icon and textual name). in at
least one of the various embodiments, each element in a financial
allocation model may display a value summarizing the costs
associated with cost object represented by the node. For example,
in one of the various embodiments, node 1302 represents cost object
Servers that may be allocated $142,135 of the costs in financial
allocation model 1300. In at least one of the various embodiments,
cost object Servers 1302 may include one or more cost line items
categorized as servers.
[0284] Furthermore, in at least one of the various embodiments,
allocation rule information may be displayed on the edges between
financial allocation model nodes. In some cases, the displayed
information may represent a percentage, or ratio, of a cost or
expense that may be allocated from one cost object to another. In
at least one of the various embodiments, edge 1304 indicates that
100% of costs of cost object Storage Devices 1306 may be allocated
to cost object Storage 1308. In at least one of the various
embodiments, the underlying allocation rules may control how costs
and expenses can be allocated and/or propagated through the
financial allocation model.
[0285] In at least one of the various embodiments, a user may be
enabled to examine or modify allocation rules by clicking on one or
more elements (e.g., nodes, edges, or the like) in the financial
allocation model visualization to reveal additional detail and/or
options.
[0286] FIG. 14 illustrates a partial view a work stream that may
include change entries implemented as audit log 1400 in accordance
with at least one of the various embodiments. In at least one of
the various embodiments, if a modification may be made to a
generated data processing application, such as a financial modeling
application, a change entry record corresponding to the
modification may be stored in audit log 1400. In at least one of
the various embodiments, an audit log may include enough
information in each record to determine what modification occurred,
the time when it occurred (e.g., timestamp), and who and/or what
caused the modification. In at least one of the various
embodiments, an audit log may include enough information in each
record to enable recorded modifications to be replayed, recreated,
or undone. Also, in at least one of the various embodiments,
multiple audit log records may he replayed to generate "duplicate"
data processing applications. In at least one of the various
embodiments, a data processing application may be a duplicate of
another data processing application if it may have been created by
replaying the audit log records generated from the data processing
application.
[0287] In at least one of the various embodiments, an audit log
1400 may store information, such as, row identifier 1402 Timestamp
1404, User 1406, Status 1408, and Description 1410, or the like.
Also, audit logs may be arranged in other ways. In at least one of
the various embodiments, audit logs may have more or less values
per row than as shown in FIG. 1400. In at least one of the various
embodiments, a sufficient configuration may include enough
information to enable replaying or recreating the modifications
made to a data processing application. Additionally, in at least
one of the various embodiments, audit logs may be altered by
marking a record as undone. In at least one of the various
embodiments, Status 1408 may indicate if an audit log record (e.g.,
change entry) may have been undone. For example, in audit log 1400,
rows 1412 and 1414 are shown with a Status value that may indicate
that the recorded. modification has been undone. In at least one of
the various embodiments, an undone record remains in the audit log
with a Status indicating that the recorded action has been
undone.
[0288] Further, in at least one of the various embodiments, an
audit log may reference other files, tables, databases, or the
like, rather than storing all of the data and information required
to recreate the recorded modification directly within audit log
1400. For example, in at least one of the various embodiments, if
recorded modifications may require significant data uploads, audit
log 1400 may reference another source for the uploaded data (e.g.,
a file system, database, or the like) to avoid storing excessive
duplicate data within the audit log itself.
[0289] In at least one of the various embodiments, the audit log
may further include records that reference other audit logs. In at
least one of the various embodiments, this may indicate that a
template or other generated application's work stream may be
included in the generated application associated with audit log
1400. in at least one of the various embodiments, change entries
that may be included in the reference audit log/work-stream may be
applied to generated application the same as if the actions may
have been take directly on the generated application.
[0290] FIGS. 15-18 illustrate a logical representation of a
generated data processing application in accordance with the
embodiments.
[0291] FIG. 15 shows a high-level logical representation for at
least one of the various embodiments, of a generated data
processing application. In at least one of the various embodiments,
application root 1502 may be the top of a data structure that may
contain an executable generated application.
[0292] In at least one of the various embodiments, data 1504 may be
the top level root to the data elements that may comprise the
application. In at least one of the various embodiments, models
1506 may comprise the models employed by the generated application.
And, in at least one of the various embodiments, user-interfaces
1508 may comprise graphical user-interface elements that may be
provided to a user for interacting and/or viewing the generated
data processing application.
[0293] In at least one of the various embodiments, the application
root may be a write root that may refer, identify, and/or reference
the location to a read and write version of the generated
application. Or, the application root may be a read root that may
refer, identify, and/or reference the location to a read-only
version of the generated application.
[0294] FIG. 16 illustrates an expanded view of application data
sub-tree 1600 for at least one of the various embodiments that may
be part of a generated data processing application.
[0295] In at least one of the various embodiments, data may be
organized and/or associated in groupings or buckets that may be
based on one or more factors. For example, in at least one of the
various embodiments, data blocks 1604-1606 may represent data in a
generated application that may be arranged and/or grouped by months
with block 1604 representing data associated with the month of
January 2010.
[0296] in at least one of the various embodiments, data associated
with block 1604 may include several tables (e.g., tables
1608-1610). In at least one of the various embodiments, each table
may hold data associated and/or managed by the generated data
processing application.
[0297] In at least one of the various embodiments, each table
1608-1610 may be associated with raw uploaded data and transform
instructions. In at least one of the various embodiments, table
1608 may be associated with raw uploaded data table 1612 and
transform instructions 1614. In at least one of the various
embodiments, raw uploaded data table 1612 may be the original
uploaded data as it was uploaded by the import layer.
[0298] In at least one of the various embodiments, transform
instructions may be instructions that may have been performed on
raw uploaded data 1612 to produce transformed data table 1616. In
at least one of the various embodiments, transform instruction may
included steps such as hiding, merging, or inserting columns, as
well as instructions to hide or exclude rows matching filter
expressions, re-ordering or columns, or the like.
[0299] FIG. 17 shows an expanded view of a generated data
processing application's model 1700 for at least one of the various
embodiments. In at least one of the various embodiments, model 1702
may represent that objects and rules associated with a generated
data processing application.
[0300] In at least one of the various embodiments, models 1704-1706
may be the one or more models that may be associated with a
generated data processing application. In at least one of the
various embodiments, one of models in an application may be model
1708 that may represent a cost model for use in a generated
financial application.
[0301] In at least one of the various embodiments, the parts of
model 1704 may be classified, sliced, and/or grouped based on
various factors such as month and year (e.g., groups
1708-1710).
[0302] In at least one of the various embodiments, each slice of a
model may include a collection of objects and rules. In at least
one of the various embodiments, objects 1712-14 and propagation
rules 1716-1718 may be may be associated with slice 1708. In at
least one of the various embodiments, each object may be generated
to represent classes of items managed by the application, such as,
printers, email servers, employees, contracts, servers, laptops,
commercial software applications, or the like.
[0303] In at least one of the various embodiments, object 1712 may
be employed to generate calculated table 1720. Also, in at least
one of the various embodiments, propagation rule 1716 may be
employed to generate assignment ratios table 1722.
[0304] FIG. 18 represents a logical representation of
user-interface 1800 for at least one of the various embodiments. In
at least one of the various embodiments, user-interface 1800
enables the developer of a generated data processing application to
create user-interfaces that may enable a user to view, access, and
interact with the generated application.
[0305] In at least one of the various embodiments, a generated
application may have user-interfaces 1802 that may include multiple
reports 1804-1806. In at least one of the various embodiments, each
report may be designed to allow users to interact with generated
application by offering a collection of user-interface components
1808-1810. En at least one of the various embodiments, user
interface components may be a graphical user interface element such
as, a table viewer, chart, button, slider, or the like.
[0306] It will be understood that figures, and combinations of
actions in the flowchart-like illustrations, can be implemented by
computer program instructions. These program instructions may be
provided to a processor to produce a machine, such that the
instructions executing on the processor create a means for
implementing the actions specified in the flowchart blocks. The
computer program instructions may be executed by a processor to
cause a series of operational actions to he performed by the
processor to produce a computer implemented process for
implementing the actions specified in the flowchart block or
blocks. These program instructions may be stored on some type of
machine readable storage media, such as processor readable
non-transitive storage media, or the like.
Generalized Operation Of Automation Of Business Management
Processes
[0307] FIG. 19 shows a data processing platform 1900 arranged to
mediate business-related metrics and entity propagation rules
between human stakeholders and data sources in accordance with at
least one of the various embodiments.
[0308] In at least one of the various embodiments, data processing
platform 1900 may incorporate a mediation logic module 1902, which
may be a logic module adapted to perform mediation functionality as
further described below. In at least one of the various
embodiments, mediation logic module 1902 may consist of a plurality
of logic modules. In at least one of the various embodiments, the
functionality described below in connection with data processing
1900 and mediation logic module 1902 may be distributed across a
plurality of data processing modules that may communicate with each
other either through specific communication channels or via a set
of networks.
[0309] In at least one of the various embodiments, user 1930 acts
as a human stakeholder 1920.
[0310] A human stakeholder 1920 and user 1930 may be any
individual, group of individuals, or business entity that interacts
with data processing platform 1900 directly or indirectly. In at
least one of the various embodiments, user 1930 and human
stakeholder 1920 may have various credentials and perform various
functions relevant to the entities using the data processing
platform. In at least one of the various embodiments, human
stakeholders 1920 and user 1930 may utilize any specific data
processing platform or combination of data processing
platforms.
[0311] In at least one of the various embodiments, mediation logic
module 1902 receives a set of business-related metrics 1960. The
business-related metrics 1960 may be defined by user 1930 or by a
set of human stakeholders 1920. In at least one of the various
embodiments, each of the business-related metrics 1960 may be
modified by the user 1930 or by any of the human stakeholders 1920.
In at least one of the various embodiments, such modification may
be based on information received from mediation logic module
1902.
[0312] In at least one of the various embodiments, the
business-related metrics 1960 may be stored in database 1940, in
data processing platform 1900, in one or more data processing
platforms associated with human stakeholders 1920, or in any other
data processing platform or memory. In at least one of the various
embodiments, database 1940 may be a single database, or may consist
of a set of databases that are co-located at a site or may be
distributed. across one or more networks.
[0313] In at least one of the various embodiments, the
business-related metrics 1960 include actual metrics, plan metrics
and goals relating to operational-related data.
[0314] In at least one of the various embodiments, an actual metric
may be the value of a metric that may be determined currently by
measuring past and/or contemporaneous operational-related data
(e.g., the present monthly cost of operating a. data processing
system, as determined by actually measuring a set of relevant
operational-related data relating to the respective data processing
system).
[0315] In at least one of the various embodiments, a plan metric
may represent a desired value of a metric (e.g., the average
monthly cost of operating a data processing system in three
months).
[0316] In at least one of the various embodiments, a. plan metric
may be compared against. an actual metric to determine another
actual metric (e.g., the desired current monthly cost of operating
a data processing system (i.e., a plan metric) could be compared
against the currently measured monthly cost of operating that data
processing system (i.e., an actual metric) to determine the current
efficiency of operating the respective data processing system
(i.e., an actual metric).
[0317] In at least one of the various embodiments, a goal
represents a metric that may be desired to be in effect currently
or in a relatively-distant future (e.g., the desired monthly cost
of operating a data processing system in two years). For example,
in at least one of the various embodiments, a goal may be used to
track progress in the operation of particular business processes,
to determine desirable changes in the operation of a business
entity, or the like. In at least one of the various embodiments, a
goal may or may not be a metric. For example, in at least one of
the various embodiments, a goal that is not specifically quantified
in terms of operational-related data may not be a metric (e.g., the
desire that a specific data processing system could be traded in to
a supplier in the future as part of an upgrade or replacement
purchase transaction).
[0318] In at least one of the various embodiments, the mediation
logic module 1902 may produce plan metrics or goals automatically
by benchmarking a set of actual metric values for a specific
business entity, or for a plurality of business entities.
[0319] In at least one of the various embodiments, metrics may be
classified into classes based on the manner in which they are
determined. In at least one of the various embodiments, modeled
metrics may be determined through links to other metrics and/or may
involve a modeling process.
[0320] In at least one of the various embodiments, calculated
metrics may be determined using rules that process
operational-related data (e.g., the number of mails relayed by a
set of data processing systems).
[0321] In at least one of the various embodiments, mediation logic
module 1902 receives a set of entity propagation rules 1970. In at
least one of the various embodiments, the entity propagation rules
1970 may be defined by user 1930 or by a set of human stakeholders
1920, or may be received from a data source (for example retrieved
from database 1940). In at least one of the various embodiments,
subsequent to being defined, the entity propagation rules 1970 may
be modified by the user 1930, by one or more of the human
stakeholders 1920, or by the mediation logic module 1902 (e.g.,
rules could be dynamically modified to address anomalies, as
further discussed in connection with the embodiment of FIG. 20). In
at least one of the various embodiments, modification may be based
on information received from mediation logic module 1902.
[0322] In at least one of the various embodiments, the entity
propagation rules 1970 may be stored in database 1940, in data
processing platform 1900, in one or more data processing systems
associated with human stakeholders 1920, or in any other data
processing system or . memory.
[0323] In at least one of the various embodiments, mediation logic
module 1902 may mediate a set of business-related metrics 1960 and
a set of entity propagation rules 1970 between human stakeholders
1920 and a set of data sources that may be stored at least
partially in database 1940. In at least one of the various
embodiments, to perform mediation, logic module 1902 utilizes
framework model 1990.
[0324] FIG. 20 illustrates the operation of a logic module that
mediates business related metrics and entity propagation rules in
accordance with at least one of the various embodiments.
[0325] In at least one of the various embodiments, mediation logic
module 2002 may mediate a set of business-related metrics 2060 and
a set of entity propagation rules 2070 between a set of human
stakeholders 2020 and a set of data sources 2060.
[0326] In at least one of the various embodiments, mediation logic
module 2002 may receive a set of goal statements from human
stakeholders 2020 and/or from data sources 2040. In at least one of
the various embodiments, an example of goal statements is a
benchmarking feed.
[0327] In at least one of the various embodiments, mediation logic
module 2002 may also receive from human stakeholders 2020 and/or
from data sources 2040 data useful for determination of actual
metrics and plan metrics. In at least one of the various
embodiments, examples of such data may include the amount of money
spent on training for a calendar month and the target training
expenditures for the following calendar month.
[0328] In at least one of the various embodiments, mediation logic
module 2002 may propagate values to and from entities according one
or more of the entity propagation rules 2070. In at least one of
the various embodiments, mediation logic module 2002 may provide
reports to one or more of human stakeholders 2020 regarding actual
metrics, plan metrics and/or goals. In at least one of the various
embodiments, mediation logic module 2002 may also permit human
stakeholders 2020 to access information regarding the definition,
modification, computation, propagation or other operations applied
to actual metrics, plan metrics and goals (e.g., how propagation
occurred, what the original input values were, source, etc.).
[0329] In at least one of the various embodiments, access to such
information may be regulated using a security clearance model based
on credentials of specific human stakeholders 2020. For example, in
at least one of the various embodiments, a more limited credential
profile for a non-managerial employee could permit respective human
stakeholder 2020 to only access specific subsets of metrics or
goals, or may limit the information presented to the respective
stakeholder for particular metrics or goals. In at least one of the
various embodiments, such a security clearance model could be
implemented using a login (e.g., username and password) validation
model. in at least one of the various embodiments, such reports may
be formatted in any file format or using any data format protocol,
and may be displayed on a screen, exported, downloaded, emailed or
otherwise made available to respective human stakeholders 2020.
[0330] In at least one of the various embodiments, mediation logic
module 2002 may perform a variety of notification and reporting
functions, including, recording remedial action items for an
individual and notifying the user or a human stakeholder,
evaluating progress towards goals and report to human stakeholder
2020 (e.g., including the current status of any remedial action
items), evaluating and reporting the estimated duration left for
completion of specific goals to human stakeholder 2020, or the
like.
[0331] In at least one of the various embodiments, notification and
reporting functions 2050, may be scheduled to occur at predefined
dates or intervals (e.g., every Monday at 12 AM EDT), may be
programmed to take place depending on the occurrence of specific
events (e.g., completion of a goal), or may be prompted by a
request from a human stakeholder 2020 or from another user.
[0332] In at least one of the various embodiments, mediation logic
module 2002 may utilize a framework model 2090 to mediate between
the set of business-related metrics 2060 and the set of entity
propagation rules 2070.
[0333] In at least one of the various embodiments, the framework
model 2090 provides an operational framework for mediation logic
module 2002 to perform some or all of the computations involved in
the mediation process. In at least one of the various embodiments,
framework model 2090 may include a set of rules and algorithms that
specify how the set of business-related metrics 2060 and the set of
entity propagation rules 2070 should be processed.
[0334] In at least one of the various embodiments, framework model
2090 may be stored within mediation logic module 2090, in a data
processing platform that includes mediation logic module 2090, in a
set of other data processing systems and/or storage media, or
within one or more data processing systems used by human
stakeholders 2020.
[0335] In at least one of the various embodiments, mediation logic
module 2002 receives information from data sources 2040 and human
stakeholders 2020 directly. In at least one of the various
embodiments, at least part of the data transmitted by data sources
2040 and human stakeholders 2020 may be filtered through framework
model 2090.
[0336] In at least one of the various embodiments, the framework
model 2090 may be defined, configured and modified by one or more
human stakeholders 2020 or by another user. In at least one of the
various embodiments, framework model 2090 may also be defined,
configured or modified based on information received from data
sources 2060 or from mediation logic module 2002. For example, in
at least one of the various embodiments, human stakeholder 2020 may
modify an algorithm for computation of an actual metric that
determines the cost for operating a corporate department by adding
the cost of the electrical power used by that department into the
computation of the metric.
[0337] In at least one of the various embodiments, the framework,
model 2090 may incorporate a set of functional capabilities that
facilitate dynamic reconfiguration of the mediation process carried
out by logic module 2002. For example, in at least one of the
various embodiments, framework model 2090 may include an undo
function that permits reversal of a specific change made within the
model. In at least one of the various embodiments, such an undo
function could permit human stakeholder 2020 to reverse a change
made to the model, and could then permit automatic re-computation
of all or part of the mediation process carried out by logic module
2002 to propagate the reversal of the change as appropriate.
[0338] In at least one of the various embodiments, framework model
2090 may include an audit function that permits the auditing of
various steps, processes, algorithms, data inputs, data outputs and
other functions performed by logic module 2002 as part of the
mediation process. In at least one of the various embodiments, an
audit function could permit human stakeholder 2020 to explore in
more detail the propagation and processing of data within framework
model 2090 and/or mediation logic module 2002. In at least one of
the various embodiments, an audit function may permit human
stakeholder 2020 to troubleshoot anomalies that may occur in
connection with the operation of framework model 2090 and/or
mediation logic module 2002. In at least one of the various
embodiments, such anomalies may include errors, inaccuracies,
inappropriate application of specific rules or algorithms to
specific classes of data, inappropriate initialization of
variables, incorrect, unexpected or undesirable system or data
conditions, or the like.
[0339] In at least one of the various embodiments, if such an
anomaly may be detected and the source of the anomaly may be traced
to a change in framework model 2090, an undo function may be
invoked to reverse the respective change.
[0340] In at least one of the various embodiments, to identify the
occurrence of anomalies in connection with the operation of
framework model 2090 and/or mediation logic module 2002, framework
model 2090 and/or mediation logic module 2002 may incorporate a set
of tracking logic modules that may be adapted to monitor the flow
and processing of data, and to identify the occurrence of such
anomalies. In at least one of the various embodiments, one or more
of these tracking logic modules may be employed to evaluate the
source and nature of any detected anomalies, and possibly to
resolve or facilitate the resolution of such anomalies.
[0341] In at least one of the various embodiments, one or more
human stakeholders 2020 may also directly participate in the
identification of anomalies in connection with the operation of
framework model 2090 and/or mediation logic module 2002, including
by directly monitoring the operation of mediation logic module 2002
(e.g., by using an auditing function), tracking changes in data
output by mediation logic module 2002, interacting with one or more
of the tracking logic modules, through a combination of the
foregoing, or the like.
[0342] In at least one of the various embodiments, if framework
model 2090 and/or mediation logic module 2002 may detect an
anomaly, mediation logic module 2002 may automatically attempt to
remedy the anomaly. In at least one of the various embodiments,
this may happen, for example, if mediation logic module 2002 flags
the anomaly to one or more of human stakeholders 2020 (e.g., by
outputting a message on a display, by sending an email, by sending
a page or text message to a mobile device, or by uploading a
message to a website), and no response is received within a
predetermined time. In at least one of the various embodiments,
this may also happen if mediation logic module 2002 determines that
the anomaly exhibits certain characteristics that may require a
prompt resolution (e.g., the anomaly is likely to critically affect
data processing within mediation logic module 2002).
[0343] In at least one of the various embodiments, to automatically
remedy an anomaly, mediation logic module 2002 may automatically
modify one or more of entity propagation rules 2070.
[0344] In at least one of the various embodiments, mediation logic
module 2002 may facilitate , the creation of a new mediation
process for a different business process based on an existing
mediation process.
[0345] In at least one of the various embodiments, mediation logic
module 2002 permits a mediation process to occur, in whole or in
part, in an "isolated environment," sometimes also denoted a
"sandbox environment." In at least one of the various embodiments,
an isolated environment may consist of a subset of human
stakeholders 2020, a combination of other individuals and/or
business entities, a subset of business-related metrics 2060, a
subset of entity propagation rules 2070, or any combination of the
foregoing.
[0346] In at least one of the various embodiments, mediation logic
module 2002 may accept a set of inputs from a specific subset of
human stakeholders 2020, and may use those inputs to process a
specific subset of business-related metrics 2060 and a subset of
entity propagation rules 2070. In at least one of the various
embodiments, such inputs may include a set of changes to framework
model 2090. In at least one of the various embodiments, mediation
logic module 2002 may propagate the modifications though the
mediation process and may present the results to one or more of
human stakeholders 2020. In at least one of the various
embodiments, corresponding human stakeholders 2020 may then have
the option to validate the results and may decide whether to apply
the respective modifications outside the isolated environment,
therefore propagating modified framework model 2090 that was
simulated within the isolated environment into the full mediation
process. In at least one of the various embodiments, such
propagation of a change to framework model 2090 may be called
"publication" of the change, or "live release" of the change. As an
example, in at least one of the various embodiments, an engineering
group within a business entity may choose to simulate a specific
change to framework model 2090 in an isolated environment that may
only be accessible to the respective engineering group, and if the
results of the simulation are validated, the engineering group may
decide to publish the change to the whole business entity.
[0347] In at least one of the various embodiments, mediation logic
module 2002 may permit multiple simulations of changes to framework
model 2090 to occur in a plurality of isolated environments,
whether in parallel or serially. In at least one of the various
embodiments, mediation logic module 2002 may permit publication of
some or all of those changes to the main mediation process, and may
merge the published changes to produce a revised mediation process.
In at least one of the various embodiments, mediation logic module
2002 may selectively reject some of the released changes if it
determines the actual or prospective occurrence of any
anomalies.
[0348] In at least one of the various embodiments, multiple
simulations of changes to framework model 2090 occurring in a
plurality of isolated environments may permit macro-level
evaluations of scenarios, such as a "what-if" scenario in which the
impacts of various sets of changes may be assessed to identify a
preferred set of changes. In at least one of the various
embodiments, as a result of such a "what-if" scenario, some
particular sets of human stakeholders 2020 may emerge as "winners"
or "losers" in terms of allocation of resources or costs (e.g., the
result of such a macro-level evaluation could suggest that
augmenting the information technology (IT) resources of an
engineering group and decreasing the IT resources allocated to an
human resources (HR) group could result in better corporate-level
return on investment.
[0349] In at least one of the various embodiments, advantages of
making changes to an application in an isolated environment may
include, isolating the changes and delaying deployment of the
modified application to protects users of the system from untested
changes, allowing changes to the application to be tested
individually (e.g., without being impacted by other changes that
may be in-progress by other developers), insulating the performance
impacts of generating a new application and re-computing models
onto dedicated hardware, or the like.
[0350] In at least one of the various embodiments, framework model
2090 may include a set of parameters that may be automatically
initialized and then may be dynamically adjusted during the
operation of mediation logic module 2002.
[0351] In at least one of the various embodiments, publication of
individual changes to framework model 2090 and the global
publication of multiple changes may be managed using a
credential-based framework for human stakeholders 2020. In at least
one of the various embodiments, the credential-based framework may
permit delegation of approvals by specific human stakeholders 2020
to other individuals.
[0352] In at least one of the various embodiments, mediation logic
module 2002 may assign action items to specific human stakeholders
2020 in connection with the mediation process. In at least one of
the various embodiments, an action item may include a set of
actions to be taken by respective human stakeholder 2020. In at
least one of the various embodiments, mediation logic module 2002
may assign such action items if an input is needed from respective
human stakeholder 2020, if data relevant to respective human
stakeholder 2020 has changed, if respective human stakeholder 2020
has been identified as a proper recipient of such action items, and
the like.
[0353] In at least one of the various embodiments, mediation logic
module 2002 may be configured. to abstract entities that may be
processed via entity propagation rules 2070. In at least one of the
various. embodiments, a particular entity may be classified based
on specific characteristics of the entity, and may be assigned to
an appropriate entity class. For example, in at least one of the
various embodiments, mediation logic module 2002 may process a list
of computer servers deployed in different physical locations and
may classify them based on operating systems or on the locations
(e.g., Windows XP/Windows Vista/Linux; or Boston/Seattle). In at
least one of the various embodiments, the abstraction of entities
may include reducing the number of individual entities to be
processed and increasing the accuracy or efficiency of the
mediation process.
[0354] In at least one of the various embodiments, an entity
propagation rule may define a relationship between a set of
entities and may manage the flow of entity-related data between at
least a subset of the respective entities. In at least one of the
various embodiments, such entities may include assets, business
entities, intangible items such as intellectual property rights,
entity-related data including money, resources and costs, or the
like. In at least one of the various embodiments, an entity
propagation rule may define a relationship between one or more
entities.
[0355] In at least one of the various embodiments, an entity
propagation rule may define relationships between variable amounts
of entities.
[0356] In at least one of the various embodiments, a model
calculation engine (sometimes also denoted a "propagation
calculation engine") may utilize one or more entity propagation
rules to calculate an instantiation for each instance of each
object that participates in a framework model (such as framework
model 2090). In at least one of the various embodiments, the
instantiation may be a monetary value, a quality measurement, a
quantity measurement, a utilization measurement, or another number,
value or metric, and the like.
[0357] In at least one of the various embodiments, a propagation
calculation engine may utilize one or more entity propagation rules
to process objects that may be part of a generated application.
[0358] FIG. 21 shows a flowchart of process 2100 for at least one
of the various embodiments for a stakeholder proposing modification
to an application that may mediated among other stakeholders. After
a start block, at block 2102, in at least one of the various
embodiments, various inputs proposing modifications of
business-related metrics may be received from the stakeholder (or
user). In at least one of the various embodiments, users or
stakeholders may supply inputs using the user-interface of a
generated application. In at least one of the various embodiments,
modifications may include adding, deleting, editing editable
objects and tables. For example, in a financial modeling
application a user-interface may enable a stakeholder to propose
costs for various objects and/or line items. Also, in at least one
of the various embodiments, stakeholders may be able to modify,
add, or delete entity propagation rules that may be associated with
the generated application. In at least one of the various
embodiments, changes to costs and rules may be modifications that
may be mediated by the mediation module.
[0359] At block 2104, in at least one of the various embodiments,
proposed. modifications may be validated by the generated
application and/or the data processing platform. In at least one of
the various embodiments, this validation step may identify
arithmetic, syntax, logic errors, and the like, that should be
resolved before proposing the modification to other
stakeholders.
[0360] At decision block 2106, in at least one of the various
embodiments, if the modification may be validated, control may move
to block 2108. Otherwise, in at least one of the various
embodiments, control may loop back to block 2102 for to receive
further input from the stakeholder (e.g., to correct the
error).
[0361] At block 2108, in at least one of the various embodiments,
the proposed modification may be released to the mediation module
for further processing. Next, control may be returned to a calling
process.
[0362] FIG. 22 shows a flowchart of process 2200 for at least one
of the various embodiments for a stakeholder receiving a proposed
modification to an application in accordance with at least one of
the various embodiments. After a start block, at block 2202, in at
least one of the various embodiments, a modification of
business-related metrics proposed by another stakeholder (user of
the generated application) may be received. In at least one of the
various embodiments, a stakeholder or user may receive a
notification that a modification has been proposed via a
user-interface notice (e.g., popup dialogs, indicative icons, or
the like), emails, SMS texts, messages, and the like.
[0363] At block 2204, in at least one of the various embodiments,
the proposed modification may be analyzed and/or validated to
determine the impact the modification may have on generated
application. In at least one of the various embodiments, the
stakeholder may tentatively (temporarily) apply the proposed
modification in an isolated environment and observe how it impacts
the results of the generated application.
[0364] In at least one of the various embodiments, a stakeholder or
user may defined thresholds in the generated application to
generate an alarm or notice if the proposed modification may cause
selected business metrics to move beyond define thresholds. For
example, in at least one of the various embodiments, in a financial
modeling application a user may require $1000 to be allocated to an
Email Service. Using this example, in at least one of the various
embodiments, if a proposed modification would reduce the money
allocated to the Email Service below $1000, an alarm and/or
notification may be provided to draw the user's attention to the
issue.
[0365] In at least one of the various embodiments, defined
thresholds may also prevent the user from accepting the proposed
modification until his or her instance of the generated application
may be in a stable state. In at least one of the various
embodiments, the user may configure the business-metrics of the
local instance of the generated application to be in conformity
with the proposed modification before accepting the proposal. For
example, in at least one of the various embodiments, if the user
has configured the application to require $1000 for the Email
Service, that user may modify that requirement (e.g., reducing the
amount of money required for Email
[0366] Servers or reducing the amount of email services required)
to bring the application into a stable state where accepting the
proposed modification may be allowed.
[0367] In at least one of the various embodiments, a user may
choose to reject the modification. In at least one of the various
embodiments, a user may be offered a user-interface to supply a
reason for the denial of proposal. In at least one of the various
embodiments, a user-interface may include pre-formatted selections
(radio buttons, check boxes, or the like) and/or a space to enter a
text description of the reasons for rejecting the proposed
modification.
[0368] In at least one of the various embodiments, a user may not
have a choice whether to accept the modification. In at least one
of the various embodiments, an executive and/or administrative
stakeholder may generate mandatory modifications, forcing the
modification onto the receiving stakeholder.
[0369] In at least one of the various embodiments, if the
modification may be mandatory the receiving stakeholder or user may
modify their instance of the generated application to bring the
application into conformance with the mandatory modification. For
example, if a mandatory modification may be received some other
values in the stakeholder's instance of the generated application
may be modified to accommodate the mandatory modification.
[0370] At decision block 2206, in at least one of the various
embodiments, if the proposed modification may be accepted, control
may move to block 2210. Otherwise, control may move to block
2208.
[0371] At block 2208, in at least one of the various embodiments,
the mediation module may be notified that the proposed modification
may be rejected by the stakeholder or user. Next, control may be
returned to the calling process.
[0372] At block 2210, in at least one of the various embodiments,
the mediation module may be notified that the proposed modification
may acceptable to the receiving stakeholder or user. Next, control
may be returned to the calling process.
[0373] FIG. 23 shows a flowchart of process 2300 for at least one
of the various embodiments for a mediation module receiving
proposed modifications to a generated application in accordance
with at least one of the various embodiments. After a start block,
at block 2302, in at least one of the various embodiments, the
mediation module may receive proposed modifications to
business-metrics and/or rules associated with a generated
application.
[0374] In at least one of the various embodiments, some of the
proposed modification may be provided by stakeholders, users, or
the like. For example, in at least one of the various embodiments,
users may offer proposed changes to entity propagation rules, cost
values, or the like. In at least one of the various embodiments,
such user changes may be received by the mediation module for
further circulation to other stakeholders.
[0375] In at least one of the various embodiments, other systems
and/or machines may automatically supply business-metrics
information that may require circulation to other stakeholders as a
proposed modification. For example, in at least one of the various
embodiments, real-time revenue data may be supplied to the
mediation module from an outside system for circulation to other
stakeholders. In at least one of the various embodiments, the other
stakeholders may make (propose) modifications to account for the
revenue changes (business-metric changes) supplied by the outside
system.
[0376] At block 2304, in at least one of the various embodiments,
the mediation module may submit proposed modifications of
business-metrics to other stakeholders for feedback. In at least
one of the various embodiments, notice of the proposed
modification, may include, sufficient data so that stakeholders may
apply the modification to their instance of a generated
application, sufficient information to identify to
source/origination of modification, or the like. In at least one of
the various embodiments, additional information such as, comments,
description, tracking history, or the like, may also be supplied
with the notifications. In at least one of the various embodiments,
the notification may provide a reference (e.g., link or pointer) to
information sufficient for the proposed modification to be fully
evaluated by receiving stakeholders.
[0377] At block 2306, in at least one of the various embodiments,
the mediation module may receive feedback from other stakeholders
regarding proposed modifications. In at least one of the various
embodiments, feedback may include stakeholders indicating that they
accept or reject the proposed modification. In at least one of the
various embodiments, feedback may also include comments for
stakeholders. Further, in at least one of the various embodiments,
feedback may include counter proposals and/or references to counter
proposals.
[0378] At block 2308, in at least one of the various embodiments,
the mediation module may determine if the proposed modification has
reached a feedback threshold that may indicate if the proposal may
be accepted or rejected. In at least one of the various
embodiments, unanimous consent from all stakeholders may be
required. In at least one of the various embodiments, proposed
modification offered by stakeholders having executive and/or
administrative authority may be considered accepted absent consent
from other stakeholders. In at least one of the various
embodiments, a majority of stakeholders may accept the proposal for
it to reach the acceptance threshold. One of ordinary skill in the
art will appreciate that additional criteria may be used to
determine if a proposal may be accepted.
[0379] At decision block 2310, in at least one of the various
embodiments, if a determination regarding the proposed modification
is still in process, control may loop back to block 2306.
Otherwise, control may move to block 2312.
[0380] At block 2312, in at least one of the various embodiments,
the mediation module may report to interested stakeholders that the
proposed modification may have been accepted or rejected. In at
least one of the various embodiments, reporting may include
actively sending the stakeholder a message (e.g., email, SMS
message user-interface notification, or the like). In at least one
of the various embodiments, the reporting may include showing the
proposed modification in a user-interface list with an indicator of
the status to the proposed modification (e.g., accepted, rejected,
cancelled, pending, or the like).
[0381] At block 2316, in at least one of the various embodiments,
the mediation module may incorporate the accepted modification
proposal into the generated application. In at least one of the
various embodiments, if the proposed modification may be rejected
or cancelled, the proposed modification may be discarded.
[0382] At decision block 2316, in at least one of the various
embodiments, if More proposed modifications remain to be processed
by the mediation module, control may loop back to block 2304.
Otherwise, control may be returned to the calling process.
[0383] In at least one of the various embodiments, the steps
described in conjunction with FIG. 21-23 may be implemented as part
of mediation module 2002, data processing platform 1900, or
combination thereof.
[0384] In at least one of the various embodiments, proposed
modifications may be implemented as change entries that may be
generated and stored in a work stream associated with the generated
application owned by the stakeholder proposing the
modification.
[0385] In at least one of the various embodiments, each instance of
the generated application may be modified independently with change
entries being preserved for that instance of the generated
application impacted by the modification.
[0386] In at least one of the various embodiments, if a proposed
modification may be added to the primary application, the change
entries from the modified instance of the application may be added
to the work stream of the primary application.
[0387] In at least one of the various embodiments, each stakeholder
modifying a separate instance of the generated application may
generate change entries to a work stream associated with their
unique instance of the generate application. In at least one of the
various embodiments, the change entries preserved in the "instance"
work stream may be separate from other instances.
[0388] FIG. 24 shows a flowchart of process 2400 for at least one
of the various embodiments that may be used to apply entity
propagation rules for objects that may be part of a generated
application. In at least one of the various embodiments, a
generated application may include a model for financial cost
modeling. After a start block, at block 2402, in at least one of
the various embodiments, the propagation calculation engine may
receive a set of entity propagation rules to be processed. In at
least one of the various embodiments, entity propagation rules may
be received from a database, local storage, remote storage, may be
generated based on the execution of change entries, user input, or
the like, or combination thereof. Also, in at least one of the
various embodiments, one or more of the entity propagation rules
may be determined based on the framework model, mediation module,
templates, or the like.
[0389] In at least one of the various embodiments, entity
propagation rules may be implemented by using formulas defined in a
programming language. In at least one of the various embodiments,
for commonly used formulas, users may select formulas using a
graphical user-interface. In at least one of the various
embodiments, the graphical user-interface components used to select
the formulas may be mapped to the underlying programming language
used to generate the formulas.
[0390] At block 2404, in at least one of the various embodiments,
the propagation calculation engine may select at least one of the
entity propagation rules for processing.
[0391] At block 2406, in at least one of the various embodiments,
the propagation calculation engine may determine a source object
that may be directly calculated (e.g., because all necessary
components have been calculated or are directly available). In at
least one of the various embodiments, an object may be table
containing one or more items classified similarly. For example, in
at least one of the various embodiments, a source object Data
Center may have associated line items of Boston, Chicago, Seattle,
each having a corresponding cost value. In at least one of the
various embodiments, a entity propagation rule in a financial
modeling application may define how the costs for each line item in
the Data Center object maybe allocated to other objects in a
financial model, such as Servers.
[0392] At block 2408, in at least one of the various embodiments,
the propagation calculation engine may determine a set of matching
source and destination rows and may alter the value at the
destination (e.g., increases the value) by the result of the entity
propagation rule.
[0393] In at least one of the various embodiments, entity
propagation rules may determine the matching between the sources
rows (from the source object) and the destinations rows (rows in
one or more other objects) by various techniques, including direct
mapping, logical formulas, complex algorithms, or the like.
[0394] At block 2410, in at least one of the various embodiments,
the propagation calculation engine may check if any entity
propagation rules remain to be processed, and if so, control may
loop back to block 2404. Otherwise, control may be returned to the
calling process. In at least one of the various embodiments, a
entity propagation rule may be configured to use one or more types
of matching algorithms (e.g., matching rules), including, but not
limited to, All/All (e.g., each source row matches all destination
rows), All/Some (e.g., each source row matches some of the
destination rows), Some/All (e.g., not all source rows are
considered, but for those that are, they each match all destination
rows), Some/Some (e.g., not all source rows are considered, not all
destination rows are considered), or the like.
[0395] In at least one of the various embodiments, if applying
entity propagation rules that selectively filter source or
destination rows, a variety of filters and matching rules may be
applied to determine if the rows match the entity propagation rule.
in at least one of the various embodiments, rows may be filter
and/or selected based on whether they include certain values, or
ranges of values. Also, in at least one of the various embodiments,
multiple values may be considered by build filter rules base on
combining logical and/or mathematic expressions. For example, in at
least one of the various embodiments, a filter may be
city=`Seattle` or it may be city=`Seattle` or city=`Portland`.
Also, in at least one of the various embodiments, numerical values
may be used such as quantity >5 and quantity <10, and the
like.
[0396] In at least one of the various embodiments, matching rules
may be generated by a user selecting them by way of a graphical
user-interface (e.g., dialog boxes). In at least one of the various
embodiments, such user-interfaces may be used for commonly used,
and/or easier to generalize matching rules. In at least one of the
various embodiments, other more complex and/or unique filters may
generated by the user supplying programming and/or query language
fragments that may define custom matching rules.
[0397] In at least one of the various embodiments, a manual
allocation algorithm (e.g., an algorithm in which allocations are
made based on human input) according to at least one of the various
embodiments may employ a set of rules, including, mapping the
source row to destination row based on entries made by one or more
users.
[0398] Also, in at least one of the various embodiments, a user may
enter and/or configure multiple matching rules that may be
evaluated in turn against a source table until one of the rules
matches: In at least one of the various embodiments, the multiple
rules entered by a user may be multiple matching rules of different
types, including those discussed above. In at least one of the
various embodiments, multiple rules may be useful for mapping
financial transaction ledgers (e.g., general ledger) into multiple
objects.
[0399] In various embodiments, an entity propagation rule may be
configured with a distribution strategy if the value from a source
row may be split across multiple destination rows.
[0400] In at least one of the various embodiments, the value for
each destination row from a particular source row may be calculated
by dividing the source value by the number of destination rows
(e.g., DESTINATION ROW VALUE=SOURCE ROW VALUE/Number of Destination
Rows).
[0401] In at least one of the various embodiments, the value for
each destination row from a particular source row may be calculated
by multiplying by a factor for the particular destination row and
dividing by the sum of the factors for all matching destination
rows. (e.g., DESTINATION ROW VALUE=SOURCE ROW VALUE*DESTINATION ROW
SomeColumn/SUM(DESTINATION ROW SomeColumn). Thus, the distribution
rule may distribute the value from the source row to the
destination row based on the simple weighting of the selected
column in the destination table.
[0402] In at least one of the various embodiments, the value for
each destination row from a particular source row may calculated by
multiplying by a factor and dividing by a different factor. For
example, in at least one of the various embodiments, such a rule
may be represented by DESTINATION ROW VALUE=SOURCE ROW
VALUE*SomeColumn/AnotherColumn.
[0403] In at least one of the various embodiments, the value for
each destination row from a particular source row may be calculated
using a factor calculated by looking at other parts of the model
(e.g., other objects).
[0404] In at least one of the various embodiments, the rule may
reference (utilize) a value computed by another rule (e.g., to
weight by the cost computed from one or more rows in another
object). One of ordinary skill in the art will appreciate how such
dependencies influence the order of propagation rule selection for
processing in block 2404 of FIG. 24.
[0405] In at least one of the various embodiments, handling
reference circularities (e.g., "A" depends upon "B" but "B" depends
upon "A") may be treated as a system of simultaneous mathematical
equations, and strategies for calculating an optimal result include
substitution, elimination and, ultimately, running Monte Carlo
simulations, or the like.
[0406] In at least one of the various embodiments, an arbitrary
formula may be used to determine a distribution. in at least one of
the various embodiments, such distribution formulas combine
multiple of the above strategies or employ additional custom
functions. For example, in at least one of the various embodiments,
a weight factor could be calculated using logic expressions
yielding distributions rules such as "Services with a
HostCount>=10 should be weighted 4.times. higher than services
with a HostCount<10."
[0407] In at least one of the various embodiments, allocation ratio
tables may be generated for entity propagation rules that may be
based on database references between associated objects. In at
least one of the various embodiments, each row in an allocation
ratio table may correspond to an allocation from one item in the
source object. In at least one of the various embodiments, in some
cases multiple items from the source abject may allocate to
multiple items in the destination object. Similarly, in at least
one of the various embodiments, individual items from the source
object may allocate to multiple items in the destination object, or
multiple items from the source object may allocate to a single item
in the destination object.
[0408] In at least one of the various embodiments, if an allocation
ratio table may be used, the distribution formula associated with
the entity propagation rule may be applied to each row of the
allocation ratio table. In at least one of the various embodiments,
if a distribution rules may be applied to an allocation ratio
table, the rows having the same source object item may be
collapsed. Values in the collapsed rows may be added together to
show a single value. FIG. 34 illustrates a use case involving an
allocation ratio table.
[0409] In at least one of the various embodiments, allocation ratio
tables may generated in advance, and/or cached as required.
[0410] Furthermore, since additional distributions rules may be
applied to distribute values from a matched source row to a matched
destination row, the rules disclosed herein should not be
considered limiting examples.
[0411] FIG. 25 shows a flowchart for process 2500 for processing an
entity propagation rule in accordance with at least one of the
embodiments. After a start block, at block 2502, in at least one of
the various embodiments, a source object and a destination object
may be determined.
[0412] In at least one of the various embodiments, objects may be
associated with each other based on relationships among line items
that may be included in each object. For example, a Data Center
object may have a column for location (e.g., such Seattle) and the
Server object may also have a property representing location. In at
least one of the various embodiments, properties may also be used
in generating the application to establish links between the
objects. In at least one embodiment, the relationship may be
determined as described in U.S. patent application Ser. No.
12/467,120 filed on May 15, 2009, entitled "Operational-Related
Data Computation Engine," which is incorporated by reference into
this patent application in its entirety.
[0413] At block 2504, in at least one of the various embodiments,
process 2500 may determine the source object line items that may
match the particular entity propagation rules that may be
executing.
[0414] At decision block 2506, in at least one of the various
embodiments, if matching source items are found, control may move
to block 2508. Otherwise, control may be returned to a calling
process because there may be no source items that match this entity
propagation rule.
[0415] At block 2508, in at least one of the various embodiments,
process 2400 may determine the destination object line items that
may match the executing entity propagation rule.
[0416] At block 2510, in at least one of the various embodiments,
an allocation ratio table may be generated if required.
[0417] At decision block 2512, in at least one of the various
embodiments, if destination object line items may be found, control
may move to block 2514. Otherwise control may be returned to the
calling process.
[0418] At block 2514, in at least one of the various embodiments,
the distribution rule(s) associated with the executing entity
propagation rule may be applied to determine how the values from
the source object line items may be allocated the destination
object line items.
[0419] In at least one of the various embodiments, if process 2500
may be using an allocation ratio table the distribution rules
(e.g., formulas) may be applied to items and/or rows in the
allocation ratio table. Otherwise, the distribution rules may be
applied to the items in the destination table directly.
[0420] At block 2516, in at least one of the various embodiments,
if an allocation ratio table was used to calculate/apply the
distribution rules, an object table may generated from the
allocation ratio table. In at least one of the various embodiments,
allocation ratio table rows having the same destination item
identifier may be collapsed into one row having a value computed by
summing the corresponding values from the collapsed rows into one
row for each unique line item identifier.
[0421] At block 2518, in at least one of the various embodiments,
if an entity propagation rule is applied, a graphical
user-interface (GUI) may be updated to reflect the application of
the entity propagation rule. In at least one of the various
embodiments, the GUI may be updated immediately upon completion of
the entity propagation rule executions or the GUI update may be
deferred until a later time. If the entity propagation rule has
completed execution, control may be returned to the calling
process.
[0422] FIG. 26 shows a screenshot of a GUI of at least one of the
various embodiments that may facilitate the definition of an entity
propagation rule in accordance with at least one of the various
embodiments. In at least one of the various embodiments, a user is
presented with a table 2602 that identifies 5 servers (Servers 1-5)
deployed in three data centers (Boston, Dallas and Chicago). In at
least one of the various embodiments, table 2604 may identify four
data centers (Boston, Dallas, Chicago and Seattle) where servers
may be located. In at least one of the various embodiments, each of
these servers and data centers may be an entity for purposes of
defining one or more entity propagation rules. In at least one of
the various embodiments, servers 2602 and data centers 2604 are
representations of servers, and respectively data centers and they
facilitate the definition of entity propagation rules.
[0423] In at least one of the various embodiments, table 2602
includes a cost that may be associated with each object
relationship, where the cost is generated from an entity
propagation rule. In at least one of the various embodiments,
properties selected from dialog box 2606 may be used to define an
entity propagation rule that may be configured to allocate cost
from data centers to servers. In at least one of the various
embodiments, this entity propagation rule may use an allocation
model defined based on a set of rules, rolling up cost from all
data centers to all servers, using an even distribution algorithm.
In at least one of the various embodiments, alternative allocation
models may be employed to map a subset of the servers to a subset
of the data centers, and may use distribution algorithms based on
weights, ratios, advanced rule definitions, and the like. In at
least one of the various embodiments, this entity propagation rule
could, for example, facilitate the allocation of costs among
various objects (or object relationships), such as, but not limited
to departments or cost centers within a business entity for
accounting or administrative purposes.
Entity Propagation Rule Use Cases For Automation of Business
Management Processes and Assets
[0424] FIG. 27 shows a logical representation of entity propagation
rule 2700 operating between Data Center object 2702 and Server
object 2710 where various parameters of an entity propagation rule
may be defined. In at least one of the various embodiments, Data
Center object may have a name/identity column, Data Center 2704,
and a cost column, Lease 2706, and a size column, Capacity 2708. In
at least one of the various embodiments, Server object 2710 may
have a name/identity column, Server 2712, a location column, Data
Center 2714, a server size column, Size 2716, and a cost column,
Cost 2718.
[0425] In at least one of the various embodiments, the costs
associated with the Data Centers 2702 may be allocated using an
even distribution rule where all the costs from Data Centers 2702
may be evenly allocated to each server.
[0426] FIG. 28 shows a logical representation of entity propagation
rule 2800 operating between Data Center object 2802 and Server
object 2810 where various parameters of an entity propagation rule
may be defined. In at least one of the various embodiments, Data
Center object may have a name/identity column, Data Center 2804,
and a cost column, Lease 2806, and a size column, Capacity 2808. In
at least one of the various embodiments, Server object 2810 may
have a name/identity column, Server 2812, a location column, Data
Center 2814, a server size column, Size 2816, and a cost column,
Cost 2818.
[0427] In at least one of the various embodiments, the costs
associated with the Data Centers 2802 may be allocated using an
even distribution rule where 80% of the costs from Data Centers
2802 may be evenly allocated to each server.
[0428] FIG. 29 shows a logical representation of entity propagation
rule 2900 operating between Data Center object 2902 and Server
object 2910 where various parameters of an entity propagation rule
may be defined. In at least one of the various embodiments, Data
Center object may have a name/identity column, Data Center 2904,
and a cost column, Lease 2906, and a size column, Capacity 2908. In
at least one of the various embodiments, Server object 2910 may
have a name/identity column, Server 2912, a location column, Data
Center 2914, a server size column, Size 2916, and a cost column,
Cost 2918.
[0429] In at least one of the various embodiments, the costs
associated with the Data Centers 2902 may be allocated using an
even distribution rule where 100% of the costs from Data Centers
2802 may be evenly allocated to each server that may be in Boston.
One of ordinary skill in the art will appreciate that other filters
that may or may not be visible on Server 2910 may be available for
use as filters.
[0430] FIG. 30 shows a logical representation of entity propagation
rule 3000 operating between Data Center object 3002 and Server
object 3010 where various parameters of an entity propagation rule
may be defined. In at least one of the various embodiments, Data
Center object may have a name/identity column, Data Center 3004,
and a cost column, Lease 3006, and a size column, Capacity 3008. In
at least one of the various embodiments, Server object 3010 may
have a name/identity column, Server 3012, a location column, Data
Center 3014, a server size column, Size 3016, and a cost column,
Cost 3018.
[0431] In at least one of the various embodiments, the costs
associated with the Data Centers 3002 may be allocated using an
even distribution rule where 100% of the costs from Data Center
3002 corresponding to the Boston location may be evenly allocated
to each server. One of ordinary skill in the art will appreciate
that other filters that may or may not be visible on Server 3010
may be available for use as filters.
[0432] FIG. 31 shows a logical representation of entity propagation
rule 3100 operating between Data Center object 3102 and Server
object 3110 where various parameters of an entity propagation rule
may be defined. in at least one of the various embodiments, Data
Center object may have a name/identity column, Data Center 3104,
and a cost column, Lease 3106, and a size column, Capacity 3108. in
at least one of the various embodiments, Server object 3110 may
have a name/identity column, Server 3 112, a location column, Data
Center 3114, a server size column, Size 3116, and a cost column,
Cost 3118.
[0433] In at least one of the various embodiments, the costs
associated with the Data Centers 3102 may be allocated using a
entity propagation rule where 100% of the costs from Data Center
3102 may be allocated to each server weighted based on server size
(e.g., indicated by Size 3116). For example, Server 1 may have a
size of 1, thus this entity propagation rule may allocate costs to
Server 1 using the formula $200,000*1/16 (e.g., Total Allocated
Costs*Size/Total Size).
[0434] FIG. 32 shows a logical representation of entity propagation
rule 3200 operating between Data Center object 3202 and Server
object 3210 where various parameters of an entity propagation rule
may be defined. In at least one of the various embodiments, Data
Center object may have a name/identity column, Data Center 3204,
and a cost column, Lease 3206, and a size column, Capacity 3208. In
at least one of the various embodiments, Server object 3210 may
have a name/identity column, Server 3212, a location column, Data
Center 3214, a server size column, Size 3216, and a cost column,
Cost 3218.
[0435] In at least one of the various embodiments, the costs
associated with the Data Centers 3202 may be allocated using a
entity propagation rule where 100% of the costs from Data Center
3202 may be allocated to each server weighted based on the ratio of
server size (e.g., indicated by Size 3216) to total data center
Capacity (e.g., Capacity 3208). For example, Server 1 may have a
size of 1, and the total Data Center may be capacity 40, thus this
entity propagation rule may allocate costs to Server 1 using the
formula $200,000*1/40 (e.g., Total Allocated Costs*Server
Size/Total Data Center Capacity).
[0436] FIG. 33 shows a logical representation of entity propagation
rule 3300 operating between Data Center object 3302 and Server
object 3310 where various parameters of an entity propagation rule
may be defined. In at least one of the various embodiments, Data
Center object may have a name/identity column, Data Center 3304,
and a cost column, Lease 3306, and a size column, Capacity 3308. In
at least one of the various embodiments, Server object 3310 may
have a name/identity column, Server 3312, a location column, Data
Center 3314, a server size column, Size 3316, and a cost column,
Cost 3318.
[0437] In at least one of the various embodiments, the costs
associated with the Data Centers 3302 may be allocated using a
entity propagation rule where 100% of the costs from Data Center
3302 may be allocated to each server only if the Data Center
location said servers associated with it. For entity propagation
rule 3300, the data center located in Seattle may account for
$40,000, but because no servers in Server 3310 may be located in
Seattle the money for Seattle may not allocated. Thus, in at least
one of the various embodiments, entity propagation rule 3300 evenly
allocation $160,000 among the five individual servers in Server
3310 within their related Data Center 3304.
[0438] FIG. 34 shows a logical representation of entity propagation
rule 3400 operating between Data Center object 3402 and Server
object 3410 where various parameters of an entity propagation rule
may be defined. In at least one of the various embodiments, Data
Center object may have a name/identity column, Data Center 3404,
and a cost column, Lease 3406, and a size column, Capacity 3408. In
at least one of the various embodiments, Server object 3410 may
have a name/identity column, Server 3412, a location column, Data
Center 3414, a server size column, Size 3416, and a cost column,
Cost 3418.
[0439] In at least one of the various embodiments, the costs
associated with the Data Centers 3402 may be allocated using a
entity propagation rule where the costs from Data Center 3402 may
be allocated to each server based on a weighting of the server size
and only if the Data Center location has servers associated with
it. For entity propagation rule 3400, the data center located in
Seattle accounts for $40,000 but because no servers in Server 3410
may be located in Seattle the money for Seattle may not allocated.
Thus, in at least one of the various embodiments, entity
propagation rule 3400 allocates $160,000 among the five individual
servers in Server 3410 weighted by the size of the servers, within
their related Data Center 3404. FIG. 35 shows a logical
representation of entity propagation rule 3500 operative between
Application object 3502 and Trouble Ticket object 3516. In at least
one of the various embodiments, Application object may have a
name/identity column 3504, and a cost column 3506. In at least one
of the various embodiments, Ticket object 3516 may have a
name/identity column 3518, and a cost column, Cost 3520.
[0440] In at least one of the various embodiments, a entity
propagation rule that may allocate costs associated with an
application to a set of trouble tickets may require an intermediate
allocation ratio table. In at least one of the various embodiments,
at least one reason to require an allocation ratio table may be if
the source object may be allocated to more than one item in the
destination object.
[0441] In at least one of the various embodiments, allocation ratio
table 3508 may include the values from Application object 3502
allocated to individual trouble tickets. in at least one of the
various embodiments, the use case illustrated by rule 3500 may have
five trouble tickets charged against the two applications. And,
notably for this example, trouble ticket 4 may be charged against
both applications.
[0442] In at least one of the various embodiments, to optimize the
calculations and to preserve financial integrity, allocation ratio
table 3508 may be generated. In at least one of the various
embodiments, allocation ratio table may have at least three
columns, Ticket 3510, Application (App) 3512, and Cost 3514. In at
least one of the various embodiments, allocation ratio table 3508
may have one row for each allocation associated with the rule. In
at least one of the various embodiments, even though there may be
five trouble tickets that may be associated with rule 3500 there
may be six rows in allocation ratio table 3508, one for each
allocation coming from each application line item. The "extra" row
may be because two applications contribute to trouble ticket 4,
resulting in two rows in the allocation ratio table associated with
trouble ticket 4.
[0443] In at least one of the various embodiments, the costs coming
from the applications may be allocated evenly across the rows in
the allocation ratio table. For example, from Application object
3502, the database application may be allocating a total of $90,000
to trouble tickets. In one embodiment, the application database may
be associated with three trouble tickets, thus $30,000 may be
allocation to each of the three associated trouble tickets (e.g.,
ticket 1, 4, and 5). Likewise, the application firewall may be
associated to three trouble tickets (e.g., ticket 2, 3, and 4)
resulting in $10,000 being allocation of each of ticket 2, 3, and
4.
[0444] In at least one of the various embodiments, allocation ratio
table 3508 may be collapsed to generate ticket object 3516. In at
least one of the various embodiments, duplicate ticket entries from
the allocation ratio table may be accumulated into a single value.
In at least one of the various embodiments, ticket object 3516 may
have a name/identity column 3518, and a cost column 3520.
* * * * *