Can you remember a year when your business both (1) grew in a healthy way and (2) changed more slowly than the year before? Besides a company’s early startup years, such would be the exception, not the rule. So, in 2011, your business is likely to continue accelerating its pace of change. A recent Forrester report, The Top 15 Technology Trends EA Should Watch: 2011 To 2013, named both business rules and SOA policy as items for your watch list — because both of them help accelerate business change.

Back in the mainframe days — and even into minicomputer, client/server, and Web applications — nearly all of the business logic for every application was tightly wrapped up in the application code. A few forward-thinking programmers might have built separate parameter files with a small bit of business-oriented application configuration, but that was about it. But, business changes too quickly to have all of the rules locked up in the code.

Some have tried the route that businesspeople ought to do their own programming — and many vendor tools through the years have tried creatively (though unsuccessfully) to make development simple enough for that. But, business is too complex for businesspeople to do all of their own programming.

Enter business rules, SOA policy, and other ways to pull certain bits of business logic out of being buried in the code. What makes these types of approaches valuable is that they are targeted, contained, and can have appropriate life cycles built around them to allow businesspeople to change what they are qualified to change, authorized to change, and have been approved to change.

Although neither makes the headlines like cloud and such, 2011 will see continued adoption and growth of business rules and SOA policy. Business rules technology is much farther along in adoption than SOA policy — as it should be. SOA policy requires much more architectural work, particularly when (a) used beyond its core of security policy and management policy or (b) set up to allow businesspeople to do their own change.

But here's the crux of the matter: Both business rules and SOA policy are part of a much broader trend to build software around flexible business design focal points. Do you need to start or expand your adoption of them in 2011? Perhaps, but only if you do your homework so that you'll get the value. The important things to focus on are (1) understanding where and how your business most needs flexibility and (2) using business rules, SOA policy, business process flow, and other techniques and technologies to accelerate your ability to change the business.

What are your plans for and experiences with business rules engines and SOA policy?