Let Your Product Define Your Technology, Not Your Technology Define Your Product
Sticking with the same solutions is limiting. Our technology-agnostic philosophy powers product development that is consistent and flexible.
As developers, we often find ourselves deep in the details as we write and review the code that powers our products. Unsurprisingly, this leads to technology discussions that focus on those details: the languages, the patterns, the frameworks, and more. They are vital discussions that ensure we are able to operate at the cutting edge, utilizing powerful emerging technologies.
However, it’s not all we need to think about.
At Invoke, we aren’t always building from scratch. Our work with organizations of all sizes has shown us that the languages and vendors we utilize need to work with the rest of the organization. A truly useful enterprise product shouldn’t exist in an advanced, yet disconnected silo, it has to talk to the rest of the organization.
Building products in unique technological environments requires a familiarity with our options. It’s why Invoke has a bench of contractors outside of the core Invoke team that can bring specific skills to unique projects. They’re familiar with Invoke processes and can be ready to step in and deliver — and if you’re a developer, we’d love to talk to you about joining our team.
Our technology philosophy isn’t driven by specific solutions. It is a philosophy that gives us a consistent approach to why we choose the solutions that we do.
Because of how we work with our clients, it is essential that our technology philosophy isn’t limited to specific solutions. We need a philosophy that gives us a consistent approach to why we choose the solutions that we do. It must be a philosophy that works alongside our overarching belief that all digital products provide user value (are desirable), business value (are viable), and can be built (are feasible).
This is why, at Invoke, we base our development practices on a philosophy that is vendor agnostic and language agnostic. We believe in being domain-driven, being behaviour-driven, using serverless architecture, and executing our development practices with agility.
Domain-Driven Development
Any product opportunity starts with understanding the domain, and development is no different. At the outset of the project, we work to concretely define the problem space that we’re working in. To be effective, this space has to be specific and contained enough to properly evaluate solutions. For example, if we think of a problem as “ecommerce”, it is large and sprawling with many conflicting considerations. On the other hand, “buying groceries online” operates at the right level. It has different users with different needs, but it’s a specific problem space to operate in.
With the problem space defined, we adapt our development practices so that the application is designed around the business domain. In online grocery, this would mean we would be considering metrics like “basket size” that aren’t necessarily used across the rest of ecommerce. We gather this knowledge by event storming with the client, enabling us to reference their problems, domain language, and business processes.
As we write code, this knowledge comes into play. Our team ensures that code is written to be self-documenting by utilizing domain language. This ensures our teams can work collaboratively with our clients, as code that uses their domain language is much easier to read and interpret. Essentially, we are modelling our code around the business — rather than molding the business around the technology — ensuring that our solution is a viable one that provides business value.
Behaviour-Driven Development
This is the complementary flipside to being domain-driven. Being behaviour-driven means considering the development of our products from the perspective of the user. The code can only be considered successful if it allows the user to accomplish their goals and gain value. Understanding users and establishing metrics based on their desires helps us be sure our products are actually desired by and provide value to the end users.
It’s also a helpful sense check for the business. If you are doing a good job at both, being domain-driven and behaviour-driven should coincide very strongly. However, if each side is pulling in distinct directions, it is often the sign of a business or product that misunderstands the problem that is being solved.
Serverless Architecture
From project to project, we shift between languages and vendors, but we believe the right solution will more often than not utilize a serverless architecture. These solutions handle many aspects of dev ops right in the service, so our development team doesn’t have to handle the redundant work involved in setting up and maintaining a project — and clients don’t have to pay for it. Companies come to Invoke to find strong solutions to unique business problems, not to reinvent the wheel. When serverless solutions handle the basics, it means our team has more time to tackle domain-specific challenges and implement new functionality.
Products built with a serverless architecture can also reduce operational costs early on, saving money as you launch your product, gain real market learnings, and begin your growth before you reach scale and look at custom solutions. When you use a serverless architecture early on, you only pay for the resources that are consumed when your product is developed and actively used, not paying massive upfront costs or for resources that sit on the shelf waiting to be called on. This puts every product in a position to scale fast with reduced investment while you’re still generating learnings.
Going serverless also enables us to separate problems into domains and solve them in isolation. A full product is the combination of these isolated solutions, seamlessly integrated with each other. By isolating problems and setting them up to talk to each other, we can continually improve each solution without needing to re-write the entire product every time we make an upgrade. As long as the endpoints are still there, it works. We can also integrate these services into existing business processes to continuously grow, evolve, and replace processes that help us stay ahead of the competition.
Building solutions with technologies that save time, money, and are inherently set-up to evolve and adapt, makes launching innovative solutions with our established clients significantly easier. A feasible solution that can be built quickly is one that is ready to make an impact for the business today.
Agile Development
Developing with agility is how we put these philosophies into practice and execute on product builds. While many companies have their own interpretation of how capital-A Agile needs to be structured, we believe that the most important part of being agile is not the adherence to a specific “Agile” process, but rather working with agility and in support of the Agile Manifesto. We work to benefit the customer, do it as fast as is responsibly possible, collaborate heavily across teams, and maintain flexibility throughout.
On a practical level, “Agile” is often simplified to “delivering bits of code every week.” That’s not really the point. We strive to deliver business value every week by breaking down our solutions into the smallest components that can have an impact with the customer. That component needs to be something we can deliver within a couple of weeks and something that has value we can measure and learn from.
The “customer” often refers to the end users of products. In the case of agency work, our “customer” is not only the end user, but the businesses we work with that directly serve those users. By speaking the language of the businesses we work with, we help put them in a position where they can meet their customer and user’s needs.
Agile delivery is how we are able to start, iterate, and improve on our work in real time. In collaboration with each other and our clients, we measure our impact and make sure the next sprint is getting every organization closer to hitting their goals.
