Tuesday, November 9, 2010

Architecture is destiny: Why the revolution in business interactions can't work on conventional database stacks

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: Workday.

Additional resources:

The Real SaaS Manifesto (whitepaper)
Things Large Enterprises Need to Know About SaaS
Strength from the Core: Why Bolted-On BI Doesn't Work for HR
Built-In Business Intelligence
Real Saas
Notes from Workday's Technology Summit

How do IT architectures at software-as-a-service (SaaS) providers provide significant advantages over traditional enterprise IT architectures?

We answer that "Architecture is Destiny" question by looking at how one human resources management (HRM), financial management and payroll SaaS provider, Workday, has from the very beginning moved beyond relational databases and distributed architectures that date to the mid-1990s.

Instead, Workday has designed its architecture to provide secure transactions, wider integrations, and deep analysis off of the same optimized data source -- all to better serve business needs. The advantages of these modern services-based architecture can be passed on to the end users -- and across the ecosystem of business process partners -- at significantly lower cost than conventional IT.

Join here a technology executive from Workday, Petros Dermetzis, Vice President of Development there, to explore how architecting properly provides the means to adapt and extend how businesses need to operate, and not be limited by how IT has to operate. The discussion is moderated by BriefingsDirect's Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:
Dermetzis: We have a unique opportunity to stand back and see what history and evolution provided over the past 20 years and say, "Okay, how can we provide one technology stack that starts addressing all those individual problems that started appearing over time?"

If you think of the majority of the systems out there, the way we describe them is that they were built from the ground up as islands. It was really very data-centric. The whole idea was that the enterprise resource planning (ERP) system gave all the solutions, which in reality isn't true.

What we tried to do at Workday was start from a completely white sheet of paper. The reality around ERP systems is actually making all this work together. You want your transactions, you want your validations, you want to secure your data, and at the same time you want access to that data and to be able to analyze it. So, that’s the problem we set out to do.

What drove our technology architecture was first, we have a very simple mentality. You have a central system that stores transactions, and you make sure that it's safe, secure, encrypted, and all these great words. At the same time, we appreciate that systems, as well as humans, interact with this central transactional system. So we treat them not as an afterthought, but as equal citizens.

If you go back in time to when mainframes started appearing, it was about transactions, capturing transactions, and safeguarding those transactions. IT was the center of the universe and they called the shots. As it evolved over time, IT began to realize that departments wanted their own solutions. They try to extract the data and take them into areas, such as spreadsheets and what have you, for further analysis.

We want to take it more to an area which is business interactions, and interactions can happen from humans or machines.



ERP solutions evolved over time and started adding technology solutions as problems occurred. They started with a need to report data and very quickly realized it was like climbing a ladder of hierarchic needs. When you get your basic reporting right, you need to start analyzing data.

The technologies at the time, around the relational models, don’t actually address that very well. Then, you find other industries, like business intelligence (BI) vendors, appeared who tried to solve those problems.

The way things evolved, you started with an application, and integrations were an afterthought; they got bolted on. ... They kept on adding more and more and more layers of vendors, and the more the poor enterprise IT customers are trying to peel it, the more they start crying -- crying in terms of maintenance and maintenance dollars.

Old approach won't scale

Right now, the state of the art is hard-wiring most of these central solutions to these third-party solutions, and that basically doesn't scale. That’s where technology kicks in and you have to adopt new open standard and web services standards.

What we try to do at Workday is understand holistically what the current problems are today, and say, "This is a golden opportunity." This is opposed to finding all existing technologies, cobbling them all together, and trying to solve the problems exactly the same way.

If you're managing any system with HRM systems, you need to communicate with other systems, be it for background checks, for providing information to benefit providers, connecting to third-party payrolls, or what have you.

Obviously, [traditional ERP vendors] were solving the problem incrementally, as they were going along. What we tried to do was address it all in the same place. Where we are right now is what I would describe as very business transaction-centric in what I define as legacy applications. Then, we want to take it more to an area which is business interactions, and interactions can happen from humans or machines.

We're creating a revolution in the ERP industry. As always, you have early adopters. At the other end of the bell-shaped curve, you've got the laggards. When you're talking to forward thinking, modern thinking, profit-oriented, innovative companies, they very quickly appreciate that the way to go is SaaS.

Now, they've got a bunch of questions, and most of the questions are around security -- "Is my data safe?" We have a huge variety of ways of assuring our customers that these are actually probably safer in our environment than on-premise.

Some customers wait, and some will just jump in the pool with everyone else. We are in our fifth year of existence, and it’s very interesting to see how our customers are scaling from the small, lower end, to huge companies and corporations that are running on Workday.

A blast from the past

