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

Q&A: What is Meant by ‘Capability’ in Business Architecture and How Does it Relate to ‘Services’ and Business Rules?

In preparation for this year’s Building Business Capabilities (BBC) Conference (http://goo.gl/6JcB9) and its new Business Architecture Summit (http://goo.gl/5hnzh), I’ve been doing some background research on how professionals in the space view ‘capability’. Here’s a good exchange I had with Alexander Samarin (http://goo.gl/DNGLp).  RGR: What is meant by ‘capability’ in the context of enterprise architecture?  Samarin: ‘Capability’ is the proven possession of characteristics required to perform a particular service (to produce a particular result, which may include the required performance). Capability needs to ‘understand’ the mechanics of delivering that service for expected demand. The mechanics include the resources, skills, policies, powers/authorities, systems, information, other services, etc., as well as the coordination of work within the service. There are three options to ensure a service has the required characteristics: 1. By contract (“re-active” approach) – acquire a service with the required characteristics, use it, check that its performance is acceptable and replace it if something is wrong with it. 2. By measurement (“active” approach) – implement a service, use it, measure it, improve or re-build it, etc. 3. By design (“pro-active” approach) – build a service model, run a simulation test, improve the model, build the service, use it, measure it, improve it, etc.  RGR: By contract do you mean ‘contract’ as a business person would understand it (legal), or as understood in object/component IT methodologies? Other?  Samarin: Legal.  RGR: By service do you mean a business service, a system service, an eCommerce service … other? All the above? Samarin: A service is a consumer-facing formal representation (i.e. explicitly-defined) of a self-contained (i.e. operationally-independent) provider’s repeatable set of activities which creates a result for the consumer. (It is considered that there are internal [even within an enterprise] providers and consumers.) It is important that the internal functioning of a service is hidden from its consumers, so that some parts of the enterprise can be changed independently. For example, a ‘proper’ service can be relatively easily outsourced. Services are expressed in terms of expected products, characteristics and delivery options (cost, quality, speed, capacity, geographic location, etc.) – this is the Service Level Agreement (SLA). RGR: How does the notion of business service apply to a company that sees itself selling widgets, not services in a conventional sense?  Samarin: An enterprise creates a result which has value to a customer who pays for this result. The enterprise acts as a provider (supply-side) and the customer acts as a consumer (demand-side). There is a (business) transaction between the provider and the consumer. From the point of view of the consumer (the outside-in view) the transaction is bounded by the pair ‘request and result’, e.g. from making an order to receiving goods. From the point of view of the provider (the inside-out view) the transaction is a set of several distinct activities (or units of work) which function together in a logical and coordinated manner to satisfy / delight the consumer. These activities are carried out in response to the consumer’s request which is an external business event for the provider. The main ‘problem’ is the coordination of activities (remember – they have to evolve). Processes, services, capabilities are, finally, the tools to improve the coordination (and the final outcome). For example, services are building blocks which are ‘glued’ by processes in bigger services. Capabilities are measures for how solid those blocks should be. RGR: In the approach you describe, how is the how-how handled? Surely know-how is essential to ensuring repeatable, ‘delightful’ results, gluing services together, etc. Samarin: As much as possible, ‘things’ (e.g. artifacts and relationships between them) should be made explicit and executable. For example, coordination of activities can be expressed in different techniques: template-based, event-based, data-based, rule-based, role-based, intelligence-based, community-based, etc. Also it should be known how to use those techniques together – similar to changing gears. RGR: Sounds a bit vague to me. Let me try a different angle. The problem with BPMN is that it is token-based. It doesn’t externalize the state of business things. But talking about the state of business things is exactly what business people want and need to do (and do informally in everyday conversation). Structured business vocabulary (fact models) is how you externalize state so business people can talk about it. Business rules are how the business encodes its know-how so as to constrain the states of things (and derive classifications) … and retain the know-how. Business processes attempt transforms and add value. Thoughts?  Samarin: You consider that BPMN is token-based, but it also provides some event-based coordination. For me, this is not a problem, but just a building block to execute some coordination techniques. I don’t think that BPMN is designed for externalizing states of business objects. You emphasize that business people want to know state. And, in addition, I am asked by business people to show them a course of actions to obtain the result and to warn them in case of potential problems. Different people have different needs.

Continue Reading

Deconvoluting EA

There is much confusion in the Enterprise Architecture space over some of the most fundamental words in the English language: what, how, where, who, when, why. I’m afraid to say there’s some very loopy thinking out there. Zachman anticipated all this and brilliantly provided six generic models for the 6 question words. Here they are roughly as follows (and possibly needing to be adjusted slightly in his new 3.0): What:  thing-relationship-thing How:  input-process-output Where:  site-link-site Who:  role-workproduct-role When:  event-cycle-event (moment-state-moment) Why:  ends-means-ends For me, it’s hard to argue that these are not what each question is about from an architectural point of view. The only thing missing is how you relate instances of the 12 elements to comprehensively configure an enterprise at any given point in time. (Zachman calls these “integration relationships”. They’ve always been there, but only on the schematic in 3.0.) IMO, the best, most dynamic (agile) way to support the ‘integration relationships’ is business rules. What could possibly be better?

Continue Reading 1 Comment

The ‘Up’ Why and the ‘Down’ Why

I had a major case of deja vu reading a recent post by Tom Graves, “The Two Kinds of Why”, at  http://bit.ly/qgJ40i #baot. I’ll tell you why in a second. Believe it or not it has to do with our business card. Zachman and I have had a continung conversation over many years about business rules and the Zachman Framework. We’ve moved forward inch by inch. You have to admire a man who is 76 years old and never tires of listening and learning. I certainly do. John has a version 3.0 of the Framework coming out very soon if not already. I can pretty much guarantee you won’t see business rules in the ‘why’ column. Graves says, “One side of Why creates a question: literally, it starts a ’quest’. For most of us, that’s the exciting bit. The other side of Why is the answer to the question, the end of the quest. That was the question, here’s the answer: The Decision. End of story.” Oh not so! Strategy should be viewed as a continuous feedback loop. You put some stakes in the ground, the ‘down’ why’, but you continuously test those ‘decisions’ to see if they hold up in the light of day. Do they achieve what the ‘up’ why (the ‘quest’) set off to achieve? We believe a conversation about strategy (both the ‘up’ why and the ‘down’ why) is exactly the one business leads are looking to have.  Our deliverable for that,  called a Policy Charter, addresses both questions, two sides of the same coin.
  • Looking down from business goals.  What are the best business tactics and business policies to achieve the business goals, and how are the associated business risks addressed?
  • Looking up toward business goals.  What is the business motivation for each of the business tactics and business policies, and why are they appropriate? 
We’ve looked at the world like this since 1996 and it’s proven highly productive in many scores of engagements. I submit to you as evidence Exhibit A below, our original business card from 1996. (I always liked it … I designed it. Obviously, I shouldn’t give up the day job!) See the intertwined why’s? Hard to miss. Finally, business rules are boring?! Not! See  http://goo.gl/0tLD3    

Continue Reading 2 Comments

Lost in Identity Limbo … Silly Rules

Gladys has started a new LinkedIn Group ‘Rules Say Must Not’. She’s looking for silly or dumb rules. I’m sure you know some — we run into them all the time! Share for the fun of it. (Prizes  offered for the best — uhm, worst — including an iPod!)   See  http://goo.gl/0tLD3  … Here’s my own first post. ~~~~~~~~~~~ A recent graduate from a top-ranked university registered for the MCAT, the gateway test to medical school. Let’s call him Jeffrey Hamilton (not his real name). Someday Jeffrey, known to all as Jeff, will make a great doctor. But Jeff made the mistake of actually calling himself ‘Jeff’ in registering and paying for the MCAT. Go figure.  Jeff knew the MCAT rules called for two forms of id. (Rule 1: A person’s name must be verified by two government-issued identity cards.) Not a problem. He had a passport and a driver’s license, both with photos and signatures. (Not great photos, but you know how id photos go.) He had not signed either one with his full name – just ‘Jeff Hamilton’.  As the date of the test approached, Jeff was talking to friends who had already taken the test. Just to make sure, it occurred to him to check whether his having registered as ‘Jeff’ instead of ‘Jeffrey’ might cause any problems.  As it turned out, big problems. The full names had to match. (Rule 2: A person’s full name must be given in an MCAT registration.) Only “Jeffrey” (the id’ed person) could take the test. ‘Jeff’ (the registered person) could not. O.K., he had messed up. So ‘Jeffrey Hamilton’ (the real person), being a poor recent college graduate, naturally asked for a refund of his registration fee (considerable for college kids). Not allowed – the rules said must not.  You would think that ‘Jeffrey Hamilton’ (the real person) had to be either ‘Jeff’ (the registered person) or ‘Jeffrey’ (the id’ed person). Since ‘Jeffrey Hamilton’ (the real person) could not take the test, he must not have been ‘Jeffrey’ (the id’ed person). So he must have been ‘Jeff’ (the registered person). But ‘Jeff’ (the registered person), couldn’t take the test, nor could he get a refund, even a partial one. (Rule 3 (presumably): A refund may be issued only if the name of registered person matches the full name on two government-issued id’s.) Bottom line: Poor Jeff was not himself. He was lost in identity limbo.

Continue Reading

What vs. How … Could We Get This Straight?

Some professionals view the interrogatives what and how as peers, each addressing a distinct area of engineering solutions (e.g., designing systems). Other professionals characterize ‘requirements’ as the what, and the design for a system as the how. Contradiction? No, just a bit of confusion over perspective. 
  • From the perspective of designing a system, both what (data) and how (processes) must be addressed. Both interrogatives (as well as the other four – where, who, when, and why) are essential for engineering a complete, robust solution.  
  • From the perspective of IT methodologies, requirements are always incomplete, so what the requirements say must be transformed into a system model that indicates how the requirements will be supported. 
In other words, the former use of what and how is based on an engineering point of view; the latter use is based on an IT-methodology point of view. Don’t confuse business people or IT professionals – or yourself – by failing to make the distinction.

Continue Reading

Business Capability … You Have to Know in Order to Do

As many of you are aware, the Business Rules Forum Conference is now one of three conferences in the annual Building Business Capabilities (BBC) Conference (http://www.buildingbusinesscapability.com/), which includes the Business Analysis Forum, the official conference of the IIBA. So Gladys and I have had to do some hard thinking about the meaning of “business capability”. Here’s our take emphasizing business … A business capability is not an application system, database, set of use cases, enterprise architecture, or any other IT artifact. Its design and implementation might depend on some or all of those things, but that’s a different matter.  Instead, a business capability is created as a business solution to an operational business problem. That solution and the problem it addresses have a scope (definite boundaries) that can be identified in terms of what business items make it up. The business solution is initially developed and expressed as a business strategy (a Policy Charter in our methodology, Proteus).  The business model you create in business analysis is the business architecture for the business capability, a blueprint enabling business people and Business Analysts to engage in a business discussion about what needs to be created, managed, operated, changed, and discontinued. Developing a business solution using a business model does not necessarily imply software development, but if software development does ensue (and it usually does), the business model provides a solid grounding.  Our definition of business capability comes down to this: What the business must know and be able to do to execute business strategy. The part that many people miss is what the business needs to know. Quite simply: How can you really ‘do’ without knowing what your business rules are?

Continue Reading

Well If You Ask Me …

… And somebody did recently: What’s wrong with current business process management (BPM) practices?  1. When a discipline becomes mature, it stops seeing itself as a solution to every problem. BPM is not there. Limitations?
  • It does not provide the order-of-magnitude improvement in business agility that companies need urgently.
  • It is not the solution to compliance issues.
  • It does not effectively provide for massive customization or personalization.
BPM needs to recognize and accommodate peers: business strategy, business rules, business vocabulary, business decisions, and business events.  2. Words matter. Well-defined business vocabulary is not a luxury or an option. It’s fundamental to effective business orchestration. Ultimately, it’s all about business communication, whether person-to-person or automated. I don’t think BPM really gets this. 3. The business world today is already in a knowledge economy (read: know-how economy); the milestone has been passed. We need to start acting and practicing accordingly. You certainly can’t get there with only BPM.

Continue Reading

Rules in a Knife Fight?! Classic Advice

The other night I watched the movie Butch Cassidy and the Sundance Kid for about the 50th time. It’s a highly entertaining movie – all you have to do is suspend judgment.  As a rules person, the classic scene for me is Harveychallenging Butch to a knife fight (with a knife about the size of a machete) for leadership of the gang. Now Butch is the one who’s always thinking. Stalling for a bit of time he walks an angling path toward Harveyand says, “No, no, not yet. Not until me and Harvey get the rules straightened out.” Harvey, thrown off guard, says (paraphrasing), “Rules?! There are no rules in a knife fight!” Well, exactly! Poor Harvey pays for his moment of verbal clarity with a challenge-ending reminder that, well, there are no rules in a knife fight.  In SBVR terms, Harveyexpressed an advice, a non-rule. If Harvey had been a rule analyst (doubtful) he might have said: “Any action is permitted in a knife fight.” The statement is not a rule because it removes no degree of freedom. Butch, always thinking, complied completely.

Continue Reading

AttainingEdge Seminar: Business Rules and Decision Analysis: Hands-On Workshop (2-Day Seminar)

Location:  Toronto, Canada You’ll walk away from this rapid-paced, hands-on workshop ready to develop easy-to-understand business rules for your company in the form of decision tables, unambiguous sentences, or some combination of both, whatever is best-suited for the purpose. You will gain an immediate boost in productivity through sharper analysis and communication skills, both for the business side and the IT side. Here’s how you can take business analysis to the next level of capability. This seminar demystifies business rules and prepares you to capture them in a wide variety of circumstances. It reviews many dozens of real-world examples and templates, many of which you can adapt to your own work. You’ll be prepared with pragmatic techniques to capture and formulate business rules separately from business process models and other kinds of requirements. Everything presented is reinforced via hands-on workshop problems. New to this seminar is the very latest on decision analysis. Proven techniques are presented to identify and analyze decisions in the day-to-day operations of the business and to capture and organize the related business rules in optimal fashion using decision tables. Your intuitive understanding of decision tables will be fined-tuned and made ready for rigorous, effective and smart application. This workshop also demonstrates how to develop smart Q&A dialogs as part of system requirements. Based on business rules and decision tables, these structured dialogs guide users in directed fashion to provide the exact information needed to make each decision correctly. In addition, since the underlying decision logic is highly organized and accessible, the dialogs can be refined rapidly as new insights are gained during actual business operation. This round-trip, business-driven approach not only produces dramatic improvements in system design practices, but also results in a highly dynamic, highly agile work environment. Now the business can learn from its own experience and continuously make itself smarter. More information: http://www.attainingedge.com/Business_Rules_and_Decision_Analysis.php

Continue Reading

AttainingEdge Seminar: Business Rules and Decision Analysis: Hands-On Workshop (2-Day Seminar)

Location:  San Francisco, CA You’ll walk away from this rapid-paced, hands-on workshop ready to develop easy-to-understand business rules for your company in the form of decision tables, unambiguous sentences, or some combination of both, whatever is best-suited for the purpose. You will gain an immediate boost in productivity through sharper analysis and communication skills, both for the business side and the IT side. Here’s how you can take business analysis to the next level of capability. This seminar demystifies business rules and prepares you to capture them in a wide variety of circumstances. It reviews many dozens of real-world examples and templates, many of which you can adapt to your own work. You’ll be prepared with pragmatic techniques to capture and formulate business rules separately from business process models and other kinds of requirements. Everything presented is reinforced via hands-on workshop problems. New to this seminar is the very latest on decision analysis. Proven techniques are presented to identify and analyze decisions in the day-to-day operations of the business and to capture and organize the related business rules in optimal fashion using decision tables. Your intuitive understanding of decision tables will be fined-tuned and made ready for rigorous, effective and smart application. This workshop also demonstrates how to develop smart Q&A dialogs as part of system requirements. Based on business rules and decision tables, these structured dialogs guide users in directed fashion to provide the exact information needed to make each decision correctly. In addition, since the underlying decision logic is highly organized and accessible, the dialogs can be refined rapidly as new insights are gained during actual business operation. This round-trip, business-driven approach not only produces dramatic improvements in system design practices, but also results in a highly dynamic, highly agile work environment. Now the business can learn from its own experience and continuously make itself smarter. More information: http://www.attainingedge.com/Business_Rules_and_Decision_Analysis.php

Continue Reading

Our Clients

[cycloneslider id="our-clients"]