Category: DM

decision management

Gartner BPM: Business Rules Management State of the Art, Marc Kerremans

Marc Kerremans’ presentation on business rules management started out looking at where rules exist in an organization, and how they are used. In many cases, rules are still embedded within applications — such that changing a rule requires changing the underlying code — or are implemented in a manual and sometimes ad hoc manner. Gartner defines business rules as “implicit and explicit business policies that define and describe a business action”, where implicit rules are those embedded within applications.

He discussed how rules can differ greatly within a single organization based on factors such as geography and the associated local regulations, and how a business rules management system — which manages rules explicitly and externally from business applications — can add value in managing all of the complex rules across an organization.

He also looked at who owns and manages business rules:

  • Line of business managers determine the most volatile rules that may need to be changed to meet business agility needs, define the rules required, and author/change less complex business rules.
  • Systems architects author more complex rules, and test rules to assure that the system is performing as required.
  • Business analysts discover and author new rules based on their analysis of the business health, and create and simulate rule scenarios.

Since 2004, BRE and BPM have evolved from distinct and separate markets to an integration of BRE in many BPMS, to the current state of business rules management systems (BRMS) that go beyond simple business rules engine functionality. Typically, a BRMS contains:

  • Rule execution engine, including execution, sequencing and chaining of rules, and event-based execution.
  • Rule repository, where rules are stored for access by design tools and at run time. This includes security and version control to prevent unauthorized changes to the rule definitions.
  • Rule modeling and simulation, for what-if analysis. This will show effects such as dependencies between rules, and performance tracking.
  • Monitoring and analysis of historical and real-time rule usage, including reporting and audit trails.
  • Rule management and administration, working in concert with the repository, to manage security, promotion between development, test and production environments, and track changes and performance.
  • Rule templates to provide a quick start for specific vertical industry rule sets, and horizontal rules sets such as compliance.
  • Rule integrated development environment, which provides a graphical, model-driven environment for authoring, testing and debugging rules. This may include wizards for easy creation of rules by business managers/analysts, and collaboration tools.

As with BPMS, not all vendors will cover all of the full range of functionality equally well. There are some open source BREs that provide only the engine functionality, such as JBOSS and NxBRE. Most of the commercial vendors, such as Corticon, Fair Isaac and ILOG, are either migrating to the full BRMS functionality or are already there. There’s also an overlap of BPMS that provide BRE functionality: Pegasystems is the most commonly-cited player here since their BPMS is actually built on a rules platform, but other BPMS vendors provide rules that can be separated from the processes to at least allow reuse across multiple processes, although not across non-BPMS applications.

Agility is the primary reason that organizations look to BRM, which can manifest as awareness (accessing and presenting the right information through rules-based event monitoring), flexibility (rule modeling and simulation to handle expected change), adaptability (rapid rule modification to handle unexpected change) and productivity (executing the right policies and procedures).

There are other reasons for implementing BRM besides agility, of course: improving the quality and consistency of business decisions, improving revenue opportunities by fine-tuning pricing rules on the fly, improving customer satisfaction through greater customization, and better regulatory compliance and governance through the use of audited rules and increased visibility into how decisions are made.

Kerremans went through a number of best practices for getting started with BRM, such as analyzing rule volatility, and establishing a process for making changes to rules. As much as possible, try to work with natural language representations of rules so that business managers are comfortable with the authoring environment, although some level of structure to the language (“rules speak”) will be necessary.

He also discussed the different types of rules technology, including inference-based and event-based rules engines, before finishing up with some recommendations on developing a business rules management strategy. As with BPMS, many larger organizations will end up with multiple BRE tools to cover their entire strategy, so don’t assume that you’ll be working with only a single vendor in this space.

For you business rules aficionados, note that I’ve change the business rules category on this blog to DM, instead of BRE.

IIR BPM: Michael zur Muehlen on integrating business processes and business rules

I finished the day listening to Michael zur Muehlen discuss business processes and rules, a topic that I spoke about a few weeks ago at the Business Rules Forum. Michael, who I know from the BPM Think Tanks, is responsible for BPM courses at Stevens Institute of Technology. You can see his presentation slides online here.

He started out with the bottom line on why you want to integrate process and rules:

  • Simpler processes
  • Higher agility
  • Better risk management

Who wouldn’t want this? However, he points out that users don’t like processes, since they find them abstract (or possibly requiring a more analytic view of the organization) and restrictive (that is, not able to capture all the actual business cases). He also points out the obvious problem with Eclipse-based process modelling tools: they’re not friendly to business types. Became of that, we end up with technical people maintaining business processes, which usually results in a lot of code and the next generation of legacy systems.

He went though an example of an insurance company with 12 process steps and 5000 business rules, and it became obvious why rules change faster than processes. He highlighted three places where rules and processes come together: control flow, work assignment, and cross-process policy enforcement. I still think that the key issue is the boundary: when is something done as a decision tree in a rules system, and when it is done as control flow directly in the BPMS. Michael suggests that you might want to first model the rules in the BPMS, then extract the rules, although I don’t think that the rules experts would consider that a best practice. The challenge, then, comes with the modelling that’s done by the business analysts: how much do they need to know about rules, and what does their modelling environment need to look like in order to support that?

He had some good suggestions about mining rule criteria from previously executed processes, determining what the automated rules should be based on prior manual processes. From an insurance standpoint, this can result in auto-underwriting on standard cases.

He talked about the links between process management, business rules and compliance: whereas BPMS can enforce process compliance, rules are used to enforce contextual compliance for all the things around the business processes that aren’t really part of process compliance.

Michael and a colleague did a fascinating study of which BPMN symbols are actually used, and found that there’s 6 or 7 symbols that are used in most of the diagrams — the rest are strictly long-tail usage. See page 39 of the slide deck that I link to above for the chart.

He had some practical advice on how business rules and business processes interact:

  • Business objectives (rules) govern and prioritize business activities (processes)
  • Process objectives (rules) govern and define core processes (processes)
  • Process objectives break down to business rules and core processes break down to business processes, where business rules govern the business processes, and bsiness processes use the business rules.
  • This can be taken to a further level of granularity with operational rules.

He also had a chart for classifying change, and showing where it made more sense to use business rules or business process for a particular decision/activity; for example, use rules if it’s rapidly changing, company-wide and less predictable.

My flight home leaves tomorrow mid-day, so this is likely the end of my IIR/Shared Insights BPM conference coverage. Next year, maybe they’ll spring for more than 2 nights of hotel…

Policies, procedures, processes and rules

Most of my customers are large financial institutions, and I help them to select and implement BPM within their organizations. The technology is only one part of that, however: I’m almost always helping them with their business processes as well. Since policies and procedures drive processes, I often end up in the thick of their policies and procedures, and that’s where the confusion starts.

First of all, there’s the definition of terms. What’s the difference between a policy and a procedure, when many people lump them together as if PoliciesAndProcedures were one word? I like this definition:

Policy is a mandate and directive from the top of the organization. Its purpose is to influence behaviour. From it, management provide the overarching principles under which the business operates. It should not vary in its message or enforcement model.

Procedures are process specific and detail the steps taken to achieve an objective. Procedures include operations manual, user manual, and all manner of process documentation.

I see policies as the rules, or laws, of an organization, whereas the procedures are the processes used to enact the policies. The problem is, however, that many companies see policies and procedures as belonging to the Legal/Compliance department, and create another set of processes — usually referred to as an "operational guide" — that are created and maintained by the operational area that executes the actual processes. If you throw in a BPMS, then some (but rarely all) of these operational procedures may be further documented in the process descriptions within the BPMS or a BPA tool.

What’s the distinction between a policy and a procedure? Is there a difference between a procedure and the operational description of a business process? What about between the business process and the process model in a BPMS?

Secondly, there’s the responsibility issue that I referred to above: who’s responsible for each of these essential bits of corporate documentation? Legal/Compliance is almost always handed policies and procedures, but what about the case when the procedures are actually descriptions the operational business processes? Should policies be left with Legal, and procedures given to the operational areas, with Compliance there to make sure that everything matches up? Or are the operational process descriptions a separate, more fine-grained version of the procedures, leaving the procedures with Legal and the operational processes with Operations?

If process maps are created within a BPMS, do they become part of the business process documentation, replace part of it, or stay as a separate "implementation view" of the processes? I’ve definitely seen cases where the process maps in a BPMS bear little resemblance to what the business perceives as its processes, either due to limitations in the BPMS environment or to the business having an incomplete view of the process.

And if there’s four separate types of documentation — policies, procedures, business processes and BPMS process definitions — who’s responsible for keeping them all in synch?

Third is the whole technology issue: how is all of this information captured, published and synchronized? There are a tools such as RulesArts and RuleBurst (both of which I saw last week at the Business Rules Forum) that help to capture policies as high-level non-executable rules — an approach that makes more sense than just trying to document them free-form in a word processor while praying for consistency. Check out the Flash demo on the RuleBurst site to see what this can look like. Some of this systems are also business rules engines, that is, they execute the rules and can be called from other applications; some are just platforms for non-technical users to document policies, detect gaps and exceptions, and help to ensure compliance.

As we move into procedures, operational guides and process definitions, it’s all about processes. Processes based on rules (and what process isn’t?), but processes nonetheless. Those organizations documenting their policies in a word processor are likely also documenting their procedures in the same way — in fact, possibly in the same document — using descriptive text and a few diagrams. At some level of detail, someone starts drawing process maps, although these are usually as illustrations to the descriptive text rather than a replacement for it.

The two biggest issues in all of this technology are synchronization (usually manual, and therefore almost certainly out of date) and publishing (ditto). From the synchronization standpoint, there needs to be something that links the policies (rules) with the various granularities of process descriptions (both text and graphical) and either keeps them in synch or alerts someone when related pieces are modified. For publication, none of this information is of any use unless it’s in the hands of the people who need it; that means that there needs to be an easy (or automated) way for all of this information to be published within an enterprise and accessed with nothing more than a browser and network authentication.

What starts to become shockingly apparent as you dig into the technology is that policies are about rules, and procedures are about processes. Yeah, I know, I said that at the start of this post, but it’s not just some abstract concept, it’s about how you need to document and implement policies and procedures. The crux of the issue is in the crossover from rules to process, since a rule (policy) usually doesn’t dictate the operational procedure required to enact it, hence there’s not a clear technology path to map from policies to procedures. If policies are maintained in a high-level rule repository and procedures are maintained in some combination of descriptive text and process maps, what’s the missing link between them?

Policy and procedure documentation is just one place where business rules and business processes intersect (they touch again at the point of process execution), and I’m interested in exploring the ideas around this. I’ve put forward more questions than answers — feel free to join the conversation by commenting on this post, tracking back from your own post, or dropping me an email.

Webinar on Enterprise Decision Management tomorrow

After attending the Business Rules Forum last week, either I’m more aware of related events or I’m on more mailing lists for rules/decisioning vendors. In either case, Fair Isaac is putting on an Introduction to Enterprise Decision Management webinar tomorrow at 2pm Eastern. From their description of the event:

Learn how your organization can automate and improve decisions by:

  • Taking control of your decisions and make them a corporate asset
  • Separating operational decisions from processes and systems for maximum agility
  • Using business rules management systems to ensure decision consistency and speed
  • Applying different kinds of analytics – descriptive, predictive and decision – to make more precise and profitable decisions

It’s free, just sign up online.

Smart Enough Systems

I’m sure that James Taylor has almost given up on me ever writing a book review of Smart Enough Systems: I wrote a brief advance review back in April that’s printed in the book, but nothing since it was released. This week, I’ve been immersed in business rules and decisioning, and had a chance to finally meet James face-to-face after a couple of years of emailing back and forth. Also, James’ situation has changed since the book was released: he’s left Fair Isaac and is now an independent, working (I think) with his co-author, Neil Raden. Neil, who I met very briefly this week, is an independent consultant and analyst who’s been focussed on business intelligence for quite a while; James refers to his work as “BI 2.0” (a term that I think that I invented here in early 2006). The two of them met through James’ blog and started the conversation about how someone needed to write a book about this crossover area between business rules and business intelligence.

Just to get started, here’s my pre-release review:

Taylor and Raden’s central manifesto highlights that it’s critical to embody more intelligence in today’s business decision-making and have consistent, automated decisioning built into business processes in order to remain agile and competitive in today’s fast-moving market. They take you through the core concepts of enterprise decision management (EDM), dive into the underlying technologies, then address how to integrate EDM into your business processes to create your own Smart (Enough) Systems.

By focusing on operational decisions that contribute to corporate strategy, Smart (Enough) Systems provide the ability not only to create agile business processes, but to have these processes be self-learning based on historical results. Instead of simply capturing operational process statistics in a data warehouse for later analysis, Smart (Enough) Systems use that knowledge to inform the business rules and allow them to adapt their guidance of the decision-making process. By extracting the decisions from legacy applications, static enterprise applications and manual procedures, and managing them within a shared enterprise decision management system, operational decisions can be applied consistently — and modified easily for processes in flight — across the enterprise.

What I like about the book is that it provides an overview that will get business people interested in the topic, as well as providing a practical guide to getting started. There’s a lot of books focussed on analytics and business rules already, but most of them assume that you already know what you’re going to do with these technologies; in many cases, it’s hard to discover the right decisions on which to focus, since some things are more important than you may have originally perceived when starting a project.

As I heard this week, there’s still a strong tendency to sell rules technology to IT as a way to implement systems fast and cheaper, instead of selling decisioning to the business as a way to solve business problems. For the most part, decisions in business processes are unconsciously relegated either to a developer coding them into an application, or to a front-line worker executing them on an ad hoc basis. Decisions, and the rules that underlie them, need to be made explicit: therein lies the path to both compliance and agility. I joked yesterday about Jan Venthienen’s presentation that he’d like to reduce all processes to a single activity and have all business logic in a rule set, but there’s definitely value in what he’s saying: we need to seek out the decisions in processes, capture the ever-changing business rules that are embedded within them, and move these out of the processes and into rules/decisioning systems. The reality is that process maps don’t change all that often if the decisions and business rules are stripped out of the processes: most business agility is based on rule changes, not process changes, especially for high-volume core transactional processes. However, since we often code rules directly into the business processes — making these processes some combination of processes and decision trees — we perceive the need to be that of changing processes rather than changing rules. And so (and I’ll be totally blackballed in the BPM community for this particular blasphemy), the entire BPM industry has focussed on building tools that allow for easy modification of process maps by the business, when maybe they really should have been focussed on pushing their customers towards the integration of business rules for decisioning in order to greatly reduce the need to modify process maps.

Climbing off my soapbox for a moment and returning to James and Neil’s book, they focus on a key benefit of this sort of smart decisioning in operational processes, which is the ability to replace the “irreplaceables”, such as insurance underwriters, before all the boomers take their knowledge and retire to Palm Beach. This greatly controls risk: not just the risk of the workers leaving, but the risk of bad or inconsistent decision-making. By allowing decisions to become more personalized based on the customer and scenario, this can also provide the ability to be more customer-centric, as well as agility in the face of changing regulations and market conditions.

They see a number of roadblocks to this sort of smart decisioning at the operational level:

  • Everyone is focussed on strategic issues and not taking their operations seriously; however, the aggregate effect of a small but poor decision on millions of operational transactions is, in fact, strategic. In other words, execution matters.
  • Business and IT have an antagonistic relationship. This is often blamed on IT being arrogant and not allowing the business to participate in technology initiatives, but there’s also some amount of the business not wanting to take responsibility since that means that they can’t blame IT if something goes wrong.

The ideas that James and Neil put forward in their book are a great place for business and IT to start collaborating on how to make smart enough systems.

You may also want to listen to the interview that Scott Sehlhorst did with James back in June (I know, I know, when the book was actually released).

BRF Day 2: How Business Rules Re(Define) Business Processes: A Service Oriented View

For the last session today, I attended Jan Venthienen’s session; he’s a professor at Katholieke Universiteit Leuven. He talked about different representations of rules, particularly decision tables (at length, although in an interesting way). He talked about the problems with maintaining decision trees, then as he moved on to business processes, he showed how a business process with the rules encoded in the process as routing logic was really just a form of decision tree, and therefore difficult to maintain from a rules integrity standpoint. As rules are distilled out of and separated from the processes, the processes become thinner and thinner, until you have a single branch straight-through flow. I have the feeling that he’d like to reduce the process to a single activity, where everything else is done in a complex rule called from that step. I’m not sure that I agree with that level of stripping of logic out of the process and into the rules; there’s value in having a business process that’s understandable by business users, and the more that the logic is encapsulated in rules, the harder it is to understand how the process flow works by looking at the process map. The critical thing is knowing which rules to strip out of the business process, and which to leave in.

He’s doing research now to determine if it’s possible to specify business rules, then automatically derive the business process from the rules; an interesting concept. In order to do this, there must be rules that constrain the permission and obligations of the actors in the process, e.g., an order must be accepted before the product is shipped. This presents two possible architectural styles: process first, or rules first. In either case, what is developed is an architecture of rules, events and services, with a top layer of business rules and processes, a middle layer of services and components, and a bottom layer of enterprise applications.

BRF Day 2: Using Business Rules to Enable a Closed Loop of Compliance

I’m eager to learn more about the relationship between policies, procedures and rules, and how they relate to compliance, so I sat in on a presentation by Peter Still of RuleBurst. There’s a pretty high percentage of vendors on the speaker roster, but so far the quality has been good so no complaints.

The theme of Still’s talk is that the business rules approach will only gain critical mass if it stops being a technical implementation tool and starts being a business problem-solving tool. The current pitch from the business rules vendors is that this is a way to implement systems faster and cheaper, while allowing the business to access some tuning parameters, but this is really focussed on the technological capabilities and not the business value of business rules. This is such a perfect mirror of the BPM field, where BPM has just barely moved from a purely technical sell to something that’s now being sold more and more to the business side of an organization, so I can completely understand where the business rules market is and the challenges that lie ahead in shifting the focus of their marketing message. Worldwide market for business rules product revenue is $250M — not a lot when you consider the size of related markets — and it could be a lot larger if there was greater recognition of the business benefits of business rules.

A perfect business case for re-targeting the business rules message is compliance: it’s an enterprise-wide initiative with executive support where business rules can be included in the decisioning at key points of the process. Although business rules aren’t the complete answer to compliance since compliance is a very process-focussed initiative, rules can be a significant contributor to compliance efforts. One of the difficulties with compliance is that many regulations, such as Sarbannes Oxley, are pretty vague since they have to deal with such a broad range of companies, and it’s difficult to determine precise business rules to implement them. Compliance at a transactional level is a mostly automated application of BPM and business rules, but as you move up to risk management and higher-level compliance factors, there’s less automation although still opportunities for business rules to be wrapped in a compliance framework, such as using business rules to classify a risk although the management of that risk may be done manually. Still maintains that there’s a link between transactional and operational compliance, and believes that business rules can help with that link although that’s not recognized by most business rules vendors.

As with most other complex applications of technology, you can solve this with an integrated compliance and rules solution from a single vendor, or go for a best-of-breed approach. Still recommends the former approach, and invited us to drop by his booth to check out what RuleBurst has to offer in this area.

BRF Day 2: True Adventures in Business Rules

Paul Armborst of the Westfield Group presented on his experiences in implementing business rules for their various insurance applications over the past 6 years. He sees one of the key problems is in documenting business rules, with two main choices for how to do it:

  • Define the rules in a repository first (a rules management/modelling tool). Although this is the most likely approach for the first definition of rules within an organization, they’ll become out of sync as soon as they are implemented since the rules will be modified in the executing code or BRE rather than in the repository.
  • Define the rules directly in a business rules engine, then generate the documentation in some automated fashion (likely provided by the BRE vendor)

He sees that the best way would be a combination of both approaches: a throw-away repository to document rules as they are discovered, and an extract from the BRE to provide ongoing documentation.

He pointed out one of the problems with introducing business rules: “real” developers want to write Java code, not this airy-fairy business rules stuff, which is an argument that I see against BPM as well. As IT budgets get squeezed, however, development teams will start to look for ways to reduce the amount of code that they have to write and pass some of the tuning capabilities directly over to the business; both BRE and BPM provide these types of capabilities.

He discussed various methods of implementing business rules:

  • Decision tables, noting that the BRE vendor needs to provide some sort of analysis tool to detect gaps and overlaps in the rules, with the caveat that it’s possible to construct a decision table that’s too big to reasonably maintain.
  • Decision trees, which can provide the same functionality in a decision table, but in a graphical form; if the decision points are not in the right order, the number of nodes can multiply unnecessarily, and overly-large trees can be difficult to follow.

He also discussed stateful and stateless implementations of business rules: although stateless is simpler to implement, stateful allows for running only the rules that use data that has changed since the last evaluation of each rule.

There were some last comments on end user rule maintenance: all of their rules are written by developers, but they’re thinking about how to offer some rule creation and modification capabilities to end users. It’s important to have a BRE that allows some sort of restricted view for less technical users, but it’s also necessary for the techies to do some helpful things like naming objects in a manner that users can understand rather than, say, reverse Hungarian notation. Users who have access to create rules need to have some notion of the logic required to do so, and there needs to be some provision for testing.

BRF Day 2: Rules Management Without a Rule Engine

I moved over to the über-geeky “chief architect” track to hear Rik Gerrits of RuleArts and Petr Choteborsky of Microsoft, but 10 minutes into the session, Gerrits is still giving some fairly basic definitions of business rules management: where rules live, how they’re developed, and how they’re managed and used. He does make a point that business processes consume business rules but that they should be distinct in terms of methodology and implementation, as well as other motivations for business rules management such as compliance and efficiency improvements.

Choteborsky took over with a case study about Microsoft’s internal development (as in applications for their own internal use, like software licence authorization), and instantly endeared himself to the audience by saying that he was in corporate IT at Microsoft, and was just as much a victim of the Microsoft product groups as we were. They had issues with software development lifecycle documents and the rules that were embedded within those documents: multiple, conflicting instances of rules in different documents; rules not explicitly defined hence less agile; no common vocabulary leading to inconsistency and miscommunication. Over time, the business logic is lost, and the business requirements documentation becomes completely out of sync with the application and the user manual, so that the only true representation of the business logic is embedded within the application as coded.

He stepped through an example, showing how to break down the prose in a requirements document to determine what is a rule set (a group of related rules), what’s a rule, what’s a fact (unchangeable, therefore may be hard-coded), what is usability behaviour (which may include hidden rules and facts), and what is contextual information that describes capability without being something that will be explicitly coded. Very cool example, since he shows the tendency for the prose in what we think of as a fairly well-written requirements document to actually be a confusing mix of facts, rules, behaviour and context that doesn’t really provide adequate information about what should be written to be easily changeable versus what can be hard-coded into an application.

He went on to show how the same paragraph should be restructured as facts and rules (describe the pure essence of how business must be conducted, independent of implementation detail), requirements (UI and application requirements to implement the rules) and context (information that makes it easier to understand the facts, rules and requirements; redundant information that is not coded). The rules mantra (which I’m just learning today) is “rules build on facts, facts build on terms”, and he shows the terms sprinkled throughout the facts and rules.

They’re attempting to change their requirements documents to this form of structured requirements using business rules (for going-forward documents, not retrofitting the existing ones), but it’s a painful process: there needs to be some common vocabulary and a significant amount of training in some cases to have people start thinking in this way. There was a comment from the audience that once the vocabulary — particularly standardization of terms — was established, there’s usually a pretty good uptake from the business community since they really like language that can help them to define their business more precisely and unambiguously.

There was another comment from the audience that what he is calling a requirement is actually a specification, which is an argument that I’ve had about a zillion times in my years of software development: I completely agree with the comment, as did Choteborsky, but he stated that this was the common terminology in use at Microsoft today and he wasn’t trying to fix everything at once. I have to see the pragmatism in that, although there should likely be some sort of migration of terminology to be more accurate.

He went into more detail on terms, facts and rules, including descriptions of each, and the use of graphical term models and fact models. He also made a distinction between a rule and a policy: a rule can produce an action or decision, whereas a policy is more general but might sound rule-like. He stepped through the before and after of a fact model, where he went through and marked each object and relationship in the model as correct, sort of incorrect, or outright wrong, then found new relationship pathways and defined new terms in the model to make it a better reflection of the actual facts and provide a more logical structure for developing rules. He’s just using Visio for creating the fact models, although I’m sure that some more comprehensive modeling tools could make this process a bit easier. They’re starting to use RuleXpress (the RuleArts product) for terms, facts and rules, although the rules themselves are actually encoded within applications: rules management without a rule engine. As he pointed out, although some business rules may end up in a business rules engine, some end up directly in the code of an application, and some are never codified but become part of an operational manual. We see exactly the same thing in BPM, where a process model may include steps that are transferred to a BPMS, but also ones that are completely manual and never represented within a BPMS. Having a modelling tool separate from the execution environment provides greater flexibility in what can be modelled, but I suspect that the same issues of synchronization and round-tripping occur in rules modelling environments as exist in process modelling.

Choteborsky was a great speaker: knowledgeable, able to explain some fairly complex concepts, and funny (when one slide came up, he said “I don’t know why PowerPoint made the font on this slide bold and ugly, but I’ve learned that I don’t need to win every battle”). The great thing is that he presented a methodology for developing business specifications that everyone in the room involved in software development could take away and start examining for their own use.