How to build a cognitive system
IBM is in the process of rolling out an exciting transformation of our eCommerce portfolio. This is the third blog in a series of posts that will formally introduce these advancements and review the architecture of the services from a technical point of view. In this blog, the author outlines the future of software platforms, the case for cognitive innovation, and how it’s a prerequisite to stay relevant in the market. Click here to review the second blog posting, A New Approach to Customization for Commerce Platforms. Click here for the first blog posting, Monolith to Pebbles: Transformation of the IBM Commerce Portfolio.
It was 20 years ago. As a bright-eyed, bushy-tailed college hire wearing a shirt and tie, I formally started my professional software career with a steaming pile of spaghetti Perl 4 code dumped on my lap with the task of — Make It Work Reliably. Within five years of that point (long having thrown away that Perl code), I was the guy in the office who could spot a memory leak in a Java Virtual Machine by glancing at log files spewing in xterms from across the room. I was the guru and god of the codebase I had designed and built. It was a great feeling being the architect.
Cognition becomes expectation
As cognition in the software we use every day advances from a pleasant surprise to an expectation, there’s a guru shift going on from the people who make transactional systems sing to those who straddle the line between pure software and data science.
For the past 20 years, engineering a system for rock-solid stability under high loads was the chief goal. Proving this scalability has been a hallmark of commercial software vendor bake-offs. Achieving that goal has become more formulaic over the past 10 years as J2EE replaced C++ as the de-facto enterprise language. While I still have tremendous respect for a high-scale working transactional system that can withstand exposure to the hard knocks of public internet traffic, I am coming to hold a higher level of fascination for systems that are able to observe real world dirty data, form hypotheses, test them by optimizing real world problems, and learn from their mistakes.
How to engineer cognitive
For all the talk of cognitive systems, what goes into engineering such a system? As the Engineering VP for IBM Watson Commerce, I’ve had the fortune of learning about this journey from building transactional systems that execute rules, such as an order management system that determines which warehouse to ship your jeans from, to systems that appear to reason and learn from cause and effect.
For example, the whole concept of conducting an end-to-end test has changed. It used to be about proving that the system behaved as expected for a certain amount of time with no memory leaks, crashes or errors. Now, it is a practice more akin to how pharmaceutical companies test new drugs, running thousands of trials under simulated conditions that are as close to the real world as possible. But how do you simulate the emotional reaction of a human? How do you simulate what UPS and FedEx will do during a snowstorm? The process becomes much more creative, like playing Sim City. When an outcome is unexpected, there’s no error to examine and fix. All you can do is hypothesize based upon the evidence and construct experiments to validate these hypotheses.
The new software gurus
Who are the new gurus who give birth to these types of systems? These are the rare people who can bridge the gap between discrete data processing code and code that finds needles in haystacks. They aren’t merely data scientists who studied statistics. They aren’t purely software engineers who studied computer science. They live with a foot in both worlds – as boundary spanners. They may not be considered ‘real math’ people by pure mathematicians as they may not have math Ph.D.’s and may not be the ones who come to mind as the architect guru’s by business users. These are the people who write code that makes you wonder “how does it know that?” when you scroll through “People You May Know” in your favorite social app. These are the people who make software go beyond automating drudgery to engaging with you with pleasant surprises.
Where do you find and hire these people who can infuse intelligence into commercially engineered software? In my experience, most originally started out as software developers who became grumpy working on “normal” development because they have untapped additional powers, being able to understand formulas with Greek letters while still having an acute appreciation for why variable names shouldn’t be one or two letters. If your company is diverse enough to have a formal data science team or a team of math experts working in a quantitative marketing department, you likely have people who approach the crossover from the other side, as formally trained mathematicians who learned software engineering to make their own code more maintainable.
As building robust transactional systems becomes easier with access to so much solid open source software and the complexity shifting towards cognition, what does this mean for the relevancy of commercial software vendors? Why not just use mature open source for your transactional systems and spend your effort learning how to build cognition on top? I believe that in order to stay relevant in the market, the key value that vendors must offer is to do the hard work of baking cognition into the ‘out of the box’ SaaS experience. While Open Source software leaves the window open for cognitive innovation, where software vendors, SaaS in particular, can shine is baking ongoing improvement to data science models into the day to day operation of the system. As a user of these systems, you should expect no less.
If the software vendor challenge of the past 10 years has been to provide rock solid, yet flexible, transactional software, the challenge for the next 10 years is who can deliver a transactional system that wakes up already knowing how to think about the data flowing through its veins – and unobtrusively makes its practitioners appear brilliant to their peers (and stakeholders). That is the challenge that vendors must excel at to prove to clients our worth relative to the many robust open source choices available. This is the challenge we hold ourselves to at IBM to be worthy of the ‘Watson’ name.
via Watson Customer Engagement https://ibm.co/2pQ2V0a
August 16, 2017 at 06:12PM