Agile IT Architecture: "Yesterday ILOG Inc announced his donation of his Rule Based Methodology to Eclipse Consortium. I need to provide some explanations on what this donation is about. The Agile Business Rules Development methodology (ABRD) is the industry’s first free, vendor-neutral methodology delivered as an Eclipse Process Framework (EPF)OpenUp plug-in. ABRD provides a step-by-step process for developing business applications using technologies such as Business Rule Management System, BPM, BPEL.
ABRD mitigates the risk associated with new business rules initiatives by providing a well documented and structured approach for developing rule-based applications. ABRD allows organizations to avoid using ad-hoc processes or having to expend significant time and effort creating their own best practices.
In case you never have a look at EPF, Eclipse Process Framework provides tools for software process engineering to develop methodology. It comes with content knowledge organized in library, and with a tool, EPF Composer, which enables process engineers and managers to implement, deploy, and maintain processes for organizations or individual projects based on the content of the library."
Mostrando postagens com marcador BR. Mostrar todas as postagens
Mostrando postagens com marcador BR. Mostrar todas as postagens
segunda-feira, abril 07, 2008
Agile IT Architecture
Agile IT Architecture: "Software Development Life Cycle for BR-BPEL application
The purpose of this article is to present an integrated software life cycle for development team who wants to leverage the capabilities offered by technologies such as BPM-BPEL and Business rules management system.
Each new business application development is triggered by a business needs to support or enhance and improve business efficiency. Even with an Agile approach, to trigger the project, architect, business users, project manager and project sponsor have to work together during the Inception phase, to define the business case, the requirements and justifications of the project. Once the project funded, the team may work on specification and requirement documents. I simplify a little here because in reality a lot more documents may be produced, but the goal here is to present how those requirements are supported in an Agile way using the BRMS and BPM products and not discussing about requirements management. So let state the specifications are our main entry point to detail the major work that needs to be done for developing the applications. The format of the specification can be user stories, or a more detailed description. (a good reference to write specifications and user case is Alistair Cockburn work ). Specifications are classically managed by a standard SDLC which includes design, build, test, and deploy of working code to the different staging platforms (development, test, or production).
The Agile approach enforces short iterations to deliver quick value to the business. The blue tasks in the diagram below represent a set of iterations that build the core of the business application."
The purpose of this article is to present an integrated software life cycle for development team who wants to leverage the capabilities offered by technologies such as BPM-BPEL and Business rules management system.
Each new business application development is triggered by a business needs to support or enhance and improve business efficiency. Even with an Agile approach, to trigger the project, architect, business users, project manager and project sponsor have to work together during the Inception phase, to define the business case, the requirements and justifications of the project. Once the project funded, the team may work on specification and requirement documents. I simplify a little here because in reality a lot more documents may be produced, but the goal here is to present how those requirements are supported in an Agile way using the BRMS and BPM products and not discussing about requirements management. So let state the specifications are our main entry point to detail the major work that needs to be done for developing the applications. The format of the specification can be user stories, or a more detailed description. (a good reference to write specifications and user case is Alistair Cockburn work ). Specifications are classically managed by a standard SDLC which includes design, build, test, and deploy of working code to the different staging platforms (development, test, or production).
The Agile approach enforces short iterations to deliver quick value to the business. The blue tasks in the diagram below represent a set of iterations that build the core of the business application."
Agile IT Architecture: A Cycle Approach for Business Rule Development
Agile IT Architecture: A Cycle Approach for Business Rule Development: "The Agile Business Rule Development methodology details all the different activities to develop a rule set, from rule discovery to rule set deployment and maintenance. We can group the set of activities into five groups. Those groups will be used to build an iterative approach to the development:
Rule Discovery
Rule Analysis
Rule Authoring
Rule Validation
Rule Deployment
The following diagram represents how the five groups of activities can be executed in a process flow using loops to implement short iterations. The rule set will grow following these cycles to get closer to the outcome expected by the business."
Rule Discovery
Rule Analysis
Rule Authoring
Rule Validation
Rule Deployment
The following diagram represents how the five groups of activities can be executed in a process flow using loops to implement short iterations. The rule set will grow following these cycles to get closer to the outcome expected by the business."
Defining Business Rules ~ What Are They Really? (Abstract and Table of Contents)
Defining Business Rules ~ What Are They Really? (Abstract and Table of Contents)
"Abstract
Systems analysts have long been able to describe enterprises in terms of the structure of the data those enterprises use and the organization of the functions they perform, but have tended to neglect the constraints under which the enterprise operates. Frequently these are not articulated until it is time to convert them into program code. While rules which are represented by the structure and functions of an enterprise have been documented to a degree, others have not been articulated as well, if at all.
The GUIDE Business Rules Project was organized in November 1993 to carry out that articulation. This paper, the original report of the GUIDE Business Rules Project (now the Business Rules Group), describes a scheme for understanding the nature of business rules and the categories into which they fall. It presents a formal approach for identifying and articulating the rules that define the structure and control the operation of an enterprise.
Table of Contents
The Table of Contents below is intended for readers who wish to load the document one chapter at a time. You may go to each chapter directly from the Table of Contents below or read the document sequentially, from one chapter to the next.
The document is also available as a PDF format document (approximately 175k).
Introduction
Project Scope and Objectives
Overview of the Paper
The Rationale
A Context for Business Rules
Definition of a Business Rule
Categories of Business Rule
Formalizing Business Rules
The Business Rules Conceptual Model
Formulating Business Rules
The Origins of Business Rules -- the Model
Types of Business Rule
Definitions
Structural Assertions
Terms and Facts
Kinds of Term
Kinds of Fact
Base Facts / Derived Facts
Attribute / Participation / Generalization
Definitions
Action Assertions
Action Assertion Classifications
Action Assertion Classes
Action Assertion Types
Controlling vs. Influencing
Definitions
Derivations
Kinds of Derivation
Definitions
Footnotes & Acknowledgments
Footnotes
Acknowledgments
Appendix A: The Complete Model
Appendix B: How to Read a Conceptual Model
Appendix C: An Extended List of Action Assertion Types
Appendix D: Case Study: EU-Rent Car Rentals
Appendix E: Glossary
Appendix F: Bibliography
Go to... Top of page First chapter BRG Home Page
Copyright ©2001, the Business Rules Group. All rights reserved.
"Abstract
Systems analysts have long been able to describe enterprises in terms of the structure of the data those enterprises use and the organization of the functions they perform, but have tended to neglect the constraints under which the enterprise operates. Frequently these are not articulated until it is time to convert them into program code. While rules which are represented by the structure and functions of an enterprise have been documented to a degree, others have not been articulated as well, if at all.
The GUIDE Business Rules Project was organized in November 1993 to carry out that articulation. This paper, the original report of the GUIDE Business Rules Project (now the Business Rules Group), describes a scheme for understanding the nature of business rules and the categories into which they fall. It presents a formal approach for identifying and articulating the rules that define the structure and control the operation of an enterprise.
Table of Contents
The Table of Contents below is intended for readers who wish to load the document one chapter at a time. You may go to each chapter directly from the Table of Contents below or read the document sequentially, from one chapter to the next.
The document is also available as a PDF format document (approximately 175k).
Introduction
Project Scope and Objectives
Overview of the Paper
The Rationale
A Context for Business Rules
Definition of a Business Rule
Categories of Business Rule
Formalizing Business Rules
The Business Rules Conceptual Model
Formulating Business Rules
The Origins of Business Rules -- the Model
Types of Business Rule
Definitions
Structural Assertions
Terms and Facts
Kinds of Term
Kinds of Fact
Base Facts / Derived Facts
Attribute / Participation / Generalization
Definitions
Action Assertions
Action Assertion Classifications
Action Assertion Classes
Action Assertion Types
Controlling vs. Influencing
Definitions
Derivations
Kinds of Derivation
Definitions
Footnotes & Acknowledgments
Footnotes
Acknowledgments
Appendix A: The Complete Model
Appendix B: How to Read a Conceptual Model
Appendix C: An Extended List of Action Assertion Types
Appendix D: Case Study: EU-Rent Car Rentals
Appendix E: Glossary
Appendix F: Bibliography
Go to... Top of page First chapter BRG Home Page
Copyright ©2001, the Business Rules Group. All rights reserved.
Assinar:
Postagens (Atom)