A Tale of Two Mainframe customers – one growing and one leaving the mainframe
This is the tale of two mainframe customers. One customer
has achieved a period of tremendous growth in their business, processing
transactions on the mainframe, while reducing expenses and becoming more
resilient. The other business chose to get off the mainframe at a significant
cost and in all likelihood, spends more today than they would have on the
mainframe. What’s interesting is that at one time, they shared the same system
infrastructure. And Clerity, a consulting firm, would like you to believe that
the non-mainframe customer got tremendous value in the move. Here are their
In any basic computer architecture class, a student will
learn that the fewer the number of data moves, the better for performance. Now,
in an era of regulatory compliance and privacy considerations, that becomes
exceedingly true because each instance of data must now be auditable and
recoverable which implies additional costs for each extra instance of data.
This becomes important when considering an outsourced computing environment. It appears that SIAC never got this level of education, while its customer, DTCC seems to have excelled in this computer architecture class. Even funnier is that Clerity has decided that SIAC is a model customer…that doesn’t bode too well for their other consulting arrangements.
So what really happened?
DTCC’s trading business was growing tremendously. But let’s have them tell you, in their own words:
Sometimes "insourcing" pays off more than
outsourcing. Until last year, two DTCC subsidiaries outsourced all their
infrastructure support activities to the Securities Industry Automation
Corporation (SIAC). Now, following the completion of a multi-year initiative,
DTCC has cut costs and bolstered business continuity by insourcing the
activities previously performed by SIAC into DTCC’s infrastructure. The two
subsidiaries are National Securities Clearing Corporation (NSCC) and Fixed
Income Clearing Corporation (FICC). ……
On top of strengthening the industry's business continuity and infrastructure, the project is yielding financial benefits, enabling DTCC to cut the industry’s overall operating expenses. In 2006, by leveraging DTCC's processing capabilities, insourcing has reduced DTCC's annual operating expenses an estimated $42 million, said William Aimetti, DTCC’s chief operating officer. This was one factor that enabled DTCC to lower its fees in 2006.
And going back to another DTCC newsletter, they explained that they got a 167% performance improvement, without a line of code change, because they reduced the number of data moves and connections necessary to process a transaction:
To keep ahead of transaction volumes that have been rising sharply over the past several years, DTCC has significantly increased the capacity of its mainframe database for equity processing. The system, called Trade Repository Processing (TRP), can now process at least 160 million sides per day. This 167% increase is nearly triple the previous capacity of 60 million sides.
What’s more, the TRP can handle the additional volume within the same time frames, thanks to changes that make the system perform more efficiently. In addition, for current volumes, the upgrade allows DTCC to deliver certain participant reports, such as the Consolidated Trade Summary, up to 45 minutes earlier.
DTCC was able to do all this without modifying any of their
customers applications. While DTCC was hosted on the SIAC systems, they found
that there were extra network hops and copies of data deployed. They also were
heavily dependent on SIAC to make changes to the infrastructure on a regular
basis. Because both of the SIAC systems were located in the New
York City area, DTCC was also afraid that a single
catastrophe would take out the redundant systems and affect their availability.
These were the fundamental concerns that led DTCC to move out on its own.
Prior to this decision, SIAC signed a multi year agreement for software, systems and services with IBM. This agreement included discounted pricing assuming capacity growth projections that SIAC provided as their objectives. By sharing the mainframe infrastructure with DTCC, SIAC dramatically reduced their own operational overhead which was predominantly associated with batch processing and account reconciliation in the evening, while DTCC used the same processing infrastructure for trade transactions during the day. Each had applications that overlapped each other though.
When DTCC pulled their two applications from the SIAC
system, SIAC was left with a lot of free daytime capacity, but still a
reasonably busy system in the evening. But SIAC was now completely responsible
for the costs of this system. The growth potential that they had promised to IBM
would no longer be possible and as such, the discounts they were offered were
no longer relevant. This underutilized
mainframe was now quite a bit more expensive to SIAC than it had been when it
was sharing the expense with DTCC. That’s a fact…nothing sweet about that.
Now SIAC could actually have downsized with their mainframe
and reduced their costs. Instead, they chose to “down size” to a distributed
environment. In doing so, they also needed to solve federally mandated business
resilience requirements, something they had ignored on their previous mainframe,
and build another data center.
So using SIAC’s own words:
In 2006, when the Shared Data Center team, the technology arm of the New York Stock Exchange (NYSE), evaluated its internal infrastructure in light of competitive market factors, changing regulations, and anticipated future growth, the decision was made to replatform its 1,660 MIPS mainframe workload onto IBM System p Model 595 servers running AIX and UniKix rehosting software from Clerity.
"Quite simply, we can now transact more business per
hour at a lower rate," said Francis Feldman, Vice President of the Shared Data Center
So let’s parse this a little bit. Notice the timeframe:
2006….it’s the same time that DTCC moved off the SIAC system. The 1660 MIPS is
the combined processing power for both DTCC and SIAC. The reality is that SIAC
NEVER used all that capacity themselves, even though they owned the system. So
while factually true, it wasn’t real. Changing regulations refers to the need
to develop a second site outside the New York metropolitan area. After converting the
applications, SIAC had to create automation and recovery scripts and deploy the
new servers at an alternative location as well. I am assuming that they
licensed the software for those systems as well. And this required changes
for all of SIAC’s customers as well. That cost certainly isn’t factored
into the migration costs for SIAC. Finally, I wonder what SIAC’s cost were when
they shared the infrastructure….is the new solution more or less than that
environment? Unfortunately, we’ll never know because the new environment
includes a new data center….but I could imagine it was less.
So, an alternative plan, at presumably far less expense, effort
and time, with little or no application changes, would have been to downsize
the mainframe to the size appropriate to SIAC’s new capacity requirements. To
meet the resiliency objectives, SIAC could have installed a mainframe in
another geographic location using IBM’s Capacity Backup pricing which would not
have charged for software usage except during a disaster, while still allowing
for regular disaster preparedness testing with no additional licensing costs. Many of IBM’s customers take advantage of this
model for availability processing.
And has availability improved? Click here for a list of outages that SIAC experienced in 2008. All types, but not associated with the mainframe. Perhaps SIAC changed their reporting structure in 2008, but I can’t find many outages listed in a search on 2007, though there is an awful lot of information dating back many years on their site.
As for SIAC, I don't know, but they don't spend nearly the amount of time bragging about their infrastructure as DTCC. That should give you a clue right there!
|by JimPorell||January 6, 2009 in Current Affairs, Economics, History, Systems Technology |
TrackBack URL for this entry:
Listed below are links to weblogs that reference A Tale of Two Mainframe customers – one growing and one leaving the mainframe: