Monday, November 22, 2010

Kapow launches data integration platform for rapid data delivery to multiple devices

Kapow Software (formerly Kapow Technologies) last week launched Kapow Katalyst 8.0, which promises rapid integration and delivery of data to any application and any device without a lot of heavy API lifting.

At the heart of the Katalyst platform is the patented Kapow Extraction Browser, a browser-based data integration engine designed to support data extraction from enterprise, web and cloud applications without the need for existing application programming interfaces (APIs).

The new platform from the Palo Alto, Calif. company is equipped with features that support collaboration among different departments, business stakeholders, application developers and IT, allowing them to deploy Kapow for their most strategic enterprise data integration projects. [Disclosure: Kapow Software is a sponsor of BriefingsDirect podcasts.]

New to Kapow Katalyst is a web-based management console that improves cross-departmental and cross-functional collaboration around strategic integration projects. Compliant with today’s enterprise IT infrastructure and security requirements, it allows Kapow Katalyst users to leverage their current IT investments. The new console also enables IT to continuously monitor the status of their organization’s entire production system across the enterprise to ensure maximum performance, governance and security.

Other features

Other features include:
The explosion of web data in the enterprise as well as applications without APIs, including web, cloud and mobile apps, creates new challenges for data integration projects. At the same time, rapid data delivery has emerged as the top strategic priority for many businesses. Traditional integration methods take months or years to rewrite applications, receive an API from the data provider, customize published APIs, or manually cut and paste data between different sources, making it difficult to extract, transform and deliver the data where and when it’s needed.

Cost, complexity, resistance to custom code, and avoidance of massive integration projects are all driving the need for efficient data integration using open web, mobile web and data standards.



Cost, complexity, resistance to custom code, and avoidance of massive integration projects are all driving the need for efficient data integration using open web, mobile web and data standards. That's a big reason why the number of web, cloud, and mobile applications delivered without the hassle of custom APIs are growing daily. Kapow is well positioned to help enterprises attain swift and lower-cost data integration -- and to also extend the benefits of that data and associated intelligence out to the web and mobile user.

Kapow’s “browser-based data integration” approach eliminates the need for IT to use APIs for data integration, saving time and money by avoiding manual coding costs. Kapow Katalyst automatically extracts, transforms, integrates and migrates data to and from any application and device.

The platform’s main solution areas include cloud/SaaS integration, partner integration, business process automation, mobile enablement, social media monitoring, market intelligence, automated web data extraction and open source intelligence.

Kapow Katalyst is available now. For more information, visit www.kapowsoftware.com.

You may also be interested in:

Tuesday, November 16, 2010

Why HTML5 enables more businesses to deliver more apps to more mobile devices with greater ease

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

The rapidly changing and fast-growing opportunity for more businesses to reach their customers and deliver their services via mobile applications is at a crossroads.

Over just the past two years, the demand for mobile applications on more capable classes of devices, such as smartphones and tablets, has skyrocketed. Now businesses need to figure out how they can get into the action.

Small and medium-size businesses (SMBs) especially need to reevaluate their application development and end-user access strategies to be able to deliver low-cost yet impactful applications to these newer devices. This goes for reaching employees, as well as partners, users, and customers.

Hopefully, there's a shift in the skills required to put these applications on these devices and distribute them. The emphasis on capabilities is moving from hardcore coders -- with mastery of embedded platforms and tools -- to more mainstream graphical and scripting-skilled workers, more power-users than developers.

This sponsored podcast explores how mobile application development and the market opportunity are shifting, and how more businesses can quickly get into the mobile applications game and build out new revenue, share more data, and provide better direct customer access in the process.

Our panel consists of Roger Entner, Senior Vice President and Head of Research and Insights in the Telecom Practice at the Nielsen Co., and Wayne Parrott, Vice President for Product Development at Genuitec. The discussion is moderated by BriefingsDirect's Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:
Entner: About 50 percent of all devices being sold in the US right now are smartphones. We expect smartphone penetration to be at about 50 percent by the end of next year. Almost 60 percent of smartphone owners are actually using applications. That’s a huge percentage.

We're now at that sweet spot where it makes a lot of sense for businesses to have applications both for their consumers and their employees alike, because there is enough of an addressable base there.

We just launched our second edition of our Mobile Apps Playbook. But to quote numbers from there, year-over-year second quarter '09 to second quarter '10, smartphone penetration in the US went from 16 percent to 25 percent.

Now, we have 3- and 4-inch screens that are actually readable. We're not just merely replicating a desktop experience, but actually tailoring it to the device and working with the strengths of the device rather than with the weaknesses.

The devices that we call now smartphones are little computers that today are as powerful as laptops a few years ago. I always say that this little thing you have in your hands, a smartphone, has far more computing power than was used by NASA to put men safely on the moon and bring them back alive.

Applications becoming easier

And now Apple, Google, Microsoft, and the others, have software development kits (SDKs) out there that make app development a lot easier than it has ever been.

If you have a talented developer or a talented person in your department, he might be able to build that internally. Or, there are now myriad development shops out there that have the capabilities to build applications and charge only a few thousand dollars -- and that's single digit thousand dollars -- to have a capable, usable application.

There are a lot more people who know how to program these things, and have good ideas of applications. There is a really good market out there to put the two together.

Parrott: We’re seeing a big move toward interest in mobile at the development side. What are the factors that’s really led to the explosion of mobile apps? It's not only the smartphones and their capabilities, but we also look at the social changes in terms of behavior.

People more and more have a higher reliance on their smartphone and how they run their lives, whether they are at work or on the move. The idea is that they are always connected. They can always get to the data that they need.

Basically, we're taking their lifestyle away from their desktop and putting it in their pocket as they move around. More and more, we see companies wanting to reach out and provide a mobile presence for their own workforce and for their customers.

The question they ask is, "How do we do that? We already have a web presence. People have learned about our brand, but they can't access this through their smartphones, or the experience is inferior to what they’ve come to expect on the smartphone."

We're seeing a big growth of interest in terms of just getting on to the mobile -- having a mobile presence for the SMBs.

Still a great deal of complexity

If you take a look at the current state of native mobile app development, it's really not much better than it was five years ago. You still see a strong fragmented programming model base, different operating systems, and different hardware capability. It's still a mess. You pretty much have to pick a subset of devices that you want to focus on.

Entner: If we take one little step back, one of the genius things that Apple has done is turn the bookmarks into an application. About 60-70 percent of all applications on the iPhone or an Android are actually glorified HTML ports. So, it's not that difficult or that demanding on the application side.

One new trend is HTML5, which is slowly but surely approaching. There has been no finalized HTML5 standard [from the W3C], but a lot of web browsers, and even mobile web browsers, have now some HTML5 capabilities. And, it will really help in the development cycle for basic applications.

Where HTML5 will not to be able to help us, at least right now, is when we try to take advantage of location-based services because there is no standard yet. They're still arguing about this one, and especially high performance graphics. But, on the standard application, HTML5 will take us miles forward and diminish the difference between the desktop and the mobile environment.

... At the same time, all of the SDKs are getting more powerful and more user-friendly. So, it's moving toward a more harmonized and more rapid development environment.

Parrott: Prior to HTML5 talking about mobile web was pretty much a joke. Mobile web was an afterthought in the phone market. You had these small, dinky displays. Most of them couldn't even render most standard HTML. What's new?

You still see a strong fragmented programming model base, different operating systems, and different hardware capability. It's still a mess.

With the advent of the smartphone what you really saw was pretty much the Internet, as you experience it on your desktop, now on to your smartphone, but with even more capability.

Part of it is because HTML5 has stepped back and looked at what the future needed to be for a web programming model. To become more of a common run-time, they had to address some of the key gaps between native hardware, APIs, and web. Much of those have really centered on one of the biggest digs that mobile web had in the old days, when you were doing something, were connected, and then you lost your connectivity.

Out of the box

HTML5, right out of the box, has a specification for how to operate in an online, offline, or disconnected type mode. Another thing was a rendering model, beyond just what you see on your desktop, that actually provides a high-end graphics type capability -- 2D, 3D types of programming. These are things that more advanced programs can take advantage of, but you can build very rich desktop type of experiences on the laptop.

Then, they went beyond what you're used to seeing on your desktop and took advantage of some of the sensors that these phones have now -- accelerometers, location capability, or geolocation. APIs are now emerging as a companion to HTML5, which is a spec that will span across your desktop to the mobile phone. It's a very capable specification.

In addition, there is the movement in terms of the standards body, especially the W3C, to address mobile device API. You will eventually program in a standard way and talk to your contacts list, your cameras, video, recording devices, and things like that. That will soon be available to us in a web programming model.

What used to be exclusively the demand of the hardware API guys to do really low level, high performance bit twiddling is now going to be available to the general web programming masses. That opens up the future for a lot more innovation than what we’ve seen in past.

There is enough HTML5 core already emerging that we could start to program to a subset of that spec and treat it as kind of a common run-time that you would program across pretty much all of the new emerging smartphones as we look forward.

Entner: It's only a matter of when ... HTML5 will come. Apple and Google are at the forefront and are already launching websites and services in it. You can get HTML5 YouTube, HTML5 Google, and even Yahoo mail access. You can have the Apple website in HTML5. It just depends on what is fully supported right now.

Some browsers support it, and some don't yet. On the mobile side, it also fully depends on what is supported. If you have the WebKit engine at the core of the browser that your device is using, HTML5 is pretty widely supported.

Parrott: As we've talked to more-and-more of our SMBs, one thing that stands out is that they don't have a lot of resources. They don't have a huge web department. Their personnel wear a number of hats. Web development is just one of n things that one of the individuals may do in one of these organizations.

At Genuitec, we developed a product called MobiOne Studio. The target user is anyone who has an idea or an vision for a mobile web application or website. MobiOne is geared to provide a whole new intuitive type of experience, in which you just draw what you want. If you can develop PowerPoint presentations, you can create a mobile web application using MobiOne.

You lay out your screens, you pane them all up, and then you wire them together with different types of transitions. From there, you can then immediately generate mobile web code and begin to test it either in the MobiOne test environment, that's an emulated type of HTML5 environment, or you can immediately deploy it through MobiOne to your phone and test it directly on a real device.

If you can develop PowerPoint presentations, you can create a mobile web application using MobiOne.



With MobiOne Studio we recognized that the first thing that most companies want to do is just mobilize, just get a mobile presence, mobilize their websites, and have that capability. As Roger said a while ago, a lot of the apps you see out there are really glorified mobile websites and are packaged up in a binary format.

Second Studio phase

In MobiOne Studio's second phase, once you design and you like what you have, you have a progressive step that you can go from a very portable form to compile it down -- or cross-compile -- from HTML5 to whatever the native requirements are of that particular target app store. So, Google will have their app store, and Apple and RIM each has their own model. They are all fairly different models.

But with HTML5, you can go directly to your customers now. You can market to them directly. It depends on your way of interacting with your customers, but we have seen a number of novel approaches already from some of our customers. When any customer is in your store, you make it very easy for them to access your site, to make them aware of your mobile capabilities, lure them in, and get them connected that way.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or download a copy. Sponsor: Genuitec. Learn more.

You may also be interested in:

Monday, November 15, 2010

Veryant introduces isCOBOL for HP OpenVMS Systems

COBOL and Java provider Veryant today announced that its isCOBOL Application Platform Suite (APS) now runs on HP’s OpenVMS operating system, providing an alternative to HP COBOL. The announcement extends Veryant’s support for multiple platforms, including HP-UX, IBM AIX, Linux, Oracle Solaris, and Microsoft Windows.

The Phoenix, Ariz. company's isCOBOL software streamlines application development by enabling users to maintain a single set of COBOL source code for multiple platforms. The compiler is written completely in Java and is portable, allowing developers to compile programs on their platform of choice and then deploy to any number of environments, instead of maintaining a separate set of source code using HP COBOL for OpenVMS distributions.

With its 'write once, run anywhere' capabilities, isCOBOL will simplify ongoing maintenance and modernization.



“A series of tests using isCOBOL APS and HP COBOL for OpenVMS verified comparable performance,” explained Dovid Lubin, vice president of Technical Operations at Veryant. “With its 'write once, run anywhere' capabilities, isCOBOL will simplify ongoing maintenance and modernization activities for organizations with COBOL-based OpenVMS applications.”

Because isCOBOL-compiled programs run on any device that supports a Java Virtual Machine, it provides a solution for thin client deployment, as well as the ability to expose COBOL business logic directly to a browser, as a Web Service or Java Servlet, without changing back-end program code.

isCOBOL APS extends new data access and distribution flexibility to businesses with OpenVMS assets. isCOBOL applications accessing ISAM files can harness the power of relational database management systems (RDBMs) such as Oracle Database or MySQL without any changes to program code. OpenVMS users can continue using existing data sources on the isCOBOL platform by leveraging ESQL statements or automatically executing COBOL file I/O statements as JDBC calls.

You may also be interested in:

rPath rBuilder 5.8 targets 'deployment dysfunction' for Windows apps, expands from Linux base

The lives of IT admins in Windows environments should get a little easier with the launch of rPath's rBuilder 5.8 for "push-button" deployment of Windows Server instances.

The Raleigh, N.C. company's rBuilder 5.8 introduces release automation to the world of Windows Server applications. With the new software, rBuilder 5.8 earns bragging rights as a first commercial solution to address deployment automation for Windows instances and apps. [Disclosure: rPath is a sponsor of BriefingsDirect podcasts.]

The deployment challenge

For most IT organizations, deploying Windows apps into production is complex, cumbersome, and time-consuming. That complexity can lead to long delays in full deployments that leave a dark cloud hanging over service levels and business agility.

The rise of public cloud services such as Amazon EC2 has further motivated IT to become more responsive to business lines.



With its automation approach, rBuilder 5.8 is wrestling that challenge to the ground with what it calls “push-button deployment” of Windows apps. This software helps to automatically resolve dependencies to virtually eliminate deployment-time failures, automatically generate standard MSI packages that are ready to deploy, apply version control to all packaged elements, and eliminate drift between dev, test, and production release stages, says rPath.

rBuilder 5.8 also generates image output on demand for rapid deployment or retargeting between physical, virtual, and cloud environments, makes way for targeted changes for low-overhead, conflict-free maintenance, and provides a single enterprise solution for automated deployment of any application, running any platform, deployed to any execution environment -- physical, virtual, or cloud, said rPath.

There are some more resources available on the capabilities and new release: Attend a free, live webinar Nov. 16; watch a short video; read a whitepaper, and learn more.

The need for deployment speed

Deployment dysfunction is a primary source of delay in delivering IT services in response to business demand. The rPath solution also works to complement Microsoft development and operating environments, including Team Foundation Server and System Center Configuration Manager.

With some 70 to 80 percent of IT spending due to operating expenses, nearly half is attributable to deployment-related tasks. This is particularly true for Microsoft Windows environments, which constitute 74 percent of the data-center server market. If rBuilder 5.8 lives up to its promises, it could find a home in many Windows-based IT departments. And it lends a hand in migration and hybrid deployments, too.

rPath has also joined the Microsoft System Center Alliance, a partner community in support of the System Center ecosystem. The System Center Alliance provides an online community that aims to help partners collaborate on the creation of solutions for the System Center and deliver an information resource about these new solutions for customers and sales channel partners.
BriefingsDirect contributor Jennifer LeClaire provided editorial assistance and research on this post. She can be reached at http://www.linkedin.com/in/jleclaire and http://www.jenniferleclaire.com.
You may also be interested in:

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: