ARCast.net - Recovery and Moving Forward - Pay Global
Voiceover: It's Thursday April 12, 2007 and you're watching ARCast TV.
Ron Jacobs: Hey, welcome back to ARCast TV. This is your host, Ron Jacobs. Today we are going down under again, all the way to Christchurch, New Zealand, which I think has to be the farthest south I've ever been anywhere on the planet. Christchurch is on the south island of New Zealand, it's kind of way, way down there. This was at the tail end of my trip to New Zealand [laughs] speaking of sheep. No, literally it was like the last day that we were down there, and just had a fantastic time meeting a lot of people.


On this episode we're going to talk to the folks from Pay Global. Now, this is a company that has built up a business kind of in the traditional software model with a nice app-- Delphi and all this, but the business kind of got into trouble. The founder left, the business was sort of languishing, they started a.NET port and that went bad.


How did this all turn out? Well, we're going to hear on this episode so stick around.


Hey, this is Ron Jacobs and I'm here in Christchurch, New Zealand at the offices of Pay Global. I'm joined by Melissa Clark-Reynolds who is the CEO of Pay Global.
Melissa Clark-Reynolds: Hello.
Ron: So, Melissa, this is a fascinating story of this company that you've taken to kind of turn around and do some fascinating work with. But before we get into the story of Pay Global, tell me a little bit about some of the strategy you've been... You we're talking to us earlier about your strategy for finding companies and turning them around, what is that?
Melissa: For me, I've bought a couple of companies and sold them, and I made some money in the '90s doing that. So for the last six years what I've been doing is I specialize in antique company turnaround. So I buy them and get them cleaned up and then I get them sold.


What I look for in a company is I look for something that has got or often had a lot of founders, a lot of entrepreneurs. They are often started by engineers or by guys who have this brilliant idea for some code. And they've managed to grow the company, but over time they often don't let go. They still continue to control, they still cut code, they still become the head of finance, they become the head of sales and marketing and they are trying to be the CEO, and they are the head of Human Resources, and the company then gets stifled by their inability to hire really good people around them and let the company be free, let it grow. So, I'm interested in that.


I think having been a founder myself of quite a large company, I can see that there was a turning point when I realized that I just had to hire smart people and get out of the way rather than try and control everything. So I look for opportunities like that.
Ron: So you came into Pay Global at a time when it was kind of struggling, and you have been turning this place around. Now, you were telling us earlier about a decision that you made to kind of partner with Microsoft in the process. Tell me about your thought processes there, why did you do that?
Melissa: I guess that I came in and I saw that we were trying to build something that was bigger than being here. We were trying to build multi-language, multi-database, global product. And I could see that the only real advantage to anybody for that was that we were going to need twice as many developers to maintain this huge code base for everything possible. I had a look at it and I thought partnering with Microsoft means that we can commit to one database, one platform, but at the same time we can become much closer to the whole dynamics family.


And I could see that for things like Navision or Exacta and Great Plains, which we use here as well, that what they need is they need good human resources and payroll bolt-ons. And by partnering with them we could solve real problems, especially in that middle tier, tier-two companies.


So, we didn't want to compete with the PeopleSoft or compete with an SAP, Oracle, or whatever in there. We didn't want to be there. We could see that in the tier-two space we could work closely with Microsoft product and really solve problems for businesses that needed it. It just seemed the easiest thing to do.
Ron: A lot of people in the payroll space are trying to do it as a service. So you are competing with the service bureaus and that sort of thing. I'm just curious if there is any thought to sort of a software as a service strategy or anything along those lines.
Melissa: I guess we look at it in different ways. I think that you have the push and you have the pulls from the market. So there is a piece of the market that wants purely business-process outsource and there is a piece of the market that wants installed software, and we cater to both. We'll take you for a tour later, but we can show you we have a business process outsource service center here.
Ron: Wow.
Melissa: Those customers buy or rent licensed software, it's hosted and we provide anything from all of their employee record keeping, their tax management, through to the direct credits of their pays, calculation of payroll, calculation of time and attendance, all of that.


So we see it as a spectrum. Where some people might want to buy it outright and put it on their own server to do what they want, some people might want to rent it and have it hosted, and some people might want full-service provision on that. And we offer all of those.


More interestingly to me, I think, is that a lot of people haven't thought about who provides service to those service providers. So the other strategy that we have, particularly in Australia, is that we provide our platform to other BPO providers, so we are really trying to develop some specialized action in that area too. Which means that people who perhaps want to offer outsourced payroll services can use our platforms to do it. And that's a new area of business for us.
Ron: That's a fantastic thought and it sparks in my mind that this has an impact on the architecture.
Melissa: Mmm-Hmm.
Ron: And certainly the way in which you are going to design the software has to take into account the business strategy, which is what I'm always telling architects.
Melissa: [laughs]
Ron: You need to know how your company plans to make money because otherwise you are going to do things that are going to work against it. So I'm excited to hear about the architecture of your solution, and it's been so nice chatting with you, thank you for popping in on such short notice.
Melissa: You're welcome.


[music]
Ron: Now we're back and I'm joined by John Guy. John, you are the architect here at Pay Global?
John Guy: That's correct.
Ron: So tell me a little bit about the technical environment that you came into. There had been an application for quite some time, right?
John: Yes. The application as it currently stands has been around for between 10 and 14 years. It started life as a DOS-based Clipper product running on a flat file database system for doing time and attendance record keeping. That has evolved over time picking up new features such as payroll, HR functionality, and migrating at the same time from the Clipper DOS products over to the Windows Delphi products. We've also moved away from just supporting a flat file database to supporting Sequel Server's primary database, and also Oracle's database as well.
Ron: Oh, OK. So, now when this company under the previous management had got a lot of funding and so they said, "We're going to go take on the world, " what happened?
John: They looked back and said "OK, we've got a legacy application that does very, very well but it's getting a bit long in the tooth, it's moved over, there are so many more things we could do out there." So they said, "OK, let's start from scratch. So we'll write a brand-new product with all the knowledge we now have and we'll go for the market and we'll support every database in the world, we'll support every language in the world, we'll support every country's tax regulations in the world and we will make the one solution to effectively rule them all."
Ron: Wow! So they bit off a very large bite.
John: Very ambitious.
Ron: And what was the result?
John: They made some good... We made some very good developments in some areas of the product but we just were never going to get up to having a full product feature set like we have in the current products; it was just too big a thing to get involved in.


And we made very strategic decisions from an architectural perspective that caused a lot of trouble. We said that date effectiveness is an issue in payroll; everything will be date effective. So then you are trying to maintain a completely date effective database. Then they turned around and said everything needs to be customizable, definable, flexible, so we won't have any fixed database tables, we'll make them all configurable on demand.
Ron: OK.
John: So you're going to make systems that are very powerful, ultimately scriptable, but very hard to report against, very complicated to explain to somebody, very complicated to configure. We're just building the perfect machine, and they just never got that.
Ron: Wow. When I talk to architects, I often talk about this idea of knowing the ceiling and the floor. You were at the talk where I answered that, right? The ceiling is the limit, the constraint - "We only have this much money and time." But the floor is, how good does it need to be? This is good enough. We want to be closer to the floor than shooting for the ceiling, right?
John: These guys were partying on the roof terrace.
Ron: [laughs] OK. Then, when Melissa came in, the new CEO, you reset the strategy, and now what's happening?
John: What we're looking at now is we're recognizing that our existing product satisfies a lot of customers and it's very well respected in the market, does very well. All of our business is in the current application. It's a bit long in the tooth in some areas, it's a bit hard to get around in some areas, but fundamentally it's all in there and it's all good.


So using that as the basis for what we're trying to take forward, we're going to take that product into the future with us. We're not going to throw away the good stuff. We're just going to replace the older stuff with some more modern platforms and architectures to take you through.
Ron: So did you break down the problem into smaller, more manageable chunks that you could address as you go forward?
John: Yeah. That's been the biggest challenge for me coming on board as architect here. It's a very big product. Our existing Delphi codebase is one and a half million lines of code, and there's another half a million to a million lines of third-party UI components in there as well.


It's all closely coupled. I generously say it's a two-tier architecture as a separate database. But everything else is fully integrated. So the first thing is to make it more manageable for the development team. We've split the application into our functional areas. We split away what we call HR, from what we call payroll, from what we call TNA rostering, and that gives us four slightly smaller modules to work with.


Then within each of these modules we're looking at the user interface elements, then the business logic elements, and beyond those. We're focusing now on, where is the biggest demand? Currently the thing we want to get out most is to actually isolate our business logic and our business processes. So we're focusing on regenerating those components first and having the new version support the old UI.
Ron: So you're trying to take the business logic, extract it out of the UI, and put it into something that's usable? Well, that would be really important based on the business model that you have here. You'll want to be able to have this hosted, people using web UIs to access it. I can imagine even, when it comes to integration with other software, you're going to need a web services interface for supporting this sort of thing as well, right?
John: Precisely. One of the big problems we have today is we don't play fair. We don't play well with other systems. We have been a monolithic application, which is your HRIS payroll solution. We need to get to a scenario where we can say, "Hey. We'll work with this piece of your enterprise solution and that piece of your enterprise solution and we will contribute to the products. So we have to open up and get into our code.


And our business logic is there. It can be accessed either from the standalone application or via our web service gateway or via a self-service web interface or even via some automated remote procedure calls.
Ron: Or, maybe even an interactive voice response system would be another one.
John: Whatever comes in. Exactly. And things I'm trying to instill is that if we can actually isolate the components of our product, we can even dovetail other processes in between our own processes and take them further. So exactly. We can get into an SMS gateway to tell people of roster changes.
Ron: Mm.
John: We can already pace delivery via our self-service offering, but we can do paced delivery via some other mechanism. In the future we could go directly to a bank and to the post office. There's no limits to what you can achieve.
Ron: I can imagine, then, you've made this first step of getting the business logic out. In the previous generation product they had this desire to make it highly, highly configurable. Of course, if you take that too far it becomes unmanageable, like you found out. But how are you addressing this customizable, configurable nature of the business you're in?
John: Payroll, by its very nature, is specific to every organization. So we have to have a certain degree of flexibility in configuration. One of the powerful features of our product is our ability to have custom payroll rules and custom award rules and TNA. They're all written in our own language internally, which is a macro language.


But we need to put layers on top of that, because we're very vertical. We're very keen on getting the health sectors. And 80% of companies use the same sets of rules. So 80% of our logic will be the same, 80% of our configurations will be the same. We need to introduce a new layer to help the consultants with configuring this for deployment, to start from a known base and only customize that layer on top of it.
Ron: Oh, OK. So you could have your health care configuration. It's going to work for 80% of companies with some minor changes, maybe. OK.
John: And the next thing for that as a business is once we have this in place, we can go into companies, and companies will actually say to us, "How should we be doing this?" We can start to lead that process as well.
Ron: It's almost like a template. In Visual Studio, I go, "I want to do a new web application, " and it spews out a template for me. It's almost like that, that you're going to have a template for a certain industry.
John: Precisely. One thing I was talking about with my other developers recently is we'd love the idea of getting Visual Studio with templates, and actually making that the tool within which our consultants are configuring our application. So some of that new technology coming downstream is very attractive to us. Things like Team Foundation Server, as a repository for version control, on their rules, and their deploying to customer sites.
Ron: Well, you know what this would be perfect for, is a software factory.
John: Yep.
Ron: You look at what the patterns and practices team does with the web service software factory, or the smart client software factory. I could easily imagine your PayGlobal software factory, their consultants come, they pick the template they want to use, they set up a few custom rules, it spews out a lot of stuff. That would be perfect.
John: Yep. And that's where, as a business, we want to be going. We're not really in the business of making software. We're in the business of delivering finished solutions to the clients.
Ron: And, see, this is exactly the point. Every piece of software isn't really about delivering software. It's really about delivering business value. Especially when you're working in this kind of mixed model, sometimes you'll get the bits, sometimes you'll just get the service, but either way, you still have to deliver on the business value.
John: That's right. That's the key for us, and also for clients that like us, the speed in which we can do it. That's something that's hard for us to do today, because we have one level of configuration, so while we're very flexible, that's a rod for our own backs today.
Ron: Yeah. Now a lot of people who are in your position have looked at workflow foundation, and said, "Well, this might be one of the keys to doing this kind of flexible configuration of business process." Is that something you're thinking about?
John: Yeah. I'm hoping to look at workflow foundation for more of our HR processes - things which are process and workflow driven. The payroll side of things is quite rules-driven. It's mechanical. It's about taking large amounts of transactions, processing them, and producing more transactions.


The HR is more about working with quite complicated workplaces. When someone joins a company, there are a lot of things that happen in different parts of the organization to make sure things are set up correctly for that payroll, for that TNA, but also for all the other stuff.


And then when they're going through their life here, they're going through training, they're going through performance reviews, they're going through transfers internally. That's all workflow-type solutions. We can allow customers, hopefully in the future, to pluck together their own workflows of the things that happen within their business, but using our module of business logic.
Ron: As we go forward, I think most experts are predicting that more and more companies are going to be interested in software as a service and less as a licensed deployment model. A lot of architects are thinking, "How are we going to support that when 80 or 90 percent of our customers are all wanting this hosted service?" And of course, a lot of this is going to depend on how many customers you can put on this server. And then you have all these issues of multi-tendency data. These are interesting challenges for the architecture.


So I'm sure that this is something that you're probably going to address further on. You're doing the smart thing, you're taking little chunks, but as you're looking at the architecture now, are you seeing things that you're thinking, "Wow, we're going to have to change that further down the road?"
John: Absolutely, you've got to... You spent yesterday afternoon actually about architects having different views on the world. A lot of my role is actually sitting up there at 20,000 feet looking down at what's going on.


So you have to look at the big picture, and I know coming down the line security is just going to become a bigger and bigger issue, it's already a very hot topic for us. But it's different in a stand-alone application, it's about individual security, what people are allowed to do.


When we move over say to multi-tenancy, you're into who can what chunks of data, and what should they co-residing in the Dating Database, should they be different databases, same servers?


Our role here is going to be one of, we can support each of those models, and to set the application, so it doesn't matter how you're setting it up. If you are going for multiple database servers, it works just as easily, and just as easily to configure, as if you are even putting multiple companies into the same database on the database server. So I know that's coming down the line.


Scalability- we're not overtly going out there and saying we have to scale to gigantic sizes today. But part of my role as an architect is to work with Melissa and say that I know where we are going to need to be in the future, scalability is going to be an issue.


Currently we run out payroll processing on a single CPU, well it would be useful today to know that we can scale to run on all the CPUs within a single server. But why not take the next step and say that we are going to have run on maybe a farmer service.


So whilst we are regenerating our product, if I can make an architectural decision or help my developers make an architectural decision, which says that it will be easier in the future as opposed to harder in the future, then we'll go that route.


But all the time not building for the ceiling, just making sure we are satisfying today's requirements.
Ron: Yeah, the other thing I think is going to be very interesting when it comes to software as a service, as you look at the cost of adding a new customer, it has to be as low as possible, you know. Because the competitive nature of this is going to become more and more intense.


I can even imagine getting to a point where changing from one vendor to another might not be that difficult, so people would say 'Oh, I've had it with you guys, I'm moving over to there.'


So maybe thinking about things like if you did have a customer who is coming from another vendor, could you import their data, or maybe your customers are going to start demanding guaranteed about 'If we decide to leave you, how do we get an export of our data, or the backup files' those kinds of problems are other issues to think about, right?
John: Yeah, I'm addressing those today just from the position of playing well with other systems. If you're prepared to take somebody else's output as your input, into any part of your application. And you are also prepared to provide your output as input to someone else's next stage, then you should be able to achieve those options.


It's about clearly defining the spaces between the chunks of your application in terms of data interfaces, process interfaces, those kinds of things.
Ron: Ah, wow. So how is the project going so far?
John: It's going well. We're just about now starting to turn on the tap on all the developers. We've been doing sort of framework architecture work for the last six to nine months, planning our attack, really. And now I am turning over about 50 to 60 percent of our Delphi developers, who are moving on to the C#.NET platform.


And we are now porting actively all the existing business logic over into the new framework. So I'm hoping after Christmas that every one of our developers will be working on new product, new code.
Ron: And do they find it pretty easy to transition to.NET development?
John: Yeah, I think so, they've all done C# training, most of them haven't come recently from a C# programming background, and they are finding the move quite nice. They have all had Microsoft training on that, they have all come back smiling, and they are all rubbing the headlights to start off with, but they are finding their way through it.


And because we have provided framework and framework examples for them, they are working in a contained space. So we haven't said to them 'Right, go away, write yourself a windows application in.NET' they are saying, 'Write a payroll function.'


And they have got the templates to start with, and the frameworks to go to. And we've got a series of support architects and developers who have been through the process before, who are helping them on a day to day basis. And we are bringing in good technologies, like peer reviews, documentation before we code, unit tests, and all that stuff.
Ron: So in terms of.NET, are you going.NET two or.NET 3, or have you made a decision there?
John: .NET two today. We are dealing with data and situations which are mission critical, we can't afford at the moment to be on the bleeding edge. But also we absolutely have to be on a current platform, and.NET two is the current platform.


We also don't yet know where our clients are going to be in terms of work stations and stuff like that, so we have to be a little careful of that one. But we'll be developing our core application on.NET 2, and then as we start to do special applications like I'm talking of developing a special user interface application, just specifically for writing business rules, custom rules.


We might use.NET three for things like workflow foundation and stuff like that for doing those things.
Ron: Yeah, I would think the business rules supporting workflow foundation would be especially helpful for you guys. But you also have this kind of legacy of business rules that people have build in the macro language you talked about as well, right?
John: Precisely. And the goal of the regeneration project, which is what we are calling this transition to.NET, is a hundred percent compatibility with the old rules, because the biggest issue is regression tests.
Ron: Yeah.
John: So I've got to be able to run the brand newly regenerated products against the latest version of our old products, check that everything is identical, and then we can enhance the product to take it forward.
Ron: Let me ask you about the database side of this, because you said that in the previous version of the product you supported SQL and Oracle, is that right?
John: Yeah, and a flat-file database. And we've taken out support for the other two now, we're just on SQL server.
Ron: OK, but when you have like the legacy database, you have there the structure of that database and whatever comes with, and if you are going to install a new version you are going to have to do some kind of data migration projects, and those sort of things, those are big headache's. What's you strategy there?
John: Every time we release a new major version of the product there are database changes, so we have an ongoing data management and database upgrade philosophy going through there. So it's build in to the team, it's build in to the products, and the product checks for the right version of the databases there.


So we'll carry on doing that. But we're hoping to use... The big error for us is when we bring new clients on board, data loading is quite a big issue. So currently we've had our own tools for doing that, but I think we are going to look at stuff like DTS in the future, combined with business logic to make sure we are introducing the right referential dependencies.
Ron: Oh yeah, OK. Yeah that would be a good choice, because it gets you in the right place there. Wow, well this is exciting, to see the work that you guys are doing, and moving forward onto.NET. Thank you so much for taking the time to share it with me today.
John: Thank you for coming in, hope to see you again when we've done it.
Ron: All right.


[radio break]
Man 1: Hey Ron.
Ron: Hello.
Man 1: It's been a heck of a week.
Ron: It has been, and I was thinking there is some sheep out here, and I've always wanted to try sheep shearing, you know, that's a big thing here in New Zealand, so what do you say?
Man 1: Well, we haven't got the sheers with us mate, and the Australians, well they would just laugh at us.
Ron: OK. Wow, you know it's been fantastic here in New Zealand, to meet a lot of companies, there's a lot more than just sheep going on here. And I was particularly interested in the story about Kiwi Bank, and they mentioned how Microsoft helped them. So how does a customer get involved with Microsoft, to where they get the kind of help, like what you did for Kiwi Bank?
Man 1: Yeah, it really depends on the type of organization, so if you're an ISV, that's an Independent Software Vendor, somebody who develops software for sale, then there's the touchdown with seeing partners.


If you're an organization like Kiwi Bank where you're an enterprise, then there's a program called In-price guide, which is the program that Kiwi Bank used. So there is a variety of ways that we can engage with customers, and quite often involve partners.


Partners can actually be critical to the process of actually helping people, reduce the risk out of adopting new technologies.


[music]
Ron: All right, well that's the story here from New Zealand, and it's a sunny summer day here in December. But you know, that's how it's like down under, so we'll see you next time in New Zealand.


What can I say about that, what an awesome time to just learn so much about architecture, you know. And people often tell me they listen to ARCast because they want to learn architecture, and how to be an architect.


We covered everything in there, from understanding the business strategy, dealing with failed strategies that came from the past, dealing with legacy applications, aligning the strategy to the business model of the future.


I mean, man, I got to tell you, I loved that interview, that was one of my favorite ones of all time. And you know, it's just fun to learn what people are doing, and how they are doing it, how they are grappling with it, that's what we do here at ARCast.


Hope you enjoyed that. If you did, send me a note at arcast@microsoft.com. We'll see you next time on ARCast TV.
Voiceover: ARCast TV is a production of the Microsoft Architecture Strategy Team: www.arcast.tv.