Starting up a Start-up
We are all used to seeing Enterprise Architecture as a big up-front exercise to fully define and direct the strategic imperative of an organisation. We are used to seeing Solutions Architecture as being deep in a project defining point solutions through various frameworks models & governance. Without the luxury of time and money that all goes out of the window. Start-ups (and in truth, not just start-ups) need to take a different approach that combines the above, and, as always, it’s all about trade-offs.
Active Orbit is a start-up, an idea born from some budding cycling enthusiasts and a desire to make the world a better place. There is the CEO (Chief Enthusiasm Officer), the COO (Chief Optimism Officer) and the CTO (Chief Technology Officer), and that is it. There was close to zero technology, an email system, and some PowerPoint slides and of course, Microsoft teams.
Getting off the Ground
We mobilised a small team of 4 developers spread globally, and me, the Architect. Oh, and we had 3 days before Sprint 0, and about 8 weeks to the first release, of what, we had no idea.
So, we spun up Confluence, set up a Product space, an Architecture space, and an Engineering space.
Starting in the Architecture space, we defined some key high-level principles to get us moving, the build would be cloud native, we would use white label products where possible, and we made some product decisions straight off the bat for Payments, CRM and build out.
We decided on blue/green deployment, automation where possible and Dev, Staging & Prod instances. This was a collaboration of the developers, CTO, and architecture in a 2 hour meeting to sort this stuff out – Done. We setup Slack for comms and landed on AWS (mainly) as the cloud base. (later we needed to incorporate some GCP elements).
We decided Sprint 0 would be the enabling sprint for setting up the DEVOPS pipeline and automation, and very quickly realised we needed a UI designer, who we onboarded within a few days and got going with the external marketing team. The senior developer who was also a ScrumMaster got Jira up and running and led the sprint planning doubling as a ScrumMaster and Lead engineer. We stayed on course with the Agile approach and did not deviate from stand-ups, retros, planning, refinement, but we kept the meetings collaborative and document as we go.
Sprint 0 – Architecture jobs
Contextualising the end-to-end design and playback to stakeholders, (I spun up Miro whiteboards for this), defining the central IP of the functionality that we would need to build and understanding the trade-offs between buy/build.
Put together a domain microservice based design, using engineering decoupling (DSM/PARNAS) techniques to isolate the domains creating a Service Orientated architecture model.
Finalised the selection for the major white label products we would use – chat, help-desk, CRM, inventory, payments, accounting etc.
Got ahead of Sprint 1 with the key logical data models, sequence diagrams, information flows and event management (Lucid chart the tool of choice!)
Supported the CTO and CEO drive out user stories for the Sprints.
Sprint 1 to 4
Now in a cadence with UI drafts, sequence diagrams, data models, user stories, the development team have enough to start build & test of the domains using a UI screen led approach. Building happy paths then adding edge cases later. Show and tells were planned and delivered with no issues and great acclaim from the stakeholders.
Architecture at pace becomes a race to get ahead of the dev team, trading off functionality into the Roadmap where possible whilst keeping the quality of the key deliverable high and the design secure.
We continued this approach with daily meetings, pivots, descoping and rescoping until we get to the end of Sprint 4 with a working deployable application that went to market and started to onboard users immediately.
A short maintenance sprint of a week was needed to tidy up and catch breath.
On to Release Two
We have much more structure in place now, the base infrastructure is there, and tooling and services are proven and working. We now move into introducing the mobile application, API’s, distributed channels, and additional functionality.
The team has grown to include a mobile development team, and we have more people in the company on the operations side to start supporting rollout/marketing.
Architecture continues to support prioritisation to produce the right things in the right order, at the right time, refining outstanding design questions and responding to new questions, solving issues we haven’t even thought of until we went live.
It’s a continuous process of refining requested functionality and adding components to balance realistic delivery expectations, whilst keeping one eye on business developments to stay ahead of the next demand from the market, and enthusiastic and optimistic leaders of the start-up.
It’s a balance, a trade off, and continues to ask of me to delve deep into a 25-year-old bag of tools and techniques that are right for the job at hand, whilst continuing to learn new things quickly and replace old thinking with new. Did you know NOSQL does not mean ‘No’ SQL?
This is full stack, just in time, architecture at pace.
And it is the future.