Breaking News! Startup develops stronger architectural foundation by gathering requirements first!
Tags: devops, startup, architecture, requirements
Published: 2019-11-07 21:50:22

The start of any project is exciting, and `shirtctl` is no different. Last month Blair and I [announced](https://dev.to/shirtctl/all-your-shirt-are-belong-to-us-55ji) we’re working a brand new project to bring continuous delivery to tech tees.

We set out with a goal to help tech brands create and ship cool t-shirts reliably to their fans at any time. 👕👚

From our experience, we know just how easy it is to get carried away with building technology solutions before we even understand our requirements.


![Solutioning/Requirements Comic](https://i.imgur.com/Hix8VmG.png)

This article is a summary of the principles we developed throughout first #shirtday hack, and how they  informed certain architecture decisions. And since we’re building `shirtctl` in the open, expect to see more posts about how we implement these as our project develops. 

##Our Mission:
We make it super easy for companies to build their brand and connect with the community by harnessing the awesome power of t-shirts.  

**How:**  Our MVP: For `shirtctl` to work, we need to be able to join brands and fans together for the reliable transfer of merchandise. 

![Process Flow](https://i.imgur.com/dYQBw5I.png)

With our MVP defined, we had everything we need to consider what high level platform architecture decisions we would need to make to build a strong technology foundation. 

## Requirement Principles:
        * [Flexibility](#Flexibility)
        * [Relentless Focus](#Relentless-Focus)
        * [Security in Depth](#Secure)
        * [Frugal by Design](#Frugal-Architecture)
        * [Easy to Consume](#Easy-to-Consume)

<a name="Flexibility"></a>

### Flexibility
We are going to make mistakes. Our path, like any startup, is unclear. Recognising that we are only a small team, we have to live and breath the fail-fast approach to bring `shirtctl` to life as soon as possible.

If we need to change directions, we need to be able to do so quickly without having to rebuild from scratch.

![Fail Fast](https://miro.medium.com/max/1200/1*JZ9i7JzobVeZbhoOODuPyA.png)
<figcaption><a href="https://medium.com/@jocatorres/fail-fast-vs-learn-fast-f7912fdc12e4">Image Source</a></figcaption>


**Adopting Architectures:**
Hybrid Cloud Architecture provides:
1. Rapid deployment.
2. Horizontally scalable.
3. Heavily automated.
4. Standardisation.
5. Minimum commitment (some services are billed per 100ms).

Continuous Delivery Architecture (Continuous Integration with Continuous Delivery):
1. Short software deployment cycles releasing software with greater speed and frequency.
2. Incremental updates for patching and feature enhancement.
3. Software release governance.

<a name="Relentless-Focus"></a>

### Relentless Focus
We know our main goal is to connect tech brands and their fans, not to host and manage infrastructure. We don’t have time to do the Design, Build and Run of a new infrastructure and platform service. In addition, the management overhead of a single tenancy wouldn't be time or cost effective. We are trying to shift as much as possible to managed services so we can worry just about `shirtctl` and leave the rest to the to the infrastructure experts.

![Serverless](https://stxnext.com/media/filer_public_thumbnails/filer_public/64/0d/640d7abe-4899-4e28-8763-267737ef7737/serverless-architecture-comparisonpng__1920x1080_.png__680x383_q85_crop_subsampling-2_upscale.jpg)
<figcaption><a href="https://stxnext.com/blog/2017/12/06/serverless-computing-explained-comparing-features-and-pricing-saas-iaas-paas/">Image Source</a></figcaption>

**Adopting Architectures:**
Managed Cloud Architecture:
1. Responsibility abstraction (just worry about the code, 'Serverless').
2. Consumption based billing.
3. Pre-architected building blocks.

Serverless Architecture provides; outsourcing as much responsibility as possible so we can just worry about the code.

<a name="Secure"></a>

### Security in Depth
With cyberattacks on the rise, and increasing consumer awareness of the risks of personal information being exposed, we need a modern approach to security that is simple and effective. We want to keep `shirtctl` free of traditional approaches to security that are prone to failure and costly to design, build and manage.

![Secure](https://i.imgur.com/JETPq5E.png)
<figcaption><a href="https://www.actiac.org/system/files/ACT-IAC%20Zero%20Trust%20Project%20Report%2004182019.pdf">Image Source</a></figcaption>

**Adopting Architectures:**
Zero Trust Security Model:
1. An alternative security model to not trust anything remediating the rudimentary fault in traditional strategies to only protect from the outside.  In this architecture, every pillar is verified.
2. All communication paths need to be encrypted especially for micro-services.
3. Validation and authentication are performed between all services.
4. Low cost with minimal special tooling required.

<a name="Frugal-Architecture"></a>

### Frugal by Design
As a super interesting side-project, `shirtctl` has no funding to splurge on unnecessary expenses. Just like a 1990’s startup using the garage as an office, we’re using modern architectures for their opportunities to save big on cost and time. As a public cloud consumer, we’re capitalising on the opportunities that cloud presents to pay for only what we consume.

We don’t expect to ever have to invest big in infrastructure development projects to enable our data lake or deployment pipeline, and just like we see the biggest disruptors changing their markets, we’re hoping it works for tech tees too.

![Frugal Architecture](https://solutionsreview.com/data-integration/files/2018/10/oie_wFhUpS8vKVmY.jpg)
<figcaption><a href="https://solutionsreview.com/data-integration/consumption-based-pricing-why-2019-will-be-the-year-to-align-value-with-investment/">Image Source</a></figcaption>

**Adopting Architectures:**
Public Cloud Architectures:
1. Consumption based billing with some products such as serverless allowing you to only pay for the CPU/RAM cycles used to run the code not the OS and below.
2. Free tier pricing for certain services to help get you started allowing for experimentation with different technologies ensuring you pick the best one.
3. Startup credits to be used on any service allowing you to try services that have costs associated.

<a name="Easy-to-Consume"></a>

### Easy to Consume
With our small team and non-existant budget, we need `shirtctl` to be usable by as many people as possible. So we’re starting out with a web app at [https://shirtctl.com](https://shirtctl.com). We think you’ll like it when ready. A lot.

![Multiplatform](https://miro.medium.com/max/600/0*QCqRjzCc_QPux8C7.png)
<figcaption><a href="https://blog.kotlin-academy.com/lessons-from-my-first-multiplatform-kotlin-project-d4e311f15874?gi=af3e85f95689">Image Source</a></figcaption>

**Adopting Architectures:**
Web App Architecture:
1. Availability to be accessed over the internet.
2. Compatibility with many different platforms and devices.
3. Very low time to get your product into the hands of your potential consumers.