How to Decompose a Spotfire Project

Have you “inherited” someone else’s Spotfire project?
Has another group built a project for you and you would like to understand it better?
Would you like to familiarize yourself with other developers’ projects?
Are you in charge of modifying someone else’s project?

This post begins another series I’ve wanted to write for a very long time. The idea first came to me when I documented a large enterprise project. I didn’t build it. It wasn’t my baby, but it was important to the company. Management wanted it documented in case the author moved on. I also think about this subject every time I build a project for a user. What’s the best way to go about helping the user get a solid grasp on the project? Is there a formulaic way to decompose a Spotfire project or at least a good order of operations. Decomposing a project you didn’t build is often quite difficult and can seem like trying to assemble a jigsaw puzzle with 1,000 pieces. Where do you even start?

This blog post will introduce the series and provide a high-level context. The series itself breaks Spotfire project decomposition into 7 parts. I’ll release one post a week that includes a “quick and dirty” version, as well as an “extended analysis”. I’ll tell you where to go in Spotfire and what to look for.

What Do You Need To Know

Let’s begin with a few high-level questions. These are the questions you want to ask and answer as you move through the project decomposition. And, while reading the list, you might ask yourself — why would someone duplicate tables or leave broken columns in a project? The answer is simple. It just happens. We all have busy day jobs and cleaning up a project that works isn’t always a priority.

How large and complex is the project?
- How many tables are in the project?
- Are the tables tall and skinny or short and wide or just huge?
- Where do those tables come from?
- What do you know about those data sources?
- Are tables related?
How “clean” is the project?
- Are there duplicate columns? <see this post for an explanation of how/why this happens>
- Did the developer use a naming convention?
- Are there parts of the project that are redundant, unused or broken?
- Does it contain property controls, filtering schemes, scripts and/or other bits in pieces that were created but aren’t being used?
- Did the author duplicate tables?
- Are all of the data connections in the project for tables that are being used?
- Are all of the tables connected to visualizations or do they feed tables connected to visualizations?
- Do all of the calculations work?
- Do you have any frozen columns?
How “technical” is the project? What skills do you need to modify it?
- Does the project use data functions?
- Does the project contain JavaScript or IronPython?
- Did the author include custom SQL queries?
- Do the data functions use packages?
- Did the author input HTML or CSS code?
- Does the project make use of custom extensions?
How can this project be improved?
- Can the load time improve?
- Can unused components be removed?

Now that you know what to be on the lookout for, here is the order of the series and why that is the order.

Part 1 — Tables and Data Sources

First, we cover tables and data sources because they are the foundation for the project. You must understand this to understand the rest of the project.

Part 2 — Data Functions

Table build and data wrangling might come next, BUT data functions commonly create data tables and/or perform data wrangling tasks, so we’ll look at them second.

Part 3 — Table Build and Data Wrangling

Next, with an understanding of data sources, we’ll look at how they come together and how much data manipulation happens.

Part 4 — Document Properties

Then, we’ll look at the Edit > Document Properties menu because they can be used in columns and calcs.

Part 5 — Columns and Calculations

Now, we have a good high-level understanding of the project, so we can get into the nitty gritty details.

Part 6 — Text Areas and Scripting

Next, we review the text area, which is where many bits and pieces come together. It’s also where you’ll see more complexity and code.

Part 7 — Visualizations & Data Limiting

Visualizations are covered last because they are where everything comes together.

Before I conclude, I want to note that there is a world of possibility when it comes to how to decompose a project. Ultimately, it will come down to how complex the project is and what your purpose is with it. As I go thru the series, I will share screenshots from a very quick and dirty template I developed. It’s not all-encompassing, but it’s a good start. Please feel free to share feedback in the comments.

Julie Sebby

Guest Spotfire blogger residing in Whitefish, MT. Working for SM Energy’s Advanced Analytics and Emerging Technology team!