Skip navigation.

Floyd Teter

Syndicate content
Watching the current trends and future direction of Oracle's Applicationsfteterhttp://www.blogger.com/profile/11221041028141787708noreply@blogger.comBlogger410125
Updated: 3 hours 39 min ago

Old Becomes New - Maker Stuff

Wed, 2015-08-05 12:23
A bit of a personal tangent for this post, as I've experienced an interesting development in life recently.  I’m taking another run at the “Maker” concept after taking a few months away from it. And I’m coming at it from an entirely different angle.  The combination of data, radio waves and networks has piqued my interest.  Some background:
My father was an amateur radio operator back in the day.  It was one of his passions…so much so that his radio call sign (K0RFS) is engraved on his tombstone.  Big radio, big amplified, big antenna tower with multiple antennas in the backyard, the best Morse code keys money could buy, etc.  He saw it as both a hobby and a way to render service to others (he used to patch up a local family of Argentine immigrants with their family back home on a regular basis).  Dad’s heyday in amateur radio started immediately after WWII and continued through his passing in 1990.
Amateur radio technology is generally very old school.  Marconi made the first wireless radio contact from Cape Cod into Europe in 1912 using Morse code.  Voice technology was added around 1921.  We’ve seen the additions of packet radio, APRS, RTTY, SSTV, PSK31, radio propagation beacons, radio satellites, and other interesting stuff.  But it all comes back around to the same old radio wave technology.
Except it’s not.  Amateur radio operators can communicate with radios across the internet utilizing the IRLP system.  Heck, you don’t really even need a radio to play anymore - EchoLink allows computer>radio, radio>computer, and even computer>computer communication.  And it’s the merging of old technology with more recent technology in new and interesting ways that has really gnawed at my imagination.
Becoming a licensed ham radio guy has been on my bucket list, mostly as a tip o the hat to the old man.  Years in coming, I finally passed the Technician’s exam here in the States and thus earned my license (call sign K1RFS…what else?).  And I’m planning on using my Tech privileges as a springboard into some interesting maker experiments.  Some of the things on my project backlog include:
  • Building a Yagi antenna from a metal tape measure and PVC - and using that antenna to talk with the ISS
  • Making an OS-agnostic communication logging program in Oracle APEX
  • Working with amateur radio frequency beacons to track objects in areas without internet or cell service - power generation here will be interesting - then creating RESTful services to display the tracking of  those locations
  • Building an HMSS mesh net in my home that can be accessed via radio wave technology - 2nd step includes reliability when the electrical grid is offline
  • Creating a permanent IRLP node with a Raspberry Pi
  • Leveraging a combination of an AMSAT satellite and a smart phone to send and receive amateur TV images wirelessly - my target audience is one of the science exploration stations in Antartica
  • Communicating via IRLP and Echolink through wearable hardware
Old becomes new.  This should be fun!

History Lesson

Mon, 2015-08-03 12:53
I'm a student of history.  There is so much to be learned from it.  Today's lesson comes from NASA and relates directly to enterprise software projects.

From 1992 to 1999, NASA launched 16 major missions under the umbrella of the "Faster, Better, Cheaper" or "FBC" program umbrella.  These unmanned space exploration missions included five trips to Mars, one to the Moon, four Earth-orbiting satellites and an asteroid rendezvous.  10 of the 15 missions were great successes, including:
  • The NEAR Earth Asteroid Rendezvous (NEAR)
  • The Pathfinder mission to Mars
  • The Stardust mission that collected, analyzed and returned comet tail particles to Earth
The nine successful FBC missions started with tight budgets, tight scopes, and tight schedules. They all delivered early and under budget.

So long as NASA stuck to the core principles of FBC, the program was a great success:  9 missions successfully executed in seven years.  By comparison the Cassini mission, while also very successful, took over 15 years to execute.  And all 10 successful missions were completed for a fraction of the cost of the Cassini mission.  The FBC program came to a grinding halt when NASA strayed from the core ideas that made the program work:  the failed Mars Polar Lander and the Mars Climate Observer came from the latter part of the FBC program.

