Manifesto suggestion: slight rewording & typo fixes

landing/docs/manifest/manifesto.adoc

@@ -1,15 +1,22 @@
-= Continuous Architecture manifesto
+= Continuous Architecture Manifesto
 :page-show-toc: false
 
-There are famous manifesto out there such as the https://agilemanifesto.org[Agile Manifesto], the reactive manifesto[Reactive one] ... Our Continuous Architecture manifesto does not even try to compete. Our intend is list our believes around our architecture operating model. To move from a former waterfall approach (where architecture was done mainly before features were implemented) to a continuous runway, as architects we need to adopt a new mindset embodied in the seven believes below:
+This Continuous Architecture manifesto aims to provide a clear set of beliefs and principles for our architecture operating model. It is not an attempt to compete with other famous existing manifestos (e.g. https://agilemanifesto.org[Agile Manifesto], https://www.reactivemanifesto.org[Reactive Manifesto]). It conveys a shift from a traditional waterfall approach with big designs up front to a continuous runway mindset. 
 
-1. We architect long term products, not just projects solutions. You have to consider your architecture activities as a runway following the life of your product (as it goes through different stages: from cradle to grave). You'll have to take decisions, design a new features, reconsider / rework what you have done given the new context you're in. The  design need to be robust to futur change . Doing so in a project approach is way more difficult not even considering the fact you'll be switching from one project to the other (each switch resulting in time loss at best case, lapse of memory more certainly) 
-2. We architect our products with a holistic view. Behind this there are two different but complementary ideas. First, we look at the architecture from a fullstack perspective considering all the different layers our products are built on: infrastructure, network, middleware, application and urbanism. In the meantime, we also need to make sure our product fits well into our system. Here we focus on the integration strategy with other systems our products have to communicate with.
-3. We prove (validate) the architecture by implementing it, not by validating document. Powerpoint slides, archimate diagrams ... don't go to production. The code developed by your squad does. And guess what: the sooner, the better ;)
-4. Architects shared the responsibility of the end-product; including its operability. When you're designing a solution, always keep in mind that the product you're shaping is likely to be deployed for real and as such it must be designed to be operated simply.
-5. Architecture is a team activity and shared understanding, not a document that is passed down from a team to another. An architecture document becomes obsolete as soon as it's written. Our intention here is not to recommend teams to not write documents. But we think that understanding the architecture, why and how decisions were made, the fullstack nature of your product is way more important than a document. The role of the architect is to transmit this his team ... and to write the just enough documents to communicate within and outside the team.
-6. Delay decisions until they are absolutely necessary. That's what we call "the last responsible moment". The idea is that the more you wait, the more you have feedback and you'll be in a position to take good decision. The tricky part of the architect job is to know when to make a decision: too early and you're almost blind; too late and the cost of rework could be high. 
-7. Risk-driven prioritization: do customer-centric features with major architectural impact first. Let's take an example to illustrate this: you want to decompose your monolith and you have the choice between doing it on back office features or user facing ones. We do recommend to start with the user facing features. Why? yes the risk of implementing such changes on a critical part of your product is higher so the benefits for your users will be. In that case, moving to a micro services approach will enable the team to deliver faster, reduce the impact of a change, scale differently the different parts of your product ...
+As software architects, we embrace the following seven core beliefs:
 
+1. **Architect long-term products** : We architect long-term products, not just project solutions. You have to consider your architecture activities as a runway following the life of your product (as it goes through different stages: from cradle to grave). You will have to take decisions, design new features, and reconsider/rework what you have done given the new context you are in. The design needs to be robust to future changes. Project-based approaches make this challenging, as transitions between projects lead to a loss of precious time and contextual knowledge.
+
+2. **Holistic product architecture** : We architect our products with a holistic view. Behind this, there are two different but complementary ideas. First, we look at the architecture from a full-stack perspective considering all the different layers our products are built on: infrastructure, network, middleware, application, and urbanism. In addition, we make sure that our product fits well into our ecosystem. Here we focus on the integration strategy with other systems our products have to communicate with.
+
+3. **Implementation as architecture validation** : We prove and validate the architecture by implementing it, not by wordsmithing documents. Powerpoint slides, ArchiMate diagrams ... do not go to production. The code developed by your squad does. And guess what: the sooner, the better ;)
+
+4. **Shared responsibility and operability** : Architects share the responsibility for the end-product, including its operability. When you are designing a solution, always keep in mind that the product you are shaping is likely to be deployed for real in production, and as such it must be designed to be operated simply.
+
+5. **Architecture as a shared team understanding** : Architecture is a team activity and shared understanding, not a document that is passed down from one team to another. An architecture document becomes obsolete as soon as it is written down. Our intent is not to recommend avoiding writing documents. But we think that understanding the architecture, why and how decisions were made, and the full-stack nature of your product is way more important than a document. The role of the architect is to transmit this to his team ... and to elaborate just-enough documentation for effective communication within and outside the team.
+
+6. **Delay decisions to the "last responsible moment"** : Defer decisions until they are absolutely necessary. This is what we call "the last responsible moment". This approach allows us to gather feedback, evaluate options, and make informed choices. The tricky part of the architect's job is to know when to take a decision: too early and you are almost blind; too late and the cost of the rework could be high. 
+
+7. **Risk-driven prioritization** : Implement customer-centric features with major architectural impact first. Let's take an example to illustrate this: you want to decompose your monolith and you have the choice between doing it on back office features or user-facing ones. We do recommend starting with the user-facing features. Why? Because the risk of implementing such changes on a critical part of your product is higher so the benefits for your users will be. In that case, moving to a microservices approach will enable the team to deliver faster, reduce the impact of a change, and scale differently the different parts of your product.
 
 image::./img/manifesto.jpg[Continuous Architecture Manifesto]