Much has been written about how artificial intelligence (AI) will put white-collar workers out of a job eventually. Will robots soon be able to do what programmers do best — i.e., write software programs? Actually, if you are or were a developer, you’ve probably already written or used software programs that can generate other software programs. That’s called code generation; in the past, it was done through “next” generation programming languages (such as a second-, third-, fourth-, or even fifth-generation languages), today are called low code IDEs. But also Java, C and C++ geeks have been turning high level graphical models like UML or BPML into code. But that’s not what I am talking about: I am talking about a robot (or bot) or AI software system that, if given a business requirement in natural language, can write the code to implement it — or even come up with its own idea and write a program for it.
At the TechCrunch Disrupt event in NY today, Dag Kittlaus delivered the first public demonstration of Viv, his team’s follow-up to the popular Siri service. There’s been a lot of press in advance of the demo and frequent chatter around eBusiness and bots and what Viv means to them. My focus is on Application Development and Delivery (AD&D) professionals, so I thought I’d update you on what all of this means to them.
Viv is attempting to create what they’re calling a Global AI. While I’m not an AI expert, as I understand it AI entities are typically ‘trained’ using either algorithms or by dumping a bunch of data into it and helping it sort through it all. The self-training algorithms are where AI research had stalled until recently, but machine learning and other methods are revitalizing it. The Viv team, however, is taking a different approach. They’ve built the requisite language processing capabilities (through a partnership with Nuance) and coupled that with a code generator (what they call dynamic program generation) that delivers the needed results. What happens in between? Well, that’s the special sauce that will be very interesting for developers.
The knowledge Viv uses to deliver on voice requests is directly driven by direct input from developers. Well, that’s not necessarily true, but you’ll see what I mean in a minute.
Knowledge is power. And in a time where insights drive business differentiation, knowledge is also the origin of power. In our daily routines as consumers, search is probably the most common application we use to find knowledge, and it forms the basis of our personal systems of insight. But at long last, search in the enterprise is catching up. A new wave of search-based applications and search-driven experiences are now being delivered by companies who understand the need to empower their employees and customers with immediate, contextual knowledge in an easily-consumable format.
In our new research, Mike Gualtieri and I look at how the emerging landscape of cognitive search experiences are incorporating advanced analytics, natural language processing (NLP), and machine learning to enable organizations to see across wide arrays of enterprise data and stitch together insights hidden among them.
Front-end developers are getting the short end of the stick: they're either considered not technical enough to be a developer or too technical to be considered a designer/engineer. This conflict resonates further into the organization and stakeholders aren't in agreement on where front-end developers should sit---with the BT organization or within the business. Both sides make compelling arguments as to why front-end devs should sit within their respective parts of the organization. Our recent developer survey tells us that 47% of developers sit within a single centralized BT organization.
The main reasons BT organization argues three reasons front-end developers should sit within BT:
To make sure that development standards are consistent.
It ensures that they work in sync with the back-end team.
Front-end devs work with code and BT should have ownership of anything related to code.
On the other hand, marketing argues that front-end developers (also referred to as designers/web developers) are better suited for marketing since:
Front-end devs can create rapid prototypes for customers to see their ideas conceptualized, but it’s not intended to be production-ready at all.
BT organization moves too slowly and is unable to deliver the changes needed to enhance the customer journey at the speed it requires.
The modern business world echoes with the sound of time-tested business models being shattered by digital upstarts, while the rate of disruption is accelerating. Organizations that will win in this world must hone their ability to deliver high-value experiences, based on high quality software with very short refresh cycles. Customers are driving this shift; every experience raises their expectations and their choices are no longer limited. Like trust, loyalty takes years to build and only a moment to lose. The threat is existential: Organizations need to drive innovation and disrupt their competitors or they will cease to exist.
Very much in the shadows of all the press coverage and hysteria attendant on emerging cloud architectures and customer-facing systems of engagement are the nitty-gritty operational details that lurk like monsters in the swamp of legacy infrastructure, and some of them have teeth. And sometimes these teeth can really take a bite out of the posterior of an unprepared organization.
One of those toothy animals that I&O groups are increasingly encountering in their landscapes is the problem of what to do with Windows Server 2003 (WS2003). It turns out there are still approximately 11 million WS2003 systems running today, with another 10+ million instances running as VM guests. Overall, possibly more than 22 million OS images and a ton of hardware that will need replacing and upgrading. And increasing numbers of organizations have finally begun to take seriously the fact that Microsoft is really going to end support and updates as of July 2015.
Based on the conversations I have been having with our clients, the typical I&O group that is now scrambling to come up with a plan has not been willfully negligent, nor are they stupid. Usually WS2003 servers are legacy servers, quietly running some mature piece of code, often in satellite locations or in the shops of acquired companies. The workloads are a mix of ISV and bespoke code, but it is often a LOB-specific application, with the run-of-the-mill collaboration, infrastructure servers and, etc. having long since migrated to newer platforms. A surprising number of clients have told me that they have identified the servers, but not always the applications or the business owners – often a complex task for an old resource in a large company.
Developers And Their Business Counterparts Are Caught In A Trap
They swim in game-changing new technologies that can access more than a billion hyperconnected customers, but they struggle to design and develop applications that delight customers and dazzle shareholders with annuity-like streams of revenue. The challenge isn’t application development; app developers can ingest and use new technologies as fast as they come. The challenge is that developers are stuck in a design paradigm that reduces app design to making functionality and content decisions based on a few defined customer personas or segments.
Personas Are Sorely Insufficient
How could there be anything wrong with this conventional design paradigm? Functionality? Check. Content? Check. Customer personas? Ah — herein lies the problem. These aggregate representations of your customers can prove valuable when designing apps and are supposedly the state of the art when it comes to customer experience and app design, but personas are blind to the needs of the individual user. Personas were fine in 1999 and maybe even in 2009 — but no longer, because we live in a world of 7 billion “me”s. Customers increasingly expect and deserve to a have a personal relationship with the hundreds of brands in their lives. Companies that increasingly ratchet up individual experience will succeed. Those that don’t will increasingly become strangers to their customers.
What a strange summer this has been! From Boston to London to Paris to Turin, the weather has offered weekly and even daily reversals, with continuous change from sun to rain, from hot and damp to cool and crisp. I missed a nice spring season. Even today, from 35º-38º Celsius (95º-100º Fahrenheit), we just went to 22º Celsius (71º Fahrenheit) with a perfect storm! A continuous climate and sudden change is quite unusual in some of these countries. Certainly it is where the Azores Anticyclone usually dominates from mid-late June to mid-late August, offering a stable summer. How many times have you had to change plans because you discover weather is about to change!?
You might be thinking, "What does this have to do with this AD&D blog?" It’s about change! I am wondering if, in our daily lives, getting used to unexpected conditions and having to handle continuous change favors a mindset where change is just something we have to deal with and not fight. A new mindset very much needed given the change we see ahead in how we develop, test, and deploy software!
My focus in this blog is testing, although the first change we need to get used to is that we can’t talk any longer about testing in an isolated fashion! Testing is getting more and more interconnected in a continuous feedback loop with development and deployment. (See my colleague Kurt Bittner's report on continuous delivery; I could not agree more with what Kurt says there!)
In the days when web applications were king, this type of insight was doable with simple web analytics and similar tools. Today, continual experience optimization is much more difficult because of:
Multiple interaction channels. You must collect, correlate, and analyze data in a coherent way across multiple channels of customer interaction. A single customer interaction may cross between channels or even use more than one channel at the same time.
Many back end servers. You must integrate data from multiple back end servers including recommendation engines, commerce, mobile application servers, digital asset management, community, collaboration, messaging, and more.
The need for rapid change. You must quickly change any or all of your digital experiences and back end services based on what you’ve learned.
The need for contextual experiences. You must use each individual customer’s context to dynamically adjust experiences in real-time.
I just finished my new report on the Agile testing tools landscape. I’ll point Forrester readers to it as soon as it publishes. But there are few things that have struck me since I took over the software quality and testing research coverage at Forrester and which I would like to share with you in this preview of my findings of the testing tools landscape doc.
My research focus area was initially on software development life cycles (SDLCs) with a main focus on Agile and Lean. In fact, my main contribution in the past 12 months has been to the Forrester Agile and Lean playbook, where all my testing research has also focused. Among other reasons, I took the testing research area because testing was becoming more and more a discipline for software developers. So it all made sense for me to extend my software development research focus with testing. But I was not sure how deep testing was really going to integrate with development. My concern was that I’d have to spend too much time on the traditional testing standards, processes, and practices and little on new and more advanced development and testing practices. After 12 months, I am happy to say that it was the right bet! My published recent research shows the shift testing is making, and so does the testing tool landscape document, and here is why: