Human brains constantly change their function and structure, and the term for this is neuroplasticity. Modern enterprises faced with constant challenges exercise a similar form of “plasticity” to adapt to a continuum of new changes. It was not always so, of course.
Thirty years ago, companies on people to get business done. They were organized in hierarchies complemented by narrowly scoped, localized systems of record. Change management programs restructured org charts, companies reeducated people, and eventually people were hired and fired. There was some change enforced on the existing system of records, but lack of agility (or lack of plasticity) was never a mission-critical impediment to success in business.
Since then, the changes have been twofold. First, the structure of an organization is now composed equally of people assets and digital assets. These digital assets—applications, data repositories, integration technologies, and so on—are part and parcel of the fabric of each company in the same way people are. Second, cycles of disruption and prosperity get shorter every day, and that requires adapting to a set of new challenges such as disruption, aggressive competitors, and new opportunities in ever smaller increments.
So, altering the structure of a company now means not only changing people but also changing the supporting digital systems across their functions and structures—faster. To survive, they must increase their levels of plasticity in their people and digital assets dramatically.
A new set of principles
This state of affairs clashes with the old strategy of acquiring prebuilt software. Just the other day, a CIO of a US corporation told me, “We buy or rent all our application software. We don’t develop anything.” But, using purchased software as-is is like outsourcing a function to an already-assembled team of people who have done it before without allowing for what makes an organization unique. It might be possible to get away with that for payroll, but for everything? That would be like outsourcing all your people. If that sounds ridiculous, why isn’t it also considered ridiculous when applied to digital assets?
The leading digital organizations have moved past trying to force-fit software someone else built into every corner of their organizations. Instead, they are applying a set of new principles to procuring, renewing, and operating digital assets—they combine buying (or renting) with building. This is how most of them go about it.
The buy side: Deploying a SaaS for your commodity processes
The buy side in the modern digital enterprise starts by identifying the areas of business that are commodities. Good examples are finance and HR (although some HR processes are not always commodities in certain industries). Once they’re identified, it is okay to bring some SaaS or packaged software in-house and deploy it as is. A certain degree of parameterization is necessary, but mostly you are following the process embedded in the software, the one that everyone else follows, too. You want your people to adapt to the software and absorb that tried-and-true industry practice.
Because there is little possibility of customization (and little reason to customize), organizations can deploy such software packages or services and have them up and running in a matter of weeks or a few months.
The build side
If your answer to “What do I want?” is “I want software that adapts to the way my organization works,” then it’s time to build. Here’s how that breaks down.
Assembling new systems from existing ones
The plasticity of a purchased software package is limited. Forward-looking digital enterprises are moving from large monolith packages or megacloud solutions and choosing smaller (cloud) services with narrower scopes and fully functional APIs as building blocks. By breaking solutions into very small pieces, companies can now select services that they don’t need to customize. Instead, new digital systems with unique interfaces, new workflow, and dashboards are assembled by stitching APIs together and developing new services and applications.
Fundamentally, you rent narrow commodity services and build the rest: what is missing, what might change in the future, and what is part of your competitive differentiation.
Migrating legacy systems
Trying to get by with existing legacy systems—old custom-developed applications or heavily customized packages— is like being given cement shoes. Moving becomes impossible. These systems serve areas of the business that are constantly being changed, and they can’t address backlogs that are growing ever larger. We have found that a lot of intellectual property has gone into these old systems. In most cases, the only sensible strategy is to redevelop (rebuild) the system into a modern architecture. As we all know, this is much easier said than done. These are big, scary projects will multiyear timelines and a lot of risk. But there are really cool strategies that are being applied here. But that’s a topic for another article.
The last mile of UI
Organizations using SaaS and scaling their number of users fast experience big problems in the way users work with the interface. Enforcing the use of the tool is a constant challenge for ops teams, lost productivity becomes an issue, and, nonvalidated, incoherent form data finds its way into data lakes and transforms them into swamps. As a result, digital leaders are developing new, highly engaging, optimized user interfaces for existing SaaS.
For example, a medium-sized organization using Salesforce.com was tripling its sales force. So, it completely redesigned the mobile and desktop user interface for sales reps, inside sales, and presales to accommodate its specific GTM model effectively.
So many things to build, so little time
In essence, “build or buy” isn’t the conundrum. Instead, it is “how do I build all these things fast and with agility?” This is because for any area of innovation or for any area where it’s extremely difficult to apply change management, building is the only answer. It also explains why developers are more important to IT departments than they have been in the recent past.
Meanwhile, building new digital assets from scratch with agility, stitching together microservices and components from different systems to create one better suited for the business, and delivering the right UI for users are very different from one another. It’s easy to think that different skills or different platforms are needed for each. And to start imagining the backlogs piling up.
This is exactly where the establishment of continuous delivery pipelines and the introduction of low-code platforms comes in. The need for innovation and the perfect UX are addressed by using low-code platforms to build what packaged systems don’t deliver—quickly and with agility. As for change management, low-code platforms offer the opportunity to build apps that address change requests and integrate with commercial off-the-shelf systems or cloud solutions.
On a final note, when you buy a software package or SaaS solution to absorb a particular best practice, make sure that everything you buy not only has user interfaces but also 100-percent functional coverage of APIs. It is very likely that pieces of what you’ve bought will become stitchable components.
This article is published as part of the IDG Contributor Network. Want to Join?
