As everyone will be aware, we currently hold the percentage ownership of certain asset types for SIPPs where the members own a distinct proportion of the asset.  Our intention has always been to build upon this as part of the re-platforming project and extend it to all asset types.

Going forward the ownership records will not only record the percentage owned by each member at the time the asset was purchased, they will also allow users to record any subsequent changes.  For example, where a property is purchased by two members of a group SIPP and a third member is introduced to the group and purchases a portion of that property asset from the existing two members then the revised percentage ownership will be recorded.  The date the change occurred will be recorded and this will then allow users to keep a history of all changes.  By recording the date of any ownership changes, any income or debts against that asset can then be split according to the ownership of the asset at that specific point in time.  In relation to property a good example of this would be in relation to receipt of rental income.

The ability to record the history of ownership percentages will be applied to all asset types held in SIPPs.  We will be keeping the distinction between group SIPPs where the ownership of specific assets is known and those group SIPPs where members do not own specific assets but have a percentage of the total group SIPP value based on receipts less payments.

We are aware that organisations can have multiple roles in relation to SIPPs and SSASs.  For example, a firm of accountants could also be the Independent Financial Adviser (IFA) to a member or an IFA could also have an investment arm and therefore also be the investment adviser.

We have chosen to revisit how this information is held in the system.  An organisation can now be created and more than one role type can be allocated to that organisation so that information about the role specific to the SIPP member or group or SSAS can be identified. 

In addition, the solution will now hold the organisation name along with a default address (or branch) and contact.  It will also allow users to enter more than one branch for each organisation and link one or more contacts to the organisation and each branch.  The advantage of this method of recording information is that where, for example, a contact within an organisation changes, it will not be necessary to ‘remove’ the organisation from the member but simply change the contact name.

We are planning that the re-platformed system will enable users to record bank accounts held in a foreign currency. Transactions will be able to be entered in the foreign currency, so for example if a deposit account is held in Euros then all transactions can be entered in this base currency.

 

There will be an ‘Exchange Rates’ table whereby users can maintain a history of exchange rates which will then mean that balances for valuations, management information etc. can be reported in Sterling. For those clients using the Price Feed Module this includes exchange rates which can be automatically fed into the system on a daily basis.

 

It is also intended at a future date to enable other assets to be recorded in a foreign currency, such as property and borrowing.

The current auditing facility has been greatly enhanced in the re-platformed system and will enable users to identify not only which fields have been changed in the system, but when (date and time), by which user and how. If there have been multiple changes to a field on a particular day then each change will be recorded rather than just the last change.

 

This functionality will cover every field on every screen and system administrators will be able to run reports showing all changes over a particular period. In addition, the planned functionality will also include recording full audit details for record deletions, so that these may be identified as well.

 

Recording these changes is one thing, but ascertaining what to then do with this information is another. At this stage, our Day 1 plans do not include roll-back or re-commit of data or records, simply a greatly enhanced audit trail so any such changes can be fully tracked and accounted for. However, we would welcome feedback from users as to whether these advanced facilities would prove useful to them for future versions.

The current search facility has been greatly enhanced in the re-platformed system. Users will be able to search against all related records in the system even when only partial search criteria, such as part of an address, is available.

Searches will be carried out by entering a query containing a series of statements such as 'equal to', 'contains', ‘less than' etc. There will therefore be the ability to create multi-layer searches again covering every field. For example this could enable a user to find every member attached to a particular adviser with a date of birth within a defined date range.

Users will have the ability to create new search criteria and save any that would be used on a regular basis.  These can accessed from the search section with ‘favourite’ searches also being accessible from the main ‘Alerts’ screen.  Any saved criteria can be amended or deleted. 

The security model for the re-platformed system will give each user the opportunity to design a structure to meet their own business requirements via the User Parameters functionality.

Individual system users will be allocated to user groups which in turn are then given access rights in the system. These range from the ability to just read data, create new records, edit them,  print or export data and extend as far as deleting records. This applies across the entire system and will enable users to give the permissions required to specific groups or individuals depending upon the requirements of their role. The access rights will also extend to specific modules within the system, such as the Payroll and Customer Invoicing Modules thus ensuring that they are only accessible to those who need to use them.

Furthermore the User Parameters will allow users to limit the permissions to specific brands within the system, so for example if there are sensitive records held such as those for a staff SIPP, it will be possible to allow access to just those staff members who require access.

The re-development of SIPP~Pro and SSAS~Pro has been broken down into a series of “releases” each of which is made up of six sprints (see What is Agile Software Development below for more background). The total number of releases is likely to be between four and six depending upon the progress made within each release.

 

Release 2 was completed on 10^th February and the attached progress document provides a summary of the content.

 

Sprint 7 included the creation of bank accounts for both SIPP and SSAS. Sprints 8 and 9 focused on the creation of contribution records including the existing SIPP bulk contribution routine and Sprint 12 incorporated the creation of customer invoices.

 

Release 3 is now underway and the Sprint 13 is dedicated to the creation of property records including re-creating and improving the existing functionality within SIPP~Pro and SSAS~Pro including property records, leases, rental invoicing, insurance and risk management.New Pro Release Progress chart - Release 2.pdf

Work is progressing well on the capped drawdown functionality in the re-platforming project.  A number of the calculation scenarios have already been completed and additional development is being undertaken in the current sprint.

Capped drawdown will continue to be calculated as it is currently and will continue to take account of any protection afforded to the member including the new ‘Fixed Protection’.  The routine will now include the automatic creation of the related Product Sales Data (PSD) 24 record.  This will only apply to SIPP members and will be created on the first drawdown event at plan level thereby doing away with the need to remember to create the records.

For both SIPP and SSAS members, where a drawdown event results in a requirement to produce an event report or an ‘accounting for tax’ record then these will also be created when placing the member in drawdown.

Flexible drawdown will follow a similar process and will allow users to operate this at plan level.  As is currently the case, It will reference the relevant ‘Minimum Income Requirement’ flag in order that users can only operate the revised calculations when the necessary information has been recorded in the member record.

The ‘Plans’ structure in SSAS~Pro and SIPP~Pro will be carried forward as part of the re-platforming.  However we have now chosen to move away from having Clusters.  The information currently displayed in the Clusters section relates to either the Plan or when a Benefit Crystallisation Event (BCE) has occurred.  In the new structure we are building, Plans will now be defined as either Pre A Day plans or Post A Day plans.  When creating a new member record, a Plan will automatically be created and it will default to Post A Day plan. 

When a member chooses to go into partial or full drawdown, information on the pension limits and review dates will now be held at Plan level – as opposed to the Cluster level where it is held currently.  Equally where Product Sales Data (PSD) records are required in relation to drawdown on SIPPs this will also be recorded at Plan level.  Going forward, we will have a separate BCE section which will hold all the information relating to each BCE that occurs.

This will allow users to see greater granularity in the information recorded for each BCE including splitting out the BCE1 – drawdown funds and BCE6 – Pension Commencement Lump Sums.  The Income Limits information as recently introduced into SIPP~Pro and SSAS~Pro will also then be recorded alongside the BCE information, allowing users to view all this data on the same screen. 

Users will also be able to record each Pre A Day (pre commencement pension) under separate Plans.  In addition, transfers in drawdown will have their own Plan created, thus continuing to meet the definition of recognised pension transfers.  This will ensure that Plan values will continue to be ‘ring fenced’. 

The re-development of SIPP~Pro and SSAS~Pro has been broken down into a series of “releases” each of which is made up of six sprints (see What is Agile Software Development below for more background). The total number of releases is likely to be between four and six depending upon the progress made within each release.

 

Release 1 was completed on 4^th November and contains a significant amount of the core infrastructure of the system including security and user access levels, creation of schemes, brands, members and the underlying parameter data tables such as GAD rates, interest rates and SMPI rates.

 

The final sprint of this release, sprint 6, was used as a “hardening sprint”, in order to consolidate the work done to date. This first release will then enter a testing phase to isolate bugs and coding issues which are then addressed and actioned in subsequent sprints.

 

Please refer to the attached document for a summary of the content of Release 1 and its underlying sprints.New Pro Release Progress chart - Release 1.pdf

Having taken on board the feedback users have provided in the recent past, when we set out to build the process for creating a new member record it was agreed that it should be more process driven and give you more control over both how, and just as importantly, what data is entered into SIPP~Pro and SSAS~Pro.

 

When a new member is created and allocated first to either a SIPP or SSAS (and then to an underlying brand in SIPP~Pro), the system now leads the user through a robust wizard process to create the new member record. All mandatory fields are highlighted and must be completed before the user can move onto the next screen.  They also contain validation appropriate to the content; for example the format of National Insurance numbers must conform to DWP standards. This means that you have greater control over the quality of data that is being entered into your system.

 

At the end of the create new member routine, the user is presented with a summary screen to review and confirm all information entered, prior to completing the process.

From Q3 of 2011, the re-platforming project has been progressed separately within Delta with its own dedicated project team, consisting of both existing Delta staff and additional resources from our development partners, NTT Data (formerly Keane, Inc.).

In the initial phase of this project, Delta’s sole objective is to ensure that all existing functionality within SIPP~Pro and SSAS~Pro currently is successfully migrated into this new environment. Subsequent phases will then allow Delta to add new and compelling features and levels of integration to our solutions going forwards.

For our re-platforming project, Delta is using a dedicated Agile development methodology. Historically Delta has always used a form of agile development, as the market which we serve is dominated by frequent and complex changes in legislation and business practice, thereby leading to regular requirements to change and update our software – a situation entirely familiar to all our users, we’re sure!

However, the partnership with NTT Data and the external focus this has brought to the project has taken this to a new and more structured and formalised level within Delta, such that both our New Platform and our BAU teams are now both implementing a true Agile development methodology.

Defining Agile development is a little awkward. The agile methods were created as a reaction to traditional development processes such as Waterfall, that looked good in theory, but that do not hold up in practice, particularly where the specification requirements were subject to change or flux.

The agile methods are therefore described as empirical – they are based entirely on practical experiences and work methods that are proven to work. A central concept for agile methods is adaptation to changing external factors. Where older methods are predictive and attempt to foresee future needs, agile methods are easy to adapt to new demands; adhering to the ―Embrace change!‖ motto.

Development cycles are run in, typically, two week ‘sprints’ where the sole objective at the end of that period is to have a functioning piece of software that performs the functions required and agreed at the start of the Sprint. The output is then immediately evaluated at the end of the sprint cycle by the project sponsors, rather than waiting until the end of a longer development project cycle to start testing, de-bugging etc.

Sprints are controlled and managed on a daily basis by a Scrum-master with each developer being accountable at the start and end of each day to the Scrum-master for delivery of agreed work. The parallels within this methodology to sport, e.g. sprints, scrums etc. are entirely intentional – the objective is to have the entire (development) team focussed on achieving a short term visible ‘goal’ – of delivering something that works at the end of each sprint.

However, absolutely critical is that the only measurement of success is functioning products.

In addition to creating a single system architecture, we have also taken the opportunity to review the underlying codebase which underpins our solutions. The existing FileMaker suite of tools has served our clients outstandingly well, and when Delta launched SSAS~Pro back in 1997, it was one of the very first applications in the UK to use both a 32-bit application and to run on Windows Server NT4.0. The current architecture continues to be extremely robust and scales effortlessly up to 250 concurrent users, well in excess of the requirements of the majority of our current user base.

The re-engineering of both SIPP~Pro and SSAS~Pro into a single system architecture is therefore based entirely on the most up to date Microsoft technology platform.

Most of our users will already have seen over the past two years that we have started down the route of engineering new and even more powerful functionality within the Microsoft suite of tools with our Report~Pro and Report~Engine tools, and our very popular Annual Review Pack module as compelling examples.

This new architecture will once again ensure that Delta’s solutions are not only market-leading in terms of functionality, but also of technology therefore. Basing the re-platformed products on this new architecture opens up significantly greater opportunities for integration with external systems, as well as providing a technology base which more and more of our users are increasingly requesting from us.

In order to ensure successful delivery of the re-platforming project, during early 2011 Delta decided that we would partner with an external organisation to drive this project forward to completion. This was because attempting to progress this project to the timescales we wanted, whilst at the same time meeting the needs of our existing customers, was proving challenging.

The choice of this external partner organisation was initially driven by a review process in conjunction with an external consultancy, and this process identified the likely overall scale of the project and an initial shortlist of 12 possible partner organisations.

From initial responses to our tender process, further reviews reduced this to a shortlist of four organisations, which Delta then interviewed and researched extensively; in much the same way as many of our clients typically make choices about partnering with us.

Following this final selection process, Delta engaged and has now partnered with Keane, Inc. an NTT Data company. They are headquartered in the US and have some 12,500 professionals worldwide. Key to our choice of this firm was that they were the right size and cultural fit for working with us – not too big to dominate the project and not too small to risk successful delivery.

During this process it became clear that simply outsourcing this project as a piece of work in its entirety was unlikely to be successful. Delta has therefore split its existing development team into the New Platform team, and an existing Business As Usual (BAU) team. Both separate teams now have additional personnel sourced from NTT Data, and what is key is that Delta staff are therefore intimately engaged not only with delivering work under the existing BAU team, but also with the new codebase and platform.

We considered this vital to the successful support and development of any new solutions going forward, in that existing Delta staff will have been instrumental in creating and developing it from the outset.  

As all of our users will be aware, Delta is currently undertaking a project to re-platform our SIPP~Pro and SSAS~Pro products.  This blog and the associated subsequent posts are our way of keeping our users informed and updated as to how this project is progressing.

The origin of this project stems from the massive changes introduced at A-Day back in 2006. Up until then the pensions legislation applying to each of SSASs and SIPPs was fundamentally different and therefore required two very different and separate database systems.

Now however under the current pension regimes there is a huge opportunity to create a single system architecture that will accommodate both SSASs and SIPPs, together with possible additional product ranges such as ISAs in future.