I am back from the Business Rules Forum, last week in Orlando. I have a lot of material to make use of, so I thought I would start with giving an overview of the major points themes of the conference:
- Business Rules has its origins in Expert Systems as well as Data Modeling.
- Business Rules and Business Processes are becoming more integrated than ever. BR approaches can be used to manage the ‘decision diamonds’, and simplify the maps themselves.
- Most common questions: who should document Business Rules? Is it Business Analysts? What is a Business Analyst?... I met a few people who are founding the Jacksonville FL chapter of the IIBA, and mentioned the existence of the IIBA in a few sessions.
- Some participants were evangelists who see Business Rules as the center of business and systems; others see Business Rules as apart but integrated with all the other ‘artifacts’ of business requirements, especially as organized by the Zachman Framework.
- The Zachman Framework was itself a common subject across many presentations, capped by a closing presentation by John Zachman himself. While his framework is methodology and artifact independent, he does however see Business Rules as a valuable addition to the Business Model of Row 2 of the Framework, mainly in the Motivation Column.
To see the overall agenda for the forum, you can visit http://www.businessrulesforum.com/
Saturday, November 19, 2005
Wednesday, November 16, 2005
Requirements and Architecture
Are my Information System Deliverables equal to artifacts that that can be organized by the Zachman Framework?
Yes and No. For those of you unfamiliar with the Zachman Framework, visit its website… http://www.zachmanframework.com/
Let’s see what columns I have covered with my deliverables:
Data Model is “what”.
Business Process Model is “how”.
Use Cases may also be “how”, and also partially “who”.
Events of the Business Process Model are “when”.
Business Rules are “why”.
That leaves “where”, which may need to be stated explicitly when multiple business locations are involved; this may require a requirements deliverable for an information systems network.
From a Zachman perspective, my deliverables may be seen as weak in the “when” and “who” columns. I am usually comfortable with these areas as they are, as “when” and especially “who” are often found more in systems design then system requirements. Overall, if you have read my earlier posts, you will notice that the words “what” and “how” have a different meaning from Zachman when describing Information System Requirements (what), versus Information Systems Design (how).
You can also see that some of my deliverables would be considered as row 2 artifacts, while others are row 3. If you feel the need to provide artifacts for both rows, so much the better; if not, I think my deliverables, plus a location/network deliverable, will usually suffice for defining a complete set of Information System Requirements.
Now, I do say this in the context of being a Business Analyst responsible for defining Information Systems Requirements, without expecting there to be an overall Architecture in place. If you are lucky enough to be working in an environment that does provide an overall Architecture, I humbly submit my favourite deliverables as candidates for use as architectural artifacts.
Yes and No. For those of you unfamiliar with the Zachman Framework, visit its website… http://www.zachmanframework.com/
Let’s see what columns I have covered with my deliverables:
Data Model is “what”.
Business Process Model is “how”.
Use Cases may also be “how”, and also partially “who”.
Events of the Business Process Model are “when”.
Business Rules are “why”.
That leaves “where”, which may need to be stated explicitly when multiple business locations are involved; this may require a requirements deliverable for an information systems network.
From a Zachman perspective, my deliverables may be seen as weak in the “when” and “who” columns. I am usually comfortable with these areas as they are, as “when” and especially “who” are often found more in systems design then system requirements. Overall, if you have read my earlier posts, you will notice that the words “what” and “how” have a different meaning from Zachman when describing Information System Requirements (what), versus Information Systems Design (how).
You can also see that some of my deliverables would be considered as row 2 artifacts, while others are row 3. If you feel the need to provide artifacts for both rows, so much the better; if not, I think my deliverables, plus a location/network deliverable, will usually suffice for defining a complete set of Information System Requirements.
Now, I do say this in the context of being a Business Analyst responsible for defining Information Systems Requirements, without expecting there to be an overall Architecture in place. If you are lucky enough to be working in an environment that does provide an overall Architecture, I humbly submit my favourite deliverables as candidates for use as architectural artifacts.
Subscribe to:
Posts (Atom)