Merge pull request #111 from innoq/programming-wolf-patch-1

Fix several language mistakes

faq.md

@@ -72,47 +72,47 @@ the SCSs containing the logic and the mobile client or single page app
 containing the UI. That way a change cannot be confined to an SCS, but
 would affect the SCS as well as the mobile clients and the single page
 app. This problem can be mitigated by modularizing the mobile client or the
-SPA so that changes to the UI are simplified. Even then the mobile
-client or SPA remains a deployment unit by itself, i.e. in addition to the SCS
+SPA so that changes to the UI are simplified. Even then, the mobile client or SPA
+remain deployment units on their own, i.e. in addition to the SCS
 also the mobile client / SPA must be redeployed and deployment of the
 client / SPA must be coordinated with the deployment of the
 SCS. Essentially, this approach violates
 [no shared UI](/index.html#no-shared-ui).
 
-### Does the user interface of an SCS has to follow ROCA Principles?
+### Does the user interface of an SCS have to follow ROCA Principles?
 We believe [ROCA](http://roca-style.org) is a good approach for web
-front ends for SCS because that approach makes it easy to combine UIs
+front ends for SCSs because that approach makes it easy to combine UIs
 from several SCSs to one. You could also have one SPA per SCS, but
 this means switching from one SCS/SPA to another one loads another
 application and you cannot easily share parts of the SPA/SCS in other
-SPA/SCS. That said, we don't rule out SPAs as a useful approach for some
+SPAs/SCSs. That said, we don't rule out SPAs as a useful approach for some
 of the SCSs. However, even though we suggest to follow ROCA Principles,
-it is not mandatory to follow them to have an SCS system.
+it is not mandatory to follow them to have an SCS.
 
 ### Can SCSs share a database?
 
 Multiple SCSs might use the same database – but they must not share any
 data. So they might have completely separate schemas in the same
 physical database. Sharing a schema is not allowed because that would mean
-schema can hardly be changed. The changes would need to be coordinated
+the schema can hardly be changed. The changes would need to be coordinated
 between all components that use the data and introduces a strong
 coupling that SCSs should avoid.
 
 Even using separate schemas in the same database causes some coupling,
 e.g. an update to the database software would influence all
-SCSs. However, all SCS can use the same backup and disaster recovery
+SCSs. However, all SCSs can use the same backup and disaster recovery
 and thereby save resources. Whether or not to connect all SCSs to the
 same database system or database cluster is one of the decisions that need
 to be made as part of the macro architecture.
 
-### Should a SCS be split by layer?
+### Should an SCS be split by layer?
 
-SCS makes no assumptions how a system is built internally and its deployables 
-(such as frontend and backend). 
+SCS makes no assumptions about how a system is built internally and
+about its deployables (such as frontend and backend). 
 This is fully up to each team's micro architecture decisions.
 
 However, it is recommended to minimize the number of deployables within
-a SCS to avoid network latency and complexity by managing internal APIs and
+an SCS to avoid network latency and complexity by managing internal APIs and
 remote communication safeguards.
 A good starting point is to have one stateless deployable containing UI and logic
 and a database for persistent data.