by Michael (Mick) Kahan |

            Recently I drafted an article on the relationship between Business Architecture and Service-Oriented Architecture (SOA). The resulting draft was pretty dreadful; a colleague said it read like a wordy PowerPoint presentation!  However, in doing the research for the article, I was able to synthesize my thoughts on “straw men”.

             There are two kinds of straw men. The first is the “run it up the flagpole and see who shoots at it”, or draft proposal kind, and the other is the “false argument” kind.

             Let's look at the first to see how it can be used both positively and negatively with Business Architecture. Business Architecture is essentially about creating and continually refining the business artifacts that allow for appropriate automation of business and technical processes. In terms of the well-known Zachman Framework for Enterprise Architecture, Business Architecture encompasses the top two rows, the Scope (contextual) row, and the Business Model (conceptual) row.

             A Business Architecture initiative will record “as-is” coarse-grained artifacts such as strategy and objectives documents, key business cycles/events, high level business processes, information flows, key resources, and so on. It can also identify  and validate “as-is” fine-grained artifacts such as semantic models, detailed business process models, work-flows, business scenarios, business use cases, business rules, and so on. Follow-on “to-be” analysis allows for the creation of updated artifacts that permit detailed business analysis to be performed to support individual automation projects.

            There's nothing wrong with performing Business Architecture straw men exercises. In business we do this all the time; we may call them “quickie” what-if studies, organizational change studies, restructuring studies, product/service change studies, trial operating plans, and so on. The resulting documents allow management to discuss and evaluate, albeit with a degree of uncertainty, the impact of changes, including changes to information technology. However, the danger is that the impacts of the studies on individuals may cause alarm if not communicated properly, especially if they indicate organizational changes, changes to accountabilities and responsibilities, and changes to career progression. The caveat is “don't set the straw man alight” by ignoring that people are key details in business-type straw men exercises.

            So now let's look at the other kind of straw man which creates a position that is easy to refute, then attributes that position to ones opponent.

            Within the IT industry, SOA is the “next big thing” and, consequently, it attracts very vocal advocates who have published many, many supporting articles. It was while reading these that I was able to classify three sub-types of this kind of straw man.

            (By the way, I'm not picking on SOA.)

            The first sub-type is the “old paradigm ?? new paradigm” argument. Invariably, this consists of a list of old paradigm phrases with their matching new paradigm phrases, for instance, “tightly-coupled distributed systems ?? loosely coupled distributed systems”, and “technical focus ?? business focus”. I dislike this approach because, first, it make me feel old  and  curmudgeonly, second I don't get to select the contents of the old paradigm list, and finally the track record of many  IT paradigm shifts  has not been  stellar (you can create the list of failures, if you want). Besides, I think the phrase “we tend to overestimate the short term impact of a new technology, and underestimate its long term consequences” nearly always holds true.

            The second sub-type is the 2 X 2 matrix. As elucidated in the book  “The Power of the 2 x 2 Matrix, Lowy & Hood; JOSSEY-BASS”, the 2 x 2 matrix can be a very powerful diagnostic tool for management, strategists, marketers, consultants, etc. Depending on the context, the vertical and horizontal axes come in related pairs such as importance versus urgency, cost versus benefits, new markets versus old markets, and so on. The entities or parameters under evaluation are positioned in one of four squares, the top right square typically being, but not always, the place to be!  It's pretty easy to understand how the matrix can be misused as a straw man – who gets to select the axes and where's the detailed positioning analysis?  Typically, the reader will see the matrix used to position vendor products against emerging architectures, standards, or marketplace acceptance.

            The third sub-type is the product comparison chart, where a vendor's offering is compared, feature by feature, with its competitors. The obvious concern here is the choice of features, the choice of competitors, and the levels of conformance to the features.

             There is a fourth sub-type that is more an incomplete argument than it is the creation of a false position. This is, of course, the product/strategy/architecture endorsement by a leading light (analyst) in the industry, or by a senior customer or business partner. Here the challenge is to acquire the complete picture – the extent of the initial problem, the detailed business case, the validated before-and-after business and technical results, and the long term consequences.

            From a senior management perspective straw men are a nuisance. They add to the “noise” in the IT industry and can contaminate the perceived value of a new idea or paradigm shift.  In their worst embodiment they can lead to the acceptance of an idea that does not stand the test of time but still becomes a “brand”. Most often though with straw men, early adaptors and the marketplace “flush-out” and validate or reject the issues revealed by them.

             Personally, I’m a skeptic, not a cynic, and, as a result, I can nearly always extract some useful information from a “false position” straw man.

© 2014 Intervista Inc.

<back to Executive Education main page

Executive Online Program

As an innovation leader or a professional, managing change is a fact of life. Our executive program will put the resources at your finger tips to help your team manage the future faster.

Innovation Boot Camp
San Jose, CA | June 3-4, 2015
New York, NY | Sept. 16-17, 2015
Empower your team with this on-site session. Ideal for teams responsible for product and service innovation.

Business Architecture
Strategies for transformation and innovation.

Services Innovation for the
Public Sector
In this 2-day interactive session, your team will develop innovation and design thinking capabilities.

Day 1
1. Challenges of business agility
2. Evolving the enterprise
3. Fundamentals of enterprise models
4. From strategy to Business Architecture
5. Managing the transformation portfolio

Day 2 & 3
1. The power of reference models
2. Analysis of business goals
3. Modeling for a client-centric world
4. Organizational design for Business Architecture
5. Creating a shared understanding
6. Lifecycle analysis
7. Modeling business processes
8. Capturing policy and business rules
9. A world of disintermediation
10. Achieving the adaptive enterprise