Pages

Thursday, December 13, 2012

Inspired a little by Kurt Bilafer's mantra of "you don't need to get all of your ducks in a row, you just need to get some ducks on the water" I shared a post on the Decision Factor blog about which subject areas to start with in a new BI implementation.

Thursday, October 25, 2012

I dropped another post on the Decision Factor blog today about who to engage in your organization on a BI project. I actually think a lot of these same points apply to any IT project, but audience blah, blah, blah.

Sunday, June 10, 2012

Not that long ago (OK, that long ago) the BusinessObjects portfolio consisted of just one tool. In the last 10 or so years, that portfolio has become a bit... bloated (it's OK for me to use that word in the same way it's OK for a flight attendant to call another flight attendant "the stewardess word"). While the robust growth of the product count was justified before (BusinessObjects buying Crystal Decisions was HUGELY important and obviously SAP buying BusinessObjects was the right move in that market), SAP has begun to show that it shouldn't continue to support the full breadth of its home-grown and acquired business intelligence catalog.

The first hint at this culling of the herd was the release of Crystal Reports for Enterprise (CRE) with it's BI4 platform update. This new tool looked exactly like Webi and Crystal had a baby and got the best DNA from each parent. The second, and more obvious signal is the eventual convergence of Xcelsius into the Zen product. With these releases SAP has signaled that they recognize just throwing half the product sheet out isn't good enough and that they need to step back and see what customers actually need NOW, not what they needed years ago.

So what do customers want/need? I think SAP has nailed this spot on by focusing on functions and users rather than tools.

The core of BI consists of canned reports, currently serviced predominantly by Crystal Reports and Web Intelligence (Webi). CRE is clearly a first stab at converging those two toolsets into something that can be developed by developers in (hopefully) a block or line format with pixel-perfect visualizations from any data source and deliverable in any number of places.

Self-service BI used to be the domain of Web Intelligence but quite frankly, it just isn't easy enough to use for most users. Unless you are a power user and live and breath the stuff, you don't want to generate a query and format a report. You want to see something more like Explorer, where you search for "Paris leather sales" and it spits you out a number. Power users want to go deeper, but they also want a more consumer-like experience, and Visual Intelligence (or Visi, part of the Explorer family) is going to make those people very happy. For those power-power users, SAP is also adding Predictive Analysis, something it can tightly integrate with its portfolio and not have to pass money down the line because they're just licensing another vendor's technology.

Finally, there are BI applications, which go beyond just delivering data into something featuring more interactivity and extensibility than we've been able to provide before. If Zen can meet its somewhat lofty goals while still allowing non-developers to develop (as Xcelsius does), then I can buy into bringing all of those use cases under one umbrella.

Some of you will (rightly) point out that I've opened a blog about "thinning" the BusinessObjects portfolio by listing 4 new products (CRE, Visi, Predictive Analysis ,and Zen) but that really had to happen. Overextending tools like Webi (which started as self-service and evolved into canned reports) is what got us in this mess in the first place. SAP is basically reinventing their portfolio to solve current problems without tossing aside the investments so many of us have already made into a specific tool.

Are there still open questions? Sure. Where does Exploration Views fit in (for my money, it is squarely between Core BI and Self-Service BI)? How do they invest in the future without letting their current tools die on the vine (as many have accused Xcelsius of doing)? How do they make sure they don't bet on the wrong horse (something something iPads and Flash)? When are they going to get the mobile piece right (they are getting closer but aren't quite there all the way across the platform)? When will Deski actually be blighted from the face of the earth (not soon enough)?

I know some are confused by the direction SAP is taking its BI portfolio, but I think this is just because most people simply haven't bought into SAP's new commitment to renewal. We aren't used to an enterprise vendor willing to invest so heavily into a completely new direction. Will this new direction give them some new license sales in the short term? Sure, but I don't think enough to offset the cost to develop it (most people with Explorer licenses don't even have to pay for Visi). SAP knows where they need to be in order to lead the market in 10 years, and they're willing to buy into that vision early.

Thursday, April 19, 2012

In case you missed it, SAP participated in a webinar today hosted by Mico Yuk that discussed the strategy, direction, roadmap, and hype surrounding dashboarding within SAP BI. This was preceded by an official Statement of Direction (preserved here by the Xcelsius Gurus) and Adam Binnie blog, delivered simultaneously with a live blog from Pieter, and followed relatively quickly by the Diversified Semantic Layer, Dallas Marks, and ASUGNews. SAP has been rightly applauded for their transparency and frankness on the topic, as they really did answer a lot of questions honestly. Unfortunately, they had very few answers that pleased me as a classic BusinessObjects customer (I did find it interesting/telling that less than 50% of the audience fell into that category).

The news coming out of the webinar wasn't particularly earth-shattering. We found out at BI2012 that Xcelsius will add some HTML5 components and that they probably won't be slated for general availability (GA) for at least a year. We knew last year that there was a project underway to create a more robust analytic application creation tool (Zen) which won't be ready for a year. The one bit of new news released yesterday was that those two tools will eventually merge, but that isn't necessarily earth-shattering (and, as Dallas points out in his blog on the topic, that is what good enterprise software companies do). There is an argument that SAP has offered us too little/too late -- since it has been obvious for a LONG while now that the iPad has won, or at least will be winning for the foreseeable future -- but it makes sense that they would be slightly behind some smaller BI competitors. SAP can't reasonably spend all of its time on the bleeding edge of tech; sometimes they have to see what sorts of things catch on in the market and then build or buy appropriate solutions.

The problem I have is that SAP is now putting the lion's share of their analytics innovation into the SAP Business Warehouse (BW) basket. The Analysis Suite (in all of itsversions) is currently heavily geared towards BW customers. Zen, which won't be GA for a year, will only support BW and HANA data sources out of the box. This means that if you don't use BW or HANA it'll be freakin' forever (all dates approximate) before you can use the tool. The message is now loud and clear: if you aren't using BW and/or HANA, you are at the back of the queue for innovation in SAP Analytics. BusinessObjects is still very much a world-class enterprise reporting solution and I don't think this webinar should or will lead anyone to scrap what they've already bought. I do think this trend should weigh heavily on BI prospects without an SAP back-end.

Monday, April 9, 2012

I've recently reviewed a paper called Accelerating the Speed of Intelligence for Fast and Flexible Forecasting, put out by CFO Research Services* and it really got me thinking about how quickly do people really need their data and whether I'd want to speed mine up. Based on the observations of myself and others, I think it's pretty clear that at least some of our data does need to be real-time (and having the rest of it real-time would, at the very least, not be a bad thing). The questions left on the table then -- assuming you don't already have a rock-solid use case -- are what does super-fast data look like, and how do we reasonably get there?

What does the real-time enterprise look like?

It looks like HANA, obviously. :)

While that answer is half-tongue in cheek, half-serious, and half-covered in Kool-Aid (being in-memory allows 3 halves to be processed simultaneously -- that's just good science) HANA (or at least something like it) really does need to be the answer going forward if a truly real-time enterprise is ever going to happen on a massive scale.

Existing relational database providers can't support real-time reporting because even in very small deployments people don't want to run reports (especially non-operational analytical reports). They don't want anything to impact the performance of their transactional systems.

Existing data warehouse appliances can get you (at least very close to) real-time, but without a specific use case they are out of reach for small to medium enterprises who can't afford the licensing, hardware, and expertise required of having multiple database technologies. These systems can't support OLTP so they are and will remain a luxury of sorts for most customers.

Some applications (think Workday) are doing great things with in-memory technology, allowing reporting and transactions to occur on the same system. Unfortunately, those great things are largely limited in what data you can pull, how you can pull it, and what you can do with it once it is pulled. It's just too proprietary and silo-ed to branch out beyond its own application.

That leaves us looking for something like HANA, and once it becomes an actual database option for building applications (and some think it is already there), there won't be a reason to not choose it over an existing competitor. It runs on (admittedly beefy) commodity hardware, it will be application agnostic, and it is very reasonably priced (Seriously, pay attention to this announcement and then ask your account rep. You'll be shocked.). If someone were starting truly carte blanche, why wouldn't they pick a database like HANA?

How do we get there?

Assuming you can't start carte blanche, the path to HANA isn't necessarily easy. You've got legacy systems you still need to pay maintenance on, a couple of DBAs who will fight tooth and nail to keep whatever you've got, and a host of applications that you aren't quite ready to rewrite to take advantage of HANA, regardless of your tolerance for pain. So how do we get started?

Small. If you feel like going the very reasonable route, I'd recommend inquiring with some of the hardware partners about "borrowing" a box for a POC (if that hardware partner is also a services provider, even better). Because of the way the software is licensed, you can buy a tiny little chunk to get started. The size of that tiny little chunk is relative to your organization, but you can always add more. Next, buy an appliance that can hold at least twice the storage capability you've licensed software for (and maybe more). Why buy more hardware than software? Because the transaction cost of the hardware is higher, silly, and because the price doesn't grow linearly like it does with the software. As a bonus? With compression, you'll still be able to put more in there than you ever thought.

Once you've made your purchase you'll want to start chucking some "fun" data in there to practice on. This would be a very good time to get some of your other "nice-to-have" initiatives rolling. Exception based reporting? HANA can support that. Predictive Analytics? SAP will sell you that. Mobile? These technologies were meant for each other. Build your next small in-house app with HANA as the database. Once you start using it, you'll see the potential beyond a data warehouse appliance.

Where are we?

Assuming you don't have a full-fledged, custom built HANA use case and you are willing to follow the plan I've just outlined for you, you are still way ahead of the game. Some swaths of your reporting will hum, you'll be able to do things in your applications that you've never done, and you will have spent a bunch of money (that you would have spent on extra CPUs of a relational database anyway) on something far newer, sexier, and ultimately better than the old tech.

Are any of these "fun" use cases "game-changing"? Probably not on their own. But the next time your current DB vendor shows up with their hand out, you may just be comfortable enough with the technology to tell them you don't need to expand their footprint in your organization. And you'll be ahead of your competition in taking advantage of the next paradigm shift in enterprise computing.

* Thanks to the SAP Office of the Finance team for providing this report to me as a member of their CFO Intellectual Exchange Network program. To learn more about improving financial performance, efficiency and overall financial transformation visit their CFO and Finance Leadership Center. **I feel compelled to say "like HANA" because someone will eventually compete with SAP on an in-memory database that can support operations and analytics once they understand the vision***. *** Sorry Oracle, but your Exa-... series is just an appliance at this point, and, as far as I can tell, has no interest in being anything else.

The study says CIOs are concerned that cloud provides business teams with a way around IT teams by acquiring cloud services on their own, which undermines the strategic partnership they are trying to build with business leaders.

But what I read was:

With lines of business increased control over IT spending and IT's complete inability to meet the needs of the modern business in a timely and pleasant fashion, here's just one more reason why I fear not only for the office of the CIO generally but for my job specifically.

I find that more than a little disheartening -- I've long said that working like you fear for your job is the best way to do a terrible job. That said, everyone's got kids to feed, so how does IT survive this "whole cloud thing" and leave the business better off to boot?

Manage these cloud connections internally. Dominic Wellington recommended this at the end of the article, and rightly so. Lines of business don't want to manage their cloud services or anything else technology-related, but often they must in order to get things done. Managing cloud services needs to have some policy and procedures around it certainly, but taking 3 months to get around to filling out a web form that takes 5 minutes isn't going to cut it.

Make everything simpler. Whether it's Steve Jobs talking about saying "no" to lots of things, or Vishal Sikka talking about removing layers, it isn't hard to find smart people willing to talk about taking complexity out of your business as a good thing (when done thoughtfully, anyway). Doing extra things can be dumb. Tactically employing "the cloud" can help you do less dumb things.

Take this opportunity to restructure IT intelligently. An investment in the cloud doesn't have to just transform the way your company does business, it can also transform the way you deliver services to your business. As a company moves to the cloud, it probably needs less pure-developers for day-to-day operations and should invest in skills such as security and configuration. This will also allow your best developers to move onto more interesting and fulfilling opportunities, like mobile development, and your less good ones to do something... less developer-y.

The cloud has put CIOs on notice, as well it should have, but being put on notice and being doomed aren't necessarily the same thing. Like with most things, proactivity is the key. Embracing the cloud now may prevent it from putting you in a choke-hold later.

Monday, March 19, 2012

We are at a point in enterprise mobility where everyone has assumed it is a given but no one has exactly figured it out. Is SAP shooting itself in the foot by trying to have a big fixed cost (SUP) and high variable costs (uber-expensive apps), meaning that they'll have to talk people into surmounting expensive barriers to entry on two separate fronts.

Consumerism and PlatformsMost people think that the "consumer experience" is about things working seamlessly and being super intuitive. That's half the story (and a big half, to be sure), but the other half (and the easier half, to be sure) is choice. We've all, I'm sure, read the Google Platforms rant. The reason Platforms are great is because if you can own the data and the infrastructure (which are the most valuable bits -- sort of like the bacon of IT) and you let others extend it and propogate it, you win without doing a whole lot of the work. You want to own the platform.

Let's use mobile Twitter as an example. Sure, you want to sell directly (the mobile Twitter website) and you'd like to have a brick and mortar store of your own (the official Twitter iOS app) and you might even buy a distributor (Tweetdeck), but in the end you really mostly just want people to be writing and reading tweets. That's why you build out an API and let all sorts of other people sell your product for you. And other people selling your product is a good thing.

That gives people choice, and people like choice (I hate Tweetdeck, but I love Hootsuite, which enables me to continue to use Twitter's core product without using it's distribution). It also generates competition, which makes your product even more valuable in the long run. Enterprise software vendors need to remember that what they really want to own is the tweets data within their systems of record.

Developers WantedSAP is getting closer to having a fleshed-out mobile developer ecosystem, but at present it isn't open enough to generate a lot of innovation or competition -- the table stakes are just too high. SAP needs to make sure the price is low enough to engage enough developers to give users choice. Need a mobile solution to approve work orders? It sure would be nice to have a couple of different apps that are inexpensive enough to try out.

In order to get those apps you need a robust developer ecosystem. In order to get that robust developer ecosystem, you need to leave enough money on the table for those developers, and you need to make it really easy for them to develop software (check out the 4:05 mark of JD-OD's video).

The Back of the Napkin

Per SAP CIO Oliver Bussmann, SAP manages some 12,500 iPads and those iPads have downloaded around 120,000 apps from their Afaria appstore (that's around 10 apps/user). For SAP. Customers, each of those apps will cost somewhere between 25 and 100 euros, so we'll say that these each average $50/app (yes, I did just switch currencies - it's cool, though, since SAP can handle that). That means that for each user, which might download 10 enteprise apps, we've effectively doubled the price of a $500 iPad (presumably people important enough to warrant more memory or 3G connections would warrant more/better apps as well) and that is before the price of SUP, Netweaver Gateway, and Afaria are taken into account.

To justify that sort of expense for the average mobile-enabled user, you have to basically disable their desktop experience to save on that cost. I for one don't know many people that are willing or able to totally leave their desktop or laptop behind yet. The easy solution? Charge less for apps. The problem is, that's the only place third-party developers can currently make money (and they have to make enough to cover their own infrastructure first).

So Where Are We?The solution -- and one, I might add, that'll be hard to swallow -- is that SAP needs to give up on making money at every possible point in the "enterprise data to mobile device" supply chain.

Give developers access to SUP, Netweaver Gateway, and Afaria for free to learn the technology. This will allow certain shops to participate in the market that never would have otherwise. You'll end up with some crap applications, but you'll also unearth some gems. The free market works in an app store.

Charge customers for the mobile infrastructure one-time. Let them connect to it via whatever means they want. This should not be a tremendously high price. How much extra do Workday or Salesforce customers pay for their mobile access?

Do what you can to keep App prices down. This will largely be up to the developer, but work with them to encourage "creative" pricing.

SAP-broadly should be trying to learn from what BusinessObjects is doing in the mobile space. It has had some struggles, but it is poised to move enterprise business intelligence to the mobile device because it has figured out the cost (an enterprise mobile service which isn't cheap but also doesn't seem to be a tremendously huge obstacle) combined with a couple of solid if not perfect free applications. They also have a developer ecosystem that is willing to play because they have low barriers to entry. This means you only have to pay once for the platform and then can distribute it however you see fit. This is the sort of model consumers have come to expect and that enterprises should flock to.

I understand SAP wants to make money everywhere in the process, but they have to remember that their back-end systems still being relevant in 10 years will be largely dependent on enterprises being able to access and manipulate that data from anywhere. Making it really expensive and unattractive to do that right now isn't going to help on that front.

Monday, March 12, 2012

I can't remember the first time I saw Explorer, but it seems like a really long time ago. It's been a part of every major SAP or BusinessObjects keynote that I can remember, shown as the delivery method for high-value information to people who don't otherwise know how to get at information, and it was really BusinessObjects first foray into Mobile BI (if, that is, you're able to ignore the Blackberry version of Mobi. Based on what I've heard, most of you were able to ignore
the Blackberry version of Mobi).

The thing is, besides coming out with an iOS interface, Explorer hadn't really changed much, at least in terms of appearance, since it first came out of the labs and was called "Polestar" (a relatively exhaustive history is available here). Why is this? The commonly held assumption is that no one bought the damned thing*, making more investment into it seem dubious. Based on some of the things happening around Explorer these days, the investment faucet has opened back up.

Which is good, as I'm taking a look at it for my employer and have run into several limitations, most of which have been resolved in the most current release (which of course I'm not on) or in the upcoming FP3 (which I am also obviously not on). Per SAP (ASUG login required), the following have all (or will be directly) added to the tool.

Second Dimension - Now you can chart by product by region. That's a big deal.

Auditing - If I can't prove people are using it, it's tough to justify spending more on it. Based on some feedback I've received this last week, I'm not entirely sure that everyone who has the latest version is aware of this feature.

OpenDoc - Or more accurately "OpenDoc-like functionality." I desperately want to be able to link from a dashboard spot to an Information Space with several facets already selected. I clearly do not want to bookmark and record the URL for every one of the possible combinations of selected facets.

Calculated Measures - These had historically only existed at the session level and are now (or will be soon) available as part of the Information Space properties. This really broadens the value of the Explorer Tool since it allows for (simple) measures to be calculated during runtime at higher levels (such as revenue/store) where storing them at the lowest grain possible (individual transactions) would lead to inaccurate aggregations.

Offline Capability - In the current App Store version you can bookmark a particular view and keep it around (and even manually resync it when you are connected), but everyone knows that isn't really the ideal end game here because you lose the ability to analyze it. Based on some conversations I've had, I'm not sure that SAP intends to extend the functionality far beyond that.

Time Trending - This allows data stored as "Wednesday" and "Mittwoch" (Wednesday in German) to be grouped automatically in facets and sorted properly in charts.

Geospatial/regionalizing/maps - For years I've rolled my eyes when salesmen would talk about this sort of functionality in BI tools, but after seeing some of the things Centigon has done I'm fairly certain geolocation has a use case (albeit a limited one) in the field. I think this is more a play for the future than the present, but it will be interesting to see it shake out.

Obviously the big thing about Explorer in FP3 is the release of Exploration Views (which is NOT supposed to be an additional license beyond Explorer). This essentially turns Explorer into a data source for sexier and more customizable visualizations, which is a good thing. An even better thing is that this application has been shown around for a long time, so it should be pretty close to fully baked when FP3 first comes out.

Why should we care about Explorer so much? Since some customers showed interest in it (and voted with their wallets) the tool has and is continuing to become a lot more enterprise class. I think in the not too distant future we'll see companies drive their "self-service" analytics needs through a tool like Explorer and their hot and heavy ad hoc users through Webi (although these folks could probably just as easily use Crystal and skip Webi altogether).

The important thing is that Explorer is finally getting beefed up, so if you haven't invested in it before, it's probably about time.

* Number of downloads is often a metric used to prove adoption of a certain application (or more often an app) but I find it flawed. Everyone and their brother/sister have downloaded the SAP Explorer app from the app store, but until they connect it to their own environment's repository, I couldn't care less. Hopefully most of SAP's BI customers aren't basing their decisions on 20 year old World Cup results or Formula One metrics.

Monday, March 5, 2012

Last week I attended the BI2012 conference (recap podcast here) and was fortunate enough to present two sessions, each of which were centered around the different data connectivity options that a user has when connecting to data that doesn't originate in SAP applications. The conference organizers, cognizant that "SAP BI" now includes a whole lot of customers who don't run anything else from SAP (and may, eventually, include a whole lot of people who don't run BusinessObjects either), sought out speakers who could talk about the BOBJ toolset from a more database-agnostic perspective.

Not wanting to waste anyone's time, I warned people upfront that if they were there to find out how to connect to BEx, BICS, BW, BWA or any other SAP-centric data source/connection they may want to move on. I lost quite a few people every time I mentioned this, which was OK, but I can't help think that a lot of SAP customers are missing out on some big opportunities to turn off some other BI solutions that they have in house.

In my first session, I asked how many folks were already running BOBJ. Almost all hands went up. I then asked how many also had, somewhere in their company, another BI solution to support another applications. About half of the hands went up (and I'd wager those that didn't just don't know about what shadow IT has put out there).

In case you haven't heard, the economy is pretty tight these days, so why are companies still paying maintenance on two BI tools when BusinessObjects can almost certainly handle all of their reporting needs? A few possibilities exist.

Because they don't know they can. A lot of SAP customers probably just bought BOBJ because they were told to, and once in, the account rep had no incentive to encourage them off of their existing tools even though the BusinessObjects family can report off of practically anything.

Because it would cost more. Obviously this will depend on what your licensing looks like, but it is probably worth a look. I haven't seen a formal study, but I'd wager that if you took into account the key cost drivers in a switch from BI tool X to BusinessObjects (retraining people, porting content in, eliminated maintenance and support) you'd come out at least even if not better off, with tons of future savings in only having one toolset to support.

Because change isn't easy. Even if an organization knows what BOBJ can do, and that it will save them money, sometimes it really isn't organizationally worth the hassle. It's "because we've always done it that way" at it's worst.

So what (legitimate) reasons do people have for having an enterprise reporting solution that doesn't cover their enterprise? Am I crazy?

Wednesday, February 29, 2012

About this time 2 years ago the former GBN was pulled into the broader ASUG user group, and I was selected into the SAP Mentor program. This was really the first time I had been exposed to the broader SAP community (sorry in advance, broader SAP community) and since that time there has been one common theme in every executive keynote that SAP has been involved in. That theme has been HANA.

It isn't that I don't like HANA. I actually really do. I think it has a ton of potential to create real customer value and to eventually substantially lower the total cost of ownership for many companies. Unfortunately for most companies, eventually isn't quite here yet (and hasn't been on any given day for the last couple of years). Has HANA changed some games? Yes. Has it changed the game? Not quite yet.

Wondering why I care so much about discussions surrounding a database technology that I may well never use? Because it comes at the expense of discussing some fantastic, ready-to-use and reasonably-affordable database technologies that I may use. Everyone knows SAP bought Sybase for mobility, but the real jewel of the deal, at least to me, was the opportunity to hurt Oracle where it hurt -- by turning off Oracle database licenses and turning on Sybase database licenses. Unfortunately, it's been very tough to get an SAP executive to talk about Sybase data solutions (except for the occasional throwaway comment) during a keynote since the acquisition. That all changed this morning during BI2012 when the keynote given by Steve Lucas and Timo Elliott included a demo of data being held virtually and in the cloud by Sybase IQ. That in fact carried over to a HANA-specific microforum where Lucas spoke candidly about how the HANA/ASE/IQ technologies fit together into a unified portfolio.

I think SAP did a brilliant thing by finally folding some Sybase products (ASE, IQ, Replication Server, SQL Anywhere) under an umbrella that really genuinely included a product that was developed in-house (HANA). That meant that the people in one database sales organization aren't trying to sell their SAP database products against different SAP database products that happened to fall under a different part of the field sales organization. This gives an SAP account representative the flexibility to actual provide their customer with an optimal solution. Crazy, I know.

SAP stated that it would be the #2 spot in the database market by 2015. HANA alone wasn't going to do that. With an integrated portfolio that includes relational, columnar, mobile, and in-memory options -- and some work in truly integrating them with each other and into their full analytics stack -- I think they may actually have a chance.

Over the last couple of months all sorts of analysts and bloggers have reviewed their 2011 predictions and made some new ones for 2012. I'd like to be the first to write about what I see happening in the SAP Business Intelligence landscape over the next 4 years, until the next Leap Day on February 29, 2016.

Culture Shock

SAP will announce that it is buying a company with a strong culture that doesn't mirror that of SAP's. Pundits (and SAP) will beat their chests and declare that this new acquisition's success will force SAP to develop a more open culture. Nothing will actually change.

Mobility

SAP will create a shadow subsidiary that will lever up and buy Apple. The next day they'll stop shipping mobile devices and everyone -- consumers, and enterprises alike -- will just give up the whole mobile thing.

Rise of the Developer

SAP will transition itself into a Development Platform Provider more than a Software Solutions Provider. This will be great for small development companies, but not great for companies who don't have a ton of developers in house. Fortunately, the apps they need will be cheap (and won't need all manner of customizations).

Big Goals

Once SAP takes over the number two spot in databases, they'll set their sites a little higher and will try to become the premier provider of men's hosiery in former-EU countries. (Former EU? That's a whole different set of predictions).

Armageddon

The Mayans retained Oracle to be its solution provider for the big ending, but they won't be able to afford the change when Oracle recalculates their maintenance and license revenues based on the Mayans hardware and software needs scaling back post-"End of the World." The Mayans' lawsuit will drag on in the courts, and we will all get to breathe easy a little longer.