Why Analysis and Design are Inseparable
The traditional axiom in business analysis that there should be a “Berlin Wall” between analysis and design is being torn down these days. Several authors and thought leaders are arguing that you cannot do analysis without designing and that you cannot design without analysis. This article is striving to visualize why this is really so.
1. Reports from the Demolition Site
The wall between business analysis and business design is tumbling down:
Figure 1 Picture provided to WikiMedia Commons by the German Federal Archive. Photographer Hartmut Reiche, 1990.
Here follow some quotes from “the demolition team”.
David Morris, a NZ-based BA practitioner, speaker, author and blogger has written an excellent blog post with the title ”We Are All Designers Now” (Morris 2013):
” … Now, let's move on from having established a future state process. Next we look at how the future state will be supported by roles. This is often where we get involved in organisation design. Perhaps those roles imply a change in responsibilities, perhaps they don't currently exist and imply the standing up of a new team, or more extremely, suggest a restructure. Sure as heck, we are designing something.” (Morris, 2013).
John Bauer commented on (Morris, 2013) like this:
”An interesting article and discussion. As business analysts we should not be concerned with being accused of designing -- It is one of the biggest value-adds we provide! If we are not designing creative solutions we're merely taking orders.”
Tony Heap, BA practitioner and blogger from the UK provokes even more with his blog post titled ”There’s No Such Thing as a Requirement” (Heap, 2013):
“The things we call requirements are actually all just aspects of the proposed business change. I prefer to label them as aspects of the design of the business change, because I believe that the process of generating options and selecting a preferred option is a process of design. Labeling these things as requirements discourages the considering of alternatives. … Requirements are Designs” and continues:
“Some business analysts point out that the difference between requirements and design is that business analysts do requirements and designers do design. This implies that business analysts don’t, or shouldn’t, consider options and make recommendations. And I have met many business analysts who work this way. In my view this is badly wrong. Business analysts should work with stakeholders and technical people to consider options and select a preferred approach. One of the problems with BABOK v2 is that it doesn’t make this clear.” (Heap, 2013).
Tony Heap’s blog post attracted a lot of highly qualified comments. For example, Steve Blais (well-known BA practitioner, author, speaker and blogger) comments:
“I agree in general with the concept and find the article well written and logical.” And: “One of the discussions when including more ‘design’ in our definitions of business analysis work is the line of demarcation between the business analyst and the systems analyst or architect (just including the word brings the controversy). There will be a major resistance from the technical analysts who will claim infringement. There has been over the years continuing border disputes between the business analyst and system analyst. … Perhaps a better approach would be to change everything to ‘design’ and then change the names of the roles to ‘business idea analysts’ and ‘technical solution analysts’.”
In my book (Frisendal, 2012) I use the metaphor of a (building) architect facing a transformation job (renovating something). That is essentially what we do a lot of the time. Analysis (inspection) is bound to find stuff in need of re-work and holes to be filled. That is why design is obviously an issue even when looking at as-is. (Which can be rather ill defined in many cases). Add to that that as-is is really also a design, albeit an old one.
Delivering value is also thing, which is a design issue. In fact, validity is driving designers all over the spectrum of design activities. So, analysis and design must go together in one process (at least if you want the business people to participate, and you do). That is what much of my book (“Design Thinking Business Analysis”) is about.
Another dimension, which is frequently overlooked, is the difference between “business design” and “solution design”. Let us look at a fictive example: “A part of our new business model for XYZ is that we want to provide the customers with self-service ordering and payment possibilities”. That is clearly a business design. And it can be supported by one or more IT solution designs spanning from a classic web-shop over reselling web shops to smartphone payment solutions of various kinds.
In the following chapters we will deconstruct analysis and design and try to identify the “shapes” of the different “configurations” of such activities.
This leads to interesting “matching of shapes” in order to “cluster” the various approaches – see towards the end of the article.
2. The Six Dimensions of Analysis & Design
First let us have a look at the ”dimensionality” of analysis and design. The focal areas most relevant to A&D activities are – in my opinion: Business Ownership, People, Business Design, Information, Process and IT Design.
2.1. Business Ownership
”Business Ownership” is obviously very important. However, the degree of involvement and ownership varies quite a lot across the different ”sub-cultures” of A&D. Take, for example, the data modeling contexts. We have not been particularly successful in business ownership and participation there – in particular when we are talking about what used to be known as conceptual modeling. There is definitely a lot of room for improvement there. True business participation is difficult to obtain. I propose that new methods and techniques are necessary in order to get true attention and participation from the business (Frisendal, 2013).
Lack of Business Ownership / Participation is a significant quality risk factor. Many failed projects (not least BI-projects) suffered from that decease.
2.2. People
The People dimension is also somewhat under-cultivated. I would like to see more psychology and less engineering in analysis and design. Just like you don’t show prospective flat owners the detailed construction drawings and the static calculations of the building. Why then do we show business people UML Class Diagrams? People are not all rational and we need to talk to the intuition, gut feelings, deep-felt concerns, habits and so forth.
Not caring about the people aspects may well be a serious threat to the project.
2.3. Business Design
The term ”Business Design” may seem unfamiliar to some. What I mean is something that happens within the business organization, and which essentially is an extension of the business model down to the lower levels of detail. It concerns both what and how, but it is not necessarily focused on IT solutions. Unless you are bleeding edge, IT is pretty much commoditized these days, anyway.
Business Design is the next Business Analysis, as I try to ”prove” below.
2.4. Information
Business information is a major constituent of the What question. It is scope defining and yet it is ill defined in many methodologies. Not the IT data models, mind you, but the business information in and by itself. The What side is primarily concerned with structure and definitions. And the ”structure” is – from a business point of view – the content of the business information, which is in scope at that time.
Detailing the information structure is frequently left to (IT) data modelers, but it is a core business analysis activity, if you ask me.
2.5. Process
Supporting business processes with IT solutions is what we are good at. It has been the major focus area of business analysis and IT development for many years; swim lanes and use cases all over the place. Lots of quality analysis and engineering has been very successful. (And some not, but that is another story).
However, seen from the business perspective, bias-cut focus on process (vs. information) is unbalanced and could stand in the way of paradigmatic changes.
2.6. IT Design
Although agile approaches have loosened up IT development considerably over the last years, IT solution design is still pretty much an engineering activity. At times I wonder whether there is still an element of the old (original?) uncertainty and awe about how to deal with this wonderful technology? But surely, we have come a long way already.
IT solutions are enablers of business; they are not the targets of anything else than a development project.
Let us move on to deconstruct popular A&D paradigms with respect to the “dimensions” above. Let us try to “shape” the alternatives.
3. Analysis & Design Paradigms
3.1. The Complete Picture
In this (somewhat un-scientific) research of various aspects of A&D I am using a radar chart built on the dimensions described above. What each of the chart diagrams illustrate is the “level of involvement” with each of the dimensions; based on my judgment and bias, of course. Please disagree and let me know about it!
I am comparing Classic Business Analysis, Information-Driven Business Analysis, Business Development, Business Design, IT Development, Design Thinking, Validity Thinking and Reliability Thinking. Explanations follow…
The radar chart below is everything on one page and is very crowded indeed. Towards the end of the article, you will find an interactive version of it!
Let us examine each of the contending approaches.
3.2. Classic Business Analysis
Traditional Business Analysis is focused on supporting business processes with IT solutions. The aim is to deliver a specification, which is solidly right before people start designing (detailed models and application modules). On the information side the level of detail is overview, not detailed and not business oriented but project oriented. Major entities are named and data models are simple.
The business and people involvements are not as high as they could and should be. Many BA’s find it up hill to get the necessary information from key resources and get the priorities set. And most BA’s are not thoroughly trained in the softer skills needed such as psychology.
Business redesign and renovation are outside of scope – many projects are driven by decisions made elsewhere to support some business process(es) with some IT.
In short classic Business Analysis is an extension of IT into ”business land” staged by IT contexts, not by business changes. (I guess I will get a few comments on this….)
3.3. Information-Driven Business Analysis
Information-Driven Business Analysis is the analysis and design process, I describe in my book and elsewhere (Frisendal, 2012, 2013).
Many business development initiatives today are information-heavy: Business intelligence / analytics, big data, federation of information by way of semantic technologies etc. In such contexts business information is the focal point. Understanding, defining and probably renovating the structure and content of the business information “body of knowledge” is the major deliverable of a business analysis project. The scope is the information structure necessary to design valid solutions for running the business in new ways, as well as supporting reliable and repeatable information syndication to various information consumers in the organization.
The latest version of the business information model is found inside people’s heads, so Information-Driven Business Analysis is a people-intensive series of brainstorming workshops mixed with data (structure) analysis and (data) prototypes. Creativity on the fly is encouraged and the flow is that of the design thinking approach to business design.
3.4. Business Development
In this context “business development” is meant to be the activities, which are generated by business development initiatives within an organization. Business development by itself is a lot more than analysis and design. All the planning, financial considerations, marketing strategies etc., etc. eventually lead to activities, which are in scope for the business analyst. Typically because they involve analysis and design of business information structures (contexts) and business processes.
Framing the new business approach is mostly a matter of defining the new context. Which is why information structure and definitions are businesswise more important than actual processes, which – by the way – more often than not are multi-channel these days.
This leads to the shape that you see in the diagram above.
3.5. Business Design
“Business Design” is a category I use to denote the context for getting businesses to change and adapt in new ways. Obviously, it is business owned and business driven and it relies heavily on both explicit and tacit knowledge, which resides mostly in people’s heads. Information is the context-king and is more important than business processes and, consequently, IT systems design.
Personally I would like seeing someone develop a true business-level process paradigm, which is independent of the nature of the supporting IT, if any. But maybe such a business process model already exists. Anyway, business processes are subject to frequent changes and IT is replaceable. Business design as a discipline is emerging and needs a robustness that makes the designs long lasting.
3.6. IT Development
“IT Development” is here understood in the narrow sense: a business analysis proper has defined and scoped a solid IT project of essentially technical / engineering nature.
These days business ownership moves upwards (thanks to SCRUM and agile).
For historical reasons (by tradition is maybe also correct) there is a firewall between business design and IT development. The focus is on support of defined business processes and the information necessary for those processes. (Which by the way possibly neglects some information not relevant for IT but important to the business anyway).
3.7. Design Thinking
I have mentioned “Design Thinking” a couple of times, and I thought that it would be pedagogical to draw the shape of that – as it is relevant to business analysis.
In my interpretation it is a business owned design type of activity focused on people and information (context) with not too much emphasis on actual processes.
The aim is to achieve business solutions, which are valid – and thus make good sense to groups of people such as customers, employees, agents and partners and so forth.
Processes are, of course, also objects of design, but the aim of a good process is predominantly reliability, ensuring robust operations of the company and steady income.
Information structure contributes context and meaning and is distilled by way of people brainstorming (information-driven business analysis in my terminology).
Cf. Roger Martin’s book (Martin 2009) for pertinent information about Design Thinking.
3.8. Validity Thinking
I have included “Validity Thinking” as a category as well. However, unsurprisingly, it is much the same shape as Design Thinking. We are talking business design of e.g. new product(s), do. categories, sales channels, business models and so forth.
3.9. Reliability Thinking
“Reliability Thinking” is the “other side of the coin” (opposed to validity-driven design thinking). As you can see below, it “clusters” with IT Development and Classic Business Analysis (good, really). Information-wise the focus is on the operational running of the business – meaning typically aggregated information and key performance indicators.
When looking at processes, reliability analysts look for process cost optimization and shorter time (to market, for instance). Reliability-driven business design looks at high yield areas, competitive issues and the like (with influence on the bottom line).
I strongly encourage you to read Roger Martin’s book The Design of Business (Martin, 2009) for a good discussion of validity vs. reliability.
4. Shape Matching
Combining the shapes leads to interesting ”conclusions” (if you agree with my premises).
Let’s us see, how they cluster together.
Note that you can use the interactive version of the chart, which is found below, to make your own combinations and investigations.
By clicking on the legends you can select and deselect each of the diagrams in order to look at them individually or in combination.
4.1. BA Classic, IT Development and Reliability Thinking
Fortunately things look good when we combine Classic Business Analysis, IT Development and Reliability Thinking. We have done something right! We are able to design and deliver IT solutions supporting business processes, which reliably help management produce results, quarter after quarter.
But (there it is, the inevitable but towards the end), we have cut some heals and toes:
-
We (who came with an IT mindset) have left Business Ownership and Business Design somewhat isolated, becoming a DIY activity for business planners / developers
-
The same goes for the true involvement of the business people
-
And the business information structure and definitions have been treated as secondary to the purpose of establishing IT support of business processes
4.2. Information-Driven BA, Business Design, Business Development and Design Thinking
Enter the design thinking, soft-skilled, information-driven business analysts of today and tomorrow:
The Validity side of the house gains importance - for the reasons Tim Browne stated back in 2008 in Harvard Business Review (Browne 2008): “... as economies in the developed world shift from industrial manufacturing to knowledge work and service delivery, innovation’s terrain is expanding”.
The business design focus is overwhelmingly important in a globalized competitive environment.
4.3. BA Classic, Information-Driven Business Analysis, Business Design and Validity Thinking
Finally, let us have a look at how Classic Business Analysis matches shape with the validity-focused analysis and design activities:
Classic Business Analysis supports the process development really well. But there is a need for structured activities on the business side. Much more than previously anticipated, one might say.
I propose that the business takes control of the softer parts of this universe of discourse and gets support for the more technology-driven development activities from IT specialists.
It is no secret that I am biased toward information-driven business analysis. I am so, because it fulfills some very strong requirements:
-
Context is king and context is information, not process
-
Involve people and rely on their knowledge
-
The Business must have the ownership and must drive the development
-
Valid design of business is of essence.
4.4. Analysis & Design – Yin and Yang?
Most of the times when you hear BA’s (and other people operating on that turf) use the term “design” they mean “IT systems design”. That is very much part of the reason for the legendary “Berlin Wall” between analysis and “design”.
However, design today has the business critical significance meaning “design of business” (for instance as defined by Martin, 2009). And that kind of design is clearly not improper conduct in a business analysis context, today.
☯
In fact, it seems to me that (business) analysis and design are as interwoven as Yin and Yang in the classic Chinese metaphor (as I understand it). Yin is the Business Design, Business Ownership, People and Information. Yang is Information (again), Process and IT Design.
Yin is the Validity = business changes. Reliability = process performance drives the Yang.
To reuse David Morris’ “We are all Designers now”: What are you? A Business Designer or a Process Support Designer? Pick you choice!
Author: Thomas Frisendal
Thomas Frisendal is an experienced business information analysis consultant with more than 35 years on the IT vendor side and as an independent consultant. He excels in the art of turning data into information and knowledge. It does not happen by itself. Since 2005 he has specialized in business analysis and concept mapping as well as design of business intelligence solutions. His approach, ”Information-driven Business Analysis” is the ”New Nordic” approach to business analysis. He has excellent professional experiences from 25+ projects. 1999-2011 he was external lecturer at the University of Nice. In October 2012 he published his first book, "Design Thinking Business Analysis" on Springer. Thomas Frisendal is a member of the IIBA, TDWI Denmark (board member), Danish IT, The Danish Management Board, IAIDQ (charter member) and The Cognitive Science Society.
References:
Brown T (2008), Design Thinking. In Harvard Business Review (hbr.org), June 2008.
Frisendal T (2012), Design Thinking Business Analysis: Business Concept Mapping Applied. Springer.
Frisendal T (2013), Humanizing Business Analysis, ModernAnalyst.com, May 2013, last accessed September 17, 2013.
Heap T (2013), There’s No Such Thing as a Requirement, personal blog, http://www.its-all-design.com/theres-no-such-thing-as-a-requirement/ , last accessed 2013-08-20
Martin R (2009), The Design of Business - Why Design Thinking is the Next Competitive Advantage, Harvard Business Press (Kindle edition).
Moon BM, Hoffman RR, Novak JD, Canãs AJ (2011), Applied Concept Mapping – Capturing, Analyzing and Organizing Knowledge. CRC Press, Boca Raton
Morris D (2013), We are All Designers Now, Business Analyst Times blog, http://www.batimes.com/articles/we-are-all-designers-now.html, last accessed 2013-08-20