Fiore’s Virtues of Business Intelligence

In the late 1300s and early 1400s, Fiore de’i Liberi was a knight, a diplomat, and a fencing master. He also wrote one of the most comprehensive treatises on medieval combat, his Flower of Battle, of which four copies survive in museums and private collections today. Fiore started – or was a significant evolutionary step in – one of the most important and long-lasting traditions in armed and unarmed combat.

In addition to detailed instruction on fighting with dagger, longsword, spear, and other weapons, Fiore’s manuscript included a preface with information about the virtues that any fencer[1] would need to be successful in combat.

MS_Ludwig_XV_13_32r.jpg

In the image above, Fiore pictures the seven blows of the sword, and his four virtues, each represented by a different animal[2][3]:

This Master with these swords signifies the seven blows of the sword. And the four animals signify four virtues, that is prudence, celerity, fortitude, and audacity. And whoever wants to be good in this art should have part in these virtues.

Fiore then goes on to describe each virtue in turn:

Prudence
No creature sees better than me, the Lynx.
And I always set things in order with compass and measure.

Celerity
I, the tiger, am so swift to run and to wheel
That even the bolt from the sky cannot overtake me.

Audacity
None carries a more ardent heart than me, the lion,
But to everyone I make an invitation to battle.

Fortitude
I am the elephant and I carry a castle as cargo,
And I do not kneel nor lose my footing.[4]

Step back and read this again: “And whoever wants to be good in this art should have part in these virtues.”

That’s right – Fiore was documenting best practices, 600+ years ago. And although I suspect that Fiore wasn’t thinking about business intelligence projects at the time, I do believe that these virtues are just as relevant to the slicing and dicing[5] we’re still doing today. Let me explain.

Prudence – “…I always set things in order with compass and measure“: A successful BI practitioner knows what needs to be done before a project can begin, and when additional work is required before they can get started. Initiating a project requires careful setup and planning, and moving before the prerequisites for success are in place can be disastrous.[6]

Celerity – “I… am so swift to run and to wheel that even the bolt from the sky cannot overtake me:  Business requirements change day to day and hour to hour. To succeed, a BI practitioner must be prepared to move quickly and decisively, engaging without delay when an opportunity presents itself – and also be prepared to change direction as the needs of the project change.

Audacity – “…to everyone I make an invitation to battle:  Any project declined presents an opening for another practitioner, another team, another tool, and this is likely to reduce opportunities over time. Saying yes to difficult projects – and succeeding in their execution – is necessary to ensure that future projects don’t pass you by.

Fortitude – “And I do not kneel nor lose my footing: When Fiore speaks of fortitude, he does not speak of the strength that comes from big muscles. He speaks of the strength that comes from structure, and balance. His “elephant with a castle on its back” is a perfect metaphor for a BI solution delivered quickly and confidently because of the solid and stable platform on which it is built. Success doesn’t come from the extra effort put in when delivering a solution – it comes from the care and planning that went into the overall data estate.

You may look at these virtues and see contradiction – how can you have prudence and audacity and celerity? The answer for BI is the same answer that it is for the sword: practice, training, and preparation. In both situations, whether you’re battling with an armed foe or battling with a difficult client, you need to apply the right virtues at the right times, and to understand both the big picture and the day to day steps that produce larger successes. In both situations you’re also facing complex and dynamic challenges where you need to quickly take advantage of opportunities as they arise, and create opportunities when they don’t appear on their own[7]. Fortunately, as BI practitioners we can rely on the strengths of our teams – it’s not always a solo battle.

You may also look at these virtues and see Matthew stretching to make the most tenuous of analogies work, just because he loves swords as much as he loves BI. While this may be true, I do honestly believe that these virtues do apply here. Over the past 20-25 years I have seen many projects succeed because these virtues were embodied by the people and teams involved, and I’ve seen many projects fail where these virtues were absent. This isn’t the only way to look at success factors… but at the moment it’s my favorite.

In closing, I’d like to mention that this post marks one year since I started this blog. In the past year I’ve published almost 90 posts, and have had roughly 50,000 visitors and 100,000 page views. Here’s hoping that by applying Fiore’s virtues I’ll be able to make the next year even more productive and more successful than the year that has passed.

Thanks to all of you who read what I write, and who provide feedback here and on Twitter – I couldn’t do it without you.


[1] Fencer in this context meaning someone who fights with swords or other edged weapons, not the Olympic-style sport of fencing that a modern reader might picture when reading the word.

[2] As translated by Michael Chidester and Colin Hatcher.

[3] Although it may not be obvious to the modern reader, the animal at the bottom is an elephant with a tower or castle on its back. I suspect that Fiore never actually saw an elephant.

[4] In case these terms don’t immediately have meaning, prudence == wisdom, celerity == speed, audacity == daring, and fortitude == strength.

[5] See what I did there?

[6] I assume that Fiore’s use of the term “measure” here is pure coincidence.

[7] If you’ve worked on a high-stakes, high-visibility BI project where requirements changed during implementation, or where not all stakeholders were fully committed to the project goals, this will probably feel very familiar.

Is self-service business intelligence a two-edged sword?

I post about Power BI dataflows a lot, but that’s mainly because I love them. My background in data preparation and ETL, combined with dataflows’ general awesomeness makes them a natural fit for my blog. This means that people often think of me as “the dataflows guy” even though dataflows are actually a small part of my role on the Power BI CAT team. Most of what I do at work is help large enterprise customers successfully adopt Power BI, and to help make Power BI a better tool for their scenarios[1].

