Architecting For Delivery at Horizon State
Delivery Architecture
Architecting a system is unsurprisingly hard. Most complex software projects are made up of multiple parts that move and change constantly. Some are slow movers — your main development language for example. Some are slower — think your relational database. Some other parts seem to move at a much faster pace — think about the new front-end frameworks that seem to sprout every other day, and that you always want to explore and use for a small PoC.
When zooming out the application architecture to look at software and tools from higher up, there are even more moving parts. Consider the various tools and frameworks you use for just about anything. Some are in the cloud, some are hosted internally — how many SaaS systems does your company use? How many issue management systems can you name? Seems like there’s a new one every month.
Now, multiply some of the decisions and their impact across multiple channels, products, teams and geographic locations. The image above displays some of the various product lines planned inside a single product suite at Horizon State. Every product line adds a level of complexity. Each has the potential to amplify good architectural decisions as well as bad ones.
When you zoom out even more — beyond software and tools — this is where you’ve got your people and your culture. Your goals and the processes to achieve them. Your beliefs. Your mission. Your fundamental principles and aspirations.
Yours, together with those of everybody else who’s involved in delivery form a habitat. At Horizon State we call this habitat our Delivery Architecture.
Focus and a Fish Eye Lens
Different delivery teams operate in different landscapes. At Horizon State we face — from day one — a medley of challenges that need to be encountered head-on.
If you know a challenge is coming — build it into your delivery architecture from the get-go.
For us — the challenges are mainly around adding complexity and uncertainty to the work that needs to be done.
Multiple Streams, Customers and Products
Your roadmap is always inside the customer’s head. Products do not live in isolation and it doesn’t matter that you can deliever a good system if it is not the right one.
For Horizon State this means we need to work on multiple product streams and lines from day one. This is a challenge to any tech company, let alone a startup growing rapidly in terms of people, locations, customers and footprint.
Multiple Technology stacks, Distributed Teams and channels
Good developers are hard to find. We know that. So are good testers, analysts, account managers, product managers, architects and support specialists. The problem is amplified when you limit yourself to a single geographic location (with a few possible exceptions — where those people will have many other options)
How do you solve for that? The answer is to architect the delivery to account for that. At Horizon State we decided that geography alone should not prevent us from hiring the right person for the job. All well and good — but you can’t just make this decision and leave it at that. This is how you leave a void. You need to qualify what traits you are looking for.
You need to figure out the character qualities of the people that will be able to work with you, towards the goals, even if they are all alone at home working remotely into the night.
These characters circle back to the way we wanted to build the company. We have a strong underlying desire to operate Horizon State like a family, where the ties between people are stronger than just being at the same office or on the same Slack channel for a few hours a day.
To do that, we need to recruit the right people. Those who think that work is more than a job. Individuals who care about the mission of Horizon State and about the people they work with. People who can get stuff done quickly and efficiently without needing to be right 100% of the time. People who know that tech — like life — has a lot of give and take, negotiations, balancing acts and communication. We don’t only want to get things right, we want to create them right.
With a good delivery architecture, the way we get things done is just as important as the things you get done.
In our interviews — we try to account for that. We ask about past relations at work, about difficult situations. We ask candidates what they learned from different projects and assignments they have been through. We try to gauge whether people acknowledge mistakes and learn from them, whether we would like to work in the same office day-in-day-out with that person even though we’ll almost certainly not.
We also don’t care what technologies the person is experienced with.
Remember — good people are hard to find. A good developer is many times as productive and efficient as an average developer. The specific technology stack a developer used in the past — just as their physical location — should not be a hinderance. Our delivery architecure has to account for that too.
Secure, International and Astounding at Ground Zero
Some products are international from day one. Blockchain voting and community enablement is possibly one of the most obvious cases. This means that we introduce multilingual support at the outset. But internationalisation and localisation do not end there.
A community enablement solution delivers content, and needs to provide a safe, open and honest community experience. This means we need to be able to include different systems of beliefs, sensitivities, cultures and vocabulary.
Different locations speaking the same language may have different meaning for the same terms. Everyone in the company needs to have that in the back of their minds.
The overall security of the system and the privacy of the users are paramount to the way we envision our products being used. These can not be treated as aspects or layers. They have to be there at ground zero. The delivery architecture, in fact, must prevent the introduction of any component that does not align with this view.
We also believe that any interface the system exposes has to be, at the very least, beautiful and elegant. From a delivery architecture point of view, this means that we adopt a methodology of Interaction-First, that designers and testers are just as important as the developers.
Every interaction the user has with our products has to be perfect. Everything that interacts with our products is a user: A person. A third party. Even software using our API. This means that from day one, everyone in the company is part of the overall User Experience.
Rapids Delivery
All streams flow into the sea, yet the sea is never full.
To the place the streams come from, there they return again.
Rapids delivery is a mechanism by which the tools, processes, deliverables and expectations are split into small pieces. Each of those pieces is then delivered rapidly, as a mini-project inside the larger stream of work it belongs to. Rapids delivery comprises a set of agile waterfalls.
I also made this term up. But it’s a good term. So I am keeping it.
In the way we architected it here at Horizon State, every rapid is a project. Every project is very independent in the path it takes to get to the end goal — but it still has to meet the expectations of the general direction we are going towards: transparency, honesty, professionalism.
There are a few architectural decisions we made to support rapid delivery: A micro services architecture, CQRS, multiple data sources, API-First, and a multi-disciplinary technology stack as discussed before. This is why we don’t mind if a developer uses Java, C#, Golang, Python etc. Because it doesn’t matter outside of the specific rapid they’re on.
Setting Up For Success
A good delivery architecture sets everyone up for success — products, people company and customers. Each of those needs the others. And they have to fit together in a framework that supports them.
Senior leadership has three jobs. These are the most important pillars of management, and they are non-negotiable:
- Define the path forward
- Remove obstacles from people’s way
- Empower people to do their best
That’s it.
Culture Guidelines
Company culture shouldn’t happen. It also shouldn’t be dictated. While it needs to grow organically, it also needs to be tended to.
The three jobs of senior leadership apply here as well. When the path towards the culture is defined, obstacles are removed, and people are empowered, the company will grow the culture that fits it. For us — we would like to see it as a family, and this is the path we define for moving forward. Families are not always perfect, but that’s ok.
A Delivery Architecture needs to take the company’s culture into account. The culture resonates in everything.
- How we deal with deadlines met and missed
- How we deal with errors and mistakes
- How we celebrate success and wins
- How we create our own family traditions
- How we overcome jealousy and bad feelings
- How we welcome someone new, how we farewell people who leave
The points above and many more must be reflected in the Delivery Architecture because they all affect it and are affected by it in turn. They will arise, and you will need a plan to deal with them.
Delivery of great products and services doesn’t just happen. It needs to be thought out, planned, measured and adjusted.
Technical capabilities and good technology will only get you so far. Delivery Architecture addresses the people, customers, relationships and focus points of the business as a whole. It is the backbone of how we do what we do.
