Business Language

I've been toying with a new type of architecture - or more specifically another approach to solving an age old problem of ad-hoc reporting.

The question usually goes something like this:

We need a flexible, ad-hoc reporting solution which will allow us to do what ever we want whenever we want. It has to be dynamic and easy to use, and should give us the complete power to answer any business question. But we also want the ability to create presentable formatted reports and link together any type of data we so chose.

The answers vary from business vendors like SAP Business Objects or Oracle Business Intelligence tools, to smaller vendors, to various products pieced together like SSAS cubes with SSRS reporting. But, in all cases, the solution is always lacking that flexible and dynamic nature. With all tools, there is always a heavy IT presence. Some of the tools attempt to simplify this by creating an abstraction - such as the Business objects universe concept. This is effectively a meta-model around a physical representation. But this is very limiting as it restricts the use-case to a relational structure. Cubes are a very cool technology but also very limiting and the truth of the matter is that the users care about small data sets such as current days data or even a small subset of current days data - and in a number of cases the cube becomes too burdensome.

So the alternative approach was to actually give a new language to the business user directly. Goldman did something like this with their slang language. Imagine a language which is simple enough and descriptive enough for the user's to use and lacks all the very technical details of an actual technical language like Java or C#. We should accept that user's already do a fair amount of programming with the tools at hand such as VBA, and combination of Excel/Access. At times, it is very impressive some of the things these guys produce and at other times it is quite scary.

So, let's say there is a functional language that allows the user to manipulate the various available artifacts - i.e. back-end systems. Some functions retrieve data based on the supplied parameters and other functions can perform actions like calculations or data changes. Before you know it - you've provided a set of very powerful tools and what emerges is that the users start tinkering with the functions to build more dynamic and abstract features that were not previously imagined. What I came to realize is that revolutions are slow things that require tinkering, and at some point, something emerges which could not at all be previously imagined but once created makes perfect sense and is the most natural. The user's need tools to tinker, and that tinkering actually creates tremendous value and innovation. Innovation drives investment and growth, etc...

So, back to the language. The language should of course work within Excel, but should not be restricted to excel. Ideally, we bridge the language with perhaps a more functional cousin like F# and create a natural set of functions with a pure functional language. At the heart of this language is a data set - to borrow from any database driver - a TDS class - a tabular data set. Let's say the language only understands data sets not objects. Everything is a table of data or perhaps, a table of tables. Some functions create tables and some functions manipulate tables. It is also interesting to see how the roles of systems and enterprise architectures change. Systems become components which are forced to expose "functions" which are manipulated from this functional language. This in turn forces systems to become more dynamic loosely coupled modules as it's not always known how an external function may want to manipulate the components of a given system. Looked broader at a higher level, the systems start to make up an overall platform - with the functional language acting as a glue that binds it all.

I think this approach gives the most flexibility - coupled with some of the more traditional options like cubes and canned reporting - perhaps even a vendor product. The approach of course is more technical and requires some learning but it strengthens the bond between user and system and makes a user an investor as they are now in affect developing the system - or platform. It is a wonderful thing to create something that you're proud of that adds value - that feeling can be given to the user to strengthen the bond to the platform and the overall enterprise architecture.