As part of my ongoing conversations with senior stakeholders from these large global companies, I’ve noticed an interesting trend emerging: customers describing self-service BI as a two-edged sword. This trend is interesting for two main reasons:

  1. It’s a work conversation involving swords
  2. Someone other than me is bringing swords into the work conversation[2]

As someone who has extensive experience with both self-service BI and with two-edged swords, I found myself thinking about these comments more and more – and the more I reflected, the more I believed this simile holds up, but not necessarily in the way you might suspect.

This week in London I delivered a new presentation for the London Power BI User Group – Lessons from the Enterprise: Managed Self-Service BI at Global Scale. In this hour-long presentation I explored the relationship between self-service BI and two-edged swords, and encouraged my audience to consider the following points[4]:

  • The two sharp edges of a sword each serve distinct and complementary purposes.
  • A competent swordsperson knows how and when to use each, and how to use them effectively in combination.
  • Having two sharp edges is only dangerous to the wielder if they are ignorant of their tool.
  • A BI tool like Power BI, which can be used for both “pro” IT-driven BI and self-service business-driven BI has the same characteristics, and to use it successfully at scale an organization needs to understand its capabilities and know how to use both “edges” effectively in combination.

As you can imagine, there’s more to it than this, so you should probably watch the session recording.

ssbi and swords

If you’re interested in the slides, please download them here: London PUG – 2019-06-03 – Lessons from the Enterprise.

If you interested in the videos shown during the presentation, they’re included in the PowerPoint slides, and you can view them on YouTube here:

For those who are coming to the Microsoft Business Applications Summit next week, please consider joining the CAT team’s “Enterprise business intelligence with Power BI” full-day pre-conference session on Sunday. Much of the day will be deep technical content, but we’ll be wrapping up with a revised and refined version of this content, with a focus on building a center of excellence and a culture of data in your organization.

Update 2019-06-10: The slides from the MBAS pre-conference session can be found here: PRE08 – Enterprise business intelligence with Power BI – Building a CoE.

There is also a video of the final demo where Adam Saxton joined me to illustrate how business and IT can work together to effectively respond to unexpected challenges. If you ever wondered what trust looks like in a professional[5] environment, you definitely want to watch this video.

 


[1] This may be even more exciting for me than Power BI dataflows are, but it’s not as obvious how to share this in blog-sized pieces.

[2] Without this second point, it probably wouldn’t be noteworthy. I have a tendency to bring up swords more often in work conversations than you might expect[3].

[3] And if you’ve been paying attention for very long, you’ll probably expect this to come up pretty often.

[4] Pun intended. Obviously.

[5] For a given value of “professional.”

Sword Fighting as Software Metaphor: Demos

I participated last night in The Sword Experience. This is a delightfully fun event organized as part of Microsoft’s annual “Giving” campaign, and I was very happy to donate to support a great cause and spend 3+ hours pretending to sword fight with actor Adrian Paul[1] and a bunch of like-minded Microsoft employees.

5dm43258.jpg

I can’t wait to do it again, but there were a few things that bothered me, especially when Mr. Paul “corrected” my footwork during some of the warmup exercises. I’ve spent much of the last four years studying various historical martial arts[2] and practicing them as a full-contact combat sport, and footwork, balance, and structure are the foundation of all of that. Damn it, man, I know how to do this the right way, and you’re trying to make me do it wrong!!

Sigh.

Of course I didn’t say this, and of course it would have completely missed the point if I had. The event was about stage combat and fight choreography, not about actual sword fighting. Even though the two things may look the same from a distance, they have fundamentally different goals.

And this got me thinking about software demos, and how they relate to building production software. These things look similar from a distance as well, but they also have fundamentally different goals.

In an actual sword fight, you want to make small, fast movements that can’t be predicted, and which make contact before their threat is recognized. You want the fight to be over immediately and decisively. In a stage fight, you want to make large, easily visible movements that are clearly expressive of threat, but which are not actually presenting one. You want the fight to last for a long time, and to be interesting to observe.

When building production software, you want to make a solution that is secure, that performs well, and that is easy to maintain and extend. The structure of your solution, and the processes used to deploy and support it, reflect these goals. Typically you do not optimize production software around its ease of understanding, and instead invest in training new team members over time.

When building a software demo, you want to make a solution that is easy to understand, and that communicates and reinforces the concepts and information that are the foundation of the demo. The structure of the demo is simplified to eliminate any details that do not directly support the demo’s goals, even at the expense of fundamental characteristics that would be required in any production system that uses the concepts and technologies in the demo.

A demo tells a story that reflects the reality of a production system, but deliberately glosses over the complicated and messy bits – just like a choreographed fight reflects the reality of an actual fight, minus all the violence and consequences.

You can learn from stage combat, and you can learn from demos. Just don’t mistake them for the real thing.[3] [4]

And now it’s time for me to go cut something with a real sword, just to make sure the things I practiced last night don’t stick around…

IMG_20181020_153015.jpg

Isn’t that a sight just overflowing with promise? Like an empty Visual Studio solution, where anything is possible…


[1] Yes, the guy from the Highlander TV series. That guy.

[2] For a great introduction to this topic, check out this short video. This video is how I discovered that HEMA was a thing, and I never looked back.

[3] I was hoping to incorporate the YouTube trope “will this martial art work on the street??” into this post somewhere, but I didn’t find a place where it fit. Maybe next time.

[4] In both situations, don’t be “that guy.” Don’t be the guy who complains about how a demo isn’t “real world” because it isn’t production ready. And don’t be the guy who complains that the stage combat moves you’re being shown aren’t martially sound. Seriously.