from #56 (review):

My gut reaction was: could we add this to our HMPPSSoftwareSystem interface, so it becomes an attribute of our object rather than a functional wrapper? Obviously that doesn't work in this case because we want to add API doc URLs to containers as well as systems, so is it highlighting the need for a container abstraction?

This does make me wonder:

1. Should we be expanding our abstraction layer to include containers, and/or
2. Is this a useful abstraction to push upstream?

It feels like we're unlikely to be the only users of this building additional tooling for this, and it'd be amazing if what we build here could end up helping other Structurizr/C4 developers.

Anyway, they're more grand thoughts than a review! This is spot-on while we consider the wider architecture, as it'll make identifying and refactoring API URLs much easier if/when we need to.

// in Delius.kt
      OASys.system.uses(system, "assessment info, risk measures are copied into", "NDH")
      NOMIS.system.uses(system, "offender data is coped into", "NDH")

I'm still a little uneasy about defining relationships this way round. It feels like the relationship should be defined alongside the initiator of the communication, so the class is more explicit about the outgoing connections of that system. To be fair, it makes no difference to the generated diagrams, but I think it makes it easier to build a mental model from the code.

Again, this looks fine for this PR. Maybe we could decide/record this as an ADR?! 🤯

Originally posted by @spikeheap in #50

We now have a few views with enableAutomaticLayout(...). The generated layouts are not very readable except for straightforward diagrams.

We could layout the diagrams ourselves. The Java library retains layout information from the workspace whenever possible. It breaks when:

• diagram keys are changed
• elements are renamed

Manual layouts also require

• a user with editor rights locking the workspace, positioning new elements on the views after each change

Should we try manual layouts?

I notice this is a test URL, where-as the other swagger docs are production.
Also it's not accessible unless on the MoJ VPN - maybe not an issue for a dev, but just an observation about the availability of the swagger docs.

Originally posted by @philroffe in #62

Todo:

• Go through all API docs and settle on the production URLs, where possible.
• Go with non-VPN URLs or mark the requirements for a VPN in the model

Everyone has different editors

Let's enforce a consistent style, so we don't auto-format over each other

It sounded like there are more arguments towards merging the prison and probation workspaces.

Pros: single model, some of our apps are cross-cutting anyway
Cons: landscape diagrams will be harder to generate or will be very busy

Please vote with 👍 if you're in favour of merging, 👎 if in favour of keeping stuff as-is. 🙇‍♂️

I'll close this issue on Wednesday, 22 July 2020.

We need to merge the workspaces, following a vote in #35.

Do we have any of the current workspaces linked widely?

I'm wondering if we should reuse one of them as the merged workspace, or should we create a new one (and delete the rest)?

📝 CI secrets are currently held in https://github.com/ministryofjustice/hmpps-architecture-as-code/settings/secrets

In the last development session, one of the feedback was about making it easier to discover things.

I was thinking that maybe removing the system context diagrams and introducing topical landscape diagrams would help with that discovery process.

For example, instead of having MoJ SignOn context, HMPPS Auth context, we could have an "Authentication landscape" which could detail these lifecycle intentions [edit: in the original PR, we discussed how to expose intent that "MoJ SignOn" is essentially deprecated].

Originally posted by @sldblog in #45 (comment)

#21 added script/generate_images.sh which uses the Structurizr CLI and PlantUML to generate images of all diagrams defined in the workspaces.

On 16 July 2020 (Thursday) we discussed that it would be useful to auto-publish these images.

Maybe a GitHub pages branch/repo with Git LFS?

The workspaces are already public, due to our open-source license:

• Probation: https://structurizr.com/share/54669
• Prison: https://structurizr.com/share/55246

What do we need to make this repository public? A crown-copyright MIT license?

Hi there
The default branch protection setting called codeowners require review is not enabled for this repository
This option affects a pull request, i.e a PR will need to be reviewed and approved by a CODEOWNER before it can be merged.
See repository settings/Branches/Branch protection rules
Either add a new Branch protection rule or edit the existing branch protection rule and select the Require review from Code Owners option
Create a .github/CODEOWNERS file
Add a or multiple entries of @ministryofjustice/team_name to the CODEOWNERS file
The team_name shall be a team from within the MoJ teams: https://github.com/orgs/ministryofjustice/teams
See GH Codeowners documentation: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
See the repository standards: https://github.com/ministryofjustice/github-repository-standards
See the report: https://operations-engineering-reports.cloud-platform.service.justice.gov.uk/github_repositories
Please contact Operations Engineering on Slack #ask-operations-engineering, if you need any assistance

It's used for defining systems:

And it's used for defining a grouping for related teams:

I've just realised we might have made HMPPSSoftwareSystem overly specific, as CourtUsers [...]

Note In the example, InterventionTeams

[...] wants to conform to the same interface but isn't a software system. That's not a criticism of this PR, and shouldn't block merge, but we may want to rename the interface or create a more appropriate one – I'm guessing that would have model entities and relationships, but not views?

Originally posted by @spikeheap in #50

Hi there

The user bjpirt had Direct Member access to this repository and access via a team.

Access is now only via a team.

You may have less access it is dependant upon the teams access to the repo.

If you have any questions, please post in #ask-operations-engineering on Slack.

This issue can be closed.