The Agnostic Flow - A Long-term Strategy for smaller tech orgs

Preamble - The common problem

A common problem I faced in the last years as CTO in the small-to-medium-sized business area is that?SMBs often try to align with larger companies or enterprises that are way out of their league. I can't blame fellow CTO colleagues since I was the same some years ago. The problem lies in the ever-changing tech industry and the challenge of modern development.

The outcome of this wrong alignment can end in different problematic scenarios, like the Legacy-Deadend, overly complex architecture, or an unwanted vendor-lock-in. The list is more extensive; I experienced only some possible bad outcomes. But the real challenge is to avoid these problematic outcomes and stay in control of your company.?

The two extremes to avoid

Some tempting technologies, like?serverless, go even one step further than managed orchestrators and let you focus on your development. There's a catch; these technologies are often vendor-specific, and you quickly run into the trap of being locked-in in without a chance to get out that easy.

The other extreme is to build everything yourself, like a?Kubernetes (k8s) cluster or, for the old-schoolers, VMs with LAMP stacks or Microsoft IIS?Servers. In this scenario, you take the other way round and take over the entire responsibility,?leading to overly complex, often insecure self-managed solutions in which IT-Ops becomes an unwanted focus in your developer org.

Stay on top of your game; Be the captain of your strategy; Stay in control.

How can we define a strategy which will be controllable and sustainable over time? What would be the criteria for such a?strategy?for a software development company?

I want to introduce you to our strategy with several platforms in B2B and B2C areas. It is one reliable approach, but only some viable one. For this approach to understand, we need to?think about Strategy, Tactics, and Operations?and?define Requirements and Qualities.

The following approach is built upon two major ideas:

• Being agnostic
• Staying in a flow

With simple words, they define the overarching strategy or the tech vision.?Being agnostic?stands for long-term thinking; since we will use cloud-native technologies and plan for years to come, we want to ensure our investment is secure. Staying biased or vendor-locked-in is a bad idea since I cannot see any advantages which outweigh the long-term stability aspect. Especially not since great PaaS solutions can keep up with the idea of rapid development of serverless.

Staying in a flow?portrays the requirement to create value constantly; otherwise, the company will fail in one way or another.

The 3-layer definition of the Agnostic Flow

The following definition includes strategies that could be seen as tactical implementations. This approach should display a long-term emphasis on points like decoupled architecture while putting this aspect as a strategic requirement.

1: Strategic Requirements & Qualities:

• Maintain?constant development flow; avoid stagnation and other dangerous circumstances.
• Minimum of 3, better five?years of long-term planning.
• Long-Term maintainability & timelessness;?to avoid Legacy Dead Ends and keep the software serving the business needs.
• Maturity & Self-Responsibility; single units of the org must work independently to avoid generating silos or complex dependencies.
• Maintain provider agnosticism (stay able to switch between different vendors).
• Focus on development only, not taking responsibility for running infrastructure.
• Decoupled Architecture; to keep a door open for changing parts of the apps even after years. (Number one reason for Legacy-Deadend). In short, avoid a monolith and every modular version when planning long-term. Monolith is purely short-term thinking.?You won't change later.

2: Tactical Instruments & Measurements:

• Culture-First:?Put the people before technology and systems. This measurement adds to the goal of maturity and competency. Implement a blameless work environment and put forward-looking communication first.?
• Platform-as-a-Service (PaaS); to meet the requirement to focus on development and reduce possible developer frustration or burn-out due to the responsibility of IT Ops.
• Cloud-Native; to meet the idea of decoupled architecture in the most native way and stay agnostic. Focus on the agnostic parts of cloud-native, like containers and managed orchestrators.
• Containerization; Dev environment matches the production environment and adds to constant flow. Reduces complexity and provides an everyday basis for developers to manage IT-Ops needs quickly.
• DevOps; implement End-to-End responsibility to meet the quality of Maturity & responsibility, as well as a constant flow and dev focus.
• Continuous Delivery; to meet the requirement of a constant flow and foster your teams to optimize their daily work to complete this tactical goal and the long-term requirement.
• Streamlined Tech Stack; use technologies and programming languages that are expected, easy to onboard, and easy to find developers. This adds to long-term planning and flow.
• Living Documentation;??This is foundational for long-term planning, maintainability, and timelessness. Every developer or stakeholder should have no problems finding the specific spot in your code base when issues are reported.

3: Operational Best-Practises & Implementations

• Foster?responsibility, maturity & competency?as a foundation of your daily work. Avoid artificial "role-playing systems"; this isn't naturally adoptable by newly onboarded devs. This includes removing Code-Reviews as a mandatory step in your flow and motivating you to communicate the "human" way.
• Define?requirements, qualities & tickets?in an?easy-to-understand?format for developers. A Ticket must be standalone and understandable, not require the developer to ask questions during the development cycle, and enables the devs themselves to review a result of a ticket.
• Avoid git branching and pull requests: foster communication and a faster flow by working together in the same branch.?
• Small teams: Keep your teams between 3-5 developers and provide clear goals and responsibilities for the Team. Small groups align with the DevOps requirement and maturity.
• A single Programming Language; avoid implementing multiple challenges when you don't have a need that would make a significant difference in business terms. In most cases, a single language like?Typescript?fits the real needs of a web development business; without the need to maintain multiple ecosystems. Typescript is an excellent choice if you want to stay on a single language since it covers all common needs.
• Apply Principles & Best Practices; Foster standard methods of working, which can be commonly found in other companies, like basic?programming & design principles. Those add to the idea of being agnostic. Hiring will become more manageable, and spreading knowledge as well, since it's common sense.?
• Integrate requirements, testing, and documentation: Consider these three elements intertwined with your development process. To minimize overhead and enhance productivity, foster an environment where developers have clear documentation and testing procedures integrated within their development environment. This approach allows them to remain within their IDE, eliminating the need to shift between platforms and tools.?By creating a streamlined workflow where initial requirements evolve into later documentation and testing, such as test-driven-development, representing the practical implementation of these requirements, you can ensure a more efficient and maintainable process.?This aspect aligns with the tactical quality of "living documentation."

For which type of company does this approach fit?

This implementation strategy is based on my experience, experimentation, and learning throughout the last few years. It's not a recommendation but a report of experience.

We have applied it successfully to our own projects and teams, as well as with partners and fellow CTOs.

It's not for everybody and focuses on smaller companies with manageable teams. For larger organizations, it might focus too less on controllability, especially regarding certifications and audits.

For small companies, on the other hand, it can and will be a performing way of work with a focus on getting things done and shipping value; while relying on the competency of your developers and fostering learning and enhancement over command & control.

This has become a very effective strategy for small traditional businesses or startups.