When To Use The IBM Planning Analytics REST API (And When Not To)
For its ability to streamline and automate enterprise-wide planning, budgeting and forecasting processes, IBM Planning Analytics has many fans. Organizations of every size and in every industry – including high-tech companies in Silicon Valley, financial services institutions and government agencies – rely on this AI-infused, algorithm-based solution to create financial plans, forecast disruptions, improve decision-making, and achieve strategic business goals. Many enterprises also leverage it to optimize their Financial Planning and Analysis (FP&A) operations, as well as for Sales and Operations Planning (S&OP). And thanks to its advanced scalability, flexibility and fast performance, others also use it for Extended Planning and Analysis (xP&A).
Planning Analytics is built on the powerful multi-dimensional TM1® server technology, and comes with two out-of-the-box user interface (UI) options:
- Planning Analytics for Excel aka PAfE: An Excel add-in to build sophisticated, multiple-query reports against multiple databases
- Planning Analytics Workspace aka PAW: A browser-based dashboarding tool that enables users to identify and understand patterns in data, make better predictions, and improve business decision-making
Most users create wonderful planning applications using a combination of these UIs. But some companies, particularly those with larger development teams, reject this idea outright, preferring instead to build their own internal planning and analysis UIs from scratch using the TM1 REST API. While this is not necessarily a bad idea – after all, the REST API is a great way to extend the solution’s capabilities as needed – organizations do need to exercise caution if they start down this particular yellow brick road.
What can organizations do with the REST API and IBM Planning Analytics? 
What can’t they do with it?
When should they use the REST API?
And most importantly, when should they refrain?
Here are the answers!
Using TM1 REST API with IBM Planning Analytics
The TM1 REST API allows external applications to directly access server objects. Unlike previous TM1 APIs that were not designed for inter-operability in a Cloud-centric architecture, the REST API returns standard JSON objects, which can be easily manipulated in most programming languages. Moreover, almost all administrative aspects of the TM1 server can be easily handled with the API.
End-user consumables like dashboards, reports and other internal user interfaces can be created using the REST API as the connection to TM1. However, the API itself is not end-user ready, so these solutions need to be custom-built in other languages like HTML or Python. The other option is to build these applications on top of PAW which uses the REST API to connect to TM1 in the back end.
But does this mean that every organization must custom-build their planning and analysis solutions from the ground up, using the REST API?
In most cases, the answer is No.
When Not to Use the REST API
Often, companies that custom-build their own internal consumables in IBM Planning Analytics with the REST API, do so with very little prior planning or strategizing. In fact, most don’t even have a fair understanding of the key business imperatives driving their need for planning and analysis in the first place!
Another problem is that developers often lack the right techno-business perspective to build customized planning solutions that can yield long-term value. Without the required knowledge of and experience in financial or operational planning, these techies underestimate the complexity of what’s involved in building customized applications. They also don’t realize that it’s very difficult to accurately determine the scope of a planning application because its requirements are often fluid and tend to change rapidly, either due to changing business conditions, or because the business strategy itself is evolving.
Due to all these challenges, the development endeavor can become very expensive, and ultimately lead to failure – no matter how many hours or dollars are thrown into the ring. Moreover, the story doesn’t end with custom development. Once down this rabbit hole, the organization is also on the hook to maintain the application. In addition to the effort involved, this also raises the solution’s Total Cost of Ownership (TCO) in the long run.
A classic example of the “build vs buy” conundrum!
The Best Way Forward: without the REST API
QueBIT recommends starting with the built-in tools in IBM Planning Analytics and focusing on solving the overall business problem. This is a departure from the “let’s custom-build everything” approach that a lot of companies take.
So rather than getting caught in the cosmetics of the UI, it’s better to explore the different ways of getting there, while staying within the parameters of the built-in PAW and PAfE interfaces. Only when a requirement arises that cannot be satisfactorily met with PAW and/or PAfE should businesses explore the REST API to build their own end-user consumables. In our experience, very few customers need to go this far, because PAW and PAfE provide almost everything required to extract maximum value from IBM Planning Analytics.
In summary, don’t reinvent the wheel unless absolutely necessary!
