Monday, November 23, 2015

The Times They Are A-Changin'

Come gather 'round people
Wherever you roam
And admit that the waters
Around you have grown
And accept it that soon
You'll be drenched to the bone
If your time to you
Is worth savin'
Then you better start swimmin'
Or you'll sink like a stone
For the times they are a-changin'.

                     -- From Bob Dylan's "The Times They Are A-Changin'"

Spent some time with more really smart folks at Oracle last week.  Yeah, this people are really smart...I'm still wondering how they let me in the door.

During that time, I probably had three separate conversations with different people on how SaaS changes the consulting model.  Frankly, implementation is no longer a big money maker in the SaaS game.  The combination of reducing the technology overhead, reducing customizations, and a sharp focus on customer success is killing the IT consulting goose that lays the golden eggs:  application implementation.  You can see indications of it just in the average cycle times between subscription and go-live:  they're down to about 4.5 months and still on a down trend.  Bringing SaaS customers up in less than 30 days is something Oracle can see on the near horizon.  Unfortunately, as the cycle times for SaaS implementations shortens, it gets more difficult for an implementation partner to generate significant revenues and margins.  The entire model is built around 12-t0-24 month implementations - SaaS make those time frames a thing of the past.

So, if I were a SaaS implementation partner today, what would I do?  Frankly, I'd be switching to a relationship - retainer approach with my customers (not my idea...all those smart people I mentioned suggested it).  I'd dedicate teams that would implement SaaS, extend SaaS functionality, test new upgrades prior to rollout, and maintain your SaaS apps.  I'd build a relationship with those customers rather than simply attempt to sell implementation services.  The value to customers?  Your workforce focuses on the business rather than the software.  You need new reports or business intelligence?  Covered in our agreement.  Test this new release before we upgrade our production instance?  Covered in our agreement.  Some new fields on a user page or an add-on business process?  Covered in our agreement.  Something not working?  Let my team deal with Oracle Support...covered in our agreement.

Other ideas?  The comments await.

The times they are a-changin'...quickly.  Better start swimmin'.

Tuesday, November 17, 2015

Be Quick, But Don't Hurry

Over the month since I've joined Oracle, many people has asked about the work I'm doing here.  And, in all honesty, the work is so varied that I've had a difficult time describing it.

Yesterday, I was traveling from my home in Salt Lake to Oracle Corporate HQ in Redwood Shores.  Having landed in San Francisco, I was in a rush to get my rental car, make the drive to HQ, and get some productivity out of what was left of my day.

In San Francisco, you take a light rail to get from the airline terminals to the rental car building.  The rail lines run every 10 minutes.  As I was approaching the platform to pick up the light rail, one of those every-10-minute trains was just pulling into the station.  So I hefted my two carry-on bags and started a mad dash to the train.  And about four steps into that mad dash, I tripped and fell...luggaging flying, me on the ground, cussing up a storm.  Know why I tripped?  For the classic shoe lace was untied.

I was in such a hurry that I failed to check my shoelaces anywhere between leaving the plane and my failed attempt at breaking the Earth's gravitational pull.

My favorite basketball coach of all time, John Wooden, has a coach principle of "be quick, but don't hurry".  The idea was to have an efficient system and work with a sense of urgency within that system.  That's being quick.  When you step out of the boundaries to get something done as soon as possible, you're in a hurry...but at the risk of no longer being quick.  Your shoelaces come untied, you trip, and the mistake causes you to miss the light rail altogether.  You invest more time in waiting for the next opportunity...mission bjorked.

So one of the primary things I'm doing at Oracle?  Working on enabling those around me to be quick while discouraging them from being in a hurry.  That's a big chunk of what a good Center of Excellence does.

Monday, November 09, 2015

The SaaS Race

So I've been back at Oracle for about a month now.  I'd say the biggest change so far is my perspective on trends in SaaS and Cloud.  Prior to gaining that perspective from the inside, I really did not have a full appreciation for just how early in the game we are.  Not just Oracle, but everybody.

During my undergrad days, when remote learning was done with smoke signals (no Internet yet), I remember learning about Bruce Henderson's Growth-Share Matrix:

Cash Cows have high market share in a low growth industry.  Dogs have low market share in a slow-growth, mature industry.  Question Marks have low market share in a fast growing industry (this is where most companies start).  And Stars have high market share in a fast growing industry.

So apply those definitions in the SaaS market.  The market itself is fast-growing, so by definition we don't have any Cash Cows or Dogs.  But I'd also say that we don't have any SaaS providers with high market share's a pretty competitive market at the moment in terms of market share.  So, by process of elimination, all the providers are still Question Marks - relatively recent entries in a fast growing market, but none of those entries have achieved a dominant market share yet...mostly because the market itself is still now.

With that in mind, I read a lot of hooey in the press:  so-and-so will dominate/collapse/rise/die/excel/be eliminated...whatever the latest news cycle dictates.  Take all that stuff with a grain of salt...we're very, very early in what promises to be a very long race for market share with many players who have the resources to see the race through to the end.  We're just getting started.

Wednesday, October 28, 2015


I've noticed a trend lately.  In working with various organizations in the early stages of evaluating SaaS, I'm hearing vigorous defense of limitations. "We can't go to the cloud because our business is so unique."  "We can't consider cloud because our data is too complex to migrate." "We can't entrust our data to a 3rd party."  While there are plenty of additional reasons, I'm sure you've noticed the two important words forming the trend:  "We can't".

One of my favorite authors is Richard Bach.  Yeah, the guy who wrote "Johnathan Livingston Seagull", "Illusions", and "Travels with Puff".  More evidence that I'm an old hippie at heart.  Bach deals with the metaphysical and the spiritual.  It can be some rather deep and mind-bending stuff.  But he also throws out some pearls that stick with the reader.  One of his pearls that stuck with me: "Argue for your limitations and, sure enough, they're yours."  Meaning that those who vigorously defend their limitations rarely move forward in significant ways.  It's the opposing force to innovation, disruption and improvement.

If you're part of an organization considering a move to SaaS, the strategic factors to weigh involve elements like building value through improving the balance sheet and/or lowering operational costs; increasing product or service share and/or quality; increasing agility through reductions in business process or development cycle times.  In other words, "better faster cheaper".  If SaaS delivers for you in those areas, then the limitations simply become challenge to be dealt with on the road to achieving the value offered by SaaS.

"Argue for your limitation and, sure enough, they're yours."  When you begin to hear those two words, "We can't", that's exactly what you're doing.  Don't do it.  Step back and change your perspective.

Thursday, October 15, 2015

About Bugs

Been a few weeks since I last checked in.  Onboarding with Oracle has been like drinking from a data firehose, so I've been a bit pressed for time...

As I write this, I'm sitting out on my backyard patio right around sundown.  It's been unseasonable warm here in Utah of late, so the flying bugs are out in abundance.  While they're a bit irritating, they're not the type of bugs I have on my mind this evening.  I'm thinking more about software bugs.

I design a software bug as a flaw that causes said software to perform differently than designed or intended.  Simple definition for my simple mind, I suppose.

One of the eye-opening insights in having an insider's perspective at Oracle has been looking at software bugs.  Not the volume of bugs so much as the type of bugs.  If I apply my simple definition of a software bug, over half the logged bugs are not really bugs at all.  The software is working as designed or intended, but we're not seeing the expected result.  Could be any one of a number of reasons:  applying the software incorrectly due to lack of knowledge, desire for features not provided, violation of business rules, data quality flaws in converted or interfaced data, errors in writing data...the list goes on and on.

Wading through this data, I see a couple of trends.  First, it's pretty obvious that enterprise software vendors could do a better job of educating and enabling customers and partners on how their software works...especially from a systems engineering perspective.  Second, the industry needs better tools for evaluating data quality prior to converting or interfacing data between data sources...a symptom of the old "garbage in, garbage out" rule.

If we could improve in this area, think of the reduced workload for application developers.  Keep in mind that most enterprise software application development teams are dealing with at least four application versions simultaneously:  the previously released version(s) in the field, the latest release in the field, the next release being built, and the design work for the release after the version currently being built.  Anything we can do to alleviate the bug resolution workload allows vendors to apply that extra bandwidth in ways that will shorten release cycle times...something everybody wants.

I'm sure there are more trends to add to the list.  You have a contribution to make?  The comments await.

Friday, September 25, 2015

Know What Ya Got

There are two extremely bad decisions commonly made with enterprise software, and I see both take place every day.

This doesn't work the way we expect.  File a bug.

Over the years, my own experience tells me that two-thirds of bugs filed aren't really bugs.  What we really have is a user who fails to understand how the software works.  And, yes, we can always respond with RTM (or worse), but the stream of bugs that aren't bugs continues to be filed.  Stop for a second and imagine all the software development productivity lost in addressing bugs that aren't bugs.  And we wonder why it takes so long to introduce new releases and features?

This doesn't work the way we expect.  We'll have to customize the software.

We're not talking about extensions or bolt-ons.  We're talking about changing the code delivered out of the box.  Seems like around 75 percent of Oracle enterprise applications customers customize delivered code in one way or another.  SaaS will cut this number way down, but it's still widely prevalent throughout the installed customer base of Oracle enterprise applications.

Why is customization bad?  First, it means a customer must have a team of developers to build and maintain the customization through it's lifecycle.  It's that maintenance part that gets really costly...each new update, each new release, each new expansion require testing and likely some change to the customized code.  And here comes the incredibly crazy part of customization:  I would confidently bet my lungs against yours that over two-thirds of those customizations are unnecessary to accomplish the purposes of the customer.  Because the software out of the box already has the functionality to achieve business goal in mind...but it's likely a new way of doing things, and many folks don't want to change.  Even when the change might be better.  So we customize the code.

What to do?

As a very young man, I spent some time as a Boy Scout.   I was a really lousy Boy Scout.  Nothing that I liked about the entire thing.  Later on, after I grew up, I developed a great appreciation for Scouting as a Scout Master.  Nevertheless, I was a lousy Scout and resented my folks for putting me through it.

My Scout Master was retired military.  Lots of gruffness at a time when I just wasn't ready for that. Only one thing he ever taught us stuck with me:  "when you realize you're lost, take a breath, know what ya got, and figure out how to use what you've got to get yourself unlost."

Years later, I got lost in the woods.  The advice from that Scout Master saved my life.  And it's been a great principle for me ever since, in many situations:  "know what ya got."

Most enterprise customers today don't know what they've got.  That knowledge gap leads to filing bugs that aren't really bugs and building customizations when existing functionality gets the job done.  And telling customers to RTM adds almost now value (heck, even most of the people building the software dread reading those things).  If those of us in the industry want our customers to succeed with our products, we have to help by showing and telling.  Which also means we have to earn the trust of our customers, because showing and telling achieves nothing if the audience fails to engage.

So you want to reduce the bogus bug filings?  Cut back on customizations that slow everyone down? Work with your customers.  Customer success starts there.

Thursday, September 10, 2015

Here We Go Again

Yup, moving on one more time.  Hopefully for the last time.  I’m leaving Sierra-Cedar Inc. for a position as Sr. Director with Oracle's HCM Center of Excellence team.

As an enterprise software guy, I see the evolution of SaaS and Cloud as the significant drivers of change in the field.  I want to be involved, I want to contribute in a meaningful way, I want to learn more, and I want to be at the center of it all.  And there is no better place for all that than Oracle.  I had the opportunity to meet most of the folks I’ll be working alongside…knew many of them and met a few new faces.  And I’m excited to work with them. So when the opportunity presented itself, I was happy to follow through on it.

I’ll also freely admit that I’ve seen…and experienced…a pretty substantial amount of upheaval regarding Oracle services partners over the past several years.  Some are fighting the cloud-driven changes in the marketplace, others have accepted the change but have yet to adapt, a few are substantially shifting their business model to provide relevant services as the sand shifts under their feet.  Personally, I’ve had enough upheaval for a bit.

The first mission at Oracle:  develop tools and methods to meaningfully reduce lead time between customer subscript and customer go-live.  Pretty cool, as it lets me work on my #beat39 passion.  I’ll be starting with building tools to convert data from legacy HCM applications to HCM Cloud through the HCM Data Loader (“HDL”).

While I regret leaving a group of great people at SCI, I’m really looking forward to rejoining Oracle.  I kind of feel like a minion hitting the banana goldmine!