Modernizing the Enterprise SDLC

The enterprise software development life cycle (SDLC) is often informed by consumer trends. The cloud and apps are two primary examples but there are many more. Once consumers experience better—or different—software in their personal lives, they demand that same experience at work.

In recent times, the maturity of enterprise SaaS itself has lead to its own innovation and patterns have developed within a new breed of enterprise cloud software. In some circles, these trends have been dubbed "Deep Collaboration" by VC firms such as Emergence Capital. They use this moniker as a lens for the enterprise cloud software investment strategy. These tools represent more sophisticated enterprise software-as-a-service experiences in cases where businesses want to take a buy versus build approach. They reveal, however, a huge opportunity to take these ideas into the enterprise software development life cycle.

These tools are designed with a jobs to be done mentality, are much more workflow-oriented, allow for greater collaboration across the organization (compared to within one group or role), and encourage democratization. I cover what each of these means and enterprise cloud software tools like Ironclad, Layer, Figma, Maze, and Cube in this episode of Sync. The more interesting takeaway for me, however, is showing how these principles have also been at work in the enterprise software development life cycle. That is, in cases where companies build over buy.

Note: What I share below comes from my experience as a digital executive leading multi-million dollar enterprise SDLCs, digital transformation, and comparable technology initiatives over the past five years at Fortune 500 firms. I've purposefully tied back these strategies to the "deep collaboration" moniker as a way to make these points more accessible and tactical.

From Personas to "Jobs to be Done"

Personas became a de facto standard for creating software in the early 2000s. Using an archetype—or some number of them—the goal was to represent those using your software (and later, apps). Personas include but are not limited to such characteristics as gender, age, ethnicity, income, and education levels. They've evolved through the years with different names such as users legends buyer legends. The point is that the software was designed for these specific people and not for those outside of them.

In the enterprise software development life cycle, personas will also include in-house team members across departments or business units, and not just clients, customers, members, or those outside their organizational walls. With deep collaboration, the mindset shifts from thinking about specific users to what jobs need to be done.

This particular concept really is the underpinning for creating deep collaboration enterprise software. Because with this approach, the philosophy to design the software is much more oriented to the organization as a whole, driving greater adoption. Which, by the way, will be a tenet that will be touched on in another section.

As an example, if creating a new app or platform for someone in the production part of the supply chain, a persona would focus just on the 2-3 kinds of production users, with perhaps different roles or permission levels. A jobs to be done mentality forces designers and architects to realize that the supply chain impacts everyone from planning, sourcing, product designers, manufacturing, distribution, and more. Even if the tool may primarily be used by product designers, its inputs and outputs will touch many others in the organization.

Beyond that, the software could be overly focused on trying to solve every problem of the product designer versus a specific set of tasks. This latter perspective is especially helpful in thinking about creating a suite of tools with shorter timelines and better economics, instead of the typical eight-figure budgets with multi-year schedules.

From Monolithic UX to Advanced Workflows

Monolithic systems are more synonymous with technology architectures than they are with UX and design. But the concept holds nonetheless. Because just as architectures were often based on single tiers that were challenging to scale and complex as they grew, so too were their corresponding interfaces.

Scrolling indefinitely, slow loading times due to the size of pages, difficulty in performing a certain task, and "frankendesigns" that represent years of ideas hacked together are just a handful of examples of monolithic UX.

One of the reasons these problems arise in the enterprise SDLC is simply the result of the sheer scope of the systems. Embracing the deep collaboration mindset of a job to be done moves from the need to build a system or platform that does everything to a specific set of tasks that tie back to a workflow or series of workflows.

With this approach, screens collapse in size, and the overall system—often, just an app—is focused on driving to an outcome. Additionally, instead of using a series of disparate docs, spreadsheets, tabs, and tools, the workflow incorporates each of those functions into one platform. That does not infer the move back to another monolithic system. Instead, enterprises wind up with a suite of focused, workflow-based applications that can "speak" to each other across a microservices software architecture.

From Departmental to Organizational Collaboration & Budgeting

In the enterprise SaaS space, pricing is a way to democratize the adoption of software. For the enterprise SDLC, the same can be done by simply embracing the principles of deep collaboration.

Designing interfaces and systems to touch each of those involved in a workflow ensures that platforms do not get relegated just to specific departments or business units. This means greater usage across the organization. But it also opens up the opportunity for shared budgets, meaning IT or technology groups alone do not have to fund software initiatives. On the flip side, it's easier for groups to justify not getting stuck with certain bills or have their budgets impacted for systems they are not using.

Concluding Note

Although deep collaboration has not been a phrase I've personally used over the last five years, it's a great way to help describe some of the strategies we've helped our clients within the enterprise SDLC. We increasingly are helping break down the historical approach of building or supporting large, complex, legacy systems and interfaces built around personas that solely are for—and funded by—specific departments or business units.

We're pushing beyond microservices to a features-as-a-service model (FaaS), where for every $1M our clients spend with us, we're saving them $10M of legacy spend. I'll be talking about what FaaS is in the coming months. With a jobs to be done and a workflow-based approach, these approaches are just beginning to impact the enterprise SDLC. In light of the advances of digital due to the 2020 impacts of COVID-19, these principles—and others that develop around them—will be incredibly important in the enterprise through 2025.

Curious about what "deep collaboration" looks like in the enterprise SaaS space? Then the episode below is for you. These examples will help you generate ideas within the enterprise SDLC.