Many companies in the financial sphere maintain a large collection of different applications, each application interprets aspects of the business and provides a functional solution to real world needs. Often these applications also provide a vocabulary and a model to help different departments understand and communicate ideas. Ideas change and develop as the business grows, new processes often get modelled on spreadsheets, taking advantage of the inherent flexibility, but then many of these spreadsheets become essential parts of the day to day running of the business and never get migrated to enterprise capable applications.

This was the situation I discovered back in 2003 when I first joined as VP of a hedge fund business in London. Things have changed a lot since those days but some of the fundamentals still remain. Complexity is still inherent in the system, try to define an underlying investor and the edge cases will defy all but the most flexible model. Flexibility is of course where spreadsheets excel, but the cost of maintaining such solutions outside of the core applications is obvious. Accounts start to become more interpretive than definitive. Back then I invested a lot of time in trying to envisage the ideal solution, an application with more flexibility than a spreadsheet, because it would need the ability to grow with the business, while at the same time able to include enterprise capabilities such as maintainability, compliance, multi-user functionality, RBAC security, etc.

Many times, I have gone back to this seemingly impossible task and I have worked iteratively on ideas to produce a solution that I now hope is both simple and powerful. Of course, being of a technical nature, my ability to describe even a simple idea may not be what it should. I have called my application Entity Account Modelling (EAM), think of the entities as being small focused accounts models that integrate to make the larger platform.

EAM provides a new type of solution; it is not a fixed application; it presents a foundation system on which you can build your own structure with an almost Lego® like simplicity. This new concept shifts responsibility to the system creators to understand the business processes and to model them effectively, in return it provides a system that is always under your control. Changes to the system are simple to implement, cost free (if performed by the administrator) and can be introduced in phases to suit the needs of the users. EAM is designed to grow with your company. Solutions represented on spreadsheets can be recreated with EAM to benefit from the secure multiuser access and a better integrated environment, keeping the calculations closer to the source data.

Diagram/Illustration 1.00 Showing how a new entity can be built from the available components.

EAM is based on the latest technology to provide the best Modelling environment possible. It has a drag and drop display with both two dimensional and three dimensional views. EAM provides templates for most of the entities you might wish to model, but the power of the system comes from being able to customise these existing templates, or create new ones; these are the building blocks. You can then add relationships to further define the structure, you can group the blocks to categorise them and you can add workflows to instruct them to perform simple or complex tasks.

The graphical presentation of the data is designed to make complicated financial patterns easier to see and understand (if a picture paints a thousand words). It also goes further to help the user to see and understand the underlying structure of the business. It encourages good business practice and communication by allowing the experts in all areas to collaborate on the construction of the models and processes.

The flexible integration inherent within EAM actually makes it possible to use it to connect previously disparate systems. Both the data inputs and outputs can be shaped to allow almost any data feeds to be connected. The data structure within the system is expandable, secure and can be easily automated.

Typically the initial stage of implementing EAM involves a meeting of key personnel in a company along with an EAM practitioner, to document and agree on the list of departments and the responsibilities of each department. The group then need to propose the set of entities that will be modelled and discuss the different functionality required from these models by each department. A fictional fund management company will be used to describe the application. For the purposes of the description the company is extremely simplified. The company has the following departments:

• Client Relations and Marketing. This department is responsible for marketing to new and existing clients, servicing existing clients and performing regulatory checks on new clients.
  
  
• Client reports. Produce monthly as well as ad hoc reports for clients.
  
  
• Data Input. Feed new data into the system.
  
  
• Accounts. Calculate fees and process money entering or leaving the system.

The second stage is to build these departments and business entities in EAM and publish them for peer review. For example the model of the Investor would be built by dragging a base object from the toolbar and then dragging properties onto it. For a very simple model, for this demonstration, the properties might consist of.

• 'Name', a simple input box.
  
  
• 'Address', a set of input boxes with predefined functionality.
  
  
• 'Status', this would be a link to a group of user defined status objects.
  
  
• 'Nationality', this would be a link to a group of user defined country objects.
  
  
• 'Invested', each base object can contain transactions to and from the object. This property would derive its value from the balance of transactions and would be set using a formula.

Each property can contain rules to require a value as simple text or as a relationship to a specific group as in the case of 'Status'. A property could also derive its value from the value of other properties, for example 'Invested' could derive its value from two other properties, the sum of all transactions made minus the sum of all transactions received. Properties can also be linked to workflows, for example the 'Status' field may trigger a list of events when it is set to 'Potential Client', the events could require the 'Client Relations and Marketing' department to request information from the client to verify their eligibility to invest. The receipt and input into the system of all the required documentation could trigger the 'Status' property to change to 'Existing Client' and the sending of confirmation to the client to allow them to invest.

Templates do not have to model whole entities but can model features that will be used by other templates that share the same functionality. Judicious use of this feature will mean that changes will only have to be made once and in one place.

Once these models are built, reviewed and agreed upon, they can be published to the data input team to use.

Stage Three - Entering the object data.

Stage Four - Entering the transaction data.