Agile Zero Sprint for Data & AI projects

By | Data & AI | No Comments

Agile methodologies have a patchy track record in Data & AI projects. A lot of this is to do with adopting the methodologies themselves – there are a heap of obstacles in the way that are cultural, process and ability based. I was discussing agile adoption with a client who readily admitted that their last attempt had failed completely. The conversation turned to the concept of the Agile Zero Sprint and he admitted part of the reasons for failure was that they had allowed Zero time for their Agile Zero Sprint.

What is an Agile Zero Sprint?

The reality of any technical project is that there are always certain fundamental decisions and planning processes that need to be gone through before any meaningful work can be done. Data Warehouses are particularly vulnerable to this – you need servers, an agreed design approach, a set of ETL standards – before any valuable work can be done – or at least without incurring so much technical debt that your project gets sunk after the first iteration cleaning up after itself.

So the Agile Zero Sprint is all that groundwork that needs to be done before you get started. It feels “un”-agile as you can easily spend a couple of months producing nothing of any apparent direct value to the business/customer. The business will of course wonder where the productivity nirvana is – and particularly galling is you need your brightest and best on it to make sure you get a solid foundation put in place so it’s not a particularly cheap phase either. You can take a purist view on the content from the Scrum Alliance or a more pragmatic one from Larissa Moss.

How to structure and sell the Zero sprint

The structure part is actually pretty easy. There’s a set of things you need to establish which will form a fairly stable product backlog. Working out how long they will take isn’t that hard either as experienced team members will be able to tell you how long it takes to do pieces like the conceptual architecture. It just needs to be run like a long sprint.

An Agile Zero Sprint prevents clogged pipes

An Agile Zero Sprint prevents clogged pipes

Selling it as part of an Agile project is a bit harder. We try and make this part of the project structure part of the roadmap we lay out in our Data & AI strategy. Because you end up not delivering any business consumable value you need to be very clear about what you will deliver, when you will deliver it and what value it adds to the project. It starts smelling a lot like Waterfall at this point, so if the business is skeptical that anything has changed, you have to manage their expectations well. Be clear that once the initial hump is passed, the value will flow – but if you don’t do it the value will flow earlier to their expectations, but then quickly after the pipes will clog with technical debt (though you may want to use a different terminology!)

BI User Personas – are you scaring users with the kitchen sink?

By | Data & AI | No Comments

BI User Personas are a key part of delivering any BI solution. Throughout my career I have encountered clients who have all faced the problem that their BI Solution has not achieved the adoption they had hoped for. This in turn has reduced the impact of the solution and thus the ROI. A common thread in the examples I have seen is the horrifying kitchen sink that is thrown at every user.

 The wrong BI User Persona causes some interesting reactions

The kitchen sink is scary for some!

To explain to those not familiar with the idiom, to include “everything but the kitchen sink” means to “Include just about everything, whether needed or not”. What it means in this context is that the BI solution presents so many dimensions, measures and KPI’s to the user that the experience becomes confusing, overwhelming and as a consequence – useless.

Why building your BI solution is like making a hit movie.

No Hollywood movie is ever made without considering the audience appeal – they even use predictive analytics to drive scripting decisions. So why should your project be any different? You have consumers that need to be satisfied, and their wishes must be taken into account.

A key element of our Data & AI Strategy is to ensure that the end users different needs are planned for. Constructing BI User Personas to define what level of detail gets exposed to each persona helps in this process. To stretch our analogy a little further, your executive team may only care that there *is* a kitchen sink and whether it is working or not. A management team may need to know how hot the water is and how water efficient the tap is. The analysts will need to know detailed water usage statistics over time for analysis. Not everyone needs to know the same thing.

Most BI tools allow you to provide different views of the data model so that you can tailor the output of a very complex model to users with simple needs. An executive may only need a few key metrics and dimensions in a dashboard to examine before they pass further analysis downstream. A manager may need a more complex report with interactivity to drill into an issue. The analyst may simply need access to raw data to answer their questions.

The same applies for less data literate users. If they are not technically minded they may find a much simpler model less intimidating. Data literacy is whole additional topic but with proper preparation, it can be managed and taught.

BI User Personas drive a smash hit!

Understanding your audience is essential. As part of the process of designing your solution, BI User Personas need to be defined so they get appropriately suited content.

Building and understanding the personas of your end user team is of course only part of the equation. There are many human components in a Data & AI Strategy that need to be implemented. Change management, training and ongoing communication help ensure that what you deliver is adopted, and part of the strength of FTS Data & AI is that as part of the FTS Group we can bring our stablemate Cubic in to help with this.

BI Project Success

By | Data & AI | No Comments

What makes for BI Project Success? I read with interest the results from the BI Survey 2018 – particularly its results on the subject of Success Factors in implementing BI Applications. I took particular interest in two interlinked themes, speed and competency of implementation.

Speed of Implementation

Speed is a critical part of achieving BI project success. It was very clear from the results that Enterprise BI Platforms took over 2 times as long to implement as Self Service solutions. This in itself isn’t overly surprising. An Enterprise platform is typically selected because the problem it is trying to solve is more complex. Self Service BI Solutions work excellently for targeted problem solving but in my experience struggle as the data landscape gets more complicated.

However what I thought was the most interesting finding was that the longer a program runs, the harder it is for it to deliver value. This seemed to be a universal effect regardless of project type or expected value. This led the survey takers to the conclusion – that I agree with – that smaller, more focused projects are more likely to deliver value. This is why we embrace Agile delivery methodologies at FTS Data & AI.

Competency of implementation

Tying in with speed of implementation is the competency of it. The more capable the company was in delivering BI programs, the faster they delivered – by a factor of over three times. Shorter implementations had less issues in delivery as well. This could well be a reflection of the higher competency teams delivering results more quickly and capably, resulting in better BI project success.

Implementation time by best-in-class companies in median months

Implementation time by best-in-class companies in median months (credit: BARC)

The competency was also impacted by the support from vendors and implementers. Vendor support had a big impact on project outcomes, with good support correlating well with project outcomes. This works the other way as well – poor support led to worse outcomes, so tool selection criteria clearly should look at local support. I would draw again on my comments on the Australian experience with Microstrategy, where I have had customers move away from that platform due to an inability to get local support for it.

Implementers also had a significant impact – projects with excellent partner support did significantly better than those without. It is also worth noting that the wrong choice of partner can lead to outcomes that are actually worse that using no partner at all. The survey team advised picking a specialist partner over a generalist firm – which I believe ties in to the above effect of vendor support – some vendors rely heavily on partners to deliver on their behalf (e.g. Microsoft) so when choosing a partner, a strong track record with your chosen vendor platform should be a key criteria.

They also advise road testing partners with a proof of concept. I support this approach as a successful relationship with a partner needs to be evaluated and there’s nothing quite like getting hands on together to properly evaluate their competency, commitment and understanding of your specific needs.

Takeaways for BI Project Success

My key takeaways from these survey results are:

  • Focus on smaller delivery cycles for better outcomes
  • Ensure vendor support is a key factor in tool decisions
  • If you need help, the right delivery partner will make a big difference

Microsoft Lead Gartner 2019 Magic Quadrant for Analytics and BI

By | Data Visualisation | One Comment

Hot BI news is the recently announced 2019 Gartner Magic Quadrant for Analytics and BI and Microsoft was the clear leader, driven in part without doubt by the explosive growth of PowerBI .

2019 Gartner Magic Quadrant BI & Analytics

2019 Gartner Magic Quadrant BI & Analytics

PowerBI is the story

PowerBI is advancing at a rate which its key competitors – Qlik & Tableau – are struggling to match. Further underpinning Microsoft’s lead is its ongoing investment in the underlying Azure Data & Analytics Platforms which give it an edge that competitors just can’t match.

One thing I am frequently hearing from the market is that other platforms are struggling to match PowerBI’s compelling price point – some might cynically say Microsoft are using their deep pockets to undercut everyone else. However in a recent conversation I had with a long standing Cognos customer, once they understood what the product could do – and how much cheaper and faster it would be – it drove them to reconsider their strategy.

I freely admit was initially cynical about Self Service BI a few years ago as it rapidly became transparent that for all the slickness of creating great looking reports the tools were still beholden to a clean set of well managed data. Now modern data platforms are reducing the cost and complexity of providing this data, I am now holding the position that self service BI can really deliver on its value rather than just provide a final polish to a Data Warehouse – as long as it is paired with such a platform.

I continue to maintain my (unpopular in some circles) position that Qlik has nothing unique to offer any more and is doomed to irrelevance unless it innovates or at the very least catches up with its competitors. Tableau remains a solid tool for self service analytics, but the absence of an underlying data platform is going to start hurting it before too long. I would expect it’s longevity to be tied to being acquired by someone suitably huge.

I also note the absence of any serious competition from the other two cloud megavendors. Google offers Data Studio & Amazon has Quicksight – but neither rate a mention. I would watch this space carefully as the pace of innovation by both companies is fierce and Google in particular has strong AI / ML capabilities. Both are also ramping up their own data platform services.

Outside the Big 3

If you are on any of the legacy on premise tools in the 2019 Gartner Magic Quadrant for Analytics and BI such as Cognos/IBM, Oracle or SAS then i’d be seriously considering where you go next. The pace of innovation in the cloud is hard to ignore and users risk lagging behind their competitors if they cling to these.

SAP and Salesforce have a strong story within their own source but have their weakness in using data from outside the native platform. Doing anything in SAP is horribly expensive, and my conversations with Salesforce BI users have not left a very positive impression of the tools’ capabilities.

The remainder either are strong in their niches and / or have minimal presence in Australia (Microstrategy is basically unsupported here as there’s no people doing it) so i’ll not pass comment on them.

Where to from here?

If you have reviewed the 2019 Gartner Magic Quadrant for Analytics and BI and decided you want to know more about PowerBI and the Microsoft Data Platform, we can help.

Full disclosure – FTS Data & AI are a Microsoft Gold Partner so this post is a bit biased. However if you are not using PowerBI and are looking at migrating to a more cost effective platform, want to understand how cloud capabilities are transforming data and analytics – or work for Qlik and want to lure me into a dark alley – please contact us.

FTS Data & AI are Microsoft Gold Partners Data Analytics

Microsoft Gold Partners Data Analytics

 

SSIS Integration Runtime Connectivity Testing

By | Data Platform | No Comments

SSIS Integration Runtime Connectivity Testing is hard as there is no physical Azure VM to log in to as part of the Azure Data Factory (ADF). While behind the scenes there is effectively a VM spun up there is no way to access it.

The scenario our Data Platform team faced was reasonably simple – we needed to connect to a 4D database that sat behind the Storman application that our customer used so that we could extract data for their various workloads. Because 4D is not supported by the Generic ODBC source in Azure Data Factory, we needed to use the 4D ODBC driver. This meant using SSIS to leverage the driver.

The client is well managed in terms of security so the target system can only be accessed within their network. Their Azure network was connected to theirs and properly secured, so part of the setup of the SSIS Integration Runtime in Azure Data Factory is to ensure that it is joined to the virtual network.

Houston, we have a problem

SSIS Azure Data Factory

SSIS Azure Data Factory

However, despite all this – we couldn’t get the ODBC connection to work when deployed. Due to stability issues our first suspect was the driver – after all it frequently crashed Visual Studio 2017 / SSDT and configuration was a pain. Also, initially we couldn’t connect on our dev machines as we weren’t on the clients VPN (easily fixed, fortunately). Then we had the wrong target server (again easily fixed).

Once we got on to ADF of course our debugging options got more limited as we now were having to do SSIS Integration Runtime Connectivity Testing without all the tools available on our desktops . Initially we struggled because the runtime was very slow at sharing its metadata (package paths, connection managers, etc.) so we weren’t initially sure it was even able to work with the driver. Eventually we got enough metadata to start playing with the JSON of the task to configure it. However we continued to get errors in ADF that were’t really helping.

Our breakthrough came when we remembered we could just connect to the more familiar and mature environment of the SSIS catalog that is deployed alongside the runtime. We configured the package correctly, ran it and got a more manageable ODBC error – “Cannot reach Destination server”. A quick ping from our desktops proved the server could be pinged, so as a test we used a simple package with just a script task to ping the server. This worked just fine on our desktop, but when deployed the script task reported failure.

So a quick connectivity test helped pin it down to probable network config issue. Now it’s in the Infrastructure teams hands to ensure everything is configured correctly, but at least we have (for now at least) got SSIS & the ODBC driver off the list of probable causes of the issue. It’s also taught us a few things about SSIS Integration Runtime Connectivity Testing.