fig1 shows a sample process , order to cash , which is comprised of various sub - processes : receive order inquiry , provide customer quotation , create customer outline agreement , create sales order , schedule production , manufacture product , ship product and invoice customer . the dashed line arrows connecting the sub - processes are the communication paths between the sub - processes . in the example shown in the figure , the sub - processes actually communicate through a messaging broker , such as an ibm mqseries component , and the paths to and from the component are identified identically . this messaging broker permits certain sophisticated messaging uses , such as message queuing , some data translation , etc . a messaging component is added to the messaging broker , through methods known in the art . this messaging component creates a “ monitoring ” message for each original message received by the broker . this monitoring message contains , in this embodiment , specific data generated from the original messages passing between the sub - processes . the monitoring message with its data is then sent from the messaging broker to a central database repository or database ( the terms “ repository ” or “ database ” are used interchangeably throughout .) the messaging component may be , in some embodiments , or may not be , in other embodiments , provided by the messaging broker . for example , ibm &# 39 ; s mqseries messaging broker provides a component that can be configured to perform a copying function for the messages it receives , and so create monitoring messages for the messages it receives . the specific data contained in the monitoring messages ( in this embodiment , this data is copied from the original messages passing between the sub - processes ) is organized into data fields . those data fields are path specific in this embodiment . for example , assume a customer calls the enterprise ( widget co .) whose process is shown in fig1 and asks whether or not widget co . has a certain product ( type a widgets .) that customer request will begin the receive order inquiry sub - process which will end with the generation of a receive order inquiry message traveling to the provide customer quotation sub - process through the messaging broker component . when the messaging broker receives the message on path a , it will create a monitoring message , and send the monitoring message to the central database repository , as shown in fig2 . in this embodiment , the data contained in the monitoring message is generated from the message on path a . other preferred embodiments may alter or add data to the monitoring messages aside from that contained in the original message . the monitoring message contains , in this embodiment , specific data fields . ( of course , other embodiments may have different data fields .) those data fields are : fields identifiers process identifier proid , sub - process identifier sbproid , customer number custno , part number partno , quantity qty , date date , time time the first field , the process identifier field , provides the identifier for the process , for example , the value “ order to cash ” because the monitoring message is being created within the order to cash process . the second field , the sub - process identifier field , provides the identifier for the sub - process , for example , the value “ inquiry ” because the monitoring message is being created within the inquiry sub - process . this embodiment prepopulates these process identifier and sub - process identifier fields , with the appropriate values . the customer number field is assigned to the particular customer generating the inquiry . the part number field is the identifier for the particular part and the quantity for the particular quantity . date and time are the data and time the message is generated . other message fields for other paths of this embodiment are shown in table 1 . of course , some , all or none of these fields may be present in other embodiments , as well as other fields as desired . for example , one or more activity identifier fields may be present in monitoring messages in other embodiments . the monitoring message data populates one information flow or transaction record (“ transaction record .”) as monitoring messages progress through any given process and / or sub - process , the transaction record is updated . once the monitoring messages complete the transaction record , all of the information needed to measure that transaction through the process is contained in one record in the central message database . ( of course , if the monitoring messages do not fully populate the transaction record , e . g ., the transaction is aborted in mid process , then these abandoned records may be made available as well with an indication that they were abandoned .) the central message database can be reviewed in any number of ways , in order to measure , monitor and track enterprise communications and processes , e . g ., to provide information or generate reports . using the central message database to provide information or generate reports “ off loads ” the information access or reporting processes from the applications that generate messages initially , e . g ., sub - processes such as those seen in fig1 . this off loading relieves some of the monitoring pressure from the source applications so that , for example , any queries that might have been made to the source applications and interfere with or slow down the operation of the source applications can now be made through the central message database . the information retrieved from the central message database may include , but is not limited to , information about any particular order or customer , information about process efficiency , “ snapshot ” or time slice information , information across time spans such as days , weeks , or months , information to gauge trends or performance , etc . also , in some embodiments , a “ real - time ” tool may be used to track the progress of transaction records and / or processes and use distribution methods such as broadcasting , wap , etc . to provide the information to users . for example , if a process such as pipeline capacity for oil and natural gas transmissions is implemented and monitored through an embodiment of the present invention , the central message database will constantly broadcast unused pipeline capacity , which information in turn can be used to sell , trade or barter that unused capacity . as another example , information about an enterprise &# 39 ; s processes can be made available over an intranet , extranet , the internet , etc . to business partners or other entities . one example would be providing information to stock analysts so that they could track any particular enterprise &# 39 ; s productivity or other areas of interest . another example would be providing information to actual or potential business partners to check production capacity , shipping capacity , or other areas of interest . in some embodiments , with regard to external entities , communication channels between the external entities and the enterprise might well be established , so that central message databases exist on both ends of the communication channel . the central message database allows for broader analysis of trends that may include : time between sub - processes , variances by customer , variances by order amount , bottlenecks in the process , etc . for example , it would be possible to determine how many orders stood between order and invoice . this may allow for the acceleration of some orders so they could be booked by quarter close . for example , a vendor bottleneck may be identified in the course of review of the processes , sub - processes and / or activities . for example , seasonal variations in processes , sub - processes and / or activities may be identified as well . of course , some embodiments may create mirror databases and / or generate other databases that can be used by various entities . for example , an enterprise may create a number of central message databases which could track processes , sub - processes and / or activities in whole or part . these databases could also be combined as desired . monitoring message database ( s ) may be used , in some embodiments , in various ways , either in addition to or instead of central message database ( s .) for example , a monitoring message database or a central message database may be used to generate messages and feedback to the processes , sub - processes , activities and / or applications , as well as to users and / or administrators ( herein generally “ users .”) various messages transmitted from sub - process applications such as error messages would generate special monitoring messages which would be added to a message monitoring database . other events , exceptions , triggers and thresholds , could be tracked as well in various embodiments and be used to signal conditions , problems , etc . by various methods such as “ flagged ” or specially designated messages or other indicators . access to the database ( s ) is , in the preferred embodiments , on a secured or authorized basis , with different users obtaining different levels of access to the data in the database . fig3 shows a screen shot of an example of a preferred embodiment where access was made available to a customer over a corporate extranet . the screen shot is of a report , generated through an xml link to the central message database , of that particular customer &# 39 ; s orders . in the preferred embodiments , the customer has the option to “ drill down ” through this screen to other screens for further detail . so , for example , fig4 shows a result of one such operation , where the customer had drilled down from the screen of fig3 . of course , these records may vary depending on the status of the transaction , that is , whether the transaction is in the middle of the process , at the beginning of the process , etc . furthermore , other reporting options may be seen depending on the embodiments . additionally , in some embodiments the user may have the option to drill down further into or past these levels if desired . the preferred embodiments of the present invention also provide a simulation module for business processes . the simulation module makes possible simulation of new processes , their sub - processes and the activities that make up the sub - processes . this provides the enterprise or other user with the opportunity to assemble , test , adjust , and simulate processes before they are integrated into the enterprise . the simulation module of the preferred embodiments provides the ability to assemble simulated processes in two primary ways . the first primary way is through provision of a toolkit or palette of predetermined sub - processes to the user . the user can then choose from that palette of sub - processes to form a process for an organization , which is then used in the simulation as is explained in further detail below . the second primary method of assembling processes is to provide the user with activities , which are the most granular construct of a sub - process . additionally , more sophisticated users will be given the opportunity to assemble their own activities . either or both options of this second primary method can be offered in various embodiments . additionally , the first and second primary methods can be combined in certain embodiments as well . the preferred embodiments permit use of discrete activities among sub - processes , perhaps in an object oriented format , in order to save time and increase productivity . these activities can then be connected to form one or more sub - processes , which in turn can be connected to form one or more processes . the ability to create additional sub - processes would allow for the company to add their unique sub - processes to the palette . it should be noted that in other embodiments , the simulation module may be constructed in other ways . for example , preconfigured , industry - specific processes may be supplied that can be altered and / or provided with enterprise specifics . the simulation model is contained , in the preferred embodiments , on a corporate intranet or extranet . the underlying assumption of the simulation model in the preferred embodiments is that the completion of each sub - process will generate a message . so , for example , if a process such as that of fig1 is simulated , the completion of the first sub - process will generate a message to be sent to the next sub - process , the completion of the next sub - process will generate a message that will be sent to the next sub - process , and so on . fig5 shows a process development environment screen for an example process called “ order ” of the simulation module . sub - processes inquiry , quote , agreement , order , schedule , manufacture , ship and invoice have been joined together to comprise this process . the sub - processes , in this example , are predetermined and their activities are predetermined . the input and output queue names are identified where appropriate . for example , the output queue name in the inquiry sub - process is inquiry_out . that output queue then feeds data into the input queue of the quote sub - process . ( these are analogous to path a in fig1 .) the base delay provides the initial time of a sub - process . for example , the base delay for the quote sub - process is 1 or a time increment of 1 . in contrast the manufacture sub - process base delay is 48 , so that the time increment for the manufacture sub - process is 48 . the current variation shows the increase / decrease variation set by the slider , permitting an increase or decrease in the latency per process and thus permits the user to see the downstream effect of altering each sub - process time . ( other embodiments may use different apparatus and methods as known in the art to vary the latency of the sub - process .) in this example , the total time of the process is obtained by adding each base delay of each sub - process , however , each sub - process may not affect the other in a geometric or logarithmic progression . for example , varying the base delay by one time increment of the quote sub - process may not lead to an exact one time increment variation in the scheduling sub - process . fig6 through 9 are examples of tools that are used in this embodiment to construct sub - process modules such as those used in fig5 . for example , fig6 shows the properties of the agreement sub - process module , which are the process , the sub - process and the application used in the sub - process . the process and sub - process are predetermined in this module . the user has the option of setting the application alternative of the sub - process to one or more predetermined alternatives . these alternatives would be used , for example , when a new application might be used to provide output from the sub - process . fig7 shows a message queue construction tool for the sub - process identified in fig6 . this tool , which may be another option combined with the process tool of fig6 or some other tool in various embodiments , or may be stand - alone in other embodiments , provides the ability to select a queue manager ( a process that manages different message queues in various machines or applications ), input queue and output queue for the particular sub - process being simulated . each of these options , queue manager , input queue and output queue , can be changed by using the arrows to access a drop - down menu of predetermined alternatives . once the alternatives are chosen , the module can be saved . of course , in other embodiments non - predetermined alternatives may be used . fig8 shows an application construction tool , which can be used to select the applications used on either end of the queue or path . here , there are two separate targets , one external , with a single monitoring message being sent to a central message database , before the source message is split and sent to both target applications . fig9 shows the particular data fields or points that may be captured in the monitoring message . these are selected by highlighting the preferred fields in this embodiment . other alternatives are possible for other embodiments of the simulation module . for example , the embodiments discussed above have some alternatives as predetermined , which makes the construction of sub - process modules more convenient . in other embodiments non - predetermined alternatives may be used . moreover , any desired processes that are not defined in predetermined modules can be developed and made available to the user . for example , a tool such as that shown in fig1 provides the ability to alter the process , the sub - process , and the application , by using the arrows to access a drop - down menu of predetermined alternatives , thus facilitating creation of new processes , sub - processes and / or activities . other embodiments may use an “ open ended ” format to allow the creation of new processes and sub - processes and / or activities . the simulation module is , in the preferred embodiments , either stand - alone or contained as part of a monitoring apparatus and / or system as had been described above . if the latter , then “ real - time ” data and processes , sub - processes and activities can be used in the simulation apparatus and / or process . the simulator module permits processes and sub - processes to be defined , simulated , and refined before modifying existent systems or implementing new systems . the above description and the views and material depicted by the figures are for purposes of illustration only and are not intended to be , and should not be construed as , limitations on the invention . moreover , certain modifications or alternatives may suggest themselves to those skilled in the art upon reading of this specification , all of which are intended to be within the spirit and scope of the present invention as defined in the attached claims .