Applications are built on top of relational databases today, and then they are being designed thinking about the end-user, sitting in front of a browser, interacting with the system. But, really they were designed around capturing the transaction and being able to report straight-off that transaction.

However, all the business logic, all the security, and the whole data structure that hangs together, is known by the application and not by the database.



The idea of integrating with third parties was an afterthought. Being an afterthought, what happened was that you find this new industry emerging, which is around extract, transform and load (ETL) tools and integration tools. It was a realization that we have to coexist within the many systems.

What happened was that they bolted on these integration third-party systems straight onto the database. That sounds very good. However, all the business logic, all the security, and the whole data structure that hangs together is known by the application -- and not by the database. When you bolt-on an integration technology on the side, you lose all that. You have to recreate it in the third-party technology.

Similarly, when it comes to reporting, relational technology does a phenomenal job with the use of SQL and producing reports, which I will define as two-dimensional reports, for producing lists, matrix reports, and summary reports. But, eventually, as business evolves, you need to analyze data and you have to create this idea of dimensionality. Well, yet another industry was created -- and it was bolted back onto the database level, which is the [BI] analytics, and this created cubes.

In fact, what they used were object-oriented technologies and in-memory solutions for reasons of performance to be able to analyze data. This is currently the state of the art.

The same treatment

Conversely, any request that comes into our system, be it from a UI or from a third-party system by integrations, we treat exactly the same way. They go through exactly the same functional application security. It knows exactly what the structure of your object model is. It gets evaluated exactly the same way and then it serves back the answer. So that fundamental principle solves most of our integration problems.

On the integration side, we just work off open standards. The only way that you can talk with a third-party system with Workday is through web services, and those services are contracts that we spec to the outside world. We may change things internally, but that’s our problem.

That’s the point where we have a technology around our enterprise service plus our integration server that actually talks the language that we do, standards web service based. At the same time, it's able to transform any bit of that information to whatever the receiving component wants, whether it’s banking, the various formats, or whatever is out there.

We put the technology into the hands of our customers to be able to ratchet down the latest technology to whatever other files structures that they currently have. We provide that to our customers, so they can connect them to the card-scanning systems, security systems, badging systems, or even their own financial systems that they may have in house.

We're a SaaS vendor, and we do modify things and we add things, but those external contracts, which are the Web services talking to third-party systems, we respect and we don’t change. So, in effect, we do not break the integrations.

Best way to access data

The next architectural benefit is about analyzing data. As I said, there are a lot of technologies out there that do a very good job at lists and matrix reporting. Eventually, most of these things end up in spreadsheets, where people do further analysis.

But the dream that we are aiming for continuously is: When you are looking at a screen, you see a number. That number could be an accumulation of counts that you'd be really interested in clicking on and finding out what those counts are -- name of applicants, name of positions, number of assets that you have. Or, it's an accumulation. You look at the balance sheet. You look at the big number. You want to click and figure out what comprises that number.

To do that, you have to have that analytical component and your transactional component all in the same place. You can't afford what I call I/Os. It's a huge penalty to go back and forth through a relational database on a disk. So, that forces you to bring everything into memory, because people expect to click something and within earth time get a response.

The technology solutions that we opted for was this totally in-memory object model that allows us to do the basic embedded analytics, taking action on everything you see on the screen.



When you are traversing, you come to a number in a balance sheet, and as you're drilling around, what you are really doing in effect is traversing an object model underneath, and you should be able to get that for nothing.

The technology solutions that we opted for was this totally in-memory object model that allows us to do the basic embedded analytics, taking action on everything you see on the screen.

So the persistence layer is really forced by the analytical components. When you're analyzing information, it has to perform extremely fast. You only have one option, and that is memory. So, you have to bring everything up in-memory.

We do use a relational component, but not as a relational database. We use a relational database, which is what it’s really good at securing your data, encrypting your data, backing up your data, restoring it, replicating it, and all these great utilities the database gives you, but we don’t use a relational model. We use an object model, which is all in-memory.

But, you need to store things somewhere. In fact, we have a belief at Workday that the disk, which is more the relational component, is the future tape. What you used to use in legacy system was putting things on tape for safety and archiving reasons. We use disk, and we actually believe, if you look at the future, that nearly everything will be done exclusively in-memory.

Make way for metadata

And, there is another bit of technology that you add to that. We're a totally metadata-driven technology stack. Right now, we put out what we describe as updates three times a year. You put new applications, new features, and new innovations into the hands of your customers, and being in only one central place, we get immediate feedback on the usage, which we can enhance. And, we just keep on going on and keep on adding and adding more and more and more.

This is something that was an absolute luxury in your legacy stack, to take a complete release. You have to live through all the breakages that we mentioned before around integrations and the analytical component.

As soon as you can have the luxury of maintaining one system, let's call it one code line, and you're hanging our customers, our tenants, off that one single code line, it allows you to do very, very frequent upgrades or updates or new releases, if you wish, to that central code line, because you only have to maintain one thing.

Multi-tenancy is also one of the core ingredients, if you want to become a SaaS vendor. Now, I'm not an advocate of saying multi-tenancy A is better than multi-tenancy B. There are different ways you can solve the multi-tenancy problems. You can do it at the database level, the application level, or the hardware level. There’s no right or wrong one. The main difference is, what does it cost?

All we're looking at is one single code line that we have to maintain and secure continuously.



We believe in one single code line, and multiple tenants are sharing that single code line. That reduces all our efforts around revving it and updating it. That does result in cost savings for the vendor, in other words, ourselves.

And as far back as I can remember, when humans realized that you take time and material, package that for a profit, and send it to your end-market, as soon as you can reduce your cost of the time or the material, you can either pocket the difference, or move that cost saving onto your customers.

We believe that multi-tenancy is one of the key ingredients of reducing the cost of maintenance that we have internally. At the same time, it allows us to rev new innovative applications out to the market very quickly, get feedback for it, and pass that cost savings on to our customers, which then they can take that and invest in whatever they do -- making carpets, yogurt, or electric motors.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: Workday.

Additional resources:

The Real SaaS Manifesto (whitepaper)
Things Large Enterprises Need to Know About SaaS
Strength from the Core: Why Bolted-On BI Doesn't Work for HR
Built-In Business Intelligence
Real Saas
Notes from Workday's Technology Summit

You may also be interested in:

Cloud-based commerce network helps Florida manufacturer MarkMaster reach new markets, streamline transactions

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: Ariba.

Businesses are increasingly using cloud and e-commerce to improve how they do sales, marketing, and online transactions.

One smaller company, Tampa-based MarkMaster, has quickly moved to nearly all-paperless sales transactions, found new customers via online networks, and increased the amount of product it sells to its existing clients. This was accomplished without a lot of additional IT or business-process spending by using cloud-based collaborative business commerce solutions.

To learn more about how MarkMaster is conducting its business better, BriefingsDirect's Dana Gardner, Principal Analyst at Interarbor Solutions, recently interviewed Kevin Govin, the CEO at MarkMaster.

Here are some excerpts:
Govin: E-commerce has definitely changed our reach, which is national and international. We have a plant in Birmingham, England, that we fulfill from as well for our American-based companies. We service nine of the top 10 banks in United States. We do eight of the top 10 insurance companies. Without cloud computing, there's just no way we would have even considered doing that. ... This all has been just a godsend for us.

It's totally changed our business. I laughed a little bit at your intro, when you talked about going "paperless." One of our main product lines is rubber stamps, and it seems counter-productive to go paperless with what we do.

Yet we have changed a lot. Now, 95 percent of our orders come electronically. We have one location in the United States that services all of the US and Europe. How could we do that without some kind of cloud transacting? It just makes the most sense. Over the last 10 years, I think 99 percent of our new customers have been coming through those kinds of systems.

Most of our products are considered office supplies. So, I have to look like the big Office Maxes, Office Depots, and that kind of thing. That’s how we present ourselves. Even though we're the biggest in our industry, we're still a small company.

We deal mostly with Fortune 500 companies. We sell rubber stamps, name badges, name plates, and interior/exterior signage. It's a unique field, kind of a niche market, as rubber stamps are a mature market. But, we seem to be gaining market share, so that’s been great for us.

Top-line, our sales are growing at least 10 to 15 percent a year for the last 10 years, and that’s the same time-frame that we’ve been on e-commerce and now cloud computing. So we have to believe that that’s a lot of it. Our industry is shrinking as well. There were 1,200 rubber stamp makers, now there are 400.

Quick turnaround from cloud

We definitely use the cloud-computing models to go out and sell. There is nothing jazzy about a rubber stamp. Name badges are pretty much specified by the customers. So, we are not out there selling anything new or exciting as far as that’s concerned.

But we have changed our model, and our salespeople don’t travel with the product. They travel with the computer and they show what we can do online and what kinds of services we can provide.

The investment in hardware has actually come down over time, but we do like to keep up today with the current technologies.



We can turn around on a customer in two days, because it's just all uploading something. There are no ports to connect or anything highly technical at all.

Because both on the buyer and the supplier supply side we are having hosted solutions or in the cloud it makes it a lot easier. There used to be a real reluctance from the customers to want to put us on board, because I might only be $100,000 year in spend, and they were going to outlay a lot of IT to connect me.

Now, with the cloud solutions, there is very little IT on either end. I'd imagine that it's even easier now than it was with the paper system before, because we can communicate to their end-users that we’re out here, and we’re ready to be bought from.

We work heavily within the Ariba network, and because of that, now we are an Ariba Silver supplier. So, there's a lot of pluses that go with that, and we use a lot of banner ads and things like that.

e’re posted out on Ariba’s Discovery area, so they can find us very easily, and when they look at that, they see number of connections, and we get instant credibility on top of that. Then, of course, we even use the Ariba LIVE event. That’s huge for us, because it puts us in front of all those users that are looking for somebody like us.

One of the larger banks that we deal with, when we originally started with them, weren’t even considering us as a supplier, but they found us on the Ariba Discovery network. They called us and said, "Can you really do all of this. You're a small supplier?"

We showed them our list of what we have, where we’d already made Silver. So they knew we were vetted already by the supplier and we ended up with the business. It wasn't necessarily in a RFQ kind of environment either. It was "Wow. You can do this, and you’re the supplier we want and, in our case, you’re a minority supplier." So, it was just having that all together.

Can't always be there

But, they found us on Ariba. We didn’t solicit them. I mean, we had been soliciting them, and they knew of us, but we can't always be there when the customers need these products now. It's just too hard, because our products are needed everyday. So, that came out very well for us.

Bottom-line, we have had year-over-year growth, and our customer service department has not grown, or added anybody to that staff. How does that work, because we've grown exponentially? The reality is online systems.

We proactively give them the information as to the status of their order, and they can actually see it go through our plan step-by-step. Does everybody need that information? No, but it does keep them from calling customer service. So it’s definitely changed.

Now, 10 years ago, we were 95 percent paper, and it's just totally flipped. So, you can count on your hand the overhead that this gets rid of.

We’re always talking about is transacting in the cloud and getting orders and billing. The billing part is where we want our customers to go next, because it seems like the front-end integration is great, but on the back end there are 100,000 different ways that people want us to bill them and get paid -- EDIs or ACH or whatever.

We see it coming. People are migrating to the pay element, so that everything is integrated, and that’s great for us. It turns money faster. I don’t deal with credit cards as much, all of which cost me a lot of overhead.

Remember, my products are $5 or $6. People buy one at a time. So, handling invoices is just a nightmare. I get 20,000 invoices every day. We need to upload them, link them, and know the bill is okay.

My clients are not the kind of clients that aren’t paying me because they don’t have the money. They're the kind of clients that aren’t paying because I didn’t do the paperwork correctly. So having that end-to-end order-to-pay integration is where we see it's coming next for us in integrating the whole cycle. Some of my larger banks have definitely gotten on-board with that and it's great, and for a small company, it changed my cash-flow as well.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: Ariba.

You may also be interested in:

Monday, November 8, 2010

WSO2 debuts Carbon Studio as a speedy IDE for SOA and composite applications

WSO2 recently announced the debut of WSO2 Carbon Studio, an Eclipse-based integrated developer environment (IDE) for WSO2 Carbon.

The new offering allows users to build service-oriented architecture (SOA) and composite applications based on WSO2 Carbon. [Disclaimer: WSO2 is a sponsor of BriefingsDirect podcasts.]

Highlights of WSO2 Carbon Studio include the ability to:
“We have found that many of our customers are developing sophisticated applications that span the WSO2 Carbon product family, and they are taking advantage of the unique strengths of our platform when used as a whole,” said Dr. Sanjiva Weerawarana, founder and CEO of WSO2. “We’re now revving up our tooling support with WSO2 Carbon Studio—helping developers to organize, develop, test, and deploy these composite applications with greater ease than ever before.”

Middleware platform

The WSO2 Carbon Studio IDE is designed to take advantage of the open source WSO2 Carbon middleware platform. The Eclipse-based offering includes graphical editors for XML configuration files, an enhanced Eclipse BPEL editor, and easy integration of Carbon-based applications with the WSO2 Governance Registry. Additionally, Carbon Studio offers a rich set of third-party Eclipse plug-ins, including Maven and the OpenSocial Gadget Editor.

We’re now revving up our tooling support with WSO2 Carbon Studio—helping developers to organize, develop, test, and deploy these composite applications with greater ease than ever before.



Carbon Studio supports SOA projects that often combine multiple application types into a single composite application or service. Developers also have single-click function for testing Java-based applications and services—without leaving the IDE. Debugging tools support Axis2-based services, Apache Synapse mediators, registry handlers, and data validators.

Tools to support SOA development include Apache Axis2 and JAX-WS, Data Service, BPEL, ESB, and ESB Tooling, as well as a gadget editor.

WSO2 Carbon Studio, available now as a set of Eclipse plug-ins, is a fully open-source solution released under Eclipse and Apache Licenses and does not carry any licensing fees. WSO2 offers a range of service and support options for Carbon Studio, including development support and production support.

You may also be interested in: