Hi.
I'll share with you my point of view but I'm sure some other Architects can have different opinions.
SHORT ANSWERS ...
- Question: Are my requirements, risks, assumptions and constraints one and the same thing as my conceptual design?
- Answer: Design factors (Requirements, Constraints and Assumptions) are the most important information of conceptual design but you can identify other information like use cases, project goals, conceptual diagrams, etc.
- Question: Is my conceptual design equivalent to my requirements, risks, assumptions and constraints plus additional content and what is that additional content? Should there be a diagram that is of a higher level more general nature than my logical design diagram?
- Answer: See answer above. I believe there should be conceptual diagram or diagrams to depict basic architecture concept(s).
- Are my design factors (requirements, risks, assumptions and constraints) NOT specifically part of a conceptual design?
- Answer: I think design factors must be part of conceptual design.
LONG ANSWER ...
VCDX Architecture design is typical example of business and requirement driven design. Therefore design factors must be the key design drivers. The most design factors (Requirements, Constraints and Assumptions) should be discovered during design workshop interviews with relevant stakeholders and documented in conceptual design "section" of Architecture Design documentation together with conceptual diagram(s). Conceptual diagrams (aka blueprints) should be prepared based on design factors and the whole concept should be accepted with project stakeholders before moving to other design stages - Logical Design, Physical Design.
Only when Conceptual Design (concept) is accepted you should move to Logical Design and do architecture decomposition into several design areas you are responsible for and are in scope of your design. Therefore I believe that conceptual diagram is very helpful for concept acceptation and project success. Of course there are situations when other design factors are identified later and impact to all architecture areas has to be considered after concept acceptation. That's exactly where design impact analysis and risk management come in to play.
Another helper I use to identify what should belong to conceptual, logical and physical designs is the target audience. Conceptual design is usually for business stakeholders or for someone who needs quick but holistic introduction into designed system architecture. Someone who understand the concept can go deeper to some design areas only when needed but he should understand the system big picture.
Risks are usually identified later during your design process but I'm including "Risk management" to conceptual design section because it is very important for all design stakeholders (and also business sponsors) to understand potential risks and mitigation plan. If someone accepts the risks it should be documented with available mitigation options for future justification of risk acceptance. If risks cannot be accepted than some architecture change has to be plan to remove particular risk colliding with design factors.
If you are asking if you should have separate document just for Conceptual Design or you should have it in single document with Logical and Physical design then the answer is - IT DEPENDS. It depends on
- project scale/complexity
- organizational aspects (org schema and responsibilities)
- format of existing documentation
- customer preference
- etc.
I think that the main driver for final documentation format should be simplicity and easy of design consumption by implementer, IT admin, Capacity Manager, IT manager and other architects building other dependent systems.
Just my $0.02.
--
The devil is in the detail.
