Author Archives: Rich Napoli

Rich Napoli

About Rich Napoli

CEO at ObjectFrontier, Inc., focused on helping companies execute their digital transformation strategies with innovative, commercial-grade, digital products.

Posted on Wed, Sep 7, 2016 @ 3:00 pm

The old expression, “Some things never change,” is one that I’ve lived by in my 40 years in the software business—until I learned it was wrong! I thought I was so smart, because I could see the patterns in new technology repeating over the years, and I got good at mapping the latest technology terms and tools back to the older ones I learned. This worked for the most part, since some principles of software and IT are universal and transcend specific technologies. For example, the notion of dividing your program into components makes sense for lots of reasons, whether they’re called subroutines, DLLs, objects or services. However, I have to say that recent technologies—those from 2010 and beyond—have defied my attempts at simple classifications.

Specifically, the term systems of insightapplies to a terrific set of new technologies designed to harvest the vast amount of data we now have on customers, then look for patterns and gain insight into their behaviors and desires based on those data patterns. These technologies, which include machine learning (ML), natural language processing (NLP), and descriptive and predictive data analytics, offer some amazing new properties through their associated reporting and graphing tools. As an old curmudgeon in this field, I thought these new tools were just rehashed, old concepts from the 80s and early 90s: artificial intelligence, expert systems, and report writers. While they do bear some resemblance to the old tools, these new technologies have come so far and so fast, they really are something altogether new.

What the old systems have in common with their newer counterparts is the ability to look at acquired data and see patterns, whether through sorting and filtering, then applying business rules and finally graphing the trends. However, the new tools I mentioned do this on a massively larger scale, at an incredible speed, and across multiple data source types, all while dealing with far more complex relationships. Their ability to handle trillions of bytes of data and make real-time decisions based on their insights goes so far beyond what’s been done in the past.

It’s not just the old, structured data about our customers that gets scanned (like purchase history and demographics), but much more personal information gathered from their cell phones and other connected devices. Today, we can know where our customers are physically located at any given moment. We can know if they’re in motion, their heart rate, what they’ve looked at online recently, what they’ve posted on social media, where they’ve traveled recently, and with whom they’ve connected on Facebook or LinkedIn.  We can know the temperatures of our customers’ homes, how they drive, their style of writing emails, the foods they enjoy at restaurants, the movies they like to watch, and so on.

The systems of insight tools, different from those used in systems of engagement or systems of record, seek to digest all this newfound customer data and create insights into a customer’s real motivations and what he or she is most likely to want or need next. Big data tools, such as Hadoop and Cassandra, give us the ability to capture and store all this diverse data, regardless of whether it’s text, pictures, sounds, documents, videos, etc.

ML tools, NLP tools and streaming analytics tools can then be used to apply advanced mathematical models and algorithms that enable us to quickly digest all this data, identify patterns, uncover hidden insights, and build ethnographic profiles of our customers to predict what they might need and—more importantly—even understand why they might need it.

ML tools such as Apache Spark, with its MLlib and GraphX graphics framework, can be connected quickly to a live stream of data from Twitter to analyze the tweets, determine their sentiment and graph the trend lines. We at OFS did this recently as a demonstration of the power of these tools. We were even able to build this in a day, and you can see a demo of it here. These ML and NLP tools are not just for social media or mobile data. You can hook up your traditional structured data stored in SQL databases by using a massively scalable and distributed pub/sub tool such as Apache Kafka to help you push a stream of data into ML tools.

Many companies are using these technologies with incredible effectiveness. For example, Stitch Fix is an online women’s apparel vendor that uses machine learning to predict which kind of clothes to send to its customers on a monthly basis. Not only does the software learn what a particular woman likes and dislikes (based on indicated preferences, social media analysis, and returns of unwanted merchandise), but the analytical model also can be improved by experts within the company who have unique insights into that particular woman from prior dialog with her. Stitch Fix sales have skyrocketed in the past three years as they have deployed these technologies.

These tools are modern weapons you must consider to stay relevant and competitive in your marketplace, because they allow you to get inside your customers’ heads to know what products and services you should offer to meet their hidden wants and needs. For those of you older types like me who think nothing ever changes, I invite you to take a look at systems of insight tools and see that things sometimes—or rather, always—DO change.

 

Posted on Thu, Aug 11, 2016 @ 7:00 am

With the multitude of devices owned by consumers today and the large amount of time they spend using them daily, businesses are realizing the powerful impact that good software can have on driving revenue. Software provides a personalized, direct way for businesses to reach their customers, and it is continually being used by forward-thinking firms to come up with new and original ways to accomplish business goals.

(more…)

Posted on Wed, Apr 13, 2016 @ 6:46 am

I’m an old ­­software warhorse and wrote my first program back in 1972. Everything certainly has changed since then, but some principles endure. For example, one of my early bosses used to remark that good software was like a good axe a lumberjack used for years. Yes, the head had been changed several times and the handle was replaced a few times too, but somehow, it was still the same axe. His point was that good code should be designed and separated into components, so that as one part wears out, it can be replaced without throwing away the entire code base. Even when all the components have been replaced over time, somehow the product is still the same.

That concept of separate components with well-defined interfaces is particularly relevant in today’s digital business. As we all rush headlong into the process of digital transformation, it’s important that we don’t get so wrapped up in the latest mobile, cloud, and IoT technologies that we forget the basic notion that it will all change again. (And, like a metaphorical Yoda in the software world, I’ve lived long enough to see it change many, many times!) We can prepare for that change by moving to an API model that encapsulates our important business logic, which doesn’t change as often, from the ever-changing ways we use that logic to drive our business.

You often hear about the API economy these days, and as a veteran from the early days, I think it’s great to see us reach that nirvana of re-use we had long hoped for years ago. You no longer need to know the details of where data is stored, how it is accessed, or all the rules pertaining to it. You just call the component with an agreed-to format (API) and you instantly get the data you need to incorporate into your own program’s needs. This has given cloud-based software a tremendous boost that allows us to quickly build new software that stands on the shoulders of software already written and tested by someone else.

That same concept applies to our internal business software. If we can componentize our business rules and database access and create a set of well-defined API calls to handle things like adding a customer, calculating a payment, or giving out the current inventory level of a specific product, we are setting up our own building blocks that enable us to assemble them in new and important ways during our digital transformation efforts. Put another way, if we expect to fully participate in the API economy with other businesses, we must build our own APIs for ourselves first.

For example, APIs that record and monitor a car rental can be used by the rental agency’s website for booking purposes, by the renter’s expense management system to get the receipt and charges, and by the car’s manufacturer to provide usage information for warranty coverage.

While all this would certainly help the customer on his journey and streamline the car rental agency’s processing, it requires a lot of effort. The agency first must simplify its backend systems by getting rid of duplicate systems of record that store rental information inherited from prior acquisitions.  However, it takes years to decommission old systems of record. In the meantime, it may be necessary to design and build lower-level APIs around each of the duplicate systems and then build higher-level APIs to hide the fact that some of the data is actually stored in different systems. Neither the renter, nor his expense management system, nor the car manufacturer care one bit about which internal system the agency is using to record the transactions they need. You need to have your APIs mask all that complexity so you can offer a single view into your company and a single way to do business. This is the essence of what APIs offer to both your external customers and your own developers.

While it might be nice to try to build APIs for all your corporate data, the reality is that even if you could do it, the time and cost required would be prohibitive. You have to focus on building your APIs over time, embedding the work to do them in each of the short-term projects that our business requires. This requires some real discipline, as it always takes longer to build some APIs first than it would to just bang out the code asked for by the business.

Also, it always seems that your own staff, who are building new APIs, are the last ones to use them. However, by incenting them through carrots and sticks (like authorship awards for new APIs or penalties for not using them), you’ll create the ability to change the axehead and handle of your systems while keeping the essence of them the same.