Enterprise Decision Management - a Weblog

EDM Helps Minimize Trade Offs Between Application Maintenance and Strategic Initiatives – So Says Forrester Research

While Enterprise Decision Management (EDM) is not called out specifically in Forrester Research’s January 28 report, “The State Of Enterprise Software Adoption: 2007 To 2008,” it describes issues top of mind among technology executives addressable with EDM technologies, such as Business Rules Management Systems (BRMSs). The report is based on results of a survey of 1,017 IT decision-makers in North American- and European-based enterprises.

Decision Management at the Heart of Future Enterprise Applications, so Says Forrester Research

Respected technology prognosticators John Rymer and Connie Moore of Forrester Research just published a new paper titled, “The Dynamic Business Application Imperative” (September 24, 2007, For CIOs). Rymer and Moore envision a new generation of enterprise application that some IT organizations today are cobbling together in order to meet ever changing business, technical and marketplace requirements.

Rules and requirements - more links

Scott and I have been working on our presentation for Business Rules Forum - Getting It Right. Rules and Requirements in Software (if truth be told he has been working on it while I "help" ) and this has prompted...

Live from ITARC - Empower Developers with Feature-Driven Development

Continuing at the IASA ITARC event in Atlanta I listened to Don Browning, Principal Architect at Turner Broadcasting, talk about Feature Driven Development. Turner considered XP, SCRUM and FDD sometime ago and found that FDD fit their waterfall-based mindset. Don...

Use Cases and Requirements - a response

Scott Sehlhorst, with whom I am presenting at Business Rules Forum this year, just posted Use Case Example With Business Rules. In the post Scott identifies 4 opportunities, in an ATM withdrawal use case, to find decisions and I thought...

Rules and requirements - what do YOU think?

Scott Sehlhorst and I are presenting at Business Rules Forum this year on rules and requirements and thought we would use our blogs (his is here) to carry out a public discussion/presentation development process! He got it started with Business...

Rules and requirements

Just a quick note. I spotted this nice summary article by Ron Ross over on the Requirements network - Business Rules Come First - and then also noticed that Larry Goldberg had asked an interesting question here - are business...

Lean application development and maintenance - some thoughts

I recently came across this McKinsey paper - Applying lean to application development and maintenance (subscription required). The abstract has a few key bullets: Lean techniques, originally developed to reduce waste in manufacturing, are boosting performance in more and more...

Are business rules a bridge or a ferry?

James Governer had a great post today - On Agile, IT-Business Alignment, Martin Fowler and The Yawning Crevasse of Doom talking about a presentation by Martin Fowler and Dan North. There were some wonderful comments in it: The biggest problem...

More on requirements gathering

Another great post on requirements from Scott over on his blog - Types of requirements gathering. Worth reading as good background for anyone gathering requirements and rules (which are not the same, remember). A couple of rules-centric comments first: Rules...

Use Cases, UML Statecharts and business rules

Interesting post over on the Tyner Blain blog Use Case vs. UML Statechart - Business Rules. This post does a good job of differentiating between use cases and UML statecharts with a view to finding the business rules. Of course,...

1 MORE thing CIOs should know about requirements

I saw this article on CIO magazine today - Five Things CIOs Should Know About Software Requirements. It seems to me that there is one more thing (at least) that they need to know about requirements: Business rules are NOT...

Does everyone even WANT to write software?

Like many of you, I suspect, I found Awaiting the Day When Everyone Writes Software (you may need to register) in the New York Times interesting. While I hate to criticize someone like Charles Simonyi (who has brought to market...

Nice presentation on rules and requirements

BPM Institute has a nice Case Study: Business Rules and Requirements Management at the IRS about the IRS' piloting of a new methodology for analyzing, documenting, and managing business rules in conjunction with requirements for system design. Has some good...

Using business rules to write maintainable code

Reddit pointed me to this post on "Writing Maintainable Code" by Jeremy D. Miller over on CodeBetter.com. It's a nice article and I look forward to reading the rest of his posts on this topic.There's lots of good stuff but...

The problem with programmers

Firstly let me say that not only are some of my best friends programmers but that I have been a programmer, development manager, product manager, architect and methodology author in my career so please don't consider this some marketing guy...

Gathering requirements, and rules

I saw this post on gathering requirements by Scott Sehlhorst today. Now I don't think requirements are the same as business rules (particularly given the nature of business rules is to change) and that one should keep them separate and...

Dig yourself out of the requirements tarpit

I saw this piece by Carey Schwaber of Forrester today - The Root Of The Problem: Poor Requirements. My regular readers will know that I have strong opinions about requirements, so much so that I have a whole section on...

Now you can use agile methods and business rules together

I wrote a little article on the use of business rules in the context of agile methods to deliver true business agility for InfoQ recently - Agile Business Rules. Deborah Hartmann also wrote a nice introduction When and How to...

Top posts on business rules

I was doing some analysis the other day and identified your favorite posts and I thought it would be fun to show the list with some comments. The first list is of ones related to business rules. Here goes: Agile...

Not another attempt to "fix" requirements!

Regular readers of the blog, and there are getting to be close to 100 of you I think, will have seen my rants on requirements management as a solution for business agility before. Over on ComputerWorld today I saw another...

Book Review: Use Cases - Requirements in Context

This second edition of the book is on how to gather and define requirements using a process based on use cases. The book outlines an iterative approach to using use cases and adapted and evolved based on real experience of...

Ch-ch-ch-changing....

Brad Appleton posted a great little piece on Unchangeable Rules of Software Change - Redux. He makes some great points in the article and I am going to shamelessly steal some. He identifies three pitfalls that are very pithy: Pitfall...

Agile Rules? A "conversation" with Scott Ambler

Scott Ambler is a well known writer on Agile techniques and some of his comments were posted on a business rules group recently - http://groups.yahoo.com/group/bizrules/. I found some of them very interesting and so got Scott's permission to re-post them...

More on focusing on requirements

I have blogged a lot about the problem of requirements. I saw another article on this today, Unraveling the Mystery of Software Development Success. Now while I agree with much Joe Marasco has to say, I was a little disappointed...

Taming Application Development with Business Rules

Nice article on some of the challenges of software development by Brian Kilcourse in CIO Magazine - Taming the Wild Child of IT—Application Development. There are some great quotes in it. Software, and more specifically software development, is arguably the...

Getting Applications Right with Business Rules

This InfoWorld survey - 2005 survey spots trends in software development - had a great section on "Getting applications right". One of the lead quotes is: This gap[between user requirements and developer specifications] was one of the two principal challenges...

Fix the requirements mess - use business rules

Don't try and fix the requirements process, empower business users to own the part of their system that IT does not understand and that changes all the time with business rules.

How do you write a set of requirements that don't encode any business rules?

One of my other posts - Writing Better Requirements - Key to Success or false hope? - prompted David Locke to ask me "How do you write a set of requirements that don't encode any business rules?" Well the key...

Writing Better Requirements - Key to Success or false hope?

Requirements need to be good but sometimes they just change too fast. That's where business rules technology lets you teach your users to fish, not just feed them.

Different Perspectives

Different perspectives from IT and the business are nothing new but business rules technology can bridge the gap.