SR2014. Part 4. Have you started yet?

In this, the 4th blog in a series around SR2014 I thought I’d share a few things that I’ve discovered as part of my own analysis now that the SR2014 User Handbook is out there.

As is normal, a few things were tweaked since the publication of the High Level Info document back in November.  One Change Request (CR) was deferred until 2015 for example.  Two previously undocumented CRs crept onto the list, so 68 CRs in all vs. the 67 noted in my earlier blog.

Another fairly significant difference is in the number of impacted messages.  Again, this is not unusual.  As the final documentation is pieced together changes at the data dictionary level are traced through to all the messages using those components. This is then cross-referenced against the list of impacted messages. 

It turns out that 16 MTs previously thought to be in scope this year per the High Level doc are no longer impacted, and there are 3 messages that popped onto the list.  So, 50 MTs in all vs. the 63 noted in my earlier post.  That’s got to be good, right? 

Digging one level deeper I reported last time 265 actual changes, at level 2- or above, across all the messages.  That’s down to 248 now, so not really all that much of a difference. 

Perhaps this is all talk of comparison is irrelevant.  All that really matters is what’s in the User Handbook now, not what was published two months ago.  The High Level Info doc was a useful guide at the time, but it cannot and should not be relied upon going forward. 

In lieu of a 100% accurate summary document, perhaps MyStandards has a role to play.  Using MyStandards it is possible to select a message category or an individual message type and pull up a list of all CRs impacting that message or that category.  Conversely, click on a CR to see all the MTs impacted by that change.  That’s a whole lot of clicking to compile the full list. I know.

Next the REAL analysis must begin for every bank.  For each change what is the impact to your infrastructure, technology platforms, systems and code?  Can you insulate your applications from the changes via the middleware?  Or does your internal messaging model need to change?  Does a new field require new code in your back office systems and database tables?  Do you need to modify the user-interface?  Then repeat all this 248 times.

As always, the year will fly by, it’s time to get cracking. 

I’d love to hear how you get on.  Please feel free to post a comment to this blog, or contact me directly.