Architecture journey — Stage 1, Building alignment, decision guardrails and some tools

This month I completed five years in PageUp. Time flew. It reminded me it has now been about eight months since I took up the latest responsibility as Head of Architecture.

In this role, my primary responsibility is to ensure that it is easier for our product development teams to build innovative products that deliver outcomes to our customers and business on a scalable and secure platform that facilitates improving the efficiency of product development continuously.

While this problem has been on my radar for a while, the last eight months have provided the mandate to expedite, create some clarity and set things in motion towards delivering the above outcome.

The first stage of it is to ensure there is an alignment on the direction, having mental models and tools that people can use as decision guardrails. We have had the first iteration of it in the last few months. They are making sense to a large extent so that now I am slowly gearing up from reactive to proactive mode.

I wanted to share some of these models, decision guardrails and tools in this post. While we built it primarily to address the need at PageUp, I want to know how relevant it is beyond us.

Let’s start with the Capability Model; capabilities are the backbone of our Platform Architecture and every other thing that follows.

Capability Model

Capability Model is a layered view of Product Capabilities. There are two fundamental purposes it serves.

1. It presents the product capabilities in a layered model that makes the need for reuse evident for our development teams.
2. It provides a ubiquitous language to describe the depth of a problem and complexity that the business and product managers find hard to understand.

We work with four layers of the Capability Model in PageUp.

• Foundational — Anything required for healthy product development, continuous deployment, source control management etc. fall in this category.
• Platform — At this level, the capabilities are SaaS aware and facilitate business process automation. Examples are Authentication Service, Relation Data Storage Management, Business Event Bus, Workflow, Data Warehouse, etc.
• Business Domain — This is where business concepts specific to PageUp’s business come into play. Typical concepts that we at PageUp require, for example, are Candidate, Requisition, Job Offer, etc. These concepts live as autonomous microservice business domains.
• Experience — An interaction layer where customers, partners, interact with our system either using a user interface (desktop/mobile/app) or some of the interaction APIs.

Having this model and managing this repository of capabilities is critical for our microservices journey. It helps us classify a system based on its potential for use and build the right boundaries to facilitate reuse.

Architecture Framework

Bringing Microservices, AWS/Cloud and autonomous teams together is a mighty thing to do. At the same, this combination can quickly complicate things when the boundaries of the Product and Platform are unknown. Autonomy without alignment could soon lead to a significant increase in the cost of service or worse, several implementations of the same service.

While teams have the right intention to build the best systems, it is only natural that they optimise for their available context and information. An Architecture Framework should reduce the cognitive overload to understand the boundaries of the PageUp Platform and provide overall direction of the architecture.

• Platform interfaces — Platform interfaces defines a single entry gateway each for API, Single Page and Web Applications making all entry points in the platform well-known small set. It makes it easy to apply sophistication such as throttling, rate-limiting or security improvements consistently and confidently. Our Authentication service that is tenant aware supporting oAuth2.0 and OpenId connect underpins these gateways.
• Platform storage management — Enable management of data in a tenant aware, secure and compliant model that will facilitate decentralised yet build once deploy anywhere approach. It intents to support Relation, Key-value NoSql and Document data.
• Platform Enablers — Platform level capabilities that are cross-cutting concerns needed for pretty much every SaaS product that deals with business process automation. Workflows, flexible data structures support, event bus, logging and telemetry etc. fall into this bucket.

They help the product development teams to understand where their microservice fits into the framework and facilitate them to build in line with the architectural direction.

Sensible Defaults

Sensible Default is a concept familiarised by Patrik Horne further explained by Steve Benett in which he calls out the side effects of “the best tool for the job” approach,

The unintended consequence of always choosing the “best tool for the job” is a software inventory which spans multiple languages, frameworks, build systems and deployment tooling.

It is precisely for this reason that we wanted a well-documented model to facilitate informed decision making of technologies, tools, languages and frameworks.

In our set up, the Architecture Framework provides the boundaries of the Platform and platform capabilities that applications must use. Sensible Defaults, on the other hand, complements day to day choices within the application.

Platform Toolkit

It acts as a catalyst to help adopt foundational capabilities, platform capabilities, sensible defaults through automation and developer tools.

It consists of,

• Domain Vending Machine — An automated machine to vend a new business domain on demand, including the AWS infrastructures and resources required to deploy an application. It is an abstraction built on top of AWS Landing Zone. By vending security guard rails, platform capabilities and sensible defaults during the domain provisioning stage, it makes adoption a breeze.
• Platform Visualisation — It is an internal web application. It maintains a repository of capabilities in PageUp along with their implementations, health, and their relationship to each other. It makes it easy for developers new to the Platform to lookup and find things. Given capabilities and their health information is available in this repository, it makes it possible to visualise the health and reuse in the Platform
• Developer tools — Set of developer CLI’s that help adoption of foundational capabilities. Such as “PageUp-AWS” — enables having elevated permissions temporarily to specific domain AWS accounts and “PageUp-CD” — to manage continuous deployment in a multi-account and region AWS set up.

Summary

The Capability Model presents a layered architecture to help developers visualise the depth of the solutions.

The Architecture Framework builds on top of it to create a view of the boundaries of the Platform. It helps development teams visualise things that they can leverage to iterate faster by fitting into the framework.

Sensible Default further simplifies and provides a structured decision-making process for tech choices teams make.

And finally, the Platform Toolkit enables adoption and alignment through automation, visualisation and developer tools.

I hope they all make sense. As I mentioned previously, this post intends to learn how relevant it is for people outside the PageUp.

What you think we are doing right and not right, etc.?

How are you dealing with such problems in your business?

I am eager to hear your thoughts.