Know Your Embedded Database Cost

This post is sponsored by NuoDB.
All thoughts and opinions are my own.

In the move of a software vendor to a SaaS business model, database costs can escalate if the architecture and license model is not built for the cloud.
This blog concludes the Mount Rushmore for choosing the database for software vendors moving to a SaaS business model. I have previously covered SQL functionality, true elasticity, and ACID compliance.  
The database will be replicated throughout your customer base unless it’s shared in a multi-tenant application, which means you’ll be dealing with one large, and very critical, database. Regardless, it is not an exaggeration to say your database vendor choice will significantly define the cost structure to serve your software. If the functionality is covered (for now and the future), it comes down to cost. You will seek a low and predictable TCO for your database, all things being equal.  
License pricing can be complex and unpredictable, even for the same product – and over time. You want to deal with a vendor who is very transparent about costs and promotes their pricing at the Mount Rushmore level.
One common pricing model is per-storage or per-server/per-core. A similar model that database vendors offer is user-based, which can be distinguished by user class. There are also tiered per-distinguished-user model, where you can fit your profile into one of a few user buckets, with descending per-user costs that cost out at a fixed, recalculated cost per year.  
Others use a data source model. I don’t prefer, or recommend for my end clients, cost models that can unduly influence architecture. Architecture should, and can, exist outside of the cost structure for the underlying software. Source pricing penalizes software companies for database count. This model will also create cost chasms to ecosystem growth.
However, the database architecture can drive pricing by providing options. While any database can be placed in the cloud, there are certain cloud features that customers have come to expect from cloud software, yet may not be getting from their database of choice.  One key feature necessary to be cloud-enabled is the ability to independently scale compute and storage through specification of nodes with emphasis on one aspect over the other.  This alleviates compromise in the resource allocation and unused costly resources.
You only pay for what you use, when you use it. Compute and Storage are independently priced. Database software from an on-premises age assumes those are all tightly coupled. In that approach, you are forced to pay for compute and storage even when you aren’t using it.
A solution built for the cloud should allow you to use and pay independently for the storage and compute you need. This arrangement is important to have in the foundation of the cloud database.
NuoDB has this approach to their pricing model. Compute, storage and pricing scale independently. Pricing is lower on a per-core basis as well. Compare list prices to Oracle and SQL Server here.
This architecture also works well if you have seasonality to your data and compute needs. With true elasticity, you get the right compute, storage and pricing for what you need.
If you are creating new product lines or converting an existing product portfolio, the database in the transition is one of the most important decisions. This series has given you the top four database requirements in the move of a software vendor moving to or engaging a SaaS business model: Full SQL functionality, true elasticity, ACID compliance and finally, a costing model that provides low TCO through the ability to separate compute and storage.  Manage your client’s “gold” – their data – and therefore your success, according to these four. Customers will see the value and you will see the agility and the valuation result.

William McKnight is a contributing Analyst at Gigaom. Read Bio »

ACID is instrumental in the move to SaaS

This post is sponsored by NuoDB.
All thoughts and opinions are my own.

When moving an on-premises app to the cloud, software vendors may find the lack of ACID in the database and – therefore the need to code data management functionality into the application – an insurmountable challenge.
This blog continues the series on the top four considerations for choosing the database for software vendors moving to a SaaS business model. In addition to the importance of SQL functionality and true elasticity, there is the importance of ACID. For certain types of applications, eliminating ACID and having to code data management functionality into the application instead of letting the database take care of it creates substantial complications.
ACID stands for atomicity, consistency, isolation, and durability.  Compliance to ACID means that a system supports transactions by guaranteeing the full committal of all or no operations in a transaction.  This ensures the state of the system is always consistent.  In a banking scenario, if I only commit the deposit and the associated withdrawal does not complete, not only is the system inconsistent, but it could be difficult to restore consistency.
Expanding on this (since ACID stands for 4 distinct items, not one), we have…

  • Atomicity – All operations or no operations of a transaction committed – no in between
  • Consistency – The database only has valid and committed transactions
  • Isolation – No views into components of uncommitted transactions
  • Durability – Committed transactions are permanent, and a restore will contain all committed transactions

A significant number of the offerings in the NoSQL and Commercial open source (OSS) camps are fundamentally different from what a Fortune 50 may be used to when it comes to ACID compliance.  So is the lack of ACID compliance a fault in the design or is there a time and place for tools short of ACID compliance?   
Nearly the entire NoSQL movement has emerged by playing up the benefits of non-ACID compliance (and taking advantage of the speed of development) such that it’s almost by definition that NoSQL is not ACID compliant.  I do note that some do provide ACID compliance using eventual consistency and others promote processes and have ACID-light features like “lazy writes” to minimize inconsistencies.
The NoSQL movement plays to the importance of the applications it serves.  It serves a different class of applications than has been tapped to-date with relational database technologies.  
Moreover, many relational applications rely on a strict level of consistency not offered by even the ACID-compliant, eventually consistent NoSQL databases. We should be careful that non-ACID and eventually consistent databases do not step over the line into areas the technology is not suited for.  One way to sum this up is the confession of a leading engineer of a product that he wouldn’t use NoSQL for “money.”
ACID compliance has a psychological side as well. ACID provides a greater comfort level to developers and managers, knowing that data will not be lost no matter what and that all kinds of data can be trusted to the database.
As operational applications (especially with those dealing with valuable and even business-critical  data) increasingly move to the cloud, they often need a database that can combine strict ACID compliance with the elastic scale out and availability advantages that caused people to turn to NoSQL in the first place. Finding an elastic SQL database – like NuoDB – that preserves ACID while providing that elasticity and availability is a valuable alternative for a software vendor moving to SaaS.

Moving to SaaS: Scale With True Elasticity

This post is sponsored by NuoDB. All thoughts and opinions are my own.
The database needs to be able to scale out and in without disruption or delay.
Software vendors moving to a SaaS business model are usually optimistic about the prospects of the product(s) and the company. Making an investment in a change like this implies a hope for growth.
This dynamic has actually been true for the vast majority of the data projects I’ve been involved with at clients. Other than projects done just for regulatory reasons, the hope is that the project takes off and supports sales, new market penetration, product line expansion, etc.
Projecting the growth is exciting, yet difficult, and there is a clear knock-on effect of this on projecting the data growth. Growth estimates are usually wildly off. Projects tend to out-perform expectations (a good problem) or underwhelm and eventually get shut down. Out-performing expectations means more data for the database than anticipated. With scalable systems and proper monitoring, database professionals have been able to adapt, although this has imposed work cycles on the organization.
More importantly, by definition an on-premises system must be over-specified so resources do not run out. On an automatically monitored system with access to practically unlimited and ready resources such as a cloud, the over-specification – and hence your wasted costs – is negligible. This is the promise of the cloud – immediate access to the resources you need.
The exact level of resources necessary should not only be what is provisioned, it is the cost basis.
A cloud database needs to be able to scale out and in without disruption or delay. If it takes hours or days to scale (in a typical relational database, this means up or down) or creates disruption for migration or repartitioning efforts, one of the key benefits is lost. The more granular the growth of the clusters, and the less of a “step ladder” approach to resources, the more elastic the solution is.
Deciding ahead of time what the next rung on the ladder looks like – or negotiating it in haste – is not true elasticity. The more proactive and involved a customer has to be in the process of resource determination, the less elastic the solution is.
If cluster expansion requires either downtime or a series of manual data copying to sync data from an old to a new cluster or database storage capacity is fixed to the node type (compute dense or storage dense), it’s not fully elastic.
This elasticity extends to upgrades. The cloud database software, like NuoDB for example, should be able to be upgraded without any downtime, performance impact or interruption of service.
Software vendors moving to a SaaS business model are in a unique position to appreciate the lack of over-commitment of resources and the cost savings that are leveraged throughout the customer base and should be sure to seek true elasticity in their database of choice.

William McKnight is a contributing Analyst at Gigaom and President of McKnight Consulting Group. Read Bio »

Moving to SaaS: Start with SQL Functionality

This post is sponsored by NuoDB. All thoughts and opinions are my own.
To leverage existing SQL tools and skills when moving to the cloud without significant rework, a solution should support ANSI-standard SQL, not a partial or incompatible variant.
If you’re a software vendor moving to a SaaS business model either by creating new product lines (from scratch or by adding cloud characteristics to existing products) or converting an existing product portfolio, the transition to a SaaS model will impact every aspect of the company right down to the company’s DNA. New software companies typically start with a SaaS model — not on-premises software – so this is more often a common consideration for many legacy software companies today. Customers see the value and software companies see the agility and the valuation result.
 
Ultimately there are major architectural changes that will be required to succeed. It is a good time to do a reevaluation of all major architectural components of the solution, including the underlying database, along with hosting plans, customer onboarding procedures, billing & pricing, security & regulatory, monitoring and the assorted challenges associated with the move to SaaS.
 
In these posts, I will address the top four considerations for choosing the database in the move. The database selection is critical and acts as a catalyst for all other technology decisions. The database needs to support both the immediate requirements as well as future, unspecified and unknown requirements. Ideally the DBMS selection should be one of the first technology decisions made for the move.
There are severe consequences of making an inappropriate DBMS selection including long development cycles related to needing new skillsets or converting existing application code, as well as cost and support expansion.
SQL is the long-standing common language of the database, supported by thousands of tools and known by millions of users.  Backward compatibility to core SQL is essential, particularly for operational applications that rely on the ACID compliance that usually comes hand-in-hand with SQL databases. SQL is essential as you move to the cloud, and it needs to be standard SQL that works everywhere and scales all of the time and for all queries.
To do this, modern databases (such as NuoDB) should support ANSI-standard SQL for both reads and writes, not limited or partial SQL or an incompatible variant as many NoSQL and NewSQL databases do. The SQL 2011 standard is the latest revision and added improved support for temporal databases, time period definitions, temporal primary keys with referential integrity, and system versioned tables, among other enhancements.
SQL remains the most viable and useful method for managing and querying data, and will be a primary language to use in the foreseeable future and should be the foundation for a software move to SaaS today. 

NaaP (Network as a Platform) is the Latest Acronym to Spell Growth

For the enterprise and service provider crowd, that means riverbed is looking to bring the agility of the cloud to existing infrastructure, by adding a new abstraction layer, which automates and simplifies thorny tasks, such as provisioning, scaling, and overall services management.

Why Bootstrapping Builds Better SaaS Apps

I used to think bootstrapping was unsustainable, then a client in the cloud changed my mind.
I used to treat bootstrapping as a joke, likening startups that “bootstrap growth” to new restaurants that keep talking about their first Zagat listing while still having only plastic displays of food in the kitchen. Then I took on sales-and-marketing startup Agile CRM as a content strategy client. Being a part of cloud-based app’s core team since before Agile CRM’s public beta launch has completely changed my opinion on bootstrapping, and not just because we passed the sacred seven-figure revenue mark last year.
I used to see investors and VC firms as market soothsayers, as if they somehow understood business better than the businesses themselves. Now I know that bootstrapping builds better SaaS apps. Here’s why.

Pitching Customers Instead of Investors

With a bootstrapped SaaS app, you pitch your customers instead of investors. And guess what? You pitch them every day. That daily engagement and interchange that enable bolder innovation, from the app to the marketplace and back again.
When I first started working with the Agile team, we were our own best customer, if only because we were the only customer. The core development team had designed the first version of the app to solve immediate, real-world problems faced by their first SaaS app, ClickDesk, when it started scaling at an unprecedented rate. They couldn’t find a single affordable, extensible, integrated option for sales and marketing automation to track lead behavior and engage contacts throughout the entire customer lifecycle. Fed up with overpriced software that seemed to be aimed only at enterprise users with unlimited budgets, they decided to build a solution themselves and voila, Agile was born. It was just an internal solution at first, but that would soon change.
In my opinion, the most innovative part of founder Manohar Chapalamadugu’s million-dollar vision in leading Agile CRM (and this was there from the very beginning) has been his emphasis on building an all-in-one solution focused on sales and marketing processes, rather than just standalone features. It’s a bold vision, encompassing everything from call automation and online scheduling to sales gamification and automated email nurturing. With the decision to bootstrap growth from the beginning, input about these processes has continued to come directly from customers.
Something special happens when you daily pitch customers and listen closely to their response. Agile now has almost 1,300 ideas posted by customers on UserVoice, with over 200 of those ideas completed or in progress. If the CRM had taken outside investment, I think it’s unlikely that features such as the in-app landing page builder with integrated lead magnets would have been able to evolve naturally on top of an already extensive feature set. There would have been too many constraints.

An Ongoing Conversation

Technically-skilled support staff are one of the core reasons that bootstrapped SaaS companies create better products in the long run. Many of Agile’s customer testimonials speak of real campaigns and successes, and those quotes come not from anonymous review websites but from actual conversations with team members in India.
A brief word of advice. Whether you call them customer success agents, sales support staff, customer happiness rockstars, or a new title we haven’t even heard yet, let me emphasize two things: 1) They need to understand customer wants and needs (ie. it’s better to have one technically-skilled success agent than three with limited knowledge or experience of the actual product and industry); and 2) They should be some of your first hires. Just because you’re bootstrapping, that doesn’t mean you should skimp on support. In fact, the opposite is true.
I’ve been continually impressed by the dedication and responsiveness of Agile’s sales and support staff to customer wants and needs, and as I’ve learned more about bootstrapped companies with exceedingly high customer satisfaction ratings, I’ve noticed that this dedication to customer success goes hand-in-hand with smart bootstrapping. Aha!, the (totally bootstrapped) visual roadmapping app for product managers, stands out in particular with their decision to forego salespeople in favor of customer success.
minimum-lovable-product-aha

Failure is the Ultimate Motivation

Bootstrapping a SaaS app isn’t about the choice between having weekly investor calls (or shareholder meetings) or weekly calls with your early adopters. It’s bigger than that. As Ryan Shank of (totally bootstrapped) mHelpDesk has written, bootstrapping is about building “an empire…one customer at a time.” We’ve already discussed the importance of customers. Now let’s shift focus to that idea of building “an empire.” The problem with empires is that eventually most of them fail.
Once a SaaS company decides to bootstrap their own growth, there’s a shift in perception regarding their own product. Maybe this is true for other types of apps, too, but with software-as-a-service I’ve noticed that the shift is much more dramatic, maybe because the rate of micro-focused iteration is so high, as are the possibilities for large-scale changes, both on the front and back ends of your product. It’s terrifying, but it’s also exhilarating. Updates happen automatically and customers are instantly engaged with them.
Bootstrapped SaaS apps can create more dynamic products because (if they’re successful) they embrace the possibility of failure, using it as motivation for streamlining their product and constantly making small enhancements, too, such as cleaning up front-end code and improving speed in as many ways as possible, like for one particular feature in one particular mobile browser. As Shank notes, having a smaller amount of cash on hand also demands a certain discipline and focus. How will you use that money? Will you build an app customers love, or will you create another pitch deck for investors?

Guest Post: The future of enterprise software is abundance

Fragmentation Continues, and Software Budgets Growing Rapidly
We’ve seen a massive change in the enterprise software market in the last dozen years and it can be described by four numbers (20, 10, 12, and 4).
Here is the summary of how the landscape has changed in the last 10 years:

  • 20x increase in software vendors
  • 10x the number of software products companies buy
  • 12x the number of internal “buyers” inside companies
  • 4x increase in budgets for software solutions

(Note: This is from hundreds of surveys Siftery did of many of the largest software buyers. Siftery helps companies discover enterprise software they should be using. Disclosure: I am an investor and board chairman at Siftery).
The high-level macro is that the world of software is getting way more crowded and way more complex.
Buying software is daunting … but it is also REALLY impactful. The right software gives you a competitive edge. Software isn’t just eating the world … it can help you eat your competitors for brunch. Choosing the right vendors is really important for businesses to succeed … so we would expect companies to be spending much more time selecting vendors … and they have.
The Four Numbers: 20, 10, 12, and 4
In the last dozen years, we have seen a software explosion. This is mainly due to software being easier to buy, integrate, deploy, and use because it no longer needs to be hosted on premises. This software is usually lumped together as SaaS (or DaaS or even some other name) … but the main take-away is that one does not need a really expensive on-premises integration and therefore it can be tried and used quickly and with less risk.
When we talk about “software”, we’re not just talking about code you run inside your corporate firewall. And we’re not just talking about traditional SaaS products (like Salesforce, Workday, etc.) either. We’re also talking about data services your company consumes (like Bloomberg and Acxiom). And services that help market your business (like ad networks and Google search spend). And subscriptions you use to help your business (like LinkedIn and Glassdoor).
20: The number of software vendors has increased 20x in just ten years
That’s right. There are twenty times the number of software vendors that there were just ten years ago. There are a lot of causes of this rapid increase:

  • As stated earlier, it is much easier to buy software, so there is more software to buy.
  • The really large software companies have embarked on a strategy of growing their product and feature set by acquiring companies (or sometimes partnering) rather than developing these features and products in-house.
  • Seeing this opportunity, venture capital firms have poured tens of billions of dollars funding software companies.
  • It is now much cheaper to start a software company because of things like distributed computing and the rise of software companies that help other software companies.

10: The number of software products (unique vendors) a company buys has increased 10x in the last ten years
This is an even crazier statistic than the first macro trend. Take the average large retailer — ten years ago they had maybe 40 software vendors across their organization … and today they will have 400. One large retailer polled by Siftery has over 2,000 software vendors!
The right software stack gives your company a competitive advantage. And because it is so much easier to buy today (and there are more people making buying decisions), companies are becoming increasingly open to buying from a large number of vendors.
The major beneficiary of this trend has been start-ups … they can get a beachhead in large companies much faster than they could in the past.
Of course, this trend is happening in some industries faster than others. Retailers are super fast adopters — probably because their business is so competitive and the market leaders there (Amazon, Walmart, etc.) are filled with incredibly smart technologists.
Companies that have many regulatory requirements to keep their data on premises (like financial institutions and healthcare) have fewer software vendors … but even there we have seen a massive increase in the diversity of vendors.
12: The number of internal buyers has increased 12x in the last ten years
The number of people buying software (or influencing the buying) of software in a company has grown dramatically. Almost every professional in a company is now a buyer. Software engineer? Buyer. Salesperson? Buyer. HR Manager? Buyer. Finance person? Buyer. Lawyer? Buyer. Marketing? Definitely a buyer. In 2012, CEB did a study that found buyers did “60% of a typical purchasing decision—researching solutions, ranking options, setting requirements, benchmarking pricing, and so on—before even having a conversation with a supplier.”
In fact, only 12% of the users of Siftery are in traditional IT. The other 88% care just as deeply about the software for their organization.
And it is easier than ever to buy. Companies like New Relic and Sendbloom have built their company selling one seat at a time to an organization and then using their internal advocates to get larger deals. Freemium software like Slack, Glassdoor, and Cloudflare make it easy to try. Freemium or low cost products mean less red tape and less need for budget approvals in the initial stages of adoption.
Engineers, lawyers, salespeople, finance, HR, marketers, etc. that can pick and implement software are the ones rewarded with promotions and bonuses. Professionals that do not develop the core skill of picking the right software vendors will find much more limited career paths.
4: The spend on software has increased 4x in ten years
A 4x spend is an astonishingly large increase — and it is because software is easier to buy and it is becoming more and more powerful. Of course, since the number of vendors a company has increased 10x, the dollars per vendor has decreased dramatically in the last ten years. This trend might be worrisome for the giant enterprise software companies but it is really good news for software companies that are innovating and are on offense.
One thing to note is that during the last ten years, these same companies that are spending so much more on software have not significantly increased the number of people they employ. In fact, many companies have FEWER employers today than they did ten years ago (even though revenue has increased). The take-away is that companies are choosing to spend on software INSTEAD of people. This may or may not be a good thing for the world … but it is happening and will likely continue to happen.
The fragmented world of software will continue

Most every macro data point on Siftery shows the trend of the last ten years will continue in the next ten. It’s easy to dismiss that this abundance and fragmentation is just part of a cycle that’ll eventually move towards consolidation. But if one digs a level deeper to look at the forces that created such a vast, fragmented and active product ecosystem, it becomes apparent that this isn’t a trend but a transformation. More business processes are automated now than ever before – run by software or reliant on it. In many cases, we see software talking to software, APIs talking to other APIs. As long as this data can be integrated well, there will be more software.
This means there will be even more software companies in the future than there are today. And buyers will be even more overwhelmed and will need help deciding what to buy, how to buy, how to integrate, and how to best use the software.
I invested in Siftery (www.Siftery.com) because I love their unique way to help discover software. Siftery believes the products you should use is dependent on the products that you do use.
About Auren Hoffman:
Auren Hoffman is the former CEO and cofounder of LiveRamp (sold to Acxiom) — the largest middleware provider in marketing technology. He is Chairman of Siftery – using data to help companies better buy enterprise software. He previously served on the board of BrightRoll (acquired by Yahoo).
He is the founder of the Dialog Retreat and investor in over 65 active technology companies (https://siftery.com/groups/aurens-portfolio).
Auren holds a B.S.E. in Industrial Engineering and Operations Research from UC Berkeley. You can find him on Quora and Twitter (@auren).”

Building For Success on AWS: Five Best Practice Tips

[person]As AWS increasingly becomes the preferred deployment model for enterprise applications and services, it’s never been more important for a software or AWS SaaS provider to work effectively with AWS. Many leading technology providers are therefore optimizing their software to run on AWS as well as building globally available cloud services delivered through AWS’ worldwide regions.
Splunk has been very pleased with the success of our SaaS business on AWS, so we thought we’d share what we’ve learned in the form of best practices for you to keep in mind when developing your software or SaaS business on AWS.
1. Embrace the change
If you’ve attended the keynote at any recent AWS Summit, you’ve heard the message “cloud is the new normal.” Our advice is to take this to heart, and invest in your business knowing the momentum behind cloud will only continue to accelerate.
This is a boon to businesses of every size and in every location around the world—cloud makes it easier than ever before to innovate, rapidly bring an offering to market and serve your customer.
2. Relentlessly focus on the customer experience
Focusing your business on customer success is a must when building a business on AWS.
Why? Because the number one driving factor behind everything AWS does is to help its customers be successful and innovative. Tactically, this can mean many things for a SaaS Partner, but the one that stands out is building technology integrations that can provide additional value to AWS customers.
A good example of this involves AWS CloudTrail and AWS Config, services that deliver log data on AWS API calls around user activity and resource changes. When properly harnessed, these services help enable enterprises ensure security and compliance of their AWS deployments. A handful of SaaS Partners deliver integrations for these AWS services. The importance of these integrations is clear when you think of the importance of security and compliance for any successful AWS deployment.
3. Leverage your customers in your go-to-market strategy
When it comes to building your software or SaaS business on AWS, nothing beats customer validation. One of the most compelling stories is when a customer fully integrates your technology into their AWS strategy.
A great example of this is the Federal Industry Regulatory Authority (FINRA). FINRA is an independent regulator that examines all securities firms and their registered persons and monitors trading on U.S. markets. To respond to rapidly changing market dynamics, FINRA is moving its platform to Amazon Web Services (AWS) to analyze and store approximately 30 billion market events every day. FINRA uses Splunk Cloud to ensure security and compliance in their AWS deployment.
4. Choose AWS and go “all-in”
When building out your cloud strategy, you have to make choices. Our advice: When two roads diverge in the cloud, choose AWS.
This is a best practice because AWS has the richest and broadest set of services in the market. If your offering is storage intensive, there are specific solutions for that; if it’s compute intensive, there are specific solutions for that; if it’s I/O intensive, there are specific solutions for that as well. Regardless of what you need on the infrastructure stack—whether it’s automated provisioning, configuration or management, AWS has a mature solution that fits the bill.
In addition, business today is global. To successfully grow your business you need the ability to rapidly expand around the world. AWS offers that through their 11 worldwide regions.
5. Leverage the ecosystem
If you’re building on AWS, chances are that other folks building on AWS will find it useful. This is what makes the AWS announcement of its SaaS Partner Program so exciting. If you’re building a SaaS storage solution, odds are we could use it for our SaaS operational and security monitoring solution. Since we’re building a SaaS operational and security monitoring solution, odds are you could use it for your SaaS storage solution.
We have the opportunity to be better together on AWS for the benefit of all of our customers.
To learn more about our cloud solutions, visit us here.

Axonify aims to shake up employee training with micro learning & gamification

Employee training is usually a profoundly unhelpful whirlwind. It’s a day or two stuffed full of information, most of which gets partially (if not completely) forgotten by the second or third week of the #grind.

It’s not that employers don’t try. I’m sure they do their level-best to make training helpful. After all, training and on-boarding employees is expensive, and high turnover rates and under-utilized employees are bad for business. But employee training is still begging for disruption. That’s exactly what Axonify aims to do.

More than just an employee training platform, clould-based software Axonify aims to be an employee knowledge system that’s available for teaching, reference tracking and improvement every day that an employee’s on the job. Using adaptive and micro learning principles, paired with ramification and on-demand knowledge centers, Axonify’s employee knowledge platform is a serious departure from the training systems that are in place at most companies today.

Axonify’s approach was born of the simple realization that human beings aren’t capable of effectively acquiring large volumes of knowledge in one long event,” says Carol Leaman, CEO of Axonify. “Attention spans are short and getting shorter.  We’re stressed and distracted.  We also have very individual and specific  information needs.”

It shouldn’t come as much of a surprise that we’re not great a focusing. Twitter, Facebook, Instagram, Snapchat and a hundred other sources of #content demand our attention hourly. And it doesn’t help that we check our email on average 77 times per day. We’re bombarded by information constantly, and when it’s more than a few sentences, we’re not great at filing it away for future use.

Our brains are really good at digesting 4 to 5 new pieces of information at a time and moving them from short to long-term memory,” says Leaman. “It turns out we’re easily overwhelmed, and too much content literally goes ‘in one ear and out the other’. It also turns out that in order to hone that knowledge, we need to actively recall the information periodically over 30 – 45 days.”

That’s where the micro learning aspect of Axonify comes in. Information specific to an employees position within a company is doled out in small, digestible segments. Sessions don’t last hours, but minutes, and gamifies the learning process with points and leader boards.

“Employees spend about 3 to 5 minutes per day on the platform receiving content in a micro learning format,” says Leaman. “Through understanding leading edge brain-based research in the areas of memory and retention, we designed the experience to create the most optimal scenario for knowledge acquisition that delivers targeted information, person by person, based on what they know, or don’t know, every single day. The proprietary algorithm we’ve developed allows us to personalize learning according to individual needs, strengths and weaknesses.”

Employees voluntarily engaging with content that makes them better at their jobs is a powerful thing. But what kind of knowledge and content are we talking about?

Right now, Axonify’s being used by companies like Walmart, Toyota, Bloomingdale’s and John Hancock. All wildly different companies in vastly different industries. Customer service, sales and product knowledge are obvious bets for the Axonify platform, but a vital piece of the employee knowledge is one that companies can’t afford to overlook: safety.

“Walmart is using Axonify across its more than 75,000 distribution centre associates to keep them safe on the job,” says Leaman. “OSHA reportable incidents dropped by 54% in the first six months. The amount of money saved was incredible.”

Axonify goes a bit further than just training, though. Understanding that question don’t always crop up at convenient times and aren’t always answered by bite-sized morsels of information, Axonify is rolling out Discovery Zone, which provides easily-accessible reference material.

“It’s a place where employees can easily find whatever they need to do their jobs in 2 clicks and 10 seconds,” says Leaman. “With so much information in most corporate archives, employees can’t find anything quickly. They need to have information at their fingertips, on-demand, instantly.”

Shaking up the way that employers and employees interact as they circle around important on-the-job information is a tall order, to be sure. Companies, particularly large ones, are notoriously slow to adopt new technology. That said, with large companies already on board, there’s an obvious benefit to shirking the old training system and plugging into the next generation of delivering employee knowledge.

“Employees feel the intrinsic benefit of being smarter, and they appreciate being given the opportunity to learn constantly, quickly, specifically and when they have a few spare minutes,” says Leaman. “All this translates into higher employee engagement that benefits the business as a whole.”

Not a shocker: SAP puts HANA at center of new biz apps push

When you hear from SAP these days, the software giant always leads with HANA, its in-memory database. HANA is to SAP what Watson is to IBM — proof that just because a company is getting along in years doesn’t mean it can’t do great stuff.

So it’ s not a huge surprise that SAP’s “next generation” business software suite, S/4, will draw heavily on HANA and sport a single unified interface across the applications. The first of these to be delivered, Simple Finance, was introduced Tuesday with more modules to follow.

At a rollout event in New York on Tuesday, [company]SAP[/company] CEO Bill McDermott characterized this as “the biggest product launch in the last 23 years and perhaps the company’s history.”

No pressure there.

The rewritten S/4HANA applications are now available on-premises across industries and regions. Simple Finance is the first application to be offered via SaaS — it’s also available on premises now, according to a spokeswoman.

Update: An SAP spokesman said these new applications were built from the ground up to run on HANA and will not work with third party databases, which is sort of shocking. (So much for earlier reports that the applications would continue to  work with third-party databases if needed — but would work better, faster, prettier with HANA.)

[company]Oracle[/company] has a similar “better together” story around its database, middleware, analytics, Linux and servers — er, make that engineered systems. All of these vendors talk about being open, but also say they’re more powerful when running with the company’s full array of technologies.

Complicating this particular storyline is that SAP and Oracle used to be more friends than enemies, with the majority of SAP’s business applications running on Oracle databases. Then Oracle decided to dive full on into enterprise applications with its acquisitions of PeopleSoft, Siebel Systems and everything else that wasn’t nailed down, while SAP doubled down in databases, buying Sybase and creating HANA. SAP and Oracle also bulked up their respective SaaS rosters — Oracle buying RightNow, Taleo  and SAP snapping up SuccessFactors.

And of course you know, this means war.

This story was updated at 11:16 a.m. PST to add SAP’s statement that the new applications will not run with third-party databases.