Came back from the Orlando and was really impressed with the Hasso Plattner's presentation.
I'll fill in my afterthoughts
Friday, May 21, 2010
Friday, July 17, 2009
Preparation for WB
Follow ITIL processes for incident management, change management, and problem management
Incident Management
The goal of Incident Management is to restore normal service operation as quickly as possible and minimize the adverse effect on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. 'Normal service operation' is defined here as service operation within Service Level Agreement (SLA) limits.
Problem Management
The goal of 'Problem Management' is to resolve the root cause of incidents and thus to minimize the adverse impact of incidents and problems on business that are caused by errors within the IT infrastructure, and to prevent recurrence of incidents related to these errors. A `problem' is an unknown underlying cause of one or more incidents, and a `known error' is a problem that is successfully diagnosed and for which either a work-around or a permanent resolution has been identified. The CCTA defines problems and known errors as follows:
A problem is a condition often identified as a result of multiple Incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant.
A known error is a condition identified by successful diagnosis of the root cause of a problem, and the subsequent development of a Work-around.
Problem management is different from incident management. The principal purpose of problem management is to find and resolve the root cause of a problem and prevention of incidents; the purpose of incident management is to return the service to normal level as soon as possible, with smallest possible business impact.
The problem management process is intended to reduce the number and severity of incidents and problems on the business, and report it in documentation to be available for the first-line and second line of the help desk. The proactive process identifies and resolves problems before incidents occur. These activities are:
• Trend analysis;
• Targeting support action;
• Providing information to the organization.
The Error Control Process is an iterative process to diagnose known errors until they are eliminated by the successful implementation of a change under the control of the Change Management process.
The Problem Control Process aims to handle problems in an efficient way. Problem control identifies the root cause of incidents and reports it to the service desk. Other activities are:
• Problem identification and recording;
• Problem classification;
• Problem investigation and diagnosis.
The standard technique for identifying the root cause of a problem is to use an Ishikawa diagram, also referred to as a cause-and-effect diagram, tree diagram, or fishbone diagram. A brainstorming session—in which group members offer product improvement ideas—typically results in an Ishikawa diagram. For problem-solving, the goal is to find causes and effects of the problem.
First there is the main subject, which is the backbone of the diagram that we are trying to solve or improve. The main subject is derived from a cause. The relationship between a cause and an effect is a double relation: an effect is a result of a cause, and the cause is the root of an effect. But there is just one effect for several causes and one cause for several effects.
Change Management
The goal of Change Management is to ensure that standardized methods and procedures are used for efficient handling of all changes,
Main article: Change Management (ITSM)
A change is “an event that results in a new status of one or more configuration items (CI's)” approved by management, cost effective, enhances business process changes (fixes) - with a minimum risk to IT infrastructure.
The main aims of Change Management are:
• Minimal disruption of services
• Reduction in back-out activities
• Economic utilization of resources involved in the change
Compliance with financial controls, audit and SOX standards
Sox Standards: IT plays a critical role in the operations of an organization. Indeed, it is difficult to imagine a successful organization existing in the 21st century without some level of reliance on IT systems. In today’s environment, financial reporting processes are driven by IT systems. Such systems are deeply embedded in initiating, authorizing, recording, processing and reporting of financial transactions. As such, they are inextricably linked to the overall financial reporting process and need to be assessed, along with other important processes, for compliance with the Sarbanes-Oxley Act.
There are three key building blocks required to ensure that IT controls exist and are formalized or structured in a way required by an organization?s management or its auditors, such that their design, assessment and remediation is totally integrated into the Sarbanes-Oxley compliance initiative. A SOX404 compliance application must support all of these three building blocks.
Building Block #1: Seamless integration of the three process-level controls - IT application controls, IT general controls and manual controls.
Since business processes and technology are deeply intertwined, there are three types of business process specific controls that exist within an enterprise:
* Process-level IT application controls: These are controls that are implemented within an ERP system. Examples in an order-to-cash process include a control that ensures that the orders should only be processed within a customer?s credit limits or a control that ensures that all goods shipped are invoiced
* Process-level general IT controls: These are controls that are implemented to ensure consistency and predictability of the ERP application that supports the business process. Examples in an order-to-cash process include a control that implements adequate security to prevent unauthorized access into the order management application or a control that ensures the version upgrade process for order management application is well defined and always followed.
* Process-level manual controls: These are process-level controls implemented manually outside the ERP system. Examples in an order-to-cash process include a control that ensures that the orders and cancellations are input correctly into the ERP application or a control that ensures users are well trained on the sales order policies.
Any compliance software must ensure that these three controls are seamless integrated within a single environment. As a result, the compliance software must provide mechanisms to seamlessly combine all of the three types of controls into a test suite to enable risk-based internal control assessment of a process or a sub-process.
Building Block #2: Automatic testing of process-level IT application controls and incorporation of its result into the overall results of the test suite.
In absence of any automation, most organizations end up manually testing hundreds of process-level IT application controls within their environment. For example, let?s take a control that ensures that the orders should only be processed within a customer?s credit limit. This control is typically implemented within an organization?s ERP system, but can be overridden for exceptions with proper authorization. Typically, most companies would print a report that lists out all orders that were processed within the last quarter, their credit limit at that time and if the override was applied, who applied the override and their role/title at the time the override was applied. Then the internal audit team would manually review each and every entry in the report and ensure that the control worked for every situation to score the control test as ?having passed?. If not, they would score the control test as ?having failed? and would have to manually record every instance the test failed, so that proper disclosures and remediation processes could be triggered.
Such a manual process would have to recur every specified period for the testing that control and is repeated for every control within the organization. With hundreds of controls within an organization, manual testing of process-level IT application controls provides a major opportunity for reduction of cost of compliance. In addition, the sheer complexity of manually testing such controls in a large organization with heterogeneous systems increases exponentially.
Next generation of SOX compliance solution enables companies to address this issue and significantly reduce their cost of compliance by providing a framework that performs all of the following activities
* Identifies if a control within the test documentation is a manual or application control. As a result, an application control does not need to be documented separately and eliminates the potential nightmare from co-relating application control documentation to test documentation.
* Automates the testing of application controls via the ?push of a button? by reading the relevant data within the ERP system and applying the testing logic
* Reports the results for the entire test ? including manual and application controls, in an integrated manner. It captures the detailed scoring from the audit (for manual controls) and specifics details of records read and which records passed and which records failed the test and why (for application controls) as a part of integrated reporting, so the results can be easily reviewed by an internal or external auditor in future to ?prove? that the testing occurred and control is working as required. The compliance solution typically leverages the APIs to access the data within the popular ERP systems such as SAP, Oracle and PeopleSoft, as well as legacy/homegrown systems. Such a solution typically provides an out-of-the-box library containing hundreds of tests for automating the testing of application level controls within general ledger, procure-to-pay, order-to-cash, inventory / cost Accounting, asset management and payroll processes.
Building Block #3: Ability to easily define and assess relevant overall IT controls ? typically derived from COBIT model - and reconcile them for the selected assessment framework such as COSO
Most organizations implement overall IT controls, which apply to all information systems, to ensure secure and continuous operation of their entire information systems in order to mitigate risks with financial reporting. Such controls are typically derived from COBIT control processes and when implemented, not only reduce IT related risks in financial reporting, but also form the basis for good IT Governance. These overall controls affect the following IT related processes:
* Acquire or develop application system software: Controls within IT organization provide reasonable assurance that infrastructure application and system software that is acquired or developed effectively supports financial reporting requirements. If the software is acquired, the process ensures that requirements are adequately defined and approved and software is evaluated against those requirements. If the software is developed or customized, kit ensures software development lifecycle is followed to ensure that the application will implement the requirements.
* Acquire technology infrastructure: Controls within IT organization provide reasonable assurance that technology infrastructure including servers, networks and databases that are acquired provide a secure and reliable information processing platform to support financial reporting applications.
* Develop and maintain policies and procedures: Controls within IT organization provide reasonable assurance that Policies and procedures include the SDLC methodology, the process for acquiring, developing and maintaining applications, as well as service level agreements, operational practices and training materials etc have been developed and are maintained, and that they define the documentation needed to support the proper use of the applications and the technological solutions for financial reporting.
* Install and test application software and technology infrastructure: Controls within IT organization provide reasonable assurance that the systems are appropriately tested and validated prior to being placed into production processes and associated controls operate as intended and support financial reporting requirements.
* Manage changes: Controls within IT organization provide reasonable assurance that system changes of financial reporting significance are authorized and appropriately tested before being moved to production.
* Service Levels: Controls within IT organization provide reasonable assurance that service levels are defined and managed in a manner that satisfies financial reporting system requirements and provides a common understanding of performance levels with which the quality of services will be measured. The controls must support Information Technology Infrastructure Library (ITIL) guidelines.
* Third Party: Controls within IT organization provide reasonable assurance that third-party services are secure, accurate and available, support processing integrity and defined appropriately in performance contracts.
* Access Control: Controls within IT organization provide reasonable assurance that a user ID in any of their enterprise systems that affect financial reporting matches to a specific person.
* Security: Controls within IT organization provide reasonable assurance that financial reporting systems and subsystems are appropriately secured to prevent unauthorized use, disclosure, modification, damage or loss of data. The controls must also be in compliance with ISO17799 specifications.
* Configuration Management: Controls within IT organization provide reasonable assurance that all IT components, as they relate to security, processing and availability, are well protected, would prevent any unauthorized changes, and assist in the verification and recording of the current configuration.
* Incident Management: Controls within IT organization provide reasonable assurance that any problems and/or incidents are properly responded to, recorded, resolved or investigated for proper resolution. The controls must support ITIL guidelines.
* Operations: Controls within IT organization provide reasonable assurance that authorized programs are executed as planned and deviations from scheduled processing are identified and investigated, including controls over job scheduling, processing, error monitoring and system availability.
The next generation of SOX compliance software should be able to define IT as a separate function with various processes listed above, define risk & control definition for IT sub-processes (controls as shown above) and drive the assessment and remediation process associated with these controls. By implementing this framework, an organization can also ensure compliance with COBIT/ISO17799/ITIL, while confirming to the COSO framework for assessment of general IT controls for financial reporting.
Summary
IT systems are inextricably linked to the overall financial reporting process and need to be assessed, along with other important processes, for compliance with the Sarbanes-Oxley Act. In this brief, we have identified three key building blocks to ensure that IT controls exist and are structured in a way required by an organization?s management or its auditors, such that their design, assessment and remediation is totally integrated into the Sarbanes-Oxley compliance initiative. A next generation SOX404 compliance application must support all of these three building block
How Sarbanes-Oxley Will Change the Audit Process
SARBANES-OXLEY WILL MEAN BIG CHANGES FOR BOTH auditors and the companies they audit. The former now will be required to certify a company’s internal controls and will no longer be able to use certain common audit strategies. Management faces the cost of implementing the new rules.
ACCORDING TO THE EXPOSURE DRAFT OF A NEW SAS , the understanding of internal controls required for CPAs to express an opinion on financial statements is not adequate for them to offer an opinion on the controls themselves. This means auditors will have to make changes to the audit process.
THE AUDITOR MUST ATTEST TO MANAGEMENT’S assessment of the effectiveness of an entity’s internal controls using standards the Public Company Accounting Oversight Board issues or adopts. The auditor will require management to identify, document and evaluate significant internal controls—management cannot delegate this function to the auditor.
AUDITORS SHOULD ADVISE COMPANIES TO BEGIN the process of assessing the effectiveness of controls as early as possible. The task will be time-consuming, requiring management to determine which locations or business units to include in its evaluation.
AUDITORS SHOULD NOT BE TOO CLOSELY INVOLVED with a company’s assessment of its controls or they risk impairing their objectivity. The auditor cannot accept management’s responsibility to reach conclusions on the effectiveness of the entity’s controls nor can management base its assertion about the controls design and operating effectiveness on the results of the auditor’s tests.
Incident Management
The goal of Incident Management is to restore normal service operation as quickly as possible and minimize the adverse effect on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. 'Normal service operation' is defined here as service operation within Service Level Agreement (SLA) limits.
Problem Management
The goal of 'Problem Management' is to resolve the root cause of incidents and thus to minimize the adverse impact of incidents and problems on business that are caused by errors within the IT infrastructure, and to prevent recurrence of incidents related to these errors. A `problem' is an unknown underlying cause of one or more incidents, and a `known error' is a problem that is successfully diagnosed and for which either a work-around or a permanent resolution has been identified. The CCTA defines problems and known errors as follows:
A problem is a condition often identified as a result of multiple Incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant.
A known error is a condition identified by successful diagnosis of the root cause of a problem, and the subsequent development of a Work-around.
Problem management is different from incident management. The principal purpose of problem management is to find and resolve the root cause of a problem and prevention of incidents; the purpose of incident management is to return the service to normal level as soon as possible, with smallest possible business impact.
The problem management process is intended to reduce the number and severity of incidents and problems on the business, and report it in documentation to be available for the first-line and second line of the help desk. The proactive process identifies and resolves problems before incidents occur. These activities are:
• Trend analysis;
• Targeting support action;
• Providing information to the organization.
The Error Control Process is an iterative process to diagnose known errors until they are eliminated by the successful implementation of a change under the control of the Change Management process.
The Problem Control Process aims to handle problems in an efficient way. Problem control identifies the root cause of incidents and reports it to the service desk. Other activities are:
• Problem identification and recording;
• Problem classification;
• Problem investigation and diagnosis.
The standard technique for identifying the root cause of a problem is to use an Ishikawa diagram, also referred to as a cause-and-effect diagram, tree diagram, or fishbone diagram. A brainstorming session—in which group members offer product improvement ideas—typically results in an Ishikawa diagram. For problem-solving, the goal is to find causes and effects of the problem.
First there is the main subject, which is the backbone of the diagram that we are trying to solve or improve. The main subject is derived from a cause. The relationship between a cause and an effect is a double relation: an effect is a result of a cause, and the cause is the root of an effect. But there is just one effect for several causes and one cause for several effects.
Change Management
The goal of Change Management is to ensure that standardized methods and procedures are used for efficient handling of all changes,
Main article: Change Management (ITSM)
A change is “an event that results in a new status of one or more configuration items (CI's)” approved by management, cost effective, enhances business process changes (fixes) - with a minimum risk to IT infrastructure.
The main aims of Change Management are:
• Minimal disruption of services
• Reduction in back-out activities
• Economic utilization of resources involved in the change
Compliance with financial controls, audit and SOX standards
Sox Standards: IT plays a critical role in the operations of an organization. Indeed, it is difficult to imagine a successful organization existing in the 21st century without some level of reliance on IT systems. In today’s environment, financial reporting processes are driven by IT systems. Such systems are deeply embedded in initiating, authorizing, recording, processing and reporting of financial transactions. As such, they are inextricably linked to the overall financial reporting process and need to be assessed, along with other important processes, for compliance with the Sarbanes-Oxley Act.
There are three key building blocks required to ensure that IT controls exist and are formalized or structured in a way required by an organization?s management or its auditors, such that their design, assessment and remediation is totally integrated into the Sarbanes-Oxley compliance initiative. A SOX404 compliance application must support all of these three building blocks.
Building Block #1: Seamless integration of the three process-level controls - IT application controls, IT general controls and manual controls.
Since business processes and technology are deeply intertwined, there are three types of business process specific controls that exist within an enterprise:
* Process-level IT application controls: These are controls that are implemented within an ERP system. Examples in an order-to-cash process include a control that ensures that the orders should only be processed within a customer?s credit limits or a control that ensures that all goods shipped are invoiced
* Process-level general IT controls: These are controls that are implemented to ensure consistency and predictability of the ERP application that supports the business process. Examples in an order-to-cash process include a control that implements adequate security to prevent unauthorized access into the order management application or a control that ensures the version upgrade process for order management application is well defined and always followed.
* Process-level manual controls: These are process-level controls implemented manually outside the ERP system. Examples in an order-to-cash process include a control that ensures that the orders and cancellations are input correctly into the ERP application or a control that ensures users are well trained on the sales order policies.
Any compliance software must ensure that these three controls are seamless integrated within a single environment. As a result, the compliance software must provide mechanisms to seamlessly combine all of the three types of controls into a test suite to enable risk-based internal control assessment of a process or a sub-process.
Building Block #2: Automatic testing of process-level IT application controls and incorporation of its result into the overall results of the test suite.
In absence of any automation, most organizations end up manually testing hundreds of process-level IT application controls within their environment. For example, let?s take a control that ensures that the orders should only be processed within a customer?s credit limit. This control is typically implemented within an organization?s ERP system, but can be overridden for exceptions with proper authorization. Typically, most companies would print a report that lists out all orders that were processed within the last quarter, their credit limit at that time and if the override was applied, who applied the override and their role/title at the time the override was applied. Then the internal audit team would manually review each and every entry in the report and ensure that the control worked for every situation to score the control test as ?having passed?. If not, they would score the control test as ?having failed? and would have to manually record every instance the test failed, so that proper disclosures and remediation processes could be triggered.
Such a manual process would have to recur every specified period for the testing that control and is repeated for every control within the organization. With hundreds of controls within an organization, manual testing of process-level IT application controls provides a major opportunity for reduction of cost of compliance. In addition, the sheer complexity of manually testing such controls in a large organization with heterogeneous systems increases exponentially.
Next generation of SOX compliance solution enables companies to address this issue and significantly reduce their cost of compliance by providing a framework that performs all of the following activities
* Identifies if a control within the test documentation is a manual or application control. As a result, an application control does not need to be documented separately and eliminates the potential nightmare from co-relating application control documentation to test documentation.
* Automates the testing of application controls via the ?push of a button? by reading the relevant data within the ERP system and applying the testing logic
* Reports the results for the entire test ? including manual and application controls, in an integrated manner. It captures the detailed scoring from the audit (for manual controls) and specifics details of records read and which records passed and which records failed the test and why (for application controls) as a part of integrated reporting, so the results can be easily reviewed by an internal or external auditor in future to ?prove? that the testing occurred and control is working as required. The compliance solution typically leverages the APIs to access the data within the popular ERP systems such as SAP, Oracle and PeopleSoft, as well as legacy/homegrown systems. Such a solution typically provides an out-of-the-box library containing hundreds of tests for automating the testing of application level controls within general ledger, procure-to-pay, order-to-cash, inventory / cost Accounting, asset management and payroll processes.
Building Block #3: Ability to easily define and assess relevant overall IT controls ? typically derived from COBIT model - and reconcile them for the selected assessment framework such as COSO
Most organizations implement overall IT controls, which apply to all information systems, to ensure secure and continuous operation of their entire information systems in order to mitigate risks with financial reporting. Such controls are typically derived from COBIT control processes and when implemented, not only reduce IT related risks in financial reporting, but also form the basis for good IT Governance. These overall controls affect the following IT related processes:
* Acquire or develop application system software: Controls within IT organization provide reasonable assurance that infrastructure application and system software that is acquired or developed effectively supports financial reporting requirements. If the software is acquired, the process ensures that requirements are adequately defined and approved and software is evaluated against those requirements. If the software is developed or customized, kit ensures software development lifecycle is followed to ensure that the application will implement the requirements.
* Acquire technology infrastructure: Controls within IT organization provide reasonable assurance that technology infrastructure including servers, networks and databases that are acquired provide a secure and reliable information processing platform to support financial reporting applications.
* Develop and maintain policies and procedures: Controls within IT organization provide reasonable assurance that Policies and procedures include the SDLC methodology, the process for acquiring, developing and maintaining applications, as well as service level agreements, operational practices and training materials etc have been developed and are maintained, and that they define the documentation needed to support the proper use of the applications and the technological solutions for financial reporting.
* Install and test application software and technology infrastructure: Controls within IT organization provide reasonable assurance that the systems are appropriately tested and validated prior to being placed into production processes and associated controls operate as intended and support financial reporting requirements.
* Manage changes: Controls within IT organization provide reasonable assurance that system changes of financial reporting significance are authorized and appropriately tested before being moved to production.
* Service Levels: Controls within IT organization provide reasonable assurance that service levels are defined and managed in a manner that satisfies financial reporting system requirements and provides a common understanding of performance levels with which the quality of services will be measured. The controls must support Information Technology Infrastructure Library (ITIL) guidelines.
* Third Party: Controls within IT organization provide reasonable assurance that third-party services are secure, accurate and available, support processing integrity and defined appropriately in performance contracts.
* Access Control: Controls within IT organization provide reasonable assurance that a user ID in any of their enterprise systems that affect financial reporting matches to a specific person.
* Security: Controls within IT organization provide reasonable assurance that financial reporting systems and subsystems are appropriately secured to prevent unauthorized use, disclosure, modification, damage or loss of data. The controls must also be in compliance with ISO17799 specifications.
* Configuration Management: Controls within IT organization provide reasonable assurance that all IT components, as they relate to security, processing and availability, are well protected, would prevent any unauthorized changes, and assist in the verification and recording of the current configuration.
* Incident Management: Controls within IT organization provide reasonable assurance that any problems and/or incidents are properly responded to, recorded, resolved or investigated for proper resolution. The controls must support ITIL guidelines.
* Operations: Controls within IT organization provide reasonable assurance that authorized programs are executed as planned and deviations from scheduled processing are identified and investigated, including controls over job scheduling, processing, error monitoring and system availability.
The next generation of SOX compliance software should be able to define IT as a separate function with various processes listed above, define risk & control definition for IT sub-processes (controls as shown above) and drive the assessment and remediation process associated with these controls. By implementing this framework, an organization can also ensure compliance with COBIT/ISO17799/ITIL, while confirming to the COSO framework for assessment of general IT controls for financial reporting.
Summary
IT systems are inextricably linked to the overall financial reporting process and need to be assessed, along with other important processes, for compliance with the Sarbanes-Oxley Act. In this brief, we have identified three key building blocks to ensure that IT controls exist and are structured in a way required by an organization?s management or its auditors, such that their design, assessment and remediation is totally integrated into the Sarbanes-Oxley compliance initiative. A next generation SOX404 compliance application must support all of these three building block
How Sarbanes-Oxley Will Change the Audit Process
SARBANES-OXLEY WILL MEAN BIG CHANGES FOR BOTH auditors and the companies they audit. The former now will be required to certify a company’s internal controls and will no longer be able to use certain common audit strategies. Management faces the cost of implementing the new rules.
ACCORDING TO THE EXPOSURE DRAFT OF A NEW SAS , the understanding of internal controls required for CPAs to express an opinion on financial statements is not adequate for them to offer an opinion on the controls themselves. This means auditors will have to make changes to the audit process.
THE AUDITOR MUST ATTEST TO MANAGEMENT’S assessment of the effectiveness of an entity’s internal controls using standards the Public Company Accounting Oversight Board issues or adopts. The auditor will require management to identify, document and evaluate significant internal controls—management cannot delegate this function to the auditor.
AUDITORS SHOULD ADVISE COMPANIES TO BEGIN the process of assessing the effectiveness of controls as early as possible. The task will be time-consuming, requiring management to determine which locations or business units to include in its evaluation.
AUDITORS SHOULD NOT BE TOO CLOSELY INVOLVED with a company’s assessment of its controls or they risk impairing their objectivity. The auditor cannot accept management’s responsibility to reach conclusions on the effectiveness of the entity’s controls nor can management base its assertion about the controls design and operating effectiveness on the results of the auditor’s tests.
Thursday, July 9, 2009
Importance of UI in application development
I've always thought of writing my views on the importance of design in the context of business strategy. Even though it is mostly underestimated and ignored feature, and always considered as a tactical issue, the design especially the UI that can make or break most of the core business strategies.
In the meantime, I've stumbled up on an interesting article, that has conveyed most of my thoughts. If you have time, please go through the article by Luke Wroblewski.
In the meantime, I've stumbled up on an interesting article, that has conveyed most of my thoughts. If you have time, please go through the article by Luke Wroblewski.
Friday, May 8, 2009
POP3 from Windows Live
What is POP3?
It is a protocol that allows almost any e-mail software program that you’ve installed on your mobile phone or PC* to get messages from your e-mail inbox on the web and deliver them in the designated program.
Although you always could access Hotmail on your web-enabled mobile phone by going to mobile.live.com, now that Hotmail has POP3, you can get to it more conveniently using the e-mail software on your PC or mobile device* such as a Windows Mobile phone, iPhone, or BlackBerry.
When you set up Hotmail in the e-mail program on your PC or mobile device, you may be asked for the following information:
POP server: pop3.live.com (Port 995)
POP SSL required? Yes
User name: Your Windows Live ID, for example yourname@hotmail.com
Password: The password you usually use to sign in to Hotmail or Windows Live
SMTP server: smtp.live.com (Port 25)
Authentication required? Yes (this matches your POP username and password)
TLS/SSL required? Yes
It is a protocol that allows almost any e-mail software program that you’ve installed on your mobile phone or PC* to get messages from your e-mail inbox on the web and deliver them in the designated program.
Although you always could access Hotmail on your web-enabled mobile phone by going to mobile.live.com, now that Hotmail has POP3, you can get to it more conveniently using the e-mail software on your PC or mobile device* such as a Windows Mobile phone, iPhone, or BlackBerry.
When you set up Hotmail in the e-mail program on your PC or mobile device, you may be asked for the following information:
POP server: pop3.live.com (Port 995)
POP SSL required? Yes
User name: Your Windows Live ID, for example yourname@hotmail.com
Password: The password you usually use to sign in to Hotmail or Windows Live
SMTP server: smtp.live.com (Port 25)
Authentication required? Yes (this matches your POP username and password)
TLS/SSL required? Yes
Setting up default browser
Go to the following >> start >> control panel >>> add and remove
programs >>> select "set program access and defaults" have the dot on custom
and click on it which should bring a drop down menu , place a dot on
internet explorer , click ok
programs >>> select "set program access and defaults" have the dot on custom
and click on it which should bring a drop down menu , place a dot on
internet explorer , click ok
Monday, April 20, 2009
Monday, April 6, 2009
workflow Patterns
Introduction
The Workflow Patterns Initiative was established with the aim of delineating the fundamental requirements that arise during business process modelling on a recurring basis and describe them in an imperative way. The first deliverable of this research project was a set of twenty patterns describing the control-flow perspective of workflow systems. Since their release, these patterns have been widely used by practitioners, vendors and academics alike in the selection, design and development of workflow systems [vdAtHKB03]. This body of work presents the first systematic review of the original twenty control-flow patterns and provides a formal description of each of them in the form of a Coloured Petri-Net (CPN) model. It also identifies twenty three new patterns relevant to the control-flow perspective. Detailed context conditions and evaluation criteria are presented for each pattern and their implementation is assessed in fourteen commercial offerings including workflow and case handling systems, business process modelling formalisms and business process execution languages.
Revisiting the Original Patterns
Here we present a revised description of the original twenty control-flow patterns previously presented in [vdAtHKB03]. Although this material is motivated by earlier research conducted as part of the Workflow Patterns Initiative, the descriptions for each of these patterns have been thoroughly revised and a new set of evaluations have been undertaken. In several cases, detailed review of a pattern has indicated that there are potentially several distinct ways in which the original pattern could be interpreted and implemented. In order to resolve these ambiguities, we have taken the decision to base the revised definition of the original pattern on the most restrictive interpretation of its operation and to delineate this from other possible interpretations that could be made. In several situations, a substantive case exists for consideration of these alterative operational scenarios and where this applies, these are presented in the form of new control-flow patterns.
New Control Flow Patterns
Review of the patterns associated with the control-flow perspective over the past few years has led to the recognition that there are a number of distinct modelling constructs that can be identified during process modelling that are not adequately captured by the original set of twenty patterns. Here we present twenty three new control-flow patterns that augment the existing range of patterns described above and elsewhere [vdABtHK00, vdAtHKB03]. In an attempt to describe the operational characteristics of each pattern more rigourously, we also present a formal model in Coloured Petri-Net (CPN) format for each of them. In fact the explicit modelling of the original patterns using CPN Tools helped identify a number of new patterns as well as delineating situations where some of the original patterns turned out to be collections of patterns.
Basic Control Flow Patterns
This class of pattern captures elementary aspects of process control and are similar to the definitions of these concepts initially proposed by the Workflow Management Coalition (WfMC) [Wor99].
1. Sequence
2. Parallel Split
3. Synchronization
4. Exclusive Choice
5. Simple Merge
Advanced Branching and Synchronization Patterns
Here we present a series of patterns which characterise more complex branching and merging concepts which arise in business processes. Although relatively commonplace in practice, these patterns are often not directly supported or even able to be represented in many commercial offerings. The original control-flow patterns identified four of these patterns: Multi-Choice, Synchronizing Merge, Multi-Merge and Discriminator.
In this revision, the Multi-Choice and Multi-Merge have been retained in their previous form albeit with a more formal description of their operational semantics. For the other patterns however, it has been recognized that there are a number of distinct alternatives to the manner in which they can operate. The original Synchronizing Merge now provides the basis for three patterns: the Structured Synchronizing Merge (WCP7), the Acyclic Synchronizing Merge (WCP37) and the General Synchronizing Merge (WCP38).
In a similar vein, the original Discriminator pattern is divided into six (6) distinct patterns: the Structured Discriminator (WCP9), the Blocking Discriminator (WCP28), the Cancelling Discriminator (WCP29), the Structured Partial Join (WCP30), the Blocking Partial Join (WCP31) and the Cancelling Partial Join (WCP32). One other addition has been the Generalized AND-Join (WCP33) which identifies a more flexible AND-join useful in concurrent processes.
Of these patterns, the original descriptions for the Synchronizing Merge and the Discriminator are superseded by their structured definitions.
6. Multi-Choice
7. Structured Synchronizing Merge
8. Multi-Merge
9. Structured Discriminator
28. Blocking Discriminator
29. Cancelling Discriminator
30. Structured Partial Join
31. Blocking Partial Join
32. Cancelling Partial Join
33. Generalised AND-Join
37. Local Synchronizing Merge
38. General Synchronizing Merge
41. Thread Merge
42. Thread Split
Multiple Instance Patterns
Multiple instance patterns describe situations where there are multiple threads of execution active in a process model which relate to the same activity (an hence share the same implementation definition). Multiple instances can arise in three situations:
- An activity is able to initiate multiple instances of itself when triggered (we denote this form of activity a multiple instance activity);
- A given activity is initiated multiple times as a consequence of it receiving several independent triggerings (e.g. as part of a loop or in a process instance in which there are several concurrent threads of execution as might result from a Multi-Merge for example; and
- Two or more activities in a process share the same implementation definition. This may be the same activity definition in the case of a multiple instance activity or a common sub-process definition in the case of a block activity. Two (or more) of these activities are triggered such that their executions overlap (either partially or wholly).
Although all of these situations potentially involve multiple concurrent instances of an activity or sub-process, it is the first of them in which we are most interested as they require the triggering and synchonization of multiple concurrent activity instances. This group of patterns focusses on the various ways in which these events can occur.
Similar to the differentiation introduced in the Advanced Branching and Synchronization Patterns to capture the distinction between the Discriminator and the Partial Join pattern variants, three new patterns have been introduced to recognize alternative operational semantics for multiple instances. These are the the Static Partial Join for Multiple Instances (WCP34), the Cancelling Static Partial Join for Multiple Instances (WCP35) and the Dynamic Partial Join for Multiple Instances (WCP36).
12. Multiple Instances without Synchronization
13. Multiple Instances with a Priori Design-Time Knowledge
14. Multiple Instances with a Priori Run-Time Knowledge
15. Multiple Instances without a Priori Run-Time Knowledge
34. Static Partial Join for Multiple Instances
35. Cancelling Partial Join for Multiple Instances
36. Dynamic Partial Join for Multiple Instances
State-based Patterns
State-based patterns reflect situations for which solutions are most easily accomplished in process languages that support the notion of state. In this context, we consider the state of a process instance to include the broad collection of data associated with current execution including the status of various activities as well as process-relevant working data such as activity and case data elements.
The original patterns include three patterns in which the current state is the main determinant in the course of action that will be taken from a control-flow perspective. These are: Deferred Choice (WCP16), where the decision about which branch to take is based on interaction with the operating environment, Interleaved Parallel Routing (WCP 17), where two or more sequences of activities are undertaken on an interleaved basis such that only one activity instance is executing at any given time and Milestone (WCP18), where the enabling of a given activity only occurs where the process is in a specific state.
In recognition of further state-based modelling scenarios, four new patterns have also been identified. These are: Critical Section (WCP39), which provides the ability to prevent concurrent execution of specific parts of a process, Interleaved Routing (WCP40), which denotes situations where a group of activities can be executed sequentially in any order, and Thread Merge (WCP41) and Thread Split (WCP42) which provide for coalescence and divergence of distinct threads of control along a single branch.
16. Deferred Choice
17. Interleaved Parallel Routing
18. Milestone
39. Critical Section
40. Interleaved Routing
Cancellation and Force Completion Patterns
Several of the patterns above (e.g. (WCP6) Structured Synchronizing Merge and (WCP9) Structured Discriminator) have variants that utlize the concept of activity cancellation where enabled or active activity instance are withdrawn. Various forms of exception handling in processes are also based on cancellation concepts. This section presents two cancellation patterns - Cancel Task (WCP19) and Cancel Case (WCP20).
Three new cancellation patterns have also been identified Cancel Region (WCP25), Cancel Multiple Instance Activity (WCP26) and Complete Multiple Instance Activity (WCP27).
19. Cancel Task
20. Cancel Case
25. Cancel Region
26. Cancel Multiple Instance Activity
27. Complete Multiple Instance Activity
Iteration Patterns
The following patterns deal with capturing repetitive behaviour in a workflow.
10. Arbitrary Cycles
21. Structured Loop
22. Recursion
Termination Patterns
The following patterns deal with the circumstances under which a workflow is considered to be completed.
11. Implicit Termination
43. Explicit Termination
Trigger Patterns
The following patterns deal with the external signals that may be required to start certain tasks.
23. Transient Trigger
24. Persistent Trigger
Disclaimer
We, the authors and the associated institutions, assume no legal liability or responsibility for the accuracy and completeness of any product-specific information contained in this body of work. All possible efforts have been make to ensure that the results presented are, to the best of our knowledge, up to date and correct.
Subscribe to:
Posts (Atom)