From Agile to Anarchy (and back again)

Introduction

TM1 development has undergone a subtle evolution over the years.

As a relatively early adopter (I still refer to TM1 as an Applix product occasionally, and I remember the original version of TM1Web) of the technology, I’ve watched this evolution with interest, and feel what I have been doing with Flow, is an attempt to bring that evolution full circle and get back to those early glory days.

In this article, I reminisce, wax lyrical, and take a look at the present and future state of selling and implementing TM1.

Warning: this post may contain heavy doses of nostalgia!

Agile Roots

Anyone else remember a time when the typical TM1 implementation went as follows:

  • Get the client’s general ledger accounts and data
  • Write a few TIs to create the account and cost center structures, and suck in the data
  • Build some Excel reports to show the new data off
  • Hook up a few manual input templates for the tricky stuff
  • Send the users to a TM1 training course
Yes, these were simpler times, times when “Excel on steroids” was the sales pitch and demonstrating the “what-if” feature would get genuine wows from the crowd.
 
We used to sell in a couple of meetings, build POCs in hours, often while the potential client watched, and put together an entire system in weeks rather than months.
 
Perhaps we can remember them fondly, even wistfully. But, sadly, it has been a long time since I was involved in a project that simple, and I believe those kinds of projects are, for the most part, behind us.
 
Now businesses expect a full budgeting and planning application, capable of multiple scenarios and rolling forecasts, and able to collect and collate data from many disparate sources around the globe.
 
TM1 has evolved somewhat to try to meet these needs, but have we evolved as consultants?

Agile Decline

As the Agile methodology became popular in IT and software development projects, those of us in the TM1 sphere were starting to realize we were becoming less and less agile.

I recall speaking on the phone with the owner of a TM1 distributor, discussing the possibility to working with them. This must be two or three years ago now. To my surprise, he started talking about sitting with the customer on a time and materials basis, and building the model with them as they watched and participated.

Of course, I said, “you can’t work like that! We’ve got to lock down the requirements in a formal document, perform a technical design to those specifications, and restrict any modification with a formal change request process!”

It was at that point, in the back of my mind, that it hit me how much TM1 development had changed. The willingness to sit down with a customer, discuss their needs, and build a solution had been replaced with a fearful and almost paranoid IT mentality.

I realized that TM1 modelling and development had become as complex as software development projects, and had evolved to encompass the same rigid processes. The very thing that had originally attracted me to TM1 development — the freedom to build a solution without inflexible requirements — was now gone.

The Problem

So how did we lose the Agile edge that used to define and differentiate TM1 implementations? How did we go from a strong customer focus to formalization, obfuscation and general ass-covering?

The answer is simple. TM1 got bigger — and I’m talking bigger in every way.

Firstly, it was acquired by Cognos, then IBM, and was suddenly thrust into the light of big business. No longer was TM1 the surprising underdog. Now it was expected to go head to head with its enterprise-ready robust big brothers and hold its own.

Concordantly, TM1 started getting larger, more complex implementations. Pre-sales guys who had once gotten away with using the word “scalable” to mean you could add lots of RAM were now being asked if TM1 could be used in a server farm, collecting data from thousands of disparate data sources across global WANs, to calculate an entire organization’s planning, forecasting and consolidation in near real time.

And as a result of all this, we as TM1 implementors got scared. And those of us with an IT background knew exactly what to do: add more layers of process.

However, TM1 did not have the tools to support the Agile processes we were used to following. Deployment was done by manually copying files. Testing was done by manually clicking a mouse. And demonstrations to the customer were performed sparingly, as they took much time to set up and present.

Worst of all, providing any kind of workflow for the customer was embarrassingly lacking. Sure we could fire off external scripts to send out email notifications or SMSes, but the solutions were hardly robust or maintainable.

So we fell back on design and documentation as the crutch to get us through. Write reams of documentation, force the customer to sign off, then quote and build based what was “agreed”.

The fact that describing a financial model in a generic way was often more difficult than building it was neither here nor there.

Reclaiming Agile

Many old-school TM1 implementors have noticed this change, at least on an instinctive level, and tried to develop processes and methods to get back to the old ways. However, most of these were just band-aid solutions, and fell short of tools found in other areas of software development.

Watching this with frustration over the past few years led me to take a step back and look at the bigger picture and think through the problem without letting myself be clouded by prior assumptions.

Flow OLAP is the result those musings, and we hope that our partners are finding value in the tools and applications we’ve released so far.

However, this is just the tip of the iceberg. Keep giving us your support, and we promise to keep innovating until TM1 development has come full circle, and we can reclaim our Agile glory days!

Hey, I warned you about the nostalgia, didn’t I?