SaaS and SME Customers

The new job at Innowave Technology is pretty cool so far: good people, great projects, very challenging work. It's pretty neat to be in the only company with 3 Oracle ACE Directors. It's also pretty neat to have the opportunity to see many different situations with customers in the SME space and the ways in which they use Oracle products.

One trend I'm noticing already: there are not many of these customers taking a bite out of the SaaS apple. I'm surprised by that. Think about it for a minute…does it really make sense for companies with under $100 million in revenue to be taking on the infrastructure required for the E-Business Suite or PeopleSoft? I'm thinking that doing so consumes a hefty chunk of their margins.

Now here is the really interesting part. I've been asking those companies if they've considered OnDemand or another SaaS partner. Most were either unaware of the SaaS option or did not have a good understanding of post-implementation maintenance costs for the apps they're implementing.

My conclusion: we're not doing a very good job of getting the SaaS message across to the SME customers. Which is surprising to me, considering they're the customers that have the most to gain from that message.

I'd be interested in hearing your observations. Are you seeing the same lack of traction for SaaS with SME customers I'm seeing? Find the comments.

Resilience and Relationships

This post is going to be a wild ride, so hang on tight to something really solid…

I've been reading and re-reading lots of interesting stuff lately: Jeremy Gutsche's Exploiting Chaos, The Age Of The Unthinkable by Joshua Cooper Ramo, and Tom Peters' classic Re-Imagine! have all been pretty typical fare for me over the past few weeks. Some pretty interesting common themes between all this reading, which has altered my perspective in terms of the way I look at some things. I can't do justice to any single work of any of the authors I've mentioned in this space, but I'll try to whip up a short version and hope I get my point across.

Ramo describes the idea that we live in a sandpile world. The idea is that if grains are continually added to a sandpile, first the sandpile will form into the shape of a rough cone and then an avalanche of sand will eventually occur. The really intriguing part of this idea is that there is no model that will accurately predict when the avalanche will occur…or where in the sandpile…or how large of an avalanche…or what type…well, you get the idea. Pretty much unpredictable. There are so many grains of sand interacting in the sandpile that we simply lack the knowledge to create a model that accounts for all the interactions of all the grains in the network of the sandpile (even one as small as 2 inches diameter at the base). The concept that seems to make the most sense in dealing with the sandpile is to treat it as an object or a system unto itself; a system of sand grains all networked together to form the sandpile. Then accept the idea that the system forms to the point of instability - the pile will form in a cone shape until the avalanche occurs.

Seems that the sandpile model works pretty well in dealing with the current world that we all live in. Our global community is now so tightly networked that it's impossible to account for all of the influences each of us has on all of the rest of us. The millionaire in Palm Beach now shares certain risks with the Bolivian farmer (commodities prices, global warming and viral outbreaks all come to mind). Some of our systems, or sandpiles, have formed to the point of instability and an avalanche has occurred (the mortgage banking crisis in the U.S. is an excellent example - we piled on easy credit until the whole sandpile collapsed). And as we change things, it's really impossible in this tightly networked global community to predict exactly what the results those changes will bring about. Did the inventor of the cell phone have any inkling of the resulting impact on the personal computer market? The Internet was initially developed to provide a means of communication in the event of a catastrophic event; now it's sometimes used as a means of causing catastrophic events. Did Henry Ford foresee the impact on the oil markets when he started up his first assembly line and began cranking out cars?

Now stop and think about this for a few minutes in terms of your own enterprise: you're facing an environment where changes to that environment are unpredictable in terms of timing, size and impact. Kind of makes you want to crawl inside a hole and pull the hole in after you, doesn't it?

The good news is that, unlike the grains in the sandpile, we're intelligent and self-aware. Although we can't change the uncertainty of the sandpile world we find ourselves in, we can adapt to the apparent chaos (and I use the word "apparent" because it's not really chaos…it's just that we don't understand it yet) and even exploit it for our advantage.

All this reading has prompted me to stop looking at enterprise architecture from a classic architecture point of view and to start drawing analogies to organic systems. In doing so, I've arrived at a bit of an "aha" idea: It's all about resiliency and relationships.

Ramo points out that our own immune systems are great examples of resiliency. Sometimes our immune system prevents sickness and sometimes it fights sickness off. In either case, our immune systems adapt and learn from the experience…the system is flexible enough to survive and even improve under pressure. Now think about your own enterprise architecture. Is it a cobbled-together pile of pretzel logic or is it flexible enough that you can adapt under pressure (pressure from economic changes, pressure from technology market changes, pressure from demands for new functionality or information, etc.)…even pressure that you can't control or predict? Here are some hints:

1) if you can find instances of tightly coupled interfaces or customizations of 3rd-party packaged code, odds are pretty good that we won't use "resilient" as a description of the architecture. Loose coupling (like SOA) and bolt-on customizations (ADF or JSF) are keys to the flexibility needed to bounce back quickly in the face of rapid and unpredictable change.

2) If your concept-to-design-to-production process is measured in years, your ability to be flexible is…in the nicest terms possible…severely compromised (I could have used another term starting with "s", but thought better of it). Resiliency requires the flexibility to adapt quickly as changes are taking place, not afterwards.

3) How quickly does management see performance information (including the supporting "drill-down" details)? Is it near-real time, or is it 30 days (or more) after events occur? If it's the latter, forget resiliency. You can't bounce back if you don't know it's happened…

So now let's talk relationships. I can think of two ways that relationships apply to enterprise architecture.

First: The lasting relationships between data (this is the easy one of the two). Although applications typically come, go, and evolve, the data always remains. But it's not the data itself that drives the information that yields the nuggets of value that separate the successes from the also-rans: it's the relationships between different chunks of data. It's not just the size of your inventory, it's the number of inventory turns. Your revenue stream may eventually run dry if your customer satisfaction ratings are too low. It's not the number of electric drills you produce, it's the number of tires you produce that work as expected in the field. Who cares how powerful your vacuum cleaners are if nobody can figure out how to turn it on? It's the data relationships that matter. This is the upshot of the value you can squeeze from master data management and data warehouse tools…shining a spotlight on important and unique data relationships.

Second: The relationships between your enterprise stakeholders? How are the relationships with your customers? If they're good, you may get a feel for a sandpile avalanche early enough to do something about it. Even better, you may get a feel for some of the early results of your innovations. Gosh, you might even get enough early info to exploit the chaos a bit…if you're flexible (there's that word again) to act on the info quickly. Do your people work well in teams? Teams working together, given some autonomy and sense of purpose, tend to produce the best results…especially in pressure situations (check the stories of Apollo 13, the Lockheed Skunkworks or FirstEnergy Capital for some basic examples). How about your relationships with your suppliers? Do you help them so that they can help you? I could go on and on here, but the gist of the matter is that relationships between people matter…it's the distinguishing factor between people and grains of sand. Social networking, supply chain, talent management and CRM tools can all help here - are you leveraging these tools in a coordinated, orchestrated way?

Yeah, I know I went deep on ya'all with this particular rambling…my apologies. I'll try not to breathe so deeply the next time my neighbor sprays those pesticides in his backyard. In the meantime, the important thing to take away: the important aspects of a good enterprise architecture are resilience (the flexibility to adapt, especially in the face of unpredictable change and pressure) and relationships (both data relationships and people relationships). Take a look at your own enterprise architecture with those ideas in mind and see if your outlook doesn't change. Let me know what you think.