Consolidation is not the same thing as integration.  What does it really take to integrate business practices?  Let me illustrate with a thought experiment. Imagine that the U.S., Canada, Cuba, Jamaica, and Japan were completely closed societies.  However, to invigorate their sports, each allows one visitor for one day each century to bring a new game idea. For the 1800s, baseball is chosen.  Abner Doubleday arrives in each country, and talks about bases, runs, strikes, balls, innings, and all the other things of baseball.  At the end of the day he leaves.  Nobody knows what happens until the next visit, a hundred years later. As it turns out, each country has embraced the game enthusiastically, and each now has a century of competitive results. So taken are the countries with the game, they express a desire to merge their results, and to begin an international league.  A commission is chartered for that purpose and hires business architects. The initial results are promising.  Each country uses the same nouns (i.e., bases, runs, strikes, batters, etc.), and many of the same verbs (e.g., “run is scored in inning”).  A data model emerges that meets general approval. Then the trouble begins.  Not surprisingly, substantial differences have arisen over a hundred years in how each country plays the game.

• In Japan, a batter loses so much face after one strike (not a foul ball) he is immediately retired.
• In Canada (being a tolerant country), an unlimited number of strikes per at-bat is permitted but, to compensate, only two outs per inning.
• In Cuba (being a socialist country), strikes are charged to the pitcher, rather than to the batter.
• In Jamaica (suffering from earlier British influence), only two bases are used, the ball is bowled, ‘pitch’ refers to the playing field, and games may continue for two days.

Can the results be merged?  Yes and no.  Because they are based on the same words, they can be consolidated (lumped together).  However, because each country plays the game differently, they cannot be integrated (compiled meaningfully). What does it take to achieve true integration of business practices?  Without common standards for how the game is played, integration is impossible. To play ball you need business rules and a shared rulebook.

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

	Interrogative	Basic Business Question	Kind of Model
1.	What	What inventory of things needs to be managed to support business activity?	structural model (e.g., concept model[1], data model)
2.	How	How do transforms of things in business activity need to take place to add value?	process model
3.	Where	Where does business activity occur?	network model
4.	Who	Who collaborates with whom to undertake business activity?	interaction model (e.g., organizational chart, use case)
5.	When	When does business activity take place?	temporal model (e.g., schedule, event model, milestone model)
6.	Why	Why are results of business activity deemed appropriate or not?	strategy model (e.g., Policy Charter[2], constraint model)

  If your business does nothing but manufacture or produce physical widgets (forget all the meta-data about those widgets), you will probably emphasize question 2 (i.e., process) above the others. Your overall approach and architecture will reflect that. You will naturally gravitate toward BPM. That tendency has at least three basic risks, even for organizations that do fall into the nothing-but-widgets category:

• Your metrics will largely focus on process productivity (e.g., throughput, bottlenecks, latency), rather than strategic goals and alerts centered on external risks. E-suite executives tend to be much more focused on the latter.
• Your mindset will be procedural, rather than declarative, which can cause you to embed business rules in process flows rather than externalize them. As a result your process models will be unnecessarily complex and your overall solutions un-agile.
• You approach will fall woefully short in addressing the intellectual capital that underlies your processes. Such operation business knowledge ranges from simple meta-data, to the business logic that underlies operational business decisions.

Fewer and fewer business problems these days fall into nothing-but-widgets category. Even for widget-centric businesses, at least three needs are increasingly urgent:

1. Ensuring the quality of meta-data.
2. Demonstrating compliance based actual rules, rather than the artifacts and effects that IT systems produce.
3. Retaining, teaching and repurposing intellectual capital.

These are not strengths of common BPM practices. ~~~~~~~ Read more about the future for processes: What is the Future for Processes? http://www.brsolutions.com/2015/11/09/what-is-the-future-for-processes/ Are Processes and BPM Relevant in the Digital Economy? http://www.brsolutions.com/2015/10/19/are-processes-and-bpm-relevant-in-the-digital-economy/ Measuring Quality and Defects in the Knowledge Economy: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ Quality and Tolerances in the Knowledge Economy: http://www.brsolutions.com/2015/10/29/quality-and-tolerances-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com

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

The point of knowledge (POK) is a real place. POK is where know-how – business rules – are developed, applied, assessed, re-used, and ultimately retired.  In other words, POK is where business rules happen. When you start to fully understand business rules, a whole lot of other pieces of the puzzle fall right into place.  You arrive at smart architectures, which gives you smart knowledge management and smart processes. In smart architecture, business systems become knowledge companions, enabling never-ending, on-the-job training.  Flash points of knowledge – real-time evaluation of business rules – enables dynamic processes and personalized, just-in-time delivery of up-to-date guidance. A smart architecture is one equipped to address the formidable challenges facing businesses today – the accelerating rate of change, massive customization, and products and services that are ever richer in knowledge.  Effective engineering of the POK is the new litmus test for agility. The question you should be asking: How do you get your company to the point of knowledge? ~~~~~~~~~~~~~~~~ Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php www.BRSolutions.com