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

What’s a Business Architecture?

What’s your definition of business architecture? Here’s ours:

a structural representation of a business solution as it relates to creating business value and achieving business goals

Like most practitioners we mean a blueprint. Actually, blueprint doesn’t completely align with the dictionary definitions of architecture.[1] You can take your pick from the following alternatives, but not one of them refers to a representation of what is being built.

1. Art and Science: the art or practice of designing and building structures … in accordance with principles determined by aesthetic and practical or material considerations

2. Structure: formation or construction whether the result of conscious act or of growth or of random disposition of the parts … e.g., architecture and function of the cerebral cortex

3. Specific Result: instance of the exercise of the art or science of architecture … architectural product: architectural work … e.g., the mansions which comprise the entire architecture of the Square

4. Method of Style: a method or style of building characterized by certain peculiarities of structure …

The first definition above refers to architecture as an art and science. That’s what architecture students go to universities to learn, and what professional architects practice daily. Who today really thinks of business architecture as an art and science? It should be – and it probably will be eventually – but it’s not yet. The first definition also highlights principles. Any viable approach to business architecture must enumerate its principles and adhere to them closely. That’s not just so much talk. The approach must provide proper thinking tools so that you can consistently act in accordance with the principles. Do most current approaches to business architecture provide such thinking tools? I think not. If they did, they would feature:[2]
  • Business policies (in the context of business strategy), business rules, and decision engineering. Those things represent the intellect of the organization and the fundamental answer for question why.
  • A carefully factored approach whose component models cover each of the facets needed to communicate effectively with all the different audiences engaged with, or affected by, a business solution.
Let’s face it. Many techniques currently offered for ‘business architecture’ frankly aren’t even really about the business. They’re about – what else – IT’s view of the business. Some related points: 1. We think that business architecture always involves some amount (often pervasive) of organizational transformation, which can be taken to include building a new business solution completely from scratch. Organizational transformation is inevitable, so other than buzzword appeal, there’s really no need to mention it in the definition of business architecture. 2. Architect can be used as a verb (to plan and contrive as an architect). Too bad “architecting” doesn’t roll off the tongue as easily as “designing” or “modeling”. After all, architecting business solutions is exactly what business architects should be doing daily. ~~~~~~~~~~~~~~~~~~ www.BRSolutions.com


[1]Merriam-Webster Unabridged Dictionary
[2] These are the two basic principles of the BRS methodology IPSpeak™, which architects business solutions featuring the operational intellectual property (IP) of the business. IPSpeak is comprehensively detailed in our 2011 book Building Business Solutions: Business Analysis with Business Rules (by Ronald G. Ross and Gladys S.W. Lam).

Continue Reading

Point-of-Knowledge Architecture: True Business Agility, Incremental Development, In-Line Training, and Real-Time Compliance

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php Let me use an example to sketch the workings of business rules in smart architecture based on points of knowledge[1].  Refer to the Figure to visualize how the system works.

Aside: I have been using this same slide since 1994(!).

Suppose you have a process or procedure that can be performed to take a customer order.
  • An order is received.  Some kind of event occurs in the system.  It doesn’t really matter too much what kind of event this is; let’s just say the system becomes aware of the new order.
  • The event is a flash point — one or more business rules pertain to it.  One is:  A customer that has placed an order must have an assigned agent.
  • We want real-time compliance with business policy, so this business rule is evaluated immediately for the order.  Again, it doesn’t much matter what component in the system does this evaluation; let’s just say some component, service, or platform can do it.
  • Suppose the customer placing the order does not have an assigned agent.  The system should detect a fault, a violation of the business rule.  In other words, the system should become aware that the business rule is not satisfied by this new state of affairs.
  • The system should respond immediately to the fault.  In lieu of any smarter response, at the very least it should respond with an appropriate message to someone, perhaps to the order-taker (assuming that worker is authorized and capable).
What exactly should the error message say? Obviously, the message can include all sorts of ‘help’.  But the most important thing it should say is what kind of fault has occurred from the business perspective.  So it could start off by literally saying, “A customer that has placed an order must have an assigned agent.”  We say the business rule statement is an error message (or better, a guidance message). That’s a system putting on a smart face, a knowledge-friendly face, at the very point of knowledge.  But it’s a two-way street.  By flashing business rules in real-time, you have an environment perfectly suited to rapidly identifying opportunities to evolve and improve business practices.  The know-how gets meaningful mindshare.  That’s a ticket to continuous improvement and true business agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a guidance message and stop there?  Can’t it do more?  Of course. For the order-taking scenario, a friendly system would immediately offer the user a means to correct the fault (again assuming the user is authorized and capable).  Specifically, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.  If successful, the user could then move on with processing the order. This smart approach knits procedures together just-in-time based on the flash points of business rules.  It dynamically supports highly-variable patterns of work, always giving pinpoint responses to business events (not system events).  In short, it’s exactly the right approach for process models any time that applying know-how is key — which these days, is just about always! The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) says this:  “Rules define the boundary between acceptable and unacceptable business activity.”  If you want dynamic processes, you must know exactly where that boundary lies, and how to respond to breaches (at flash points) in real time. Is that as smart as processes can get?  Not yet.  Over time, the business rules for assigning appropriate agents might become well enough understood to be captured and made available to the system.  Then when a fault occurs, the system can evaluate the business rules to assign an agent automatically.  At that point, all this decision-making gets tucked very neatly under the covers.  Even if the business rules you can capture are sufficient for only routine assignments, you’re still way ahead in the game. Smart architecture based on business rules is unsurpassed for incremental design, where improvement:
  • Focuses on real business know-how, not just better GUIs or dialogs.
  • Continues vigorously after deployment, not just during development.
  • Occurs at a natural business pace, not constrained to software release cycles.
The Manifesto says it this way:  “An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.”  That’s exactly what you need for knowledge retention, as well as to move pragmatically toward the knowledge economy.  Business rules give you true agility.

Continue Reading 1 Comment

Re Zachman and What He Really Says …

One way of looking at the Zachman Architecture Framework is that it is about asking the right questions in the right ways at the right times of the right people. The number of transformations (between the rows) is fixed … either they happen in your head or they happen via specifications to tools. Some developers have great heads, but personally I prefer the answers to be traceable, auditable, and reversible over time. BTW, the lower-level transformations could be automatable and simple … if only the higher-level specification support were powerful enough. And with machines more powerful every day, they should be.

Continue Reading

Looking to Find Out What Decision Analysis is About? Make Business Processes & Business Architectures Smart? Design Business-Friendly Decision Tables? Write Business-Friendly Business Rules? >>> Free downloads …

As part of the April announcement of the new 4th edition of my book Business Rule Concepts: Getting to the Point of Knowledge, I’m pleased to make available some additional complementary (and complimentary!) downloads: Decision Analysis – A Primer: How to Use DecisionSpeak and Question Charts (Q-Charts) – 49pp http://www.brsolutions.com/IPSpeakPrimers (free) Decision Tables – A Primer: How to Use TableSpeak – 121pp http://www.brsolutions.com/IPSpeakPrimers (free) Tabulation of Lists in Rulespeak®: A Primer Using “The Following” Clause – 16pp http://www.brsolutions.com/IPSpeakPrimers (free) We’ve comprehensively written-up state-of-the-art experience and insight in these important areas. I hope you will make the most of them! P.S. Do have a look at other items of interest: http://goo.gl/WPV7O  

Continue Reading

What is a Business Capability? How Do Business Rules Relate? The Missing Man in Business Capabilities?

There seems to be widespread difference of opinion about what a “business capability” is. When I use the term, however, I simply mean the ability of the business to conduct some form of operational activity. What does the business need for that? It clearly needs people, technologies, data, and processes. And it also needs guidance (aka business rules). Business rules are not just things you document; they are things you run the business by. That intelligence, that intellect, is perhaps the most important business capability of all.

Continue Reading 2 Comments

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

Where Rules Fit in the Zachman Framework … Conspicuous in Their Absence?

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #8 Question: Why aren’t rules found in any of the cells of the latest Zachman Framework? The Manifesto says clearly (principle 1.1) that rules should be considered a first-class citizen of the requirements world. Yet rules cannot be found in any of the cells of the latest Zachman Framework. Contradiction? No. For an artifact to appear in a cell of the Framework it must represent a primitive. An artifact that references multiple primitives is considered a composite Rules are intrinsically composite. Even atomic rules can address multiple primitives. (Atomic means “can’t be reduced into two or more rules without losing meaning.”) An example: An accounting must be given by the CFO in Delaware on March 15, 2015. This rule refers to a thing (‘accounting’), a person (the CFO), a place (Delaware), and a date (March 15, 2012). Simply because an artifact is composite, however, doesn’t necessarily make it unimportant. Consider what Zachman calls integration relationships – the connections tying the six primitives together. Integration relationships serve to configure the enterprise at any given point in time. No integration relationships, no enterprise. To illustrate, Zachman frequently rolls the Framework into a cylinder and looks through it like a telescope. The primitives must be tied together through that empty cylinder by integration relationships. What can serve in that role? Traditionally, integration relationships have been implemented by procedural means – hardcoded into application programs. Unfortunately, that’s like setting the business in concrete. It also plays havoc with process as the simple, straightforward primitive it should really be. A much better alternative is rules. Rules, by comparison, are far easier to change. So consider rules as the first-class candidate to achieve configuration agility for the enterprise  


[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 *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

How Many Different Ways Can Your Organization Be ‘Silo-ed’? Why You Need to Address Every ‘Silo-ing’

‘Silo’ is so common as an industry buzzword we mostly just take it for granted. The usual sense is ‘functional’ silo or ‘organizational silo’. I recently heard ‘no man stands alone’ (‘alone’ = ‘silo-ed’) as a common-sense justification for Big-P process. (See http://goo.gl/Cuk3s) That logic is simply flawed. Here are other ways your business can be fundamentally ‘silo-ed’.
  • You can stand alone (silo-ed) in your strategy – goals not aligned, tactics not aligned, policies not aligned.
  • You can stand alone (silo-ed) in your timing – events, intervals and schedules not coordinated.
  • You can stand alone (silo-ed) in your logistics – locations isolated, connections and transport linkages not optimized.
  • You can stand alone (silo-ed) in your language – different vocabularies and meanings, producing semantic silos (a.k.a. a Tower of Babel).
And of course, you can stand alone (silo-ed) in your business rules. Any one of these ‘silo-ings’ can be worse than ‘functional’ or ‘organizational’ ones. My bias, of course, is toward language (nothing gets done effectively in a Tower of Babel) and strategy (if you’re storming the beaches, you’d better hope the generals already got it together strategy-wise). But that’s not the point. If an approach doesn’t evenly addresses all the ‘silo-ings’, it’s trouble. As we say in our new book (http://www.brsolutions.com/b_building_business_solutions.php) you need a well-factored approach. (And of course, John Zachman has been saying that for 25+ years.) The Big-P process view steers you in a harmfully simplistic direction … and probably right into the waiting arms of some eager consultancy or services provider.

Continue Reading