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

Is There Such a Thing as Meta-Architecture?

Louis Marbel, President, Interactive Design Labs, commented[1]: Is there such a thing as “meta-architecture”? This is a simple one – yes! Let me explain. Essentially, an architecture description is a specification of the structure/form for organizing the function of system of interest in order to achieve its intended purpose effectively. The system of interest can be a building, bridge, enterprise, software system, application, enterprise/business data, etc. Now a meta-architecture is a high-order system that operates on an architecture specification as an instance/object, and can validate and/or evaluate the specification to determine consistency and coherence. This view of meta-architecture is consistent with predicate logic and concepts such as meta-types for software type systems, which are also specifications of the behavior of objects. My reply: You say “meta-architecture is a [high-order] system”. But you also say an “architecture [description] is a specification of … structure/form”. “Structure/form” is not the same thing as a “system”. So doesn’t that violate the fundamental meaning of meta- … something that operates on other things of its own kind? I have no doubt that there’s such a thing a meta-system. Should we think of (true) architecture as a system? http://www.brsolutions.com/


[1] This series of point/counterpoint replies is a follow-up to my post “Meta Here. Meta There. Meta Everywhere?” (March 31, 2014), which generated a surprising amount of great discussion. (Thanks all!) Refer to: http://www.brsolutions.com/2014/03/31/meta-here-meta-there-meta-everywhere/ The definition I’m using for meta- is from Merriam-Webster’s Unabridged Dictionary [3b]:

3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem*

Continue Reading

Testing for “Meta” Somethings – An Example

The definition I use for meta- is from Merriam-Webster’s Unabridged Dictionary (MWUD)[1]:

3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem*

In the definition of something that can also be meta- I recommend that there be an active verb that requires an object. The something must be able to be both subject and object of that verb. Example: model Definition (loosely): A model is something that represents another something. Active Verb Requiring an Object: represents Ability to Play Both Subject and Object of the Verb: In the definition above …
    • Suppose the “another something” is other models.
    • Then “other models” can be substituted for the object, which yields: “a model is something that represents other models”.
    • So “model” can play both subject and object of the verb.
    • That makes the subject a meta-model.
    • Substituting “meta-model” for the subject yields: “a meta-model is something that represents other models”.
www.BRSolutions.com


[1] This series of point/counterpoint replies is a follow-up to my post “Meta Here. Meta There. Meta Everywhere?” (March 31, 2014), which generated a surprising amount of great discussion. (Thanks all!) Refer to: http://www.brsolutions.com/2014/03/31/meta-here-meta-there-meta-everywhere/  

Continue Reading

MetaProcess vs. Generalization of Processes

John Bertolet, Global Business Process Management director at Schneider Electric, commented[1]: I have seen the term metaprocess used as the generic name for a high-level process. This usually comes up in the context of trying to name the levels of a process architecture – for example:

1) Highest-level, end-to-end process or “value chain” or assembly of processes 2) Process 3) Sub-process 4) Activity 5) Task

People usually mean the first level above as a metaprocess. But I have not seen any universally accepted standard for this naming convention; so it is whatever you define it to be. My reply: My definition of metaprocess is process that transforms other processes. Your hierarchy represents the decomposing of processes. A process being (passively) decomposed is certainly not the same thing as a process (actively) transforming another process. Based on that difference, no, I would not say a value chain is a metaprocess. Of course, there is (must be) a process for decomposing other processes. But that specific functionality is highly specialized; not all processes do it. In fact most don’t. So decompose is not an appropriate verb for a definition of metaprocess. It’s not intrinsic to what all processes do. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A Systems Architect commented: Is there such a thing as a metaprocess? Yes. One way to look at the answer is processes for the creation and management of processes. But another way is a generalized process … like a design-level process pattern for a certain class of operable processes … which must go through a process design and implementation for specific situation before it is an operable process. My reply: Design-level process patterns can be highly useful. However, I don’t think they qualify under the useful dictionary definition of meta-. Let’s test the ‘rule for meta’. Inserting a verb phrase I get “design-level process pattern that can be customized to a more specific process”. There are at least two problems with that:
  • The nouns must be the same on either side of the verb phrase. But a “pattern” is not the same as a “process.”
  • A process is fundamentally one that transforms things. But “can be customized to” has no sense of transforming something else.
So no, I don’t think a design-level process pattern should be viewed as a metaprocess in the strict sense of the term. (Thought-provoking though!) ~~~~~~~~~~~~~~~~~~~~ Filipe Pinto, business process architect, commented: An example of a metaprocess is the epistemic process. My reply: I assume you mean the process through which knowledge is acquired. That’s an interesting one. For the sake of argument I’ll say that doesn’t fit the definition of metaprocess I’m using: process that transforms other processes. Instead, I would argue it’s a case of extreme generalization. Rather than being a process that supports the learning of only one kind of thing, it’s a process that supports the learning of many (all?) kinds of things. Meta- and generalization are not the same. But of course, it all depends on what definition you use – which is the whole point of this discussion. http://www.brsolutions.com/


[1] This series of point/counterpoint replies is a follow-up to my post “Meta Here. Meta There. Meta Everywhere?” (March 31, 2014), which generated a surprising amount of great discussion. (Thanks all!) Refer to: http://www.brsolutions.com/2014/03/31/meta-here-meta-there-meta-everywhere/ The definition I’m using for meta- is from Merriam-Webster’s Unabridged Dictionary [3b]:

3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem*

 

Continue Reading 2 Comments

MetaProcess vs. Something More than a Process

Amit Mitra, Senior Manager at TCS America, commented[1]: Is there such a thing as a metaprocess? Yes, there is! I am teaching the metaprocess in a master’s course … as a part of an overall model of knowledge that integrates reasoning, measurement, business rules, and process. Indeed, you can infer the business functionality required of the ideal BPM tool from the properties and parameters of the metaprocess (No current tools support them all, but they do support the most obvious properties). The metaprocess also accounts for progressively unstructured processes, and processes that reason about themselves, to infer how they could adapt to different situations. My reply: Interesting indeed. However, what is your definition of process? I think the key part of what a process is (and isn’t) is that it transforms something (turns raw material into finished goods, inputs into outputs). Business rules never transform anything – that’s a key differentiator from business processes. Reasoning and measurement ‘transform’ something only in a trivial sense. My point is that the thing you’ve created a meta- for isn’t really a process. It’s more comprehensive. It’s more like core business know-how or core business capability. The industry desperately needs a better name for the kind of thing you’re creating … because it’s central to moving toward a knowledge economy (and a more rational, sustainable way of doing business). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eric Ducos, CTO of EmeriCon, commented: Is there such a thing as a metaprocess? I would definitely think so. A methodology for identifying, analyzing and building a BPM solution is a metaprocess (i.e. a process to build a process). My reply: I agree except for the word methodology. A methodology is more than a process. It includes rules and guidelines, for example. Merriam-Webster Unabridged Dictionary (MWUD) defines methodology as (1a):

a body of methods, procedures, working concepts, rules, and postulates employed by a science, art, or discipline.

But here’s a thought: There could be such a thing as a meta-methodology … a methodology indicating how to create (other) methodologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John Morris, Director, Solutions Sales at Bosch Software Innovations, commented: In terms of driving work on metaprocesses, I suspect that tort law, regulation and compliance issues might eventually prove to be motivators, more than competition. One might think that having good software would be guaranteed by competition, especially as the information content of most products and services is increasing. The governance challenge, however, is that the semantic content of software is buried by “what you see” – i.e., the surface of the software. All too often that’s where discussion stops. My reply: I couldn’t agree more. That gets you into rules and meta-rules – i.e., into something more than processes. http://www.brsolutions.com/


 [1] This series of point/counterpoint replies is a follow-up to my post “Meta Here. Meta There. Meta Everywhere?” (March 31, 2014), which generated a surprising amount of great discussion. (Thanks all!) Refer to: http://www.brsolutions.com/2014/03/31/meta-here-meta-there-meta-everywhere/ The definition I’m using for meta- is from Merriam-Webster’s Unabridged Dictionary [3b]:

3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem*

 

Continue Reading

Three Basic Principles for Business Architecture

Here are what I firmly believe are three basic principles for business architecture. To me they are just common sense, but they are certainly not so common in prevailing industry practices. 1. Business architecture should be of, by and for the business. (Otherwise, why add the modifier “business”?!). Our rule of thumb is that if business people don’t use a methodology term naturally, then it has no place in *business* architecture. Ever hear a business person use the term “business use case” or simply “use case” without prompting from IT?! The technique is an obvious misfit for *business* architecture. This is simply a case of IT trying to elevate its own tools to a problem it frankly often doesn’t understand. 2. The blueprinting techniques used for business architecture should apply exactly the same no matter how wide the scope – project, business process, whole business, whole supply chain, etc. These are all business problems (first), just sitting in different ecosystems. Also, it should make no difference whether automation is anticipated or not. (Actually, running business operations by hand may be harder in some respects than if automated. Anyway, systems do sometimes go down.) If a blueprinting approach fails in these regards, it’s not about *business* architecture. 3. A major shortcoming in most current approaches is the absence of attention to specifying semantics and knowledge. These need not be interpreted as anything arcane – they’re not. Basically, ‘semantics and knowledge’ simply means defining business vocabulary – words – in an organized manner, and practicable rules to run the business by. Now what business person hasn’t heard of “words”, “definitions”, and “rules”?! Yet traditional IT methods treat them as alien (or not at all). In a day and age of IBM Watson, how could such practices not be seen as archaic?! ~~~~~~~~~ P.S. Yes, such blueprinting techniques for business architecture do exist, and we practice them – in-depth – all the time with our clients. This is what our book Building Business Solutions: Business Analysis with Business Rules (http://www.brsolutions.com/b_building_business_solutions.php) is all about, as well as our on-line training based on it (http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php). www.BRSolutions.com

Continue Reading 2 Comments

Working with Business Rules: Capture, Specification, Analysis & Management

Location: Online Seminar Overview Do your business processes always produce correct and consistent results? If not the problem probably lies with your business rules and decision logic. Business Analysts need the right techniques to fix these problems – process models, use cases, data models and other requirement techniques just aren’t right for the job. This hands-on series will equip you with proven techniques for success. More info: http://www.attainingedge.com/online-training-business-rule-analysis-masterclass.php Register for full series!

Session 1. The why, what and who of business rules

Next Session: October 1, 2013 @ 10:30am – 12:00noon (ET)

  • Why business rules
  • What benefits you can achieve
  • What business rules are, and are not
  • Business rules vs. business processes
  • Kinds of business rules: definitional vs. behavioral
  • How the business should react to violations
  • Business rules and decisions
  • What skills you need to capture business rules effectively
  • What you need to know
Register Session!

Session 2. Eight steps to find and capture business rules

Next Session:October 1, 2013 @ 3:30pm – 5:00pm (ET)

  • Capturing business rules from people’s heads
  • Capturing business rules from great big documents
  • Using facilitated sessions
  • Step-by-step approach
  • What about reverse-engineering business rules from code
  • Do’s and don’ts
Register Session!

Session 3. Eight steps to express clear business rules

Next Session: October 2, 2013 @ 10:30am – 12:00noon (ET)

  • Business policies vs. practicable guidance vs. automated rules
  • The role of business vocabulary
  • Step-by-step approach
  • Clarity and completeness
  • Eliminating ambiguity
  • Addressing exceptions
  • Guidelines
  • What to avoid and why
Register Session!

Session 4. How to analyze and communicate business rules

Next Session: October 2, 2013 @ 3:30pm – 5:00pm (ET)

  • Basic principles for rule analysis
  • Rule quality
  • Handling conflicts
  • Developing business reactions to violations
  • Simplification – When, why and for whom
  • How to validate business rules with business people and SMEs
  • Verification – Examples
Register Session!

Session 5. Eight steps to set-up decision tables

Next Session: October 3, 2013 @ 10:30am – 12:00noon (ET)

  • When to use decision tables
  • How to set up decision tables
  • Decision tables and business process models
  • What your decision tables should not do
  • Decision tables and business vocabulary
  • Best practices
  • Alternative formats
  • Completeness, subsumption and conflicts
Register Session!

Session 6. Ten steps to start or refine your business rules projects

Next Session: October 3, 2013 @ 3:30pm – 5:00pm (ET)

  • Business rules and requirements
  • Properties of business rules
  • Traceability of business rules
  • Retaining corporate memory
  • Managing the life cycle of business rules
  • Business rule management – examples
  • Business rules and rule engines – implementation examples
  • How to get started
Register Session!

Continue Reading

When is a Business Architecture a Dumb One?

In a recent discussion on social media I was explaining what I thought would make a business architecture smart. Tom Graves replied that he wasn’t sure what made one smart, but that he did know what makes one dumb. His criteria …  
    • rigid rule-based boundaries.
    • over-reliance on rigid true/false rules.
    • attempts to implement most or all of that architecture through automated ‘business-rules engines’ that can only work with rigid true/false rules.
He went on to say that these criteria suggest that “a first requirement for a smart business-architecture is that it go beyond all these mistakes.” Tom’s emphasis on ‘true/false’ rules needs to be carefully qualified. After all, you do want the internal workings of a rule engine to be based on formal logic. I believe what he really means is an approach that allows no shades of gray with respect to nuanced enforcement of business rules. On that point I hardily agree. In addition, Tom got me to agree with him on two major points about the current state of the industry. In his words …

1. The quest for ‘certainty’ in an inherently-uncertain world is futile. Rules of all kinds exist to help human thinking and human judgment, not to act as a substitute for it.

2. The software vendors … are frankly not far short of committing fraud with many of the claims they make as to the efficacy and validity of their ‘business-rules engines’.

The term business rule unfortunately has been hijacked by software vendors to mean something very different from the original concept. For example, production rules[1] (the basis for the majority of current product offerings) are not business rules. Full stop. This distorted view of business rule needs to be rectified. Don’t let yourself be sucked into it! For real business rules there are three (optional) supplemental specifications for each business rule statement[2]:

(1) level of enforcement

(2) violation (breach) response

(3) violation (breach) message.

It is through these specifications that the richness of behavioral coordination can arise.


[1] Production rules (also called productions) can be used to implement business rules, but are not business rules per se.  Production rules typically provide support for action selection, which results in non-declarative statements. According to Wikipedia, a production rule system (essentially, an expert system) is …

a computer program typically used to provide some form of artificial intelligence, which consists primarily of a set of rules about behavior

Production rule systems are a class of platform whose rule format and operation are aimed toward developers.  According to Wikipedia:

“A production system provides the mechanism necessary to execute productions in order to achieve some goal for the system.  Productions consist of two parts:  a sensory precondition (or ‘IF’ statement) and an action (or ‘THEN’). If a production’s precondition matches the current state of the world, then the production is said to be triggered.  If a production’s action is executed, it is said to have fired.”

[2] Refer to “Breaking the Rules: Breach Questions” http://www.brsolutions.com/2012/06/03/breaking-the-rules-breach-questions/

Continue Reading

Time Shock, Training, and Knowledge Companions: How to Develop Smarter Workers

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 What people-challenges face your business today?  What role should business systems play? Time shock.  As the rate of change accelerates, workers are constantly thrust into new roles and responsibilities.  They must be guided through unfamiliar procedures and know-how as thoroughly and as efficiently as possible.  The business pays a price, either directly or indirectly, if getting workers up to speed is too slow (or too painful).  Time shock is like culture shock — very disorienting if you’re not prepared for rapid immersion. Training.  The flip side of time shock is training — how to get workers up to speed.  Training is expensive and time-consuming.  Yet as the rate of change accelerates, more and more (re)training is required.  Where do you turn for solutions? The foremost cause of time shock for business workers is rapid change in the business rules.  At any given time, workers might be found at virtually any stage of time shock.  Sometimes, you might find them completely up-to-speed, other times completely lost.  Most of the time, they are probably somewhere in between.  That poses a big challenge with respect to training. The only approach to training that will truly scale is on-the-job self-training.  Knowledge Companions. Such built-in training requires smart architecture, where pinpoint know-how can be put right in front of workers in real time as the need arises — that is, right at the point of knowledge[1].  What that means, in effect, is that the relevant portion of the company’s know-how — its rulebook — is ‘read’ to the worker on-line, right as the worker bumps up against the business rules. So a key idea that business rules bring to architecture is that operational business systems become knowledge companions for workers in the knowledge economy.  After all, isn’t making people smarter the whole point of knowledge?!

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