システム構築方法に関するこれまでの前提が今日，見直しを迫られている。そのひとつが，大規模システムは単一環境でなければならない，というものだ。プロジェクトのスコープとシステム構築は１対１にマッピングされることが多く，結果として１プロジェクト=1システムとなっている - Stefan Tilkov氏は，システムとアプリケーション，マイクロサービスの特徴を検討するプレゼンテーションで，このような説明をしている。
innoQの共同創立者でプリンシパルコンサルタントのTilkov氏は，大規模システムを小さなアプリケーションに分解するという考え方は，すでに広く普及したものだと見ている。その主な理由として，氏が上げるのがアイソレーションだ。大規模システムの個々のパーツ間にバウンダリを導入することで，独立すべきパーツ同士が結合して通信することは難しくなる。それ以外のメリットとして氏が指摘するのは，個々のパーツをそのロードに従って独立的にスケールアップ可能になることから，その判断をローカルに下すことができる点だ。これによって各チームは，バウンダリ内に留まる限り，自分たち自身で意思決定を行うことができるようになる。
小規模なパーツによる論理システムの構築方法を検討したTilkov氏は，次の３つの方式を比較する。
- マイクロサービスはビジネス機能を中心に構築される。小規模で，それぞれ独自のプロセスで動作し，軽量な通信メカニズムを使用する。
- アプリケーション(Apps)はそれより多少大きいが，それでも小さく分離された実行プロセスである。マイクロサービスと同じ特徴をいくつか備え，シェア・ナッシングモデルを採用する。
- 自己完結型システム(SCS/Seff-Contained System)は，氏とその同僚たちが，一般的なシステムという呼称を避けて，より具体的なルールセットの名称として思い付いた名称だ。SCSは非常に巨大な自立型アプリケーションである。データとロジックを内包する，ひとつのチームによって保有される，同期型リモートコールを使用せず，必要であればサーバAPIを使用する，といった特徴を持つ
これら３つのスタイルの数値や特性を比較したTilkov氏は，この中のどれが最適な選択なのかという点について，いまだコンセンサスが得られていない点を強調している。そうではなく，氏が意図するのは，それぞれの範囲と可能なオプションを示すことなのだ。
| SCS | Apps | マイクロサービス | |
|---|---|---|---|
| サイズ(Kステップ) | 1-50 | 0.5 - 10 | 0.1 - ? |
| 状態 | 自己完結型 | 外部 | 自己完結型 |
| 論理システムあたりの数 | 5 - 25 | >50 | >100 |
| ユニット間のコミュニケーション | なし(可能であれば) | ? | あり |
| ユーザーインターフェイス、UI | 含まれる | 含まれる | 外部（？） |
| UI統合 | 可能（Webベース） | ? | ? |
氏にとって最も興味深いパラメータは，大規模システムの最初の分解レベルを示す数値としての，論理システムを構築するパーツ数だ。氏が支持するのは自己完結型システムである。小規模なサービスは，それ自体はシンプルではあっても，多数集まることによって，他のレイヤは非常に複雑なものになる。ただし氏は，特定のモデルを推奨しようとしているのではなく，さまざまなレベルでの議論が必要であると強調している。