Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘business architecture’

The Procedural Paradigm Won’t Scale: We Need Configuration Agility!

It’s been said that I claim the procedural paradigm won’t scale anymore. Guilty as charged! Let me explain. Procedural vs. Declarative In the big scheme of things, you have two basic choices for conceptualization, and ultimately implementation, of business capabilities: procedural vs. declarative. Let’s make sure we agree on what these terms mean. I’ll draw directly on Merriam-Webster Unabridged to make sure we’re on the same page. If the terms don’t mean what they’re supposed to mean, all bets are off. But I guess that goes without saying, doesn’t it?

procedure: 1a: a particular way of doing or of going about the accomplishment of something 1b (1): a particular course of action (2): a particular step adopted for doing or accomplishing something (3): a series of steps followed in a regular orderly definite way

You can spot the seeds of the scalability problem right away with repeated use of the word “particular” and with the phrase “regular orderly definite way” in the definition. Given the degree of product/service customization desired today, and the accelerating rate of change, how much business activity still occurs in a particular and regular orderly definite way? The answer, of course, is less and less all the time. ‘Exceptions’ have become the rule. The essential characteristic of procedures is that they flow. The flow comprises the steps by which a thing is intended to become a different thing (or the same thing in a different state). The essence of ‘procedure’ is therefore that something will be hopefully transformed. For sure, that’s a very basic, very important, very necessary part of any business capability. The problem arises taking procedure beyond that point. Something declarative, in contrast, doesn’t flow. It just states something that must (or should) be true.

declarative: 2: having the characteristics of or making a declaration : ASSERTIVE;  specifically : constituting a statement that can be either true or false

Business rules are that way; they simply give guidance. They don’t do anything. They don’t flow anywhere. They can’t be anything other than true or false. In short, business rules are fundamentally different than procedures. Big-P Process The traditional procedural paradigm (I’ll call it Big-P Process) embeds business rules in procedures (and in process models and in procedural code).What happens when you treat things that could be declarative in a procedural way? You get bloat. You lose business intent. You produce needless complexity. And you also get what I call configuration stagnation. As you scale, these problems grow exponentially. How many business rules are we talking about? Any given business capability easily has hundreds, sometimes thousands of business rules – especially when you begin to factor in the know-how needed to make smart operational business decisions. And don’t our businesses increasingly depend on ever more complex know-how? Is there any end to that trend in sight? At the scale of today’s business, the Big-P Process paradigm simply doesn’t work. It results in ungovernable business operations and unretainable know-how. Big-P solutions are like setting the business in concrete. It’s all so unnecessary and so counterproductive. It’s just not smart. Configuration Agility The key question for agile business capabilities is how the business is configured (and quickly reconfigured) for operation at any given point in time. In the Big-P paradigm, the building-blocks become thoroughly entangled with flow (procedure). The result is essentially a semantic dead zone. Because things that could be expressed declaratively aren’t, the opportunity is lost to use logic to automatically evaluate business rules (read ‘business practices’) for conflicts, anomalies and other logical defects. The future clearly does not lie in that direction. Instead, it lies with granular, declarative, semantically-rich specification of business configurations in building-block fashion. It lies with the paradigm that can produce the optimal configuration agility. In addition to procedures, smart configuration models will feature at least these other building blocks for business capabilities, all specified at the business level:
  • business rules 
  • operational business decisions 
  • structured business vocabularies (concept models, also known as fact models) 
  • business goals and risks 
  • business events
From an engineering perspective, the secret to agile configuration is ‘late binding’ – that is, bringing all the pieces together for execution (i.e., performance of procedures) as late as possible. That way, performance can be as up-to-date and as flexible as possible. Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I simply see no alternative. Doing more of the same is simply not going to work anymore (and already hasn’t been for a good, long while). [Warning, plug coming]: Smart configuration schemes also address business governance and compliance – essential in a world of constant change – and just-in-time (JIT) delivery of know-how for operational workers. In our new book, Building Business Capabilities (see http://www.brsolutions.com/b_building_business_solutions.php) we call systems built using smart configuration models business operation systems (as opposed to ‘information systems’).  

Continue Reading 2 Comments

What Role for Business Rules in *Enterprise Architecture*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #6 Question: What role should business rules play in enterprise architecture? Reverse-engineering business rules from legacy systems accurately is virtually impossible. The full, original business intent is simply lost. Reconstruction of business logic has been tried time and time again, often aided by automated tools, but measured against time and cost, seldom achieves satisfactory results. What a waste! The solution is simply to stop hard-coding business rules into procedural languages. Rules will change and they will be needed for new business initiatives and platforms. The opportunity costs of continuing to follow traditional practices – not to mention the ‘maintenance’ costs – is simply too great. The alternative is applying rule technology that can support rules expressed in more natural (declarative) form. The Manifesto summarizes these points as follows …

6.2. Executing rules directly – for example in a rules engine – is a better implementation strategy than transcribing the rules into some procedural form.

With computing power so vastly improved, there is less and less reason every day to support business rules using procedural languages. Why are we still programming the evaluation of rules ourselves?! Just as a DBMS removes data management as an application concern, so too does a rule technology for the evaluation of rules. A related issue is compliance – not just regulatory compliance, but compliance with contractual obligations, deals, agreements, licenses, warranties, and so on. If you want to delight customers, keep your commitments. To do so you must be able to determine how your systems actually got the outcomes they did. That way, if there’s a mistake you can correct it. So the Manifesto says …

6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.

Today, demonstrating compliance is a largely hit-or-miss affair, always after the fact. Does it have to be? No! A state-of-the-art enterprise architecture is one that logs the rules used to make evaluations and decisions just as a DBMS logs all transactions. Compliance based on rules can and should be built-in.


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Continue Reading

What Role for Business Rules in *Business Agility*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #5 Question: How do business rules support business agility? Think of business rules as expressing business practices. These practices can cover a wide range of business concerns, including the composition of products, the customization of services for individual customers, operational hand-offs with suppliers, implementation of regulatory constraints, and so forth. Historically, rules have been embedded (hard-coded) in processes, in many different places and often inconsistently. There is no easy traceability for any given rule. Changing rules inevitably requires IT intervention, along with the associated cost and delay. From a business perspective, the resulting business support is simply not agile. Business rules support business agility by providing pinpoint means to evaluate and modify business practices. Rules are expressed and managed independently of processes (a.k.a. rule independence). By that means they can be consolidated (single-sourced) and evolved more rapidly and reliability. From a platform point of view, the Manifesto says it this way …

6.1. A business rules application is intentionally built to accommodate continuous change in business rules.  The platform on which the application runs should support such continuous change.

Clearly some platforms are far better than others in this regard. The quality of their support for rules should be a critical factor in selection and design. Unfortunately, many organizations are trapped as much by legacy platforms as by legacy systems. True business agility requires migration to new platforms as quickly and easily as possible. For example, a central concern of many organizations these days is mobile computing and social media – capabilities not even on the horizon ten years ago when the Manifesto was written. There’s no end to platform innovation in sight – and companies will always want to get on-board faster and faster. Is there any way of doing so without knowing your business rules? No! So the Manifesto recommends …

10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.

Always remember that business rules are what you need to run your business, not to design systems, at least directly. There will never be a future platform for which you do not need to know your business rules.  


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Continue Reading

My New Talk and New Take on Business Architecture at BBC2011: The Architecture of Enterprise Know-How

Business Architecture Summit at BBC2011 – Thurs, Nov 3, 2011 – 10:10am I am giving a talk next week called The Architecture of Enterprise Know-How at the Building Business Capability (BBC2011) event in Florida. If you’re there, I hope you’ll come listen. I’ll be plowing new ground. We’ve done some fascinating work the past several years and now it’s time to talk about it … Does the know-how of the company have intrinsic structure at the enterprise level? Can you use that structure to assess and plan operational business capabilities? Where do business rules, business processes, and business analysis fit in? Every company depends on its special know-how, a point so obvious we often overlook it. The products and services we deliver to customers can never be better than our capacity to organize, manage, revise, and deploy that know-how. In a knowledge economy, operational know-how is king. Current techniques for creating enterprise architectures are largely IT-centric. They focus on processes, data and services rather than on business products and the business capabilities to produce and deliver them. We need to change all that using proven, pragmatic techniques that directly engage business managers. The new approach is highly innovative, business-driven, and surprisingly easy.
  • How to conduct a deep, meaningful, rapid assessment of business capabilities
  • How to identify life-cycle-long, enterprise-wide dependencies
  • How to give Finance the crucial, coordinated touch points it needs
  • How to plan for massive customization and reconfiguration of products
  • How to put the ‘business’ into business architecture and business agility
  • How to rekindle the spark of creative thinking in your organization
 

Continue Reading

Why Don’t Requirements Approaches and IT Methodologies ‘Get’ How to Use Strategy as a Technique? … Not Acceptable!

An enterprise architect recently said to me, “The motivation (why) column of the Zachman Architecture Framework is the most underrated, underutilized construct in architecture.” Absolutely correct. Even worse, IT methodologies (that is, the people who create and use them) don’t realize how far afield they are on the matter. As a result they cause business people to focus on the wrong things … or to drop out entirely. Ironically, IT then becomes the impediment, rather than the solution, to much needed business innovation. A bit of background: The Business Rules Group (BRG – www.BusinessRulesGroup.org) identified the area of business strategy as a missing ingredient for business rules in the mid 1990s. In 2000, we came out with a standard for the area, now sponsored by OMG, called the Business Motivation Model. It’s a highly readable document with lots of good examples (and free): http://www.businessrulesgroup.org/bmm.shtml. It provides standard vocabulary and structure for strategy. Zachman, by the way, was a key participant. I am proud of my role as co-editor and author of the first working draft. My business partner, Gladys S.W. Lam, and I have just come out with a new book that explains how strategy (and business rules) can be an integral part of business analysis. It’s actually not that hard to do (if you have the right people, motivation, scope, and approach), and it doesn’t take all that long (ditto same caveats). Those are big myths. Gladys is generally given credit for some of the key ideas in the standard. She grew up in a highly entrepreneurial environment and has a natural sense of business risks and solution sinkholes. But I digress … See Chapter 4 of Building Business Solutions: Business Analysis with Business Ruleshttp://www.brsolutions.com/b_building_business_solutions.php.

Continue Reading

What is a ‘Business Capability’ … And Can It Be Part of a Business Architecture Methodology?

Suppose you wanted to make ‘business capabilities’ the centerpiece of a business architecture methodology. Could you go out into the business and find existing ‘business capabilities’ in some form? Would a focus on business capabilities help you better design the business as a whole? My answer is at this point in time is … well … I dunno. I’m looking forward to the new Business Architecture Summit (http://www.buildingbusinesscapability.com/bas/) at the BBC2011 Conference (http://www.buildingbusinesscapability.com/) the first week of November to shed some light on the matter. There’s going to be some real excitement at the Conference this year on that topic! Here’s our current thinking on the term ‘business capability’ … An IT project always delivers a system and/or database and/or rulebase. But let’s say you want to take a business-oriented approach to solving some problem in business operations. The solution will probably involve significant (re-)automation – but not necessarily. The main focus is finding a winning business solution. What would you call what you deliver as an end-result from such an initiative? Unfortunately, there’s no generally accepted business name for such end-results. In our new book coming out this month – Building Business Solutions: Business Analysis with Business Rules (http://www.brsolutions.com/b_building_business_solutions.php) – we call them simply ‘business capabilities’. Any given business capability is likely to include business processes, business rules, business vocabulary, business roles and more. And it should also feature key performance indicators to measure continuing alignment with business goals.  So my bottom line is this: I know it when I’ve created a business capability, but I’m not sure I would know one beforehand. I’ll let you know if anything I hear from this post or at the Conference changes my mind. Please jump in!

Continue Reading 8 Comments

Business Analysis & Business Rules – Announcing Our New Book and BBC 2011 Conference – **Special Discounts** for Friends and Colleagues

Let me mention two important things happening soon and special discounts for them – Both discounts good only through **Friday, September 30**   1. ANNOUNCING OUR NEW BOOK … Coming in October! BUILDING BUSINESS SOLUTIONS: BUSINESS ANALYSIS WITH BUSINESS RULES … an IIBA Sponsored Handbook (304pp) … It’s all about taking Business Analysis to the next level of capability.  http://www.brsolutions.com/bbs >> Receive 25% off the book’s list price of $39.95 if you pre-order now. Use discount code **BBS1001**.  2. BUILDING BUSINESS CAPABILITIES CONFERENCE (BBC 2011) … Oct. 31 – Nov. 3, Ft. Lauderdale, FL  http://www.buildingbusinesscapability.com/  The must-attend conference of the year covering all things ‘business’.  Four conferences in one for a total of 9 tracks on pace this year to be a sell-out!  >> Receive a 15% discount on registration. Use discount code **RRBBCFL**.  * Business Analysis Forum, the Official Conference of the IIBA. http://www.buildingbusinesscapability.com/baf/ * 14th annual Business Rules Forum Conference. http://www.businessrulesforum.com/ * The 1st annual Business Architecture Summit. http://www.buildingbusinesscapability.com/bas/ * The Business Process Forum. http://www.businessprocessforum.org/

Continue Reading

I talk about business rules – Roger Burlton and I both talk about recent problems of the financial sector

Here’s a short clip about business rules from an interview in Amsterdam not too long ago. I actually agree with what I said … http://www.youtube.com/watch?v=fhv7bGf3r3Y&feature=related There are several related clips there with John Zachman, Roger Burlton, and Silvie Spreeuwenberg (LibRT) worth a few minutes of your time — business rules, decisions, business processes, enterprise architecture, and more.

Continue Reading

Where are Your Business Rules … In a Big-P Process Dead Zone?

On an EA LinkedIn group last week, Nick Malik wrote the following about business rules in Zachman Framework 3.0: I’ll bite. If the ‘enterprise ontology’ is similar to the periodic table of elements, then business rules are molecules. They are compositions of elements with specific implications, embedded in event handling logic. Why would you expect to see them, or models of them, on the Zachman Framework? OK… that was my humble, and perhaps uninformed, opinion. You are the master of business rules. You tell me where you’d see them.” Nick, You know the definition of ‘master’, right? Same as ‘expert’ … someone who has made all the known mistakes. Zachman and I have had over-dinner conversations for many years about the question of where business rules fit (or don’t) in the Framework, even more so in the past couple of years. I won’t speak for John, but I think he agrees. Yes, business rules are ‘molecules’ and yes, they are ‘composites’. So you don’t see business rules anywhere in Framework 3.0. Instead, if you look at the new cross-column thin gray lines, at row 2 in particular, some or many of those could be business rules. Aside: For convenience, here’s a zipped pdf of the new 3.0 version (with permission): ZF3.0.zip [approx 1.5M]. Visit Zachman’s new website for all the latest. The thing about molecules or composites – unlike the primitives – is that they can be conceived in many different ways. Each conceptualization leads you to a different representation approach, and each representation approach leads you ultimately to a particular implementation strategy. Some implementation strategies, of course, are better than others (by a mile!). Moving Beyond the Big-P Approach At the risk of over-simplification, you have two basic choices for conceptualization, and ultimately implementation, of composites: procedural or declarative. Historically, we have embedded business rules in process models and in procedural code. We have taken the column 2 (how) primitive, process, and used it to create composites. At the scale of today’s business, this Big-P process paradigm simply doesn’t work. Why? The thin gray lines in Zachman 3.0 are really about how the business is configured for operation. (At row 6 the thin gray lines represent the current actual configuration of the operational business.) In the Big-P paradigm, all building-block ‘molecules’ become thoroughly entangled with flow (input-transform-output). The result is essentially a semantic dead zone. You’re never sure what things really mean, and you can’t easily disentangle them. There are no built-in impediments to replication … and no opportunity to use logic to automatically evaluate configurations (models/designs) for conflicts, anomalies and other logical defects. Aside: The Big-P approach also has implications for data models. In current practices, there is no way to automatically perform any meaningful verification of data models either. The future lies with granular, declarative, semantically-rich specification of building-block composites (‘molecules’) for configuration. I know I used the ‘S’ word there (‘semantics’) but I’m simply talking about structured business vocabularies (SBVR-style fact models). Fact models, by the way, must cover anything with a name, including instances from columns 2-6, so they too are composite rather than primitive. Aside: Was I happy to see John use the ‘O’ word (‘ontology’) in 3.0? I think I know why he did it – to emphasize the Framework is not a simple taxonomy, but rather something rigorous enough to potentially reason over. I’ll let others judge that choice. Re-factoring the Big-P Paradigm Clearly, business rules are one building-block composite for disentangled forms of enterprise configuration. Another thing not considered a primitive – Nick mentioned them – are events. They too possess the granular, configurable potential of business rules. And yes Nick is right – events and business rules have a very close relationship, one not widely appreciated. (If the industry did, it would already be taking a very different approach to process modeling.) Aside: But no, Nick, I would not ’embed’ business rules in ‘event handling logic’ … no more than I would embed ‘event handling’ in business rules. Unfortunately, expert systems do allow you to do that. What else do we need as building-block composites to configure an enterprise at a given point in time? Let me propose decisions – but with caution. ‘Decision” is the buzzword de jeure. No, decisions are not a cure-all, no they do not replace business rules or events, and no they do not solve all our problems. But in proper perspective, yes, they are most definitely a building-block composite. Smart Configuration Models Big-P configuration of the enterprise is like setting it in concrete. To replace that flagging paradigm we need smart configuration models. Such models will feature at least: (a) business rules, (b) business events, and (c) operational business decisions. And of course, structured business vocabularies (fact models). Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I see no alternative. By pinning down the primitives definitively in 3.0, Zachman has opened the door to a whole new realm of rich architectural potential. But there’s more. Smart configuration schemes must address additional challenges facing business today. These include business governance and compliance – essential in a world of constant change – and just-in-time (JIT) delivery of know-how for operational workers. In our new book coming out the end of September, we call systems built using smart configuration schemes business operation systems (BOS), as opposed to ‘information systems’. I think you’ll find these new ideas quite exciting. Watch for them!

Continue Reading 2 Comments

Audit Trails and Tracing the Impact of Operational Errors … It’s Ultimately about Compliance and Business Rules

Robin Bloor wrote  a very interesting piece about why business needs explicit audit trails for data: http://www.dataintegrationblog.com/robin-bloor/the-quality-of-data-is-not-strained/ Here’s the gist: “… data has no explicit audit trails, so we lose information, some of which may be critical. This has the effect of hiding the record of and the impact of data errors.” He says all data should be time-stamped. I agree … but it’s not enough. I’ve believed for decades (before it was conceivably practical) in the concept of the ‘perfect machine’. In the perfect machine, there are really no such things as changes or deletes; instead, all data just get time-stamped when created and the newer data takes active preference over the older. That gives you built-in audit trails — of data — and more importantly, (mechanized) business memory.  There is, however, at least one circumstance in which data really does need to be deleted (purged). That’s when the business is required for legal reasons to expunge all ‘records’ about some sensitive matter (e.g., the legal transgressions of a minor at age 18). In other words, there are *business rules* that sometimes require true ‘deletes’. Business rules can trump ‘perfect memory’.  Actually, there are business rules for virtually all ‘changes’ made to operational data. Failure to apply the correct business rules consistently is the rrot cause of poor data quality. And good luck trying to reconstruct after-the-fact what really happened (what business rules were actually applied) at some past point in time when things downstream go awry. And they will, of course.  What’s needed is not just an audit trail of changes to data, but an audit trail of all business rules tested at each point in time some data ‘changed’ (or was created or deleted). If the system automatically logs the relevant business rules, then you have a true, complete and indisputable record of ‘history’.  I’m talking here about nonething less here than built-in (mechanized) methods of addressing compliance. No human intervention. Compliance across the board … with external regulations, contracts, agreements, deals, business policies … whatever.  If you want your business to be both extremely agile and highly compliant (which is to say, always meet operational expectations), there’s untimately no alternative. How else can you support one-on-one customized relationships with a million customers? Of course, first you would have to know your business rules. There’s the rub. Do you?! 

Continue Reading