Let’s put you on the hot spot. You are forced to agree or disagree with the following statement, and defend your answer. What would you say?
Deep subject matter expertise is irrelevant for a business analyst, especially in agile business analysis.
Here’s how I answer: I disagree. How about you?
My reasoning: Actually I agree that deep subject matter expertise is generally irrelevant for a business analyst. Where I disagree (strongly) is that it’s especially true for agile business analysis.
Agile business analysis is no silver bullet. It doesn’t imbue you with magical powers to learn faster. Failing faster to learn faster is simply churn. There’s no end to it.
We’re missing the big picture. Exploring ‘deep subject matter expertise’ you’re not familiar with is a matter of having the right architectural tools to probe knowledge. It’s that deep operational business knowledge that makes subject areas hard.
So you simply need the right architectural techniques to map the knowledge of a domain explicitly. You need to be able to ask probing questions about the domain intelligently without wasting SMEs’ time.
The architectural techniques you need are true business rules and concept modeling (structured business vocabulary). By the way, business rules and concept models can be made to work equally well for both agile and waterfall – and anything in between.
Mark Your Calendar: The annual Building Business Capability (BBC) conference is November 6-10, 2017 at the Loews Royal Pacific Resort, Orlando, FL. The BBC is the place to be for professional excellence!
Definitions of business terms with subtle IT or ‘data’ bias are an anathema to effective communication with business partners. Good business definitions are oriented to what words mean when used by real business people talking directly about real business things.
Here are 5 basic criteria for great business definitions:
It should be easy to give examples for the thing defined, but there should be no counterexamples.
Each definition should communicate the essence of what a thing is, not what it does, how it’s used, or why it’s important.
The definition of a thing should focus on its unique characteristics.
Each thing you define should be distinguishable from every other thing you define using the definition alone.
Each definition should be concise and as short as possible without loss of meaning. A definition should be readable.
One thing may surprise you about great business definitions. The very first noun in each definition is absolutely key. These first words are the secret sauce of excellent business definitions. Read more in our new Primer (free download).
There’s a high premium on knowing how to craft great definitions. Every business analyst should know how. We’ve just published a new Primer on creating business definitions (see below – free download).
There are various schools of thought about how to define terms, some arising from professional terminologists and academia. But those approaches are often relatively arcane and not well-suited to everyday business practice.
So you should stick with common dictionary practices. They are perfectly adequate for your needs. By ‘dictionary’ I mean natural language dictionaries of course, not any kind of dictionary arising from IT (e.g., data dictionaries).
If you want to talk about how data is retained or exchanged, do a data model. A good data model has definitions too of course, but they subtly relate to fields and data types, not directly to things in the real world. That bias throws them off-center for business communication. This implicit mindset is often hard for those with a data or IT background to unlearn. But not impossible! If you fall into this category, our Primer will teach you how.
Our new Primer is organized as a set of guidelines, each with one or more examples. Each guideline can be understood on its own, but the overall set is mutually supportive and comprehensively interlocking. Master this set of guidelines and your definitions are guaranteed world-class.
John Zachman says you can (and probably should) develop each of the following three kinds of artifacts to “excruciating level of detail”.
1. For the business management’s perspective (row 2), a conceptual model (roughly CIM in OMG terms).
2. For the architect’s perspective (row 3), a business logic design (roughly PIM in OMG terms).
3. For the engineer’s perspective (row 4), a class-of-platform design (roughly PSM in OMG terms).
Because each is a different kind of model, there is a transform from one to the next. One implication is that it is possible to make a clear distinction between analysis (CIM) and design (PIM). Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That’s wrong.
A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It’s about communication.
A logical data model is about how you organize what you think you know about the world so it can be recorded and logically manipulated in a systematic way.
I started my career in data. It took me as much as 15 years of intense work on business rule statements (1990-2005) to fully appreciate the difference. But now I am very clear that concept models do need to be developed to excruciating level of detail in order to disambiguate the intended business communication. Most businesses don’t do that today. They jump in at data design (conceptual, logical or even physical). And they unknowingly pay a big price for it. By the way, a good concept model can be readily transformed into a first-cut logical data model – just as Zachman says.~~~~~~~~~~~~~~~www.BRSolutions.com
How does legality work with business rules?To say that differently how should an intelligent tool work so as to help you establish the business regimen you want to follow where legality is involved?Consider the example of Same-Sex Marriage. Let’s suppose you want to make it illegal.SBVR does not have an innate concept/approach for “legality” in the sense of MWUD 1: attachment to or observance of law. So if you wanted “is legal” in the most direct sense, you must define a unary verb concept for the concept Same-Sex Marriage. In a looser sense, if you are in an organization (business) with the standing to define business rules, you could do several things, as follows. (I’ll make up a bit of vocabulary here.)1. Specify a behavioral ruleA behavioral rule is one that can be potentially violated by people or organizations. The relevant rule might be expressed as follows:
The people united in a marriage must not be of the same gender.
Then you would decide how strictly you want to enforce the rule. Options range from strictly enforced to guideline.The rule would be active when a relevant state of affairs arose (i.e., specific people get married).2. Define several definitional rulesA definitional rule is one that cannot be violated; it exists to ensure the consistency of the concept system you chose to follow. Relevant definitional rules might be expressed as follows:
The people united in a marriage are not to be of the same gender.
The people united in a same-sex marriage are to be of the same gender.
See the conflict? Your friendly intelligent tool would (immediately) disallow one or the other specification. The rules are clearly in conflict; the logical conflict would simply not be allowed to stand.
3. Define the relevant definitions
Marriage: the uniting of people of different genders in wedlock
Same-Sex Marriage: the uniting of people of the same gender in wedlock
Again, your friendly intelligent tool would (immediately) disallow one or the other specifications. The definitions are clearly in conflict; the logical conflict would simply not be allowed to stand.Actually, under the covers, approaches 2 and 3 work exactly the same way In SBVR. SBVR recognized that some people prefer to do things via rules, some with definitions, and if truth be told, most times you will do some of both.~~~~~~~~~www.BRSolutions.com
Semantics of Business Vocabulary and Business Rules
Guest Post by Markus Schacher
We should first agree on the semantics of underlying concepts and only then start to think about the best terms for those concepts.
One particular technique I often apply in such cases is the following:
1. Name controversial concepts with proxy names such as “Greg”, “Mike” or “John” (or whatever name you prefer) to get potentially misleading names and their implicit connotations out of the way of progress.
2. Draw a concept diagram showing those concepts as well as important semantic relationships among them.
3. Formulate intensional definitions for each concept – still using the proxy names. Ensure that those definitions are consistent with the relationships shown on the concept diagram.
4. Identify one or more communities that “baptize” those concepts by giving them better names.
If synonyms and/or homonyms appear among those communities, that’s just how the world is; we simply have to live with it. This is why SBVR formally supports semantic communities as well as speech communities.
Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php
Get it on Amazon: http://goo.gl/HXxN1fWhat It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide.
Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ
New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3.
OMG released version 1.3 of SBVR (Semantics of Business Vocabulary and Business Rules) last month – comprehensively reorganized for approachability, but not changed. Some thoughts …
Ever hear the conversation that three baseball umpires once had? If you don’t live in a baseball country, it’s an archetypical story, so you’ve probably heard some variant. By the way, in American English a ‘pitch’ is a throw of the ball for the batter to try to hit, not the field of play. Meanings matter!
The first umpire says, “Some pitches are balls and some are strikes. I call them as they are.”
The second umpire says, “Some pitches are balls and some are strikes. I call them as I see them.”
The third umpire says, “Some pitches are balls and some are strikes. But they aren’t nothing till I call them.”
Most modeling techniques primarily focus on modeling the real world as it ‘really is’. They essentially take a first-umpire point of view or maybe second-umpire. I come from that tradition too. My 1987 book Entity Modeling was about doing that … modeling the real world as it ‘really is’. Pretty much all professionals with some IT background come from that world.
Working with business people and business rules for the last 25 years, however, has taught me that business is really more of a third-umpire world. Think of laws, regulations, statutes, contracts, agreements, terms & conditions, policies, deals, bids, deeds of sale, warranties, prospectuses, citations, complaints, receipts, notices … and business policies.
Even businesses that deal with tangible stuff (e.g., railroads, electrical transmission, infectious diseases, etc.) live in a third-umpire world. And many of the most automated organizations around have no tangible product at all (e.g., finance, insurance, government, etc.). They really exist only in a world of words (between people).
It’s humbling to realize that the way the business world ‘really is’ is more directly the product of words exchanged by the players in a conversation game than anything IT professionals can model directly. But why would it be otherwise? Do IT professionals really know better than business owners, business managers, lawyers, engineers, subject matter experts, etc.? Really?!
SBVR, in contrast to almost all other standards, doesn’t try to model the way the real world ‘really is’. Instead, its focus is on modeling what is said about the way the world really is. It’s fundamentally a third-umpire standard. You simply have to understand what the words mean – and that’s a human-communication issue.
Yes, the SBVR world view is a game changer. It also happens to align closer with some of the most exciting new work in computerization today including cognitive computing and machine learning.
I stand accused by peers in the standardization community of wanting to go beyond the ‘capture, exchange and production of information’. Sure, I can live with that.
Professionals should always focus on business solutions first, then and only then on designing systems. Not just lip service, I mean applying the power techniques of true business architecture. The first two of these techniques are:
The third technique is structured business vocabulary – a concept model.
The value-add companies produce today is based on rich operational business knowledge. No business solution can prove truly effective if business people (and the tools they use) are unable to communicate about that knowledge clearly. Who profits from operating in a Tower of Babel?
A concept model is about identifying the correct choice of terms to use in business communications (including statements of business rules) especially where subtle distinctions need to be made. A concept model starts with a glossary of business terms and definitions. It puts a premium on high-quality, design-independent definitions, free of data or implementation biases. It also gives structure to business vocabulary.
Essential for any true architecture is stability over time. Are the core concepts of an operational business stable over time? Yes. Did you know that?!
When you show business people class diagrams or data models, you’re not really talking business. Class diagrams and data models are design artifacts that inevitably focus on how knowledge about real-world things is to be represented (and manipulated) as data in machines. If we want business people to talk business to us, we must talk business back. That means talking about their words, concepts and meanings. To do that you need to develop business vocabulary in a structured way – i.e., develop a concept model.Practitioners are slowly starting to ‘get’ this. Examples:
IIBA’s recently released Business Analysis Body of Knowledge (BABOK) version 3 devotes a new section to concept models.
A solid standard exists for concept models – OMG’s Semantics of Business Vocabulary and Business Rules (SBVR). Version 1.3 of the standard, comprehensively reorganized – but not changed – is due out this week.
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“Sessions flow together well and build upon the concepts for the series which makes the learning easy and better retention.
The instructor is knowledgeable and very attentive to the audience given the range of attendees skill and knowledge of the subject at hand. I enjoy her training sessions.”
Deborah – American Family Insurance
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”