## Overview

    component "Delivery Infrastructure" as di
    component "API Gateway" as api 
    component "Developer Portal" as dp 
    component "GitHub" as gh
    di --- api
    dp --- gh
    di --- dp
    di --- gh
    api --- dp
    api -- gh

- These is some of the platform pieces we're working with
- We can't go the route of having all of these things talking to each other
- It'll be harder for teams to work independently
- harder to scale
- harder to replace
- We're not intentionally architecting that plaform.

## Architecture principles
- We understand that **everyone who writes code is an architect**. This is because everyone who writes code makes architecturally signficant decisions.
- We have to **guide teams in an incremental and experimental way**.
- Establish clear relationship between **business goal, architecture guidelines, and the code** that people write
- We clearly **define what constitutes "good"** and we measure it over time
- We **focus on architectural outcomes** not implementation. Not just technology and topologies but how effectively every team can work
- **City planning problem.** We don't need blueprints we need to define boundaries, connection points, and communication paths.
- We understand that **command and control is not an effiective approach** with autonomous teams.
- We don't want to apply inappropriate governance. How do we **build consensus** and maintain an **open, collaborative, and pragmatic** architectural posture?
- What architectural characteristics do we want to prioritize? How do we guide that incrementally and measure it over time?

## Big ball of mud

    component "Delivery Infrastructure" as di
    component "API Gateway" as api 
    component "Developer Portal" as dp 
    component "GitHub" as gh
    component "GitHub Enterprise" as ghe
    component "Continous ATO" as cato
    di --- api
    dp --- gh
    di --- dp
    di --- gh
    api --- dp
    api --- gh
    di --- cato
    di --- ghe
    dp --- ghe
    dp --- cato

- We moving towards a big ball of mud. For example we know we may need to add support for
- GitHub enterpise
- Continuous ATO

## Challenges to decoupling
- We **don't want to disrupt urgent work** with heavy handed process or guidelines
- We **don't have handle on our domain model**. The mental models everyone is using are focused on implementations and not VA developers and the jobs they're trying to do
- We don't understand the kinds of architectural migrations VA teams are doing or how our platform can solve their migration problems.

## What are we doing right now?
- Getting some people trained up on **DDD**
- Provider team
- Doing some **event storming** with the provider team to try to understand their urgent needs. We need to push more content to the portal.
- External provider onboarding is getting initiated from many places
- Our internal teams are not consistently working with the provider team
- DI should automate a lot of this process but it's not going to be ready for months
- Backstage
- We want to start building / testing an MVP. We could do that in tandem with helping the provider team
- Opportunity to try setting up backstage to have **decentralized contribution model**.
- Embed ourselves in the provider team
- Build a plugin for their users
- Help them take over the mainteance of that
- Long term many contexts will be represented in backstage and the backstage team can't be experts at all of those. So I think we're going to focus on facilitating by treating this as a platform team _for_ the platform team.

## What about the decoupling problem?

    package "Delivery Infrastructure" {
        component "Scaffolder" as di
    }
    component "Apigee" as apigee 
    component "Developer Portal" as dp 
    component "GitHub" as gh
    component "GitHub Enterprise" as ghe
    component "Continous ATO" as cato
    package "Platform Capabilities" {
        interface "???" as plat
        interface "Scaffolder API" as scaff
        component "Apigee Adapter?" as adapter
        interface "API Gateway Capabilities?" as gateway
        queue "Event queue?"
    }
    interface "Apigee API" as apigeeapi
    apigee --- apigeeapi
    apigeeapi --- adapter
    adapter --- gateway 
    di --- scaff 
    gh --- plat
    ghe --- plat
    cato --- plat
    dp --- gateway
    dp --- scaff

- Delivery infrastructure
- Right now you can use the CLI manually
- Intent is to build an API that can trigger this behavior
- **Does this API become part of the decoupling layer?**
- Apigee also has an API
- Do we expose the API directly in the layer or do we write an adapter?
- **If we write an adapter for Apigee, why wouldn't do that that for the scaffolder?**
- Do we want to be a **conformist** to Apigee or Do we want to make an **anti corruption layer**?
- Do we know enough about this domain to make that decision? What about the team over Apigee- they probably don't know DDD.
- How do we start splitting this up into subdomains?
- Right now this is all implementation focused
- Documentation publishing
- Documentation building process needs to know when docs are updated in GitHub
- Right now we're only considering Backstage TechDocs but future state may have something like a beta testing capabiliity that would also need to be notified when documentation was updated to publish specs to external api beta testers