When someone visits a page anchor (e.g. https://scs-architecture.org/#autonomous), the navbar obstructs the card title.

In order to make the site accessible for everyone the slide images should have descriptive alt texts.

After making some changes I wanted to look at the changes at http://0.0.0.0:4000/. So, I ran docker run -v "$PWD":/usr/src/app -p "4000:4000" starefossen/github-pages. Running this command caused the following error:

% docker run -v "$PWD":/usr/src/app -p "4000:4000" starefossen/github-pages
Unable to find image 'starefossen/github-pages:latest' locally
latest: Pulling from starefossen/github-pages
911c6d0c7995: Pull complete 
66c75bb6a8fc: Pull complete 
a1d8100f3d6a: Pull complete 
640ab4473371: Pull complete 
0965307349c7: Pull complete 
5a58628acff1: Pull complete 
615f9e5a42c3: Pull complete 
Digest: sha256:5097d63b50e7a894b694761ded6ace912aa901b98f283824801db649ddb37684
Status: Downloaded newer image for starefossen/github-pages:latest
/usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler/lockfile_parser.rb:108:in `warn_for_outdated_bundler_version': You must use Bundler 2 or greater with this lockfile. (Bundler::LockfileError)
	from /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler/lockfile_parser.rb:95:in `initialize'
	from /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler/definition.rb:84:in `new'
	from /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler/definition.rb:84:in `initialize'
	from /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler/dsl.rb:218:in `new'
	from /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler/dsl.rb:218:in `to_definition'
	from /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler/dsl.rb:13:in `evaluate'
	from /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler/definition.rb:35:in `build'
	from /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler.rb:135:in `definition'
	from /usr/local/lib/ruby/gems/2.5.0/gems/bundler-1.16.3/lib/bundler.rb:101:in `setup'
	from /usr/local/bundle/gems/jekyll-3.8.5/lib/jekyll/plugin_manager.rb:50:in `require_from_bundler'
	from /usr/local/bundle/gems/jekyll-3.8.5/exe/jekyll:11:in `<top (required)>'
	from /usr/local/bundle/bin/jekyll:23:in `load'
	from /usr/local/bundle/bin/jekyll:23:in `<main>'

After I have removed the Gemfile.lock, I am able to run docker run -v "$PWD":/usr/src/app -p "4000:4000" starefossen/github-pages successfully.

If we have slides, we may run into issues:

• how do you keep them consistent on the website? e.g., slides say we have to use ROCA, which is not the case on the website
• someone downloads the slides and uses them instead of the website. The website is updated, but the slides are not.
• how do you handle versioning of the slides?
• is it accessible for e.g. blind persons?
• the slide deck is available in keynote, pptx, why not in a standardized format like ISO 26300
• the slide deck is available in English, German, why not in other languages? (websites can be translated via browser plug-ins)

Suggestion for acceptance criteria:

• There exists a What? website that contains:
  • definition of SCS
  • characteristics of SCS
  • all information with images taken from the slides
• The What? page replaces the current index/home page.
• The download links and embedded slide deck have been removed

This issue eases solving #48.

Eine Sache, die ich noch nicht ganz verstehe:

All data, the logic to process that data and all code to render the web interface is contained in the SCS.

Was genau bedeutet das? Das die Datenbank Teil des SCS ist? Oder das keine Datenbanken zwischen SCSen geteilt werden?

SCSs might have layers - but SCS make no assumptions about the internal design of an SCS. This is somewhat confusing in the presentation - in particular concerning the internal layers and where specific interfaces (REST, UI etc) are located in the layers. We should explicitly say that we make no assumptions about the internal design of an SCS.

The page SCS vs. Microservices says "Of course it is possible to split an SCS even further so it consists of microservices". Because it's often said that microservices have their own database in order to be decoupled from other services (see e.g. Pattern: Microservices Architecture) I'd try to avoid the usage of the term "microservices" and rather prefer "subsystems" or "processes". This is just to start the discussion about terminology, which was also already questioned on the discussions page.

To shorten and obtain a more concise definition of the notion SCS, I suggest the following change:

Current Definition:

The Self-contained System (SCS) approach is an architecture that focuses on a separation of the functionality into many independent systems, making the complete logical system a collaboration of many smaller software systems.

New suggested version:

Self-contained System (SCS)
An architectural approach to create a set of autonomous, smaller subsystems that collaborate to cover the overall system's functionality.

The usage of the word independent of the current definition seems wrong to me because the list of characteristics states autonomy and not independence, cf. https://scs-architecture.org/#autonomous.

To avoid tight coupling an SCS should share no code with other SCSs. It might be fine to create a pull-> request for an SCS, but certainly no source code should be shared.

I think the definition should focus on business-orientated code and not technical things like oAuth Clients or DB client libraries, which might also be developed internally.

To me, when one builds self-contained systems, a data mesh is the continuation of a lot of those ideas of decentralization, but applied to analytical data. Would it make sense to add a link to https://www.datamesh-architecture.com/ to guide the curious reader? If so, where would it make the most sense?

In @rstrangh's presentation about the topic he explicitly talks about ROCA:

Should that be the case on the website as well?