Code != Product

When I was a young consultant working in professional services, I would make the mistake of writing some cool product feature, throwing it over the wall to product development and waiting for my feature to show up in next month's release. Inevitably they'd throw out all of the beautiful code I'd written and the feature would show up in a release a year or two later. I made the rookie mistake of equivocating code with product. Having worked in product development at Oracle for five years and now commercetools for three years, it's now painfully clear how much of the picture I was missing. Product development is really hard.

Product development is even harder today due to the fundamental change in how software is delivered. Infor's GM of Retail, Corey Tollefson, summed it up best when he Tweeted:

The service is now the product.

Product

Let's start with fundamentals. All product development starts with a product manager or product owner who defines what's being built, for whom and in what priority relative to the feature backlog. It's the product manager or product owner's job to bring the voice of the customer back to the development teams to ensure the right feature is being built for the right customer segments. This often involves looking into the future, as the customers you have when you start out are unlikely to be the customers you'll have after being on the market for a few years. Depending on the organization, many product managers are also tasked with go to market and even commercialization of new features.

Architecture

Next, it's up to architects to properly design the feature based on the scope decided by the product manager or product owner. Architects (or developers serving in an architecture role) step back and take into consideration how current and future customers will use the feature, keeping in mind that the feature will likely have to be built on and extended years or even decades into the future, depending on the strategic objectives of the organization. A small startup in San Francisco startup pioneering some new technology may be building software to last for the next six months whereas a big established tech vendor writing a new ERP may be building it to last for the next 25 years. Whatever the time horizon, it's the architect's responsibility to ensure the feature lasts as long as its projected lifespan.

Architects also have to consider the deployment of the feature. For example, will the feature scale? A feature built to run across 100 containers may not scale when the platform grows to 1,000 containers. For applications in multi-tenant architectures, the scale is often a few orders of magnitude larger than single-tenant architectures. That brings other considerations, such as whether the feature impacts overall platform stability. For example, would a user trying to index 100 million products cause stability or performance issues for other tenants of the platform? Multi-tenancy is great for users of the platform but does cause additional overhead for software vendors who have to take more considerations into account. Every single feature has to be architected to work at scale.

For API-based platforms, architects have to model APIs to be as easy as possible for developers to consume, taking into account whether APIs are versioned and/or evolved over time.

Development

Next, developers take over and actually build the feature according to the prioritization and scope defined by the product manager or product owner, and according to the architecture defined by the architect(s). The feature then has to be surfaced in any business user tooling (which itself requires UX design), and any reference applications.

For API-based platforms, developers need to update the API specification (usually OpenAPI or RAML), re-generate SDKs, and re-generate any other artifacts that are driven by the API specification. If APIs are versioned, the feature may need to be back ported to older versions of the API. If GraphQL is offered, the feature also needs to be exposed there as well, for both queries and mutations.

Finally, handoff instructions need to be given to those who are responsible for testing and those who are responsible for deploying the code.

Testing

Once developed, the feature must be added to all of the automated testing scripts that are (should be) executed with each merge. The scripts should cover all of the ways a feature is surfaced including API, SDKs, GraphQL, and business user interfaces. The various scripts themselves can be big applications that have their own architecture/development/testing lifecycles.

Once the feature has been added to all of the testing infrastructure, all of the tests need to be executed to ensure that the new feature introduced doesn't cause any problems. For API-based platforms that rely on evolving APIs, the feature needs to be tested to ensure it doesn't break backwards API compatibility.

Next, source code needs to be scanned (white box testing) and then the running application then needs to be scanned (black box testing).

Go to Market

At this point, the feature is ready to be made available to customers. But before that can happen, a number of go to market-related tasks need to be performed. Features just can't be released without the rest of the organization and customers being notified that the feature is coming.

To begin, all of the documentation needs to be updated, including any tutorials, examples, and recorded demos. Documentation is just as important for internal constituencies (support, customer success, training, professional service, sales, etc) as it is for external constituencies (partners, customers).

Next, support, customer success, training, and professional services need to be given notification that the feature is coming and be given links to documentation and any other technical collateral, including architecture documents. Depending on the size and complexity of the feature, it may even be appropriate for developers to host internal training on the new feature.

If the feature is visible enough, it may be necessary to train pre-sales engineers and sales people on the new feature.

Finally, the feature should be announced publicly through release notes, social media, a blog post or even a press release in the case of an extremely valuable feature. The public communication should include links to documentation, tutorials and demos where appropriate.

Operations

At this point, the feature is architected, developed, tested, the organization is prepared, and the feature is announced publicly. It's now ready to be used by actual customers.

If the feature is particularly experimental, it may not be a bad idea to have the feature beta tested by a few friendly customers and/or partners. These folks can offer real-time feedback on how useful the feature is or how it could be improved. If the feature has issues, they're not likely to get too upset.

If the software is traditional on premises, the customer is then responsible from this point forward. The feature is shipped as part of a release, the customer downloads the binary and deploys it to production on their own. If the software is delivered as SaaS, the vendor's responsibility is just beginning. Customer are buying a service, not an artifact that they have to deploy and manage on their own.

Operating a service begins with taking the artifact that's produced by the CI/CD pipeline, deploying it to some physical hardware, and instantiating it. The artifact could be a binary, a package that's deployed to an application server, a Docker image or a virtual machine image. Typically, the artifact is a Docker image that's deployed to Kubernetes. New code is often rolled out slowly using a canary-style release methodology so that it can be tested and rolled back if it causes problems.

Once running, the application needs to be scaled up and down in real-time based on customer demand. If the entire application stack is containerized and deployed to a container orchestration platform like Kubernetes, new capacity can be added and removed within a few hundred milliseconds. But configuring all of this takes a lot of work, from defining the scaling policies, to configuring the API gateway, to configuring the networking and storage infrastructures.

Security is also a big topic. Any application that touches sensitive data like credit cards or personally identifiable information is an immediate target. Regular external penetration testing is required. Additionally, the entire platform is likely required to meet standards such as ISO270***, SOC *, PCI *, GDPR, and even more country-specific standards. Individual features can impact compliance.

As being responsible for a service, the vendor is also responsible for 24/7 monitoring and alerting. If there is an issue, there has to be well-documented escalation policies that can actually get service restored. It can take years to establish a functional process. New features in particular can cause issues that an ops team needs to be able to resolve even if the developer(s) who built the feature are sound asleep half way around the world.

Next, backups and restores need to be handled, sometimes on a feature-by-feature basis. Backups should be on a regular interval. Restores should be able to happen within tens of minutes. The restoration process should be tested on a regular basis.

Finally, the software and services on which you rely need to be upgraded and patched. For example, your operating systems, your encryption libraries, any cloud services you use, etc. The dozens of pieces of software and services that compose your stack are constantly evolving.

Final Thoughts

As you can see, offering a product is an enormous amount of work. Offering that product as a service is even more work. Don't make the same mistake I did by equivocating some code to a product or a service. In some cases, the code is the easiest part. It's the entire value chain around that code that's the difference between a customer's success or failure. As Corey's tweet correctly points out, the relationship you have with your vendor now begins at contract signature - not ends.

About commercetools

commercetools is a next generation software technology company that offers a true cloud commerce platform, providing the building blocks for the new digital commerce age. Our leading-edge API approach helps retailers create brand value by empowering commerce teams to design unique and engaging digital commerce experiences everywhere – today and in the future. Our agile, componentized architecture improves profitability by significantly reducing development time and resources required to migrate to modern commerce technology and meet new customer demands. 

The innovative platform design enables commerce possibilities for the future by offering the option to either use the platform's entire set of features or deploy individual services, á la carte over time. This state-of-the-art architecture is the perfect starting point for customized microservices, enabling retailers to significantly reduce time-to-market for innovative commerce functionalities.

With offices in Germany and the United States, B2C and B2B companies from across the globe including well-known brands in fashion, E-Food, and DIY retail trust commercetools to power their digital commerce business.

Visit www.commercetools.com for more information.