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/HXxN1f What 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. ~~~~~~~~~~~~~~~~~ www.BRSolutions.com

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[1]. The first two of these techniques are:

• Structured business strategy. See: http://www.brsolutions.com/2015/05/31/basics-for-business-architecture-1-structured-business-strategy/

 

• Business processes and business rules. See: http://www.brsolutions.com/2015/06/02/basics-for-business-architecture-2-business-processes-business-rules/

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[2] 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.[3] Did you know that?! ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

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[1]. The first of these techniques is structured business strategy. See: http://www.brsolutions.com/2015/05/31/basics-for-business-architecture-1-structured-business-strategy/. The second technique is business processes and business rules. Effective business solutions require architecting both the following:

• What is done to create value-add (business processes).
• What ensures value-add is created correctly (business rules).

Many professionals are unclear about the respective roles of business processes vs. business rules. At the risk of stating the obvious, let me make the following points.

1. Business processes and business rules are different. They serve very different purposes: A business process is about doing the right things; business rules are about doing things right.
2. There is no conflict whatsoever between business rules and business processes. In fact, they are highly complementary. Each makes the other better. If they don’t fit hand-in-glove, somebody is simply doing something wrong.
3. You need both. Neither can substitute for the other. Period.

~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

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[1]. The first of these techniques is structured business strategy. True business solutions of any size or description hinge on strategy. Not project or IT strategy – not business case or project objectives – but real business strategy. Are you sure you really know the difference? Time and time again I find that many business analysts don’t. Here are two quick tests. Test 1. Are you aware of the standard The Business Motivation Model (BMM)[2]. Have you actually read it? If not, I’d say the issue is in doubt. Real strategy is about ends and means, not about change or how you plan, design or engineer such change. Change is inevitably involved of course – but that’s what projects and project plans are about. Test 2. Which of the following is closest to your thinking about alignment?

• IT needs to be aligned with the business.
• Business capabilities need to be aligned with business strategy.

If you instinctively went with the former, again I’d say the issue is in doubt. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

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

I was asked to explain why Business Architecture in 75 words or less. Here’s my response (in only 65 words). Agree? Disagree? Can you do better? Your feedback most welcome! ~~~~~~~~~~~ Business innovation coupled with massive digitization is the hot topic in business circles far and wide. The challenge in transforming the organization, however, is that the complexity is far too great, and involves far too many players, to hold in any one person’s head. The need for explicit architecture thus arises – not IT architecture, but ones suited for capturing relevant aspects of the business itself. www.BRSolutions.com

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

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.

I asked: What is a Business Capability? How Do Business Rules Relate? The Missing Man in Business Capabilities? http://goo.gl/JLLdx Guest Post by Ralph Whittle, independent consultant This is a most interesting topic, but one I fear will NOT yield answers to your questions. Considering all of the LinkedIn “capability advocates” who have actively participated in other various discussions, why have they NOT responded to your posting during its six months listing? Perhaps the “capability advocates” have realized that they can respond to your posting, but ONLY with indeterminate comments, and these are NOT real answers! At the end of their typical response, you will still NOT have the very much needed “guidance (aka business rules)” you mentioned, just more imponderable opinions!  I too, wish to see the formally accepted “guidance (aka business rules)” on capability modeling and mapping, along with some real industrial strength examples. Abstract examples are good, but they need to be supported with real ones. Where are the seminal documents, articles and research papers from any historical capabilities related archives, which describe how capabilities are designed and developed? Since capability modeling and mapping are usually associated with the Business Architecture, where is the analysis of the approach that was used to determine that capability artifacts meet specific architecture criteria? For that matter, where is the formally documented and accepted capability modeling and mapping, ontology and metamodel? Surely these documents exist, but where are they?  Maybe as in your posting, my questions may get responses, but not answers!

A reader of my blog observed that rulebook management often faces the same organizational challenges as business architecture. So true. Some 30,000-foot thoughts about why it’s so hard so get organizations to adopt them …

1. John Zachman says enterprises (organizations) are the most complicated things ever invented by humans. Now I can think of some things that are pretty darn complicated … say nuclear weapons … but ultimately they reduce to mathematical equations. Businesses don’t. He’s probably right.

2. We’ve been at automating enterprises for how long? Say 50 years? Only one generation. Our generation (well, mine anyway). There might be a few things we haven’t figured out yet?!

3. The power of computers has increased faster than our imagination about how to use them. Add to that the huge inertia faced in changing the current skill base (much less the current legacy portfolios themselves) and it all adds up to … a gigantic logjam.

And that’s where we sit today. Management feels pain, but they can’t diagnose the real sources of the pain. IT knows … well … IT. The economics of the current scheme no longer produce real value except at the edges of operations (e.g., analytics, social media, etc.). And the current infrastructure is no longer scalable or sustainable cost-wise. Logjam. But what happens in a logjam? Pressure builds up and eventually it bursts. So let me repeat my prediction made a few posts back … and add that something equivalent will eventually happen for business architecture.

>> In the long run the whole equation will change. The fundamental problem lies with the fact that business rules still have to be programmed. (Even production rules are programming.) Take programmers out of the business of implementing rules, put business analysts and skilled writers in their place (with appropriate tools), and the current economics of rule management (and IT as a whole) can be improved by at least an order of magnitude. At least!

Entrepreneurs will eventually see the opportunity. (I just hope some of them are in North America.)