Let's look at the core principles that made FBC successful:
  • Do it wrong:  Alexander Laufer and Edward Hoffman explained in a 1998 report entitled "Ninety-Nine Rules for Managing Faster, Better, Cheaper Projects" that in order to do things quickly and right, you have to be willing to do it wrong first.  Experience is the best teacher.
  • Reject good ideas:  NEAR project manager Thomas Coughlin had no shortage of well-meaning good ideas for features, parts and functions to add to the spacecraft.   Essentially all stayed on the cutting room floor.  Reject good ideas and stick to your original scope.
  • Simplify and accelerate everything:  the NEAR project used a 12-line project schedule for the entire mission.  That's right - 12 lines.  Progress reports were limited to three minutes.  If we can build spacecraft with a 12-line project schedule, tell me again why our enterprise project schedules run multiple pages?
  • Limit innovation by keeping it relevant.  While innovation is always cool, it's not relevant if it does not contribute meaningfully to your project's objectives.  Shipping something that actually does something well is much better than shipping something built on the newest technology that is complex to use or fails to perform reliably in a multitude of circumstances.
  • You can't inspect quality into the system.  NASA's failure to stick with this principle lead to the poor ending for the FBC program.  To a great degree, the Mars Pathfinder was a success at JPL because the project was so small that it flew under the radar - no significant administrative oversight.  When FBC oversight increased after 1999 at all NASA centers, the successes stopped coming.  You can put the clues together here, can't you?
Do you recognize the themes here?  Simplicity.  Restraint.  Freedom to act and take risks within tight constraints.  The combination led to some elegant and highly successful projects.

And, by the way, the recent New Horizons mission sending us pictures and data from Pluto?  Lots of heritage from FBC.  So, yes, these ideas still work...for missions much more complex than enterprise software.

So, you want to #beat39 with your enterprise software projects?  This history lesson is a great place to start.

Beat 39

Thu, 2015-07-16 17:00
Let's start today's thought with a tidbit from the Standish Group's 2013 Chaos Report.  In that report, the Standish Group cheerfully shares that IT project success came in at 39%...cheerful because that is an improvement.  In other words, 6 out of 10 IT projects are failing to meet schedule, cost and quality objectives and we're thinking that's good news.  Yikes!!!

If we look at the numbers in SaaS carefully - regardless of vendor - we see a pretty consistent gap between sales and "go live".  Guess how large the gap is?  Yeah, about 61%.  Arithmetic anybody?  Granted that my access to data is somewhat limited here but, even with my small sample size, it's one of those things that make me "stop and go hmmm".

The upshot?  In the developing space of SaaS, I think we may have all underestimated the level of difficulty in implementing those nifty SaaS applications.  At the very least, it seems like we're missing the boat on how to move from vision to achievement.

Enablement.  SaaS customers need tools that ease the implementation and use of the applications.  And preferably things that scale...inventing the tool every time you tackle the project buys nothing but headaches.  But I think good tools for enablement are the key if we're ever going to "Beat 39".

More on this in later posts.  I think I may be focusing on this for a bit.



Enterprise Software's Life Lessons

Mon, 2015-07-06 13:13
Well, I ain't always right but I've never been wrong.
Seldom turns out the way it does in a song.
Once in a while you get shown the light
In the strangest of places if you look at it right.
                               - From Jerry Garcia's "Scarlet Begonias"

Somebody asked the other day what I've learned from from 25-plus years of working with, implementing, and developing enterprise software applications.  Kind of a life's lessons thing.  A pretty innocent question, but one that got me thinking.  And the more I thought, the longer the list became. I've been shown the light several times, usually in the strangest places and when I least expected it.  So the list grew to the point that I thought it might be worth sharing.  The list is not organized into subject areas, importance, thought streams, or sand piles.  I just wrote 'em down as I thought of them.

One caveat:  you may get the impression that my perspective here is a little negative...dark even.  Nothing could be further from the truth.  I love my job, I love being in this industry, and I love what I do and who I do it with...every day.  But, like much of what we learn, most of these ideas came from painful experiences.  I just wrote 'em the way I learned 'em.


So, without further delay:


  1. The Prime Directive: at no time shall anyone interfere with the natural progression of a project by introducing unnecessarily advanced technologies or over-engineered features.
  2. Nobody buys enterprise applications for the technology.  They buy for desired outcomes…end states.  Everything else is white noise.  The software vendor that best understands those desired outcomes and how to achieve them usually wins the business.  Enterprise software is a set of tools, not a finished house.
  3. If you’re in product management or product development, the most important word in the English language is “No”.
  4. If project success is measured by achieving the originally desired outcomes on time and within budget, enterprise applications projects (both developing and implementing) only succeed 39% of the time.  This stuff is hard.
  5. In the world of SaaS providers, 4 measures matter:  A) subscription revenue growth; B) subscription recurring revenue (often referred to in the negative sense as “churn”); C) percentage of subscription customers who have “gone live”; D) the time from original subscription to “go live” date.
  6. If you’re a consultant, your client will “vote you off the island” more often than not…usually at the next speed bump encountered.  It’s similar to being the manager of a sports team…the team manager’s reign usually ends with termination because something isn’t going right.  Don’t worry about it.  Be as good as you can be at doing what you do, be honest and transparent, and understand that it’s just the nature of the business.  So travel light.  You can’t please all of the people all of the time.
  7. In the SaaS market, good product gets you a seat at the table.  But good service keeps you there.
  8. Usable tools to compliment enterprise applications are just as important as the applications themselves.
  9. There will always be glitches at launch that did not appear in testing.  Keep cool, tune out the screaming, and work the issue.
  10. When estimating a project for internal or external customers, the required deadline is never negotiable.  Someone in leadership stuck that stick in the sand long before you learned about the need.  It’s not changing until it slips.
  11. When estimating a project for internal or external customers, the required budget is never negotiable.  Someone in leadership stuck that stick in the sand long before you learned about the need.  It’s not changing until the need for change is manifested.
  12. Fast, inexpensive, restrained (in scope) and elegant (simple but effective) projects with small teams are much more likely to succeed than projects with big scope, long schedules, bug budgets and big teams.
  13. If you find yourself speaking more than 20 percent of the time in any given exchange, you may want to consider shutting your yap and listening for a few minutes.
  14. If all of your stakeholders can’t describe your project in 30 seconds or less, you have organizational change managements issues to resolve before you can hope to deliver.
  15. Whenever your budget burn rate varies more than 15 percent (plus or minus), you have a problem that must be corrected before it grows worse.
  16. A great user experience is no longer a competitive advantage; it’s simply a requirement for entering the market.
  17. There is a “love cycle” in enterprise software implementation projects.  Early on, it’s a love fest.  The love fest shortly becomes an “us against them, but we’re stuck with each other” atmosphere.  Finally comes the “thank goodness this thing is over.”  The same cycle always applies, whether the project is successful or not.  It’s just a symptom of the stress that comes from taking the risks represented by the project itself.
  18. Packaged integrations out of the box don’t work.  They’ll need revising or rebuilding. Just build it into the plan up front.
  19. Be prepared.
  20. Always, always, always follow the money.
  21. Customizing packaged software is the most difficult and expensive choice.  Be sure you understand what you can accomplish within the functionality of the software before you decide to customize.
  22. Burn your calories where it matters.  Moving buttons on a screen does not change delivery of a desired outcome.  Tweaking a business process might.
  23. Ease of use trumps depth of features every time. Complexity is not a sign of sophistication.  The most important product and project decisions often revolve around what to leave out…minimalism generally breeds success.
  24. When you reveal innovation, you have about a 24-month window before a competitor does it better, faster or cheaper.
  25. When you feel like you’re out of the communication loop, it’s probably to late to do better with communicating - the vote of no confidence has already taken place and you’re on the way out.  So, right from the beginning of any effort, keep in mind that you can never over-communicate.  Listen and talk - it’s the key to gain the confidence of others.
  26. The customer is not always right.  Nevertheless, listen to, empathize with, and guide your customers (in that order)…regardless.
  27. Reporting and business intelligence are best planned earlier rather than later.  And information without context is just data.
  28. Mobile matters:  if you can’t offer productivity from a phone, it doesn’t much matter what else you offer.
  29. A project leader’s influence is inversely proportional to the size of the budget.
  30. If you’re fast because you’re quick, that’s good.  If you’re fast because you hurry, that’s bad.  The former indicates efficiency, while the latter just breeds mistakes.  As famed college basketball coach John Wooden often said:  "Be quick, but don’t hurry."
So, how about you?  Have some pearls of wisdom to share with the class?  Comment away!

Please Sell

Wed, 2015-06-17 18:12
Oracle's financial results for Q4 of their fiscal year 2015 came out a few minutes ago.  Seems they missed targets on license revenues and earnings per share.  So the stock may be headed for the professional investor's dog house.  I've even read of an analyst or two publishing a "sell" rating on Oracle stock.

Geez, please sell.  Drive the price down.  I can buy some more shares on the cheap and laugh all the way to the bank.  Let me explain.

First, license revenues shrank.  Gee, no kidding?  Oracle is transitioning away from licensed software to cloud and license revenues shrank?  (insert sarcasm tag here) Better dump the stock before the bottom falls out! (end of sarcasm)

Second, Oracle (like every other tech firm recently) was theoretically dinged by exchange rates.  The dollar fell against the yuan, peso, ruble, ducat, yen, etc.  But currency rates average out...even over the short run.  Take a snapshot after the Greeks and the European Union work out their issues in a few weeks...regardless of how they work it out, bet that exchange rate issue becomes less of an issue.

Third, the name of the game in measuring success in providing whatever-as-a-service is recurring revenue.  You'll compromise margins on new subscriptions to grow share, then work hard to minimize churn...which maximizes very high margin recurring revenue.  So the telling numbers for Oracle's future as a cloud provider:  subscription revenue growth, recurring revenue growth, and recurring revenue margins.  Which I do believe were the high points in the results.

Fourth, the technical fundamentals...which is really the most important factor...are very good.  Solid products with lots of functionality.  I'm not too concerned about Oracle's financial viability as long as they keep producing great products.

So only am I not worried, I'm actually pretty enthusiastic about the results and what they really mean.

So please sell...I'd like to increase my minuscule Oracle holdings.  If enough folks sell, I'll be able to do so on the cheap.

Integration Is Hard

Tue, 2015-06-16 20:58
If you know me at all, you know I love services-based integration.  The whole idea of interfacing, moving and exchanging data, guided by industry standards...I'm an enthusiastic supporter.  The appeal of this idea made me an ardent supporter of Oracle's Fusion Applications.  And I still believe it's an important part of the potential for today's SaaS offerings.

So I'll share a secret with you...I really hate services-based integration.  It's hard.  Packaged integrations rarely work out of the box.  SaaS integrations are tough to implement.  Integration platforms are still in their infancy.  Data errors are frequent problems.  Documentation is either inaccurate or non-existent.  Building your own - oy!  Even simple integrations require large investments of blood, sweat, and tears.  And orchestrating service integrations into a business process...agony on a stick.  I personally believe that the toughest aspect of enterprise software is services integration.  SaaS, hybrid, on-premise, packaged applications, middleware...it does not matter, services integration is hard regardless of context.

I see SaaS integration as "hero ground":  there is nowhere to go but up, and even simple wins will create heroes.  Service integrations that really work, simple and easily understood documentation, design patterns, data templates and useable tools... I think we have a ton of work to do.  Because, even though it shouldn't be, integration is hard.

Sticker Shock

Sun, 2015-06-14 17:37
A little off-subject, but still felt this experience was worth sharing.  I'll get back on track next post.

My smart phone is an iPhone 5.  My carrier is ATT.  It's been a great relationship since the iPhone first came out.  Sadly, I think it's coming to an end.

My two-year contract expired on June 1st...ATT informed me immediately that I was eligible for a phone upgrade and a new contract.  Exciting news, as I've had my eye on an iPhone 6-Plus.

Last week, I decided it was time to grab that new iPhone and renew my contract.  My wife came with...we're on the same plan and she is also upgrade eligible right now.  The local AT&T store is right around the corner, so we dropped by on the way out to lunch, figuring this would be about a 20-minute deal: cool new phones, new contract, and then off to lunch.

The experience did not quite work out as planned.  As you're probably aware, subsidized phones and 2-year contracts are on the way out with the wireless phone carriers.  More on that here.  So we were hit square between the eyes with sticker shock.  We were told we could buy new phones outright or pay in installments (including about $100 in fees...aka interest...over a two-year period).    Pretty significant bump in hardware out-of-pocket costs.

To add insult to injury, the price of carrier service has gone up around 33% for the same service levels as our own contract.  Regardless of whether we opted for a "Next" plan or not, the monthly outlay came out to the same amount.  And I thought data access was getting less expensive...

We left ATT in pretty short order and decided to try the Verizon store next door.  No help there...the numbers played out exactly the same.  The only difference was the branding of "Edge" rather than "Next".

Sprint tried to do better...they actually matched the level of service and price of our old plan.  For the first year.  Then they recovered that cost in the 2nd year.  So, over a 24-month period, the three major providers came out with the same price for service.  Contract, no contract, "Edge", "Next", or whatever...prices up 33% regardless.

We checked out Best Buy's $1 phone deal too.  I won't bore you with the details, other than to mention that the deal would not have saved us a dime on hardware or service over a two-year period.

Where I live, we have two more options.  T-Mobile and Boost Mobile.  Having checked T-Mobile, I've learned that they're leading this trend in higher service costs.  And their coverage map for my area is really spotty.  Boost Mobile, on the other hand, is offering substantially better pricing on service...which leaves me wondering how they do that, considering that they're leasing infrastructure and air time from Sprint in order to provide those services?

So, to sum up, I've learned two important things:  1) subsidized phones are now a thing of the past, and that smart phones (especially Apple smart phones) are expensive; 2) carrier providers are raising costs pretty substantially.  I suppose this is the cost to the consumer of finally converting perceptions of smart phones from a "cool new thing" to a necessity of modern life.

A few days have passed and I've now managed to talk my wallet down from jumping off a ledge.  We've made the decision in our house to hold the line on cell phone costs.

The sticker shock has made my old iPhone 5 look much, much better in my eyes.  I may just keep it until it dies. Or perhaps switch to the much lower-priced 'Droid-based OnePlus?

As far as increased provider costs, I imagine I'll be lowering my data plan and depending on the ever-increasing availability of free wifi.  Once that becomes less practical, I'll have to consider options...maybe switch back to a "dumb phone" and reconsider carrying a wifi-enabled tablet?  Yuk, that even sounds ugly :(

I suppose I've known for years that cell phone sticker shock was coming...but that doesn't make it any easier to deal with now that it's here.

Selling SaaS

Fri, 2015-06-12 14:51
Read a great article on the vendor-customer SaaS sale sdynamic  - Mike Vizard wrote the article at "Talkin'' Cloud".  Anthony Anzevino, Director of America Sales for AWS, describes selling cloud customers.  And Mr. Anzevion nails it.  Rather than summarize, I'll just quote the gist of it:
Speaking this week at a Marketplace LIVE event sponsored by Telx, a provider of hosting services, Anthony Anzevino, director of America sales for AWS, says the cloud giant focuses its own inside sales efforts on some 3,500 named accounts, which is then supplemented by some 5,000 systems integrators.Most of those customers, says Anzevino, are looking to find a more agile way to deliver IT services using a cloud service provider that is committed to innovate across a wide depth of product offerings. After all those factors are considered it's only then that the conversation turns to cost and pricing models, said Anzevino.The single biggest deterrent to making that sale, said Anzevino, is the internal IT organization. Unless there is some plan in place regarding how the skills of the internal IT staff will be reapplied to add value to the business Anzevino said most internal IT organizations will go to significant lengths to prevent application workloads from moving out to the cloud.Counterbalancing that influence, says Anzevino, is usually a chief financial officer that wants to outsource everything that is not core to the business. More often than not the CFO does not see IT as being strategic to the business and the real costs of delivering IT to any line of business inside that organization are generally poorly defined.For the most part AWS became the largest cloud provider by targeting independent software vendors (ISVs) that didn’t want to invest in IT infrastructure to deliver a software-as-a-service (SaaS) application. To fuel continued growth AWS is now targeting traditional enterprise IT organizations, many of whom are eager to at least move application development activities into the cloud. The battle comes when it’s time to move those applications into production environments. More often than not because of security, performance, compliance and total cost of ownership issues the internal IT organization will make a strong case for deploying production applications inside a private cloud or in a managed hosting environment.Yup.  See this very situation play out every day in the "whatever as a service" market.  I could not have described the situation better myself...You can read the entire article for yourself here.

The State of SaaS

Sun, 2015-06-07 12:09
I've been reading quite a bit lately about the maturation of SaaS...how the market is transitioning away from the "early adopter" phase into more of a mainstream marketplace.  With all due, respect to those making such claims, I must offer a dissenting opinion.  While a big fan of SaaS, I still recognize at least three factors that must be addressed before SaaS can be considered a mature offering.  These three areas represent the soft underbelly of SaaS: integration, data state, and fear of losing control.

Integration
Perhaps your experience is different, but I have yet to see a service integration for enterprise software that works reliably out-of-the-box.  Pick your vendor:  Oracle, Workday, Amazon, Microsoft, Salesforce, Infor...it just doesn't happen.  There are too many variations amongst various customer applications.  And, in all honesty, enterprise software vendors just don't seem to be all that good at writing packaged integrations.  That's part of the reason we see integration as a service players like MuleSoft and Boomi making a play in the market.  It is also why so many technology companies offer integration implementation services.  We're still a far cry from easy, packaged integration.

Data State
After spending years in the enterprise software market, I'm firmly convinced that everyone has loads of "dirty data".  Records that poorly model transactions, inconsistent relationships between records, custom data objects that have worked around business rules intended for data governance.  Every closet has a skeleton.  The most successful SaaS implementations I've seen either summarize all those records into opening entries for the new system or junk customer data history altogether.  Both these approaches work in the financial applications, but not so well in HCM or Marketing.  Until we can figure out automated ways to take figurative steaming piles of waste and transform them into beautiful, fragrant rose beds of clean data, SaaS will continue to be a challenging transition for most enterprise software customers.

Fear of Losing Control
Certain customer departments are resistant to SaaS, mostly out of a fear of losing control.  Some is borne of a genuine concern over data security.  Some is over fear of losing job security.  

For those concerned over data security, consider that data security is critical for SaaS vendors.  Without the ability to secure data, they're out of business.  It's a core function for them.  So they hire armies of the best and brightest security people.  And they invest heavily in security systems.  And most customers can't match that, either in terms of talent or systems.  Result:  the SaaS vendors provide security solutions that are simply out of the reach of enterprise software customers.  There is a greater risk in keeping your data in-house than in utilizing a SaaS vendor to protect your data.

For those fearing the loss of job security, they're correct...unless they're willing to change.  The skills of maintaining large back-office enterprise software systems just don't apply in a SaaS world (unless you're working for a SaaS vendor).  I'd lump database administrators and database developers into this category.  However, there are new opportunities for those skills...developing and maintaining software that enables strategic in-house initiatives.  There are also opportunities to extend SaaS applications to support unique in-house needs.  Both scenarios require a change - working more closely with business as a partner rather than as a technology custodian.

Overcoming the fear of losing control will require significant in advocacy and evangelism...most customers need information, training, and assurance in overcoming these fears.  But we can't really say that SaaS is "there" until we see a significant turn in perceptions here.


So there you have it.  Is SaaS up-and-coming? Absolutely.  Is the SaaS market transitioning to a mainstream, mature marketplace?  No...lots of maturing needed in the areas of integration, data state, and fear of losing control before we can get there.

As always, your thoughts are welcome in the comments...

Old Folks Boogie

Tue, 2015-06-02 08:42
And you knowThat you're over the hillWhen your mind makes a promiseThat your body can't fill...             - From Little Feat's "Old Folks Boogie"
I think I'm must be over the hill...a grumpy old man.  There was a time when, faced with an app that failed to work as promised, I would fuss and fight with that app to make it work.  No more.  Now, in the event that an app doesn't work as promised, I delete it and move on try something else.  No patience anymore.  I continually tell myself that I'll put the "fixer" hat back on my head, but I just never get to actually do so.
Mobile apps are the best example of my impatience.  There are many mobile apps for any outcome I care to achieve:  mobile meetings, tracking my heart rate, listening to music, taking notes... Plenty of alternatives.  So, when I run into an app that fails to work (or even fails to meet my expectations), I immediately junk it and move on to the next choice.  No effort, no feedback to the app developer, no nothing.  Just junked.  As my newest daughter-in-law would say: "ain't nobody got time for that".
In today's market, there is an expectation that apps just work.  Buggy apps die quick deaths in the market.  Reliability is not something special now...it's simply a requirement to get a seat at the table.
Classic example.  Last week, I was in Kansas visiting my new granddaughter.  Having taken our pet dogs on the trip, I wanted to find the local dog park.  Google Maps failed to find the dog park recommended by my son...the town in Kansas is just too small for Google Maps to fuss with.  Waze took me right to it.  Any guess as to which app is still on my smartphone and which one got junked on the spot?
Of course, there is a downside.  If everyone took my approach, the developers would never get feedback on their app from the field.  So their app would never improve.  But I have a "grumpy old man" response for that too.  So what?  Why should I be the beta tester?  Build something that works in the first place.
So yeah, I have that grumpy old man attitude when it comes to apps...especially mobile apps.  It either meets my expectations or gets kicked to the curb without further thought.  If I don't immediately get the outcome I'm expecting, I move on.
What about you?  Are you another member of the figurative "grumpy old man" or "grumpy old woman" club (no gender bias here - we accept everyone)?  Or are you willing to provide feedback and work with an app to help make it better?  Respond in the comments.

The Long Goodbye

Wed, 2015-05-20 10:43
I'm in the process of saying a long goodbye to my iPad 2...and tablets in general, at least for now.  I'm losing my tablet for a couple of reasons.

First, I've pushed the limits of my iPad's usability.  I really have...for a couple of years.  But I just don't find myself using it for any kind of serious work.  My MacBook Air has really taken over for both premise-based and cloud-based work.  Even with a keyboard of the tablet, I find myself much more productive on the Air.

Second, I'm finally upgrading my iPhone 5 next month.  The most likely upgrade candidate is the iPhone 6 Plus.  Yes, the Samsung Droid offerings look really great - even better in many respects.  But I'm invested in the Apple platform and there's not enough extra benefit in other platforms to justify a transition in my mind.  So it's likely the 6 Plus...with a very large screen.  And I see the 6 Plus taking over the few functions I now perform with my iPad.  So the iPad would become just another weight to lug through the many airports I visit every year.  I'm actually looking forward to cutting back on the amount of tech gear carried when I eliminate the iPad.

In all fairness, I think I would have come to this conclusion with any tablet.  I still consider the iPad to be the best of the bunch.  I have just come to the conclusion that the tablet format just does not provide enough value for me...at least, not right now.

What's to become of the iPad?  It may become a third screen in my home office.  Or it may become a media viewer on a planned treadmill.  I mean, it's nice and all...but, at least for me, I've discovered the iPad concept to be much more of a nice to have than a got to have.  Cool but not necessary.

What about you?  Different view or experience?  Sound off in the comments.


Mismatch

Mon, 2015-05-18 09:44
In the world of enterprise software, we sometimes find ourselves with a mismatch between sellers and customers.  From my worm's-eye view, we seem to be wrestling with one of those mismatches right now.

My typical week is mostly spent in conversations with customers.  Sometimes it's more of a formal work scenario with higher education institutions as part of my role with Sierra Cedar.  More often than not, it's a bit more informal:  advising customers across a wide range of industries in my role as an Oracle ACE Director (and, before you ask, yes - it's a freebie.  Just part of my advocacy role as a member of the Oracle ACE Director program.)

In listening to those customers - mostly about Oracle SaaS - the conversation is based on a description of an expectation or hope of an outcome or end state:

  1. Reduce required capital (think money here) required for using and maintaining enterprise software
  2. Eliminate or repurpose hardware
  3. Reduce headcount (due to budget or competitive pressures) or redirect skilled efforts toward more unique and value added activities (the latter is actually more common these days)
  4. Better information for making better decisions: more timely, more contextual, and more useful for both evaluation of the past and prediction of the future.
Now, keep in mind that no customer ever comes out and explicitly lists any of these four items.  Every customer is different, with unique wants and desires.  But, as I dig to get a better understanding, it typically comes back to some variation on one or more of these four.  So I'm shortcutting the process here to get to the real point:  the customers are in outcomes.  Will SaaS help us to enable/reduce/achieve something that delivers the outcome we desire?  Now just hang onto that concept for a moment; the idea of expected or hoped-for outcomes.

Think back to the last time you sat through an enterprise software or service demonstration, either as a seller or a customer or a partner.  Where was the emphasis?  I'll bet my dollars to your donuts that the demo focused on the capabilities of the software or service.  Lots of emphasis on an easy-to-use search engine, or great user experience, or cool features, or a well-integrated business process, or easy-to-build-and-delivery dashboards. All of which are very important.  But it's an emphasis on products and/or services.

The mismatch is between customers desiring enterprise outcomes and vendors/partners selling products and/or services to achieve those outcomes.  It's akin to shopping for a home in a certain neighborhood with a specific lifestyle in mind, while the builders sell to you based on the quality of their tools, their craftsmen, and the different homes they've built in the past - regardless of lifestyle or location.

In the enterprise software world, organizations often act like individuals.  Each one has unique needs and desires...which lead to unique outcomes.  The mismatch comes when vendors and partners sell services and products in response to those desired outcomes.  Folks, that is the mismatch.

So, how do I plan to handle this myself?  By first working harder to understand the outcomes desired by the customers with whom I engage in one way or another...mastering the who, what, why, when, where and how.  And then by explaining how the Oracle products and the services provided by Sierra Cedar can be utilized to help achieve those desired outcomes...and that's where I'll burn my calories going forward as I explain possibilities, lay out roadmaps, design solutions, and develop products/services.

So now that your life has been enlightened by this pearl of wisdom, may I ask for a small contribution on your way out?  Comments please.