We Are Doing Agency Tech Wrong
Digital Agency technology: I’ve been doing it for about 20 years now, and it sucks. Technology projects at digital agencies are expensive, high risk, and often produce mediocre results. It’s no wonder that quite a few design-led agencies have chosen to exit the technology part of the business altogether, heading for the relatively calmer waters of visual design, UX, strategy etc.
In the past, as a developer, and later as a technology manager, I used to blame the account people for this. They made terrible, unrealistic promises to the client, I thought, throwing us tech people under the bus. But then I noticed something: the account people were unhappy with the situation as well. Turns out, the agency was losing money on the tech job.
Later, as a business owner I came to realize the problems with selling agency tech. It is perceived as a commodity by most clients, who simply seek a baseline level of competency for the cheapest cost. This is the force that has driven agencies towards offshore development which, despite the difficulties of managing it, has effectively become an inevitability for many agencies. Offshoring has become essential to ensure the technology component of a project is profitable.
How did we get here?
The Slow Moving Train Wreck
To understand the evolution of tech at digital agencies, one first has to look at the sales process.
No account or new business person wants to make a sale harder. That means removing as many objections as possible: project risks (real or perceived) that the client may raise that can kill a deal. One huge perceived risk is unfamiliar technology. To non-technical decision makers, technology is an opaque source of potentially project-threatening risk that scares the hell out of them. Many people have had experience with tech projects that have failed, and they don’t want to repeat those failures.
To overcome the technology platform objection, most agencies have either rallied around well known open source projects (such as Drupal, Magento, Wordpress etc.) for small and medium sized clients, or big, enterprise offerings (Microsoft, Oracle, IBM) for large corporate clients. As they say, no one was ever fired for selecting these stacks, so the objection is overcome.
A second issue is that everyone has developed the expectation that pre-existing tech tools provide comprehensive solutions for business problems. People look to a single tool or framework to provide all of the necessary functionality to automate a complete business function (e.g. Magento: everything you need for e-commerce). Frequently, these comprehensive frameworks will offer out-of-box experiences that are easy to stand up and demo great. However, they are rarely exactly what a client needs. They have to be customized in order to solve the client’s specific business problems.
This is where the problems begin. Monolithic solutions frequently incur exponential development costs as they are modified further and further from their default functionality. Eventually, one could start to question the advantage of using them in the first place. Someone will raise the question: why didn’t we just build this from scratch, using a more general purpose tool like Rails, Django or Node.js?
The answer: because it’s harder to sell. That’s because it’s clear that the upfront costs of implementing the solution with a general purpose framework will be more than using a specialized monolithic solution, and it’s difficult (and for the client, probably impossible) to visualize when the project will cross the line and cost more for the monolithic solution than the general purpose framework. This means the perception of risk by the client is greater for general purpose frameworks, even if they are safer in reality.
Finally, the drive towards re-use of technology, the use of pre-existing monolithic frameworks and the general commoditization of technology services has culminated in the establishment of very conservative goals for technology. Neither agencies nor clients look towards technology as a source of innovation for projects. (Typically, an agency will position their visual design or UX as innovative.) This means that clients who rely on agency tech will always trail the market by a significant factor. Technology provides little to no competitive advantage to them, and at best they can hope to achieve a hygienic level of technology use: they are up-to-date enough to be acceptable, but certainly not notable.
If you put all of these factors together, you get an agency tech environment that sucks. It is conservative, expensive, and certainly not providing the best technology has to offer to clients. There is, however a better way.
A Club Sandwich of Technology Services
A re-engineering of digital agency technology services should result in offerings that are cheaper to implement, easier to predict and estimate, and yet flexible enough to allow for client-specific innovation. I’m proposing a four-layer approach to agency tech to make this happen.
Let’s have a look at the stack. We’ll start from the bottom up.
Intelligence / Data Layer
The overall trend in tech is toward making products smarter, and this usually means a good foundation of data. Outside of Silicon Valley, while there is a general understanding that data is important, there is much less clarity on how to make it actionable. Additionally, data collection efforts are frequently clumsy.
A digital agency should identify one or two target industries and start to collect data (probably consumer behavioral data) that is specific to those industries. The idea is to look for data that can form the basis for behavioral segmentation and insights.
This collected data will become a proprietary asset of the agency. Now, when clients from that industry come calling, the agency can offer a unique domain expertise that will inform and power the products they build.
The data can also be used to generate reports and whitepapers, feeding directly into the agency’s PR efforts and thus become part of their overall marketing effort.
Microservice Primitives Layer
Next is a layer of business function primitives, organized as microservices. Microservices expose functionality via an HTTP service, making them set up to integrate, regardless of the tech stack that is consuming them.
What’s a primitive in this context? For this architecture, we’re going to define a primitive as a cluster of features that solves a specific, core business problem.
For example, a primitive microservice in e-commerce might be checkout — providing all the business logic required to process payments and order creation. Alternately, a primitive might handle product pricing and discounting. In the publishing space, a primitive might take care of related content.
The primitives can be addressed as microservices themselves, or they can be combined together to create more complex services. The capability of the primitives to be combined decouples the scope of individual primitives from the service API, allowing for whatever level of API granularity suits the situation best.
Because the functionality that these primitives provide is exposed as microservices, they are designed to be integrated, from the ground up, with other systems. In contrast to a monolithic framework that requires modification, the primitives only incur a linear cost to integrate, because there is no default integrated structure that has to be stripped out.
Additionally, the primitives would leverage the Intelligence/Data Layer. So if the agency had built a consumer behavior database for the publishing industry, a content recommendation primitive could leverage that data when making recommendations.
Business Rules
No matter how well thought out the default behavior of the Microservice Primitives Layer, it is likely that the requirements of individual clients will be different than what is offered. This is expected, and can be addressed with client-specific business rules.
The Microservice Primitives are designed to have their behavior modified by easily written business rules. Rules like shipping is free when more than $200 is ordered or this week’s featured book should always be at the top of the recommendations are easy enough to author that a business analyst can handle it without requiring a developer. The primitive picks up the rule and modifies its behavior accordingly.
The important idea here is to jettison the assumption that the default behavior works for everyone, and to design services from the ground up that accept rules-based modification. This keeps the cost of modification under control.
Design Patterns and Customization
Atop this infrastructure sits a layer where agencies can create complete client-specific solutions that are unique and hopefully innovative. I call out the idea of Design Patterns in this layer in order to reinforce that there are archetypal best practices that can be used to construct a product. However, I also mention Customization, to indicate that it’s completely reasonable to seek innovative solutions that leverage technology.
This layer is the visible part of the product, with everything else being infrastructure. However, that infrastructure sets up this layer for success. It enables innovative technology to power clients’ products, even if those products are built by an agency.
Why This Works
While not all digital agency problems can or should be addressed from the technology discipline, digital agencies that adopt the Club Sandwich can gain three big advantages over their competitors:
First the proprietary data in the Intelligence / Data Layer provides differentiation for the agency. Look at a dozen digital agency websites and you’ll notice that they all start to look the same: digital agencies have a hard time distinguishing themselves in a crowded market. However, an agency with a proprietary database of industry-specific consumer behavior is significantly differentiated.
Secondly, the combination of the Microservice Primitives Layer and the Business Rules Layer enables bespoke functionality at a reasonable, linear cost. By controlling the cost of implementation, the agency can be price-competitive and avoid the exponential cost of customization associated with monolithic frameworks.
Finally, the prior existence of microservices that provide functionality that address specific business problems, reduces the client’s perceived risk, which in turn eases the sales and account management functions of the agency. For example, a microservice that specifically addresses sales tax calculation will be perceived as less risky to use than the agency’s assertion that they can build sales tax calculation using a general purpose web framework.
Agency technology doesn’t have to suck. It doesn’t have to be risky, expensive and mediocre. The Club Sandwich architecture is an approach that tries to address the actual technology needs of digital agencies and their clients, instead of merely re-purposing solutions that aren’t optimized for agency work.
Like the thinking? Hire me. I work in technology leadership, team building and technology strategy. More info at www.lorendavie.com.
