Uploaded image for project: 'Kuali Rice Roadmap'
  1. Kuali Rice Roadmap
  2. KRRM-36

Research into various open standard workflow process definition languages (such as BPEL, BPMN, YAWL, XPDL, etc.)

    Details

    • Type: Rice Research Item
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Component/s: KEW
    • Labels:
      None
    • Rice Theme:
      Industry Standards
    • Priority Score:
      6
    • Functional Justification :
      Hide
      KC's primary goal is functional equivalence with the Coeus system. KRRM-29 and KRRM-30 are necessary to meet this goal. Current Coeus schools will not upgrade to KC without these items. While these are critical for our project success, they also create effective solutions for required and desired functionality across Kuali projects. This information is posted to both KRRM-29 and KRRM-30; the ability to modify workflow and manage business rules are tightly linked.

      Schools will use this functionality to:
      • Create and maintain business rules/validations/routing maps that descend the unit hierarchy from the top down for central administration requirements: rules/validations/maps set up at the top of the hierarchy can be applied to lower units
      • Create and maintain business rules/validations/routing maps that add a further layer of requirements at the college or department level for further detail (can descend the hierarchy from the college/department down, or not): each college/department may have additional requirements that are not the same as those of central administration or other units on campus.

      The functionality in Coeus allows a savvy functional user to maintain workflow and business rules without needing to modify code. In research administration, flexible workflow, routing, and business rules are critical business needs, and these needs also exist in other campus functional areas (Financial, Student, HR, etc). Ongoing maintenance of these items is the key to this flexible functionality, as they will change regularly, for a number of reasons. Examples are listed below:

      • Personnel changes: Aside from changes to users/rights/roles, personnel changes at the department and/or college level can mean an entirely new series of routing requirements and business rules (examples: change in department head, dean, or business officer)
      • Institutional Policy changes: An audit (internal or external) can mean that changes to validations, notifications, and routing need to be made quickly - often to respond to the auditor in a matter of hours. These and other internal institutional changes impact both financial and non-financial systems/activities
      • External Policy Changes: Changing federal requirements for Grants.gov or new funding opportunities often require quick changes to validations to ensure the system can handle the proposal submissions. Changing state or federal requirements related to financial activity or recruitment/hiring may result in a need to quickly change business rules and routing.
      Show
      KC's primary goal is functional equivalence with the Coeus system. KRRM-29 and KRRM-30 are necessary to meet this goal. Current Coeus schools will not upgrade to KC without these items. While these are critical for our project success, they also create effective solutions for required and desired functionality across Kuali projects. This information is posted to both KRRM-29 and KRRM-30 ; the ability to modify workflow and manage business rules are tightly linked. Schools will use this functionality to: • Create and maintain business rules/validations/routing maps that descend the unit hierarchy from the top down for central administration requirements: rules/validations/maps set up at the top of the hierarchy can be applied to lower units • Create and maintain business rules/validations/routing maps that add a further layer of requirements at the college or department level for further detail (can descend the hierarchy from the college/department down, or not): each college/department may have additional requirements that are not the same as those of central administration or other units on campus. The functionality in Coeus allows a savvy functional user to maintain workflow and business rules without needing to modify code. In research administration, flexible workflow, routing, and business rules are critical business needs, and these needs also exist in other campus functional areas (Financial, Student, HR, etc). Ongoing maintenance of these items is the key to this flexible functionality, as they will change regularly, for a number of reasons. Examples are listed below: • Personnel changes: Aside from changes to users/rights/roles, personnel changes at the department and/or college level can mean an entirely new series of routing requirements and business rules (examples: change in department head, dean, or business officer) • Institutional Policy changes: An audit (internal or external) can mean that changes to validations, notifications, and routing need to be made quickly - often to respond to the auditor in a matter of hours. These and other internal institutional changes impact both financial and non-financial systems/activities • External Policy Changes: Changing federal requirements for Grants.gov or new funding opportunities often require quick changes to validations to ensure the system can handle the proposal submissions. Changing state or federal requirements related to financial activity or recruitment/hiring may result in a need to quickly change business rules and routing.
    • Technical Justification:
      Hide
      We've got our own proprietary way to define workflows and it doesn't adhere to the standards for defining workflows that are out there. By using industry standards, implementations as well as on-boarding of new developers to a project should be easier.
      Show
      We've got our own proprietary way to define workflows and it doesn't adhere to the standards for defining workflows that are out there. By using industry standards, implementations as well as on-boarding of new developers to a project should be easier.
    • Impact if not Implemented:
      Future implementers that have familiarity with these standards and tools that use these standards will have to learn a whole new set of things. It will give Kuali the perception of not adhering to standards and not being flexible.
    • Priority - KFS:
      Medium
    • Priority - KC:
      Medium
    • Priority - KS:
      No Priority
    • Priority - Rice:
      Medium
    • Theme:
      Adopting Existing Code
    • Application Impact:
      High
    • Effort Estimate:
      Medium ~ 500 hrs

      Description

      Research various BPEL or BPM products and/or standards to support integrating with KEW. This may provide us with a path to get a KEW WYSIWYG graphical design capability which is another issue on our Roadmap. We've got our own proprietary way to define workflows and it doesn't adhere to the standards for defining workflows that are out there.

        Attachments

          Issue Links

            Activity

            Hide
            cfairlie Cath Fairlie (Inactive) added a comment -

            KS - Don't see that BEPL and KEW are in the same space. Don't see what this buys us.

            Show
            cfairlie Cath Fairlie (Inactive) added a comment - KS - Don't see that BEPL and KEW are in the same space. Don't see what this buys us.
            Hide
            ewestfal Eric Westfall added a comment -

            I agree with the statement about BPEL, but I think having a graphical tool for workflow design will be important for many implementers (as most workflow systems out there have such a thing) although that's a separate issue. This one's probably more of a research item to determine if we want to continue with our current proprietary process definition language or look to try and move to one of the standards that is out there. I think there's a decision that needs to be made here.

            Show
            ewestfal Eric Westfall added a comment - I agree with the statement about BPEL, but I think having a graphical tool for workflow design will be important for many implementers (as most workflow systems out there have such a thing) although that's a separate issue. This one's probably more of a research item to determine if we want to continue with our current proprietary process definition language or look to try and move to one of the standards that is out there. I think there's a decision that needs to be made here.
            Hide
            lschultz Lori Schultz (Inactive) added a comment -

            KRRM-29 is important for KC in getting us to functional equivalence with Coeus, our source system. I ranked this research item as medium, but it should not supplant our ranking for KRRM-29 (Critical). KC developers may be able to assist with this item.

            Show
            lschultz Lori Schultz (Inactive) added a comment - KRRM-29 is important for KC in getting us to functional equivalence with Coeus, our source system. I ranked this research item as medium, but it should not supplant our ranking for KRRM-29 (Critical). KC developers may be able to assist with this item.
            Hide
            ewestfal Eric Westfall added a comment -

            Worst case scenario, application impact could be high here, depending on whether or not the existing process definition continues to be supported or not.

            Show
            ewestfal Eric Westfall added a comment - Worst case scenario, application impact could be high here, depending on whether or not the existing process definition continues to be supported or not.
            Hide
            Anonymous added a comment -

            Two items to look at regarding GUI interfaces related to workflow:
            Activiti Engine/Workflow GUI: Under the Apache 2 License; developed by Spring/Alfresco and includes a nice GUI tool. (www.activiti.org)
            XO Framework: GUI development tool out of UCSD, works with edoclite (www.xoframework.org)

            Show
            Anonymous added a comment - Two items to look at regarding GUI interfaces related to workflow: Activiti Engine/Workflow GUI: Under the Apache 2 License; developed by Spring/Alfresco and includes a nice GUI tool. (www.activiti.org) XO Framework: GUI development tool out of UCSD, works with edoclite (www.xoframework.org)
            Hide
            ewestfal Eric Westfall added a comment -

            It's important to nail down the scope of what this roadmap item represents. Based on what i'm reading in the comments, here's my synopsis:

            1) First of all, this roadmap item is a research item. This means it will probably primarily include research and recommendations into how to proceed (and optionally, some amount of prototyping).
            2) I'm assuming at the heart of this roadmap item is the ability for us to declare workflow processes using some of the more standardized workflow languages that are available (i.e. BPEL and BPMN)
            3) I'm assuming that this jira is not about researching a graphical tool for workflow process authoring. I think that aligns more with KRRM-51.
            4) So essentially, this roadmap item would result into research into various open standard workflow process definition languages and if we feel any of them are a good fit to augment KEW with by implementing support for that language. Not that support for graphical tools for a particular language may be a deciding factor.

            Are my expectations of deliverables from this roadmap item in line with others who have weighed in on this issue?

            Final question: Should we looking at deprecating our current process definition language (the one supported by KEW "Document Types" presently)

            Show
            ewestfal Eric Westfall added a comment - It's important to nail down the scope of what this roadmap item represents. Based on what i'm reading in the comments, here's my synopsis: 1) First of all, this roadmap item is a research item. This means it will probably primarily include research and recommendations into how to proceed (and optionally, some amount of prototyping). 2) I'm assuming at the heart of this roadmap item is the ability for us to declare workflow processes using some of the more standardized workflow languages that are available (i.e. BPEL and BPMN) 3) I'm assuming that this jira is not about researching a graphical tool for workflow process authoring. I think that aligns more with KRRM-51 . 4) So essentially, this roadmap item would result into research into various open standard workflow process definition languages and if we feel any of them are a good fit to augment KEW with by implementing support for that language. Not that support for graphical tools for a particular language may be a deciding factor. Are my expectations of deliverables from this roadmap item in line with others who have weighed in on this issue? Final question: Should we looking at deprecating our current process definition language (the one supported by KEW "Document Types" presently)
            Hide
            sagee Sandra Agee (Inactive) added a comment - - edited

            The Business is interested in determining which route to take to ease integration with KEW. Believe there are benefits that using an open standard language like BPEL/BPMN will negate the need to develop custom GUI tools and allow Rice to leverage graphical modeling tools from the open source or commercial market.

            Business features:

            Align with charter by coming closer to open standards

            Increase number of available server components which can easily integrate with RICE/KEW such as BPEL extensions.

            Make available a wide range of GUI tools to do process modeling.

            High level Scope

            This is a research into various open standard workflow process definition languages and if we feel any of them are a good fit to augment KEW with by implementing support for that language. It does not mean that support for graphical tools for a particular language may be a deciding factor

            Research the value in deprecating our current process definition language (the one supported by KEW "Document Types" presently)

            Show
            sagee Sandra Agee (Inactive) added a comment - - edited The Business is interested in determining which route to take to ease integration with KEW. Believe there are benefits that using an open standard language like BPEL/BPMN will negate the need to develop custom GUI tools and allow Rice to leverage graphical modeling tools from the open source or commercial market. Business features: Align with charter by coming closer to open standards Increase number of available server components which can easily integrate with RICE/KEW such as BPEL extensions. Make available a wide range of GUI tools to do process modeling. High level Scope This is a research into various open standard workflow process definition languages and if we feel any of them are a good fit to augment KEW with by implementing support for that language. It does not mean that support for graphical tools for a particular language may be a deciding factor Research the value in deprecating our current process definition language (the one supported by KEW "Document Types" presently)
            Hide
            ewestfal Eric Westfall added a comment -

            Changing the title to better reflect the purpose of this jira.

            Show
            ewestfal Eric Westfall added a comment - Changing the title to better reflect the purpose of this jira.
            Hide
            ewestfal Eric Westfall added a comment -

            Reducing estimate from 1000 to 500 hrs since this is primarily a research item. However, there is an awful lot to research and my hope is that this would result in some amount of prototyping so I'm still leaving the estimate at medium to account for that work.

            Show
            ewestfal Eric Westfall added a comment - Reducing estimate from 1000 to 500 hrs since this is primarily a research item. However, there is an awful lot to research and my hope is that this would result in some amount of prototyping so I'm still leaving the estimate at medium to account for that work.

              People

              • Assignee:
                ewestfal Eric Westfall
                Reporter:
                byock Bill Yock (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: