During the last few months, I repeatedly found myself trying to determine how to better demonstrate the capabilities of my company's new products. Working with payment systems, this always creates the same problem: almost all functionality of our products resides on the server side. There's nothing visually appealing to show, unless someone considers ISO 8583 traces and transaction records appealing (which is not likely).
So I started working on demo applications. And a demo application these days translates to either a web-based or a mobile-based application. Since some of our products offer capabilities for the end-users of our prospect customers, which are mostly banks and processors, and given the current trend of our time, it's becoming clearer that mobile-based demos are the way to go.
Here's the problem: how do you turn developers who are experts in creating server-based payment applications that most often than not completely lack a user interface, to developers that can create good-looking mobile demos? The answer so far turns out to be: slowly.
Mobile development is a totally different beast than the payment system in almost every imaginable way.
- The mobile user interface is of prime importance, whereas core payment system components may lack a user interface altogether.
- While more powerful than ever before, mobile devices still impose severe limitations in terms of processing power and memory capacity when you're used to working in a server-based environment.
- Regardless of your choice (Android or iPhone) the development workflow is radically different, hence you get an additional barrier that needs to be negotiated.
A different mindset is required. My experience so far is painful but slowly improving with time. The most important personal asset that is being heavily taxed is my patience. I find that even the simplest things can take a significant amount of time to accomplish. It's not only the fact that one is not familiar with the mobile development mode and need to constantly look up some piece of reference; the edit-deploy-debug cycle is frustratingly slow.
Consequently, the sole piece of advice I can offer is: be patient. Take your time. Go through the process of working out samples even if they appear to be brain-dead easy. Write a few applications on your own even if they are equally worthless to the easy samples. Slowly try new things, a few at a time. Whatever you do, make sure that you don't start on a schedule before acquiring enough experience to make informed decisions about development effort required to accomplish something, regardless of how trivial it may seem.
We've recently set out at my workplace to perform a daring undertaking: implement authorization scripting for a payment system that does not have a scripting facility. The idea initially surfaced some time ago as a half-joke. "Wouldn't it be something if the switch supported scripting"? It seemed a bit crazy at first.
We debated amongst ourselves for a while about the merits of such a capability. During our time working with the payment system, it became apparent that we could do anything we wanted by using the software development kits. It was also obvious that some solutions we provided were bloated-by-design by static code and would be better implemented by authoring a quick script. Validating the input of a cardholder performing a custom payment at the ATM is a very good example of such a situation. Validations typically examine few transactions and verify the cardholder input by using a custom verification algorithm, such as a variation of a check digit verification algorithm. The typical solution would be to author a custom plug-in and attach it to the payment system; easy and can be delivered in a few days. The scripting solution would require creating a few lines of scripting code; easier and can be delivered in a couple of hours.
There was value in the idea, no matter how preposterous it might seem. It's not, after all, every day that you set out to plug-in something as significant as a scripting facility to a payment system. However, the flexible nature of the system allowed us to be optimistic.
So we rigged a proof-of-concept implementation and tried it out. The results were surprisingly pleasant and everyone started thinking of scripts for everything after working with our pilot. Stress-testing the solution to more than one thousand scripts per second was the final action before we started using the ideas from the pilot to create a full-blown system.
Some time passed and we're now there, with a scripting product finalized. It's surprising how your perspective changes from the time when you're building proof-of-concept, throw-away code to the moment you set out to create a polished product. A gazillion things that we didn't expect needed to be handled in a manner that makes sense to an end-user. Create a new scripting language or use an existing one lots of people are familiar with? Which one? How would the user write and debug scripts? How would the scripting service be notified of configuration changes? What facilities should the scripting service offer to the end-user, on top of those provided by the scripting language itself? What level of control should we allow to scripts? How could scripts be extended to communicate with external data? And external systems?
Once again, the graphical user interface
took a disproportionate amount of time when seen through the eyes of a
developer/integrator who would be quite happy with configuring
everything through a raw XML interface. But the real lesson here was understanding the need for a roadmap in order to reduce the scope to something manageable and release version 1.0 in a reasonable amount of time.
If we took the time to implement everyone's idea, and lots of people had great ideas, we would be lucky to have released 1.0 sometime at the end of the next year. One developer had a great visualization about how the graphical interface could be made to be much more intuitive. Another proposed a radical implementation that would allow anything in the payment system to be scripted. Yet another one indicated that a workflow should be used to push scripts through an author, then through an approving member, then to testing, to QA and then to production. Very often I was finding myself in the awkward position of having to shoot down good ideas that I liked just to keep the scope manageable for an initial implementation. "That's for version 2.0" became a phrase spoken quite a few times.
Having a developer's background, I can understand what a kill joy I turned out to be. Still, I had to be firm about the release date otherwise there wouldn't be a specific release date. And I do like releasing software!
One recurring theme that keeps coming back over the last few years is how to best integrate payment systems in a SOA environment. The SOA acronym may mean different things to different people but I've found that, more often than not, when developers think of SOA, web services and related technologies are involved.
Web services offer the advantage of providing a common framework of communication between different systems. The concept is powerful enough to bridge the gap between different programs, different development languages and different operating systems.
It should, therefore, not come as a surprise to know that payment systems users increasingly require their payment systems to connect to web services. Some payment systems are better at this than others. But I've found that the majority of payment systems have ISO 8583 so close to their heart that it's not as easy as it should be to use an external web service.
During the last few months, I've decided to tackle this in a generic way to allow payment systems to connect to web services at the backend. The approach is simple: create a SOA adapter that translates ISO 8583 to web service calls in a configurable way. The SOA adapter would connect to the payment system, receive an incoming ISO 8583 message, understand what is being said, call the appropriate web service and return the results to the payment system using an ISO 8583 response message.
This seems easy enough at first glance and it's a task that, in some form of another, most developers have encountered at some point of their career. Communicate with one system using its own language/API and translate what is being said to another system's language/API.
In the context of the SOA adapter, there is a complication. On the one hand you have web services that, more or less, use the same language. But on the other hand you have payment systems that use ISO 8583 in completely different ways that are often incompatible between each other.
One approach to tackle this is to create different flavors of the SOA adapter. This way you could end up with SOA.BaseI, SOA.Biciso, SOA.PostBridge and several other combinations that cater for specific needs. While this could solve the problem, it quickly adds up maintenance costs as it's necessary to keep track of different versions of the software.
The approach I've used is to code an ISO 8583 implementation generic enough to be able to read the application-level protocol from an XML configuration file. In this way, you have a single version of the software which comes with several configuration files so you just pick one that works for you. Plus, you get the benefit that you can implement an ISO 8583 customization by changing an existing XML file or by creating a new one; no code changes.
After completing this development exercise, the result is a clever piece of middleware that can be used to quickly connect payment systems to external web services using configuration only. The notion appears to be good enough to market. An end-user could connect the SOA adapter to their system, edit a few configuration files to describe their web services, their methods and parameters and SOA adapter just picks this info up and does the rest.
It may come as a surprise to some but the most difficult task which I'm still battling with is the creation of a user interface to drive the configuration. Strictly speaking, a config GUI is not required to use SOA adapter, especially when the technical background of potential end-users is considered. But, like my boss says, a GUI is more than just a necessary evil; it's the front end of the system and plays a major role in forming the perception users can have of the whole system.
After a short struggle, ACI has managed to acquire S1.
In a big turn of events, starting from the S1-Fundtech merger proposal to today's (3/10) press release, ACI has finally achieved their objective.
This acquisition creates a true payments software giant. Not that ACI wasn't the market leader before; but with this acquisition the new ACI will have the vast majority of the market with all other competitors coming a very distant second.
How does this translate for ACI and S1 customers, both existing and prospect ones? No way to tell at this point. It all depends upon the strategy that ACI will follow in the next few months. Will Base24.EPS be favored instead of S1's Postilion? Or will ACI keep both offerings...for now? Despite the original ACI position, Base24.EPS and Postilion have much more in common than not and it might not make sense to keep both products alive.
This situation certainly is familiar to people that remember what happened to Open/2. Postilion, though, had more traction than S2's Open/2 and ON/2 combination and there are a lot more customers that have chosen Postilion during the last two or three years. I would expect that there are a lot of nervous customers around, wondering how this situation will play out.
It looks like ACI has been at least partly successful with their offer to acquire S1. Partly because the proposed merger between S1 and Fundtech is now history and ACI has averted the rise of an S1-Fundtech combination which would be an even bigger competitor than S1 is on their own right.
So what happens now? By the turn of events it appears that after the ACI offer turned hostile, both ACI and S1 are building up their S1 stock to get control of the company. The S1 board is fiercely fighting against this but, despite initial impressions, it's not going to be easy for S1 to maintain autonomy.
When the S1 stock jumped up a few notches, some sold and some bought. At the end, it appeared that it's not entirely clear if the S1 CEO can rally the shareholders to fight off the attempted ACI takeover. And with the shareholder meeting for the Fundtech merger cancelled, it remains to be seen who has the most votes.
The current situation is not exactly the best S1 hoped for. There is uncertainty amongst both existing and prospect customers, as well as resellers of S1 products. Will the S1 payments platform still be around a year from today? That is the important question here. Although not a betting man, I would be willing to bet that the current situation is hurting S1 financially. Prospect customers, especially those affected by the ACI sunset, would not feel comfortable by selecting S1 now and then find out that they'll be dealing with ACI again after a few months.
With things being what they are, a shadow of doubt is cast upon the S1 future. Even if ACI does nothing at the moment, no one can be sure that they're not just accumulating S1 stock and trying to convince the shareholders to back them up so they can force a change of the board members or reach an agreement with the board behind the scenes.
In that sense ACI has gained an advantage over S1, at least for now. S1 has to clear this mess as quickly as they can, especially during the year of the setting sun. Unless of course, the game ends with ACI managing to acquire their most serious competitor.
Time marches on. Technologies change and systems are upgraded. Every once in a long while, banks have a good hard look at their payment infrastructure and decide that it's time for a change. This may happen every few years or every twenty years, depending on the bank's culture. It's that time of the decade. It's migration time.
An RFI is circulated to several companies. Then an RFP is sent to the select few that seem capable of doing the job of migrating the bank from the, now perceived, old dinosaur to their platform advertised as supporting the latest-and-greatest of technical goodies and being able to drive customer innovation to new unheard-of heights. Committees form to evaluate the responses to the RFP. Vendors drool over the possibility of a new customer, especially if the customer currently uses the arch-enemy's product. Discounts rise to unbelievable heights. The bank negotiates the hell out of the deal.
The bank typically pays attention to the following items:
- Budget. These days, this is one of the most important factors in shaping a decision.
- Vendor capability to execute. Regardless of the value of each product, great attention is being paid at the ability of the vendor to present and execute a good migration plan that minimizes the risks as much as possible.
- Vendor product, customer references, vision and fit. All vendors advertise their product as being the best on the market. But is the product a good fit with the bank? Does the vendor have a product vision? Are there enough positive customer references?
After some time a decision is being made and a migration project begins. Depending on the technological and architectural gap between the system being replaced and the system replacing it, the migration can range from tricky to painful. Some areas are more problematic than others, requiring special handling and attention.
It's a time of change. And a great opportunity for the bank to look hard at some of the existing processes, procedures and infrastructure. I almost always advise against introducing unnecessary changes during a large scale project. Most of the time, changes introduce some level of risk and nobody likes that. However, a radical case such as migrating from a payment system to another offers some opportunities that are simply too great to pass up.
Perhaps the single, most important thing a bank can do at this point is re-evaluate some of the things they do and, most importantly, examine why are they doing them in the way they do. It can be pretty amazing to discover that some things just happen in a certain way because someone was used in doing them that way two systems ago. Or that some manual and/or tedious process can be automated or simply removed because of the architecture of the new system. That's the reason business solution specification cycles tend to focus on the "why" instead of the "how". The question "why is this process in place" is always very important.
Other, more technical, matters can be closely examined during a migration. It is always advisable to try and play by the rules of the new system and not against them. This might necessitate changing a few existing interfaces or alter some existing process to better fit the new system. A good example that comes to mind is the way the host system communicates with the payment system. More often than not, the host uses an application protocol that does not resonate well with the new system designers (especially true for stream protocols with new systems that favor ISO-style protocols). In my experience, re-programming the host to make it understand a modern protocol is always a dreaded exercise. But it's worth it in the long run. Having the new system implement a custom protocol is certainly doable but the repercussions of such a decision will be felt for years - possibly for the duration of the lifetime of the new system. Choosing the modern application-level protocol of choice of the new system that is seamlessly and continuously upgraded to cater for new needs may require an expenditure of a few hundred man-hours of host programmers. But in the years to come no one will have to worry again about protocol translation, mapping and all the related headaches of such maintenance exercises.
Other systems, in production or planned, could also be examined and amended to be as compatible with the new system as possible. As a rule of thumb, new systems tend to offer way more integration options than older systems. It might be a good idea to try and take advantage of this resiliency and avoid ugly hacks that were necessary in order to play with the old system but are now obsolete. Example: channel integration. Older systems usually treated channels very differently according to their capabilities. The result is that newer channels have a hard time communicating with the payment system, making it necessary to resort to weird workarounds. Internet and MOTO channels might use a standard POS interface to send transactions because that was the only way to do it. But if the new system offers a simpler and standardized way to achieve the same result, it's better to bite the bullet now and do the change to use that interface than to suffer from the shortcomings of the old interface forever.
I'm obviously not advocating a complete re-engineering. The norm should be the payment system bending over to cater for the needs of a bank and not backwards. But this rule should not be always be blindly applied to everything. There will be situations where change, especially in existing processes that are not transparent to the end users, could be beneficial to the bank.
News of the ACI bid for S1 caught up with my summer vacations pretty quickly. Just a few weeks after the announcement of the S1-Fundtech merger, ACI stepped in and made an attractive bid for S1. According to ACI, its offer represents a more attractive option to S1 shareholders than the S1-Fundtech merge.
Some people would remember that this is not the first time ACI made a bid to acquire a competitor. Back in 2002, if memory serves, ACI acquired S2 which was the maker of Open/2 and ON/2. During those days, S2 held a reasonable size of the market (although much less than ACI). The result of the acquisition was that ACI in effect placed both Open/2 and ON/2 in sunset status. The bid was simply a move to take out a competitor, eliminate the competing products and acquaint ACI with the S2 customer base.
Back then, it wasn't a secret that S2 was not in the best of financial shapes. This is not the case with today's S1, even without considering the financial size of an S1-Fundtech combination.
Perhaps none have more interest in the ACI bid than current and prospect Postilion users. And it is understandable. Users wonder what will the future of the Postilion product be. Would ACI want to capitalize on the platform and continue to develop it? Or would they favor their existing EPS product and just kill Postilion?
It's impossible to tell at this point. The ACI announcement speaks of "complementary products" but that's really not the case. Postilion and EPS have much more in common than not, in terms of functionality offered to end users. Under that light, why would ACI want to keep two pretty different platforms that provide the same offering to their customers? Wasn't one of the reasons to sunset Base24 classic based on the principle of focusing business development on one platform only?
Some might suggest that ACI plan to use part of the technology behind Postilion and incorporate it in their EPS product. If that's so, the logical plan would be to move some of the Postilion tech leads to the EPS team and use their skills there. But in this case, Postilion would be gradually abandoned with no business improvements scheduled and with minimal support for card association updates only. ACI would issue a sunset statement for Postilion in a future date, while figuring out a way to offer a realistic migration plan to EPS to current Postilion users.
Perhaps ACI might even consider a wait-and-see tactic and see how their sales force does with Postilion. Maybe there's a plan to go with Postilion on small and mid-level bids and go with EPS & IBM on large-level bids; not that it makes a lot of sense from a technological point of view.
Considering the above, a buy-to-eliminate plan would seem to make sense. But then again, as a friend of mine pointed out, if that's the case we'd be talking about a very expensive move. And that's true. Spending more than half a billion just to kill off a competitor does seem a bit over the edge and won't get many big fans from the ACI shareholders.
There is still no reaction from S1, other than a statement that the bid will be reviewed by the S1 board. I guess we'll just have to wait for the S1 response to see how this whole affair will play out.
UPDATE: S1 has quickly rejected the ACI bid saying that it was not in the best financial and strategic interest of their shareholders. To translate, S1 is saying that they have complete faith in their own long term business plan. And perhaps rightly so. Postilion has evolved from a regional switch owned by a relatively small company to a global player praised by Gartner, sold and operated worldwide. Considering events of past years, I suspect that the S1 CEO was the driving force behind this decision.
This puts ACI in a bad position. In competitive comparisons, ACI is now going to have a hard time explaining to prospects how their own EPS offering is better than Postilion. Likewise, the S1 sales force will surely make certain that prospects know about this series of events and the failed ACI attempt to buy them.
UPDATE: ACI fights back the S1 board decision and wants to get direct support from S1 shareholders. In my very humble opinion, I very much doubt that the S1 board did not contact the major S1 shareholders before rejecting the ACI proposal. Regardless of what's happening behind the scenes, it's becoming painfully obvious that ACI is not happy with the S1-FundTech deal and will go at any lengths to prevent it.
UPDATE: Well, this is getting more and more exciting. After ACI's attempt to solicit proxies against the S1-FundTech merger, S1 issued a comprehensive response to shareholders. Soon thereafter, ACI increased the cash part of the bid to acquire S1. I think that ACI is trying to persuade investors not in for the long run to go for the cash. The ACI press releases keep on singing this tune. In these uncertain times, some investors might very well be tempted. The S1 press release recommending to vote for the S1-FundTech merger appears to offer more concrete arguments to shareholders.
