How To Become Just Enough of A Software Company To Succeed

I’m told by people who would know that Jeff Bezos thinks of Amazon as a software company, not a retailer or an e-commerce company.

I’m told by people who would know that Jeff Bezos thinks of Amazon as a software company, not a retailer or an e-commerce company. I have no doubt that large Internet players like Facebook, Google, LinkedIn, Twitter and others in that category understand deeply that they are in a software arms race that is fueled by computer science, engineering, data science, digital marketing, and lots of talented people.

But what does this mean for the rest of us? Large companies like Wal-Mart have sought to get into the action by creating Wal-Mart Labs in Silicon Valley. But how will the average company get into the software business? Do we really have to?

Yes, is the answer. We really have to. As Mark Andreessen famously said, “Software is eating the world.” And remember, each bite takes place through a powerful application.

We’re All in the Software Business

So, yes, we must be in the software business. But we must do so in a way that fits our needs, our skills, and the amount of money we have to spend. I run a content marketing agency. I’m a CTO and a trained computer scientist. So perhaps I could do some hacking on Google Apps Script, or use Splunk to sift my Twitter feed or web logs. If I really had a good idea, maybe once a year I could do an app in Python or Java or Ruby. But what would this do for me? Well, if the app were powerful, it might help a lot. But in my small company, it would also create some technical debt that could only be paid by my time or by spending money on a developer, and we don’t have developers on staff.

My situation is a microcosm of what happens in most companies in which perhaps there is some small development capacity somewhere. If you use those folks to create the software using the same sort of raw materials that the large players use (Java, Python, Hadoop, and the like), you may end up creating a good app, but you will certainly create a load of growing technical debt. Any application needs to be configured, operated, and maintained. The more complex and low level the tools you use, the higher the debt will be.

We Need More Apps

In addition, when you create an application, it often does one thing quite well, but it won’t take long before you want to collaborate about what’s happening, to add documents and link to other content, and to access the app from a mobile device. Adding all this takes time and money. You will never get there with a small team.

Now the reason that Google and Amazon are using raw materials to build software is that they are indeed making a ton of money from their apps. But in most companies, the killer app is rare, but the app that makes something better in a moderate way is common. Think of apps as call options on a good outcome. The cheaper development is and the cheaper it is to maintain, the lower the price to exercise those call options and get better results.

Wanted: Faster App Creation, Less Technical Debt

So, if we could somehow make development less expensive in a way that incurred little technical debt, we could create a lot more applications. If we could make development easier so that not just a small team but a much larger group could create applications, we would remove another bottleneck.

Attempts to improving programmer productivity are nothing new. Since the first programmer started coding in assembler language, there have been a succession of attempts to make programming better. Languages from Fortran, Algol, and C all helped. CASE tools and third generation languages led to fourth generation languages and declarative programming and on an on.

But now I think we might have gotten there. The world of BPM and case management has morphed and expanded into a large scale model for developing applications. While many of the players in this space have made great strides both as businesses and in creating modeling environments, names such as Pegasystems, Lombardi, MicroPact, and many others, we have environments in which quite complex applications can be modeled and deployed without using raw computer science resources and without incurring technical debt.

Appian’s Vision

The company that I think is further along in executing on this vision is Appian, and this week I am visiting their annual conference. I’m using it as an opportunity to do some research for Appian into the question of how you can put in place an internal capability for creating applications that expands productivity, increases the pool of available developers, incorporates social and mobile, can easily incorporate data and documents, and can be deployed in the cloud.

Appian 7 makes great strides toward the kind of system that meets those requirements. The goal of Appian 7, and all previous versions, is to subsume as much of the complexity of development as possible and make it as inexpensive as possible to create custom applications. The latest round of funding Appian received is based on the investor’s view that the company has indeed cracked the code on this challenge. “It’s a huge opportunity, because this is a monster new industry,” said NEA General Partner Harry Weller in an article in the Wall Street Journal. “Have you ever wanted to automate something? Did you ever just want to pay someone to do it because the application just doesn’t exist? Enterprises have this same problem. Companies are trying to automate everything. [Custom software and applications] account for a third of the total software market. It is absolutely huge.”

In future research, I will examine the degree to which Appian has fulfilled this vision. But it is clear from the case studies presented at Appian World 2014, from which I’m writing this, that companies in many industries are finding a way to dramatically increase their capacity to create custom applications using Appian. Of course, other BPM vendors have victories they can point to as well.

My point is not that Appian is the only way to do this, but rather, that it is time for those of us who are early adopters seeking business advantage to take a close look at what Appian has done.

From Problem to Platform to Transformation

As I’ve talked to customers and implementation partners, an interesting pattern has emerged. At first companies implement Appian to address a particular pain point or problem. They then see how widely it can be applied and regard it as a platform. Finally, the most advanced companies realize that they can use Appian as a way to power a program to reengineer and transform their businesses, finding both efficiencies and new revenue.

Case Study: The Chicago Mercantile Exchange

A presentation by the Chicago Mercantile Exchange entitled “BPM for Growth: Driving Revenue, Not Just Efficiency” describes the transformational power of Appian in a brilliant fashion. What struck me about the progression described by the speakers from CME was the way that the pattern of problem, platform, and transformation was executed. The first apps built advocates and got the attention of senior executives. Early successes were quantified and supported large investments. Gradually executive involvement in apps was increased. Now CME is increasingly focused on improving the speed of new product introductions and the quality of customer experience. The creation of new apps is not just about efficiency but has become a program to improve and reengineer the way business takes place and to add new revenue creating products.

This is of course the vision described in a case study of a victor. But to me, someone who has seen many such cases presented, it rings true.

Focus on Growth, Not Cutting Costs

Now my interest is to figure out what can be learned from companies that have successfully moved from problem to platform to transformation. The CME speakers didn’t underestimate the difficulty of transformation. They coined the concept of organizational debt, which refers to the gap between current operations and processes and a desired future state. In addition, they said that many cultural changes were needed, such as a focus on metrics, process discipline, and growth. One of the best pieces of advice they gave was that any program of improvement using a technology like Appian must be sold as a growth accelerator not as a cost cutter. If you focus on growth, everyone can get on board without getting nervous.

Of course, there are always bumps on a challenging road such as this. It is my job to find out what they are and let you know about them. But right now, I am excited that as an early adopter there appears to be a way forward that can have significant business impact without incurring technical debt. If you are on a journey like the one I am describing, please drop me a line. I would love to learn more about how to get this right because in the near future we all need to figure out how to be in the software business without drowning in technical debt.

Author: Dan Woods

My mission: Find technology for Early Adopters. Follow me on Twitter @danwoodsearly and on LinkedIn www.linkedin.com/in/danwoodsearly/. I am a CTO, writer, and consultant. For tech vendors, I help explain their technology. For users, I help find, select, and deploy new solutions that have explosive business value. I love to speak and share ideas.