By Sameer Soman
Managing Director for ThoughtWorks in India
There is an evolving enterprise-wide disruption where technology is fast becoming the prime enabler of new business opportunities. We, at ThoughtWorks call this ‘Tech@core,’ and it will make-or-break most enterprises in the next 5-10 years.
Let’s quickly go over the primary intent of any organization’s digital transformation journey -
At the same time, it’s just as important for everyone partaking in this journey to acknowledge a few hard truths about transformation. These include -
In retrospect, the big question is no longer, ‘How can an enterprise transform?’ but, ‘Can it continue to evolve at the required pace?’
I would advise every far sighted enterprise leader (on the digital transformation path) to visualize these five building blocks. They are what I believe will make up an ideal-state Modern Digital Business.
A modern digital business is made up of these 5 building blocks
Of these 5 blocks, I have focused on Building Digital Product Capabilities while writing this paper. Here’s why? It’s when modern digital businesses view their technology assets as multiple products (not multiple point solutions) that they can evolve the products to meet dynamic business needs and become responsive to external environmental changes.
This flexibility stems from the seamless collaboration of people, process and technology while building the product. And, it ensures that digital experiments don’t break down as organizations progress along the path of transformation.
At its core, digital businesses build products with no significant upfront capital expenditure and the product development lifecycle transforms cost and value benefits, effectively converting CapEx into OpEx.
Products built in a traditional business environment vs. in a modern digital business
Getting a winning product or service into your customers’ hands begins with your proven value proposition. What follows is your product evolution strategy for enhancing, scaling or transitioning your product over time.
This approach takes businesses down the path of building strong product innovation capabilities that ensure the continued refinement and reinvention of the product. For organizations that are thinking along these lines, the question is, 'What does my end state look and feel like?', 'How will I know that I have arrived?'
My recommendation when trying to answer these questions is to look at the progression across four parameters:
The four parameters to consider when building a digital product capability
Agile practices like Continuous Delivery help organizations rapidly react to market changes. However putting them into practice when armed with a big legacy monolith application can be difficult. Over time, the industry has come out with different ideas to solve this problem. And, microservices, pushed by companies like Netflix or Amazon is one such approach.
The integration of disconnected systems using APIs and coupled with microservices enables the distribution of previously monolithic systems. This leads to a powerful mix that leverages tools and processes composed of multiple systems, running in different places.
Good architecture balances business and techical requirements
However, it’s no easy task to migrate from a monolith to microservices because it’s hard to decide when to split services. This approach requires a strong underlying platform and great DevOps practices to be in place., making microservices, a great destination with a long journey.
I often see people end up with a distributed monolith — a distributed system with none of the benefits. This is because the domain modeling goes wrong and fails to adopt the microservices architectural style. The result is businesses just winding up with small services.
As represented above, a true ‘microservices operating model’ encompasses shifts in team design, responsibilities and associated organizational impacts. This model should be founded on a series of business and platform capabilities. This should be followed by aligning long-lived teams that plan, build and run products to deliver those capabilities.
I’d very much caution against the idea of creating a monolithic ‘platform’ team or simply hoping that shared business capabilities will emerge by chance and be curated by osmosis.
A distributed engagement between ThoughtWorks' London and Bangalore offices for over 12 years (with a peak team size of 240 people)
The client’s business was constrained by an unscalable platform
This resulted in:
What we did:
Most organizations have already adopted infrastructure automation tools and dynamic private or public clouds. However, technology alone cannot help IT quickly respond to changing opportunities and challenges. At worst, the ability to rapidly spin up new infrastructure could lead to a sprawl of poorly maintained systems.
Infrastructure as Code, IaC manages infrastructure by leveraging software engineering practices. Ultimately, infrastructure should aim at reducing system-related friction while increasing flexibility and ease of scaling. Companies like Facebook and Etsy are exploiting the IaC approach and can incorporate changes far more frequently while ‘upping’ the reliability, security and quality of their IT services.
I believe that a defining characteristic of the ‘Cloud Age’ is how infrastructure can now be treated like software. Couple this shift with effective software development practices and businesses can take advantage of the growing ecosystem of tools that has been designed to support change.
A year long partnership with a 35+ strong team mobilizing technology understanding, local market context, strong agile practices and a customer-first approach
What we did:
As businesses continuously innovate their digital products and services, there is a relentless focus on human-centered design and frictionless customer experiences. Once a business’ value proposition has been proven to customers, it’s time for leadership to think about the product evolution strategy. This will focus on enhancing, scaling or transitioning the product over time.
At its core, product thinking involves a shift from the traditional approach to development, where software or products are built to order and are ‘handed off,’ to a more expansive, holistic process, defined by continuous ownership and improvement.
Applying the right resources to a customer problem can be a delicate art. With customer value being the ultimate goal, customer-centricity is the defining characteristic of the product mindset. This course works best when everyone involved in the product cycle, designers to C-suite, occasionally serve on the front lines and involve themselves in customer interaction. This same approach works with respect to the intelligent use of data as well; supplementing caches of data with real-world analysis and experience.
Along with learning more about its customer base, the enterprise aiming to excel at customer experience will need to look within. Particularly at companies saddled with legacy structures, product thinking often requires cultural and organizational changes.
An 8 member team built a mobile Web site for different smartphones across the iOS, Android, BlackBerry, Windows platforms
What we did:
I believe Martin said it best when he said, “Don’t run it like a city.” His analogy goes on to describe the similarities between the ‘projects-mode’ and how cities are run. A city has to keep the lights on across departments such as water supply, sanitation, transportation, law and order etc. The people that work in these departments are the equivalent of ops (run) teams.
When a new metro line is to be introduced, the city funds them as projects and contractors execute them, the equivalent of build (change) teams.
Traditional enterprise IT has followed the two-pronged city model of permanent ‘run’ teams and on-demand ‘change teams’ i.e. the ‘projects’ approach, and have paid the price in terms of responsiveness to the business. Digital-age businesses can ill afford to be sluggish in responding to feedback from business stakeholders or the market. Business-capability aligned teams need to have access to funding, staffing and the authority to pivot their approach to a problem on the fly.
Product teams should ideally be empowered to own a product end-to-end and throughout its lifecycle - from envisioning and discovery through to delivery and optimization or evolution based on customer feedback. Product thinking recognizes that digital experiences deliver value to customers in the same way that physical products and services do, so they need to be continually enhanced and refreshed to stay competitive.
Building teams that are diverse and cross-functional, blending designers, developers and business representatives, helps make sure that they’re efficiently self-contained and empowered to deliver a successful experience from end to end.
An engagement spanning 5 years with a team of over 95+ people at peak, in 4 streams across ThoughtWorks' Cincinnati and Bangalore offices
What we did:
This paper extols product building capabilities as a critical enabler for building an innovative and dynamic organization. And, I believe this to be an imperative, in the emerging hyper-connected marketplace also called the Fourth Industrial Revolution. In fact, according to the World Economic Forum. We are looking at a “....transformation...unlike any humankind has experienced before...disrupting almost every industry in every country.”
Businesses like yours are functioning in an environment where, on the one hand, new digital organizations are disrupting old businesses and traditional enterprises, who, on the other hand are acquiring new firms to protect their turf.
Traditional enterprises are in the habit of developing several point solutions and then integrating them vertically - to form an end to end service or product for their customers. But, they are fighting for their place in a world where the digital natives are thinking product-first. The latter are building capabilities and infrastructures to horizontally scale these products - across market segments, customer bases, geographies etc. The winning formulae speaks for itself!
My hope is that this article will provide you with the required nudge and also present a starting point from where you can take forward your product-first approach.