Return to
HomePage
Base Schema Components
* Scenario Overview
* Solution
* Product Mapping
* Pattern Mapping
* Analysis
* How To
* Pitfalls
* Questions and Answers
* Related Scenarios
* Community
* Related Resources
* Downloads
* Feedback
Scenario Overview
Provides a fast, visual reference (ideal) of the end-to-end scenario.
Keys
* Leverage the
WhiteboardApproach (simple, sketch/skeletal visuals)
* For operational requirements (security, performance, availability), use visal deployment overview
* For functional requirements, consider simplified sequence diagram of key components and interaction.
Exit Criteria
* Simple visual - (Is this me?)?
* End-to-end scenario?
* Context is clear?
* Is the problem course enough (e.g. application-level)? (e.g. Does the problem warrant a composite solution?)
* Is the problem too granular? (e.g. simpler problem/solution that can be solved by a How To or a Pattern?)
Solution
Solution is an elevator pitch answer to the problem. It distills the most important information down into easiy consumed key points.
Exit Criteria
* What are the key decision points?
* How is addressed at a conceptual level?
* Can the solution be repeated in the hallway?
* Does the solution explaination resonate with 8 out of 10 practitioners?
Product Mapping
This is the solution at a glance with products applied. However, only the essential elements are highlighted.
Exit Criteria:
* Simple visual with product mappings?
* Product Mapping highlights the key decision points?
* Implementation details are not mixed in? (How To section addresses implementation)
Pattern Mapping
Pattern mapping shows the skeletal frame in terms of patterns applied to the solution.
Exit Criteria:
*
* Patterns are cross-referenced?
Analysis
Exposes the thinking. Provides the rationale behind the solutions and recommendations.
Exit Criteria:
* What are the key considerations?
* Exposes the thinking?
* Exposes the rationale? (e.g. Why are we solving the way we're solving?)
How To
How To provides a path through the solution, highlighting key steps. The purpose is a linear path to implementation. Each high-level step may require more detailed implementation steps, which would point to appropriate How Tos, Patterns, Blocks, ... etc.
Exit Criteria:
* Role-based?
* Task-based?
* Detailed implementation steps are factored out into separate, reusable How Tos as appropriate?
Pitfalls
Common mistakes customers make. Product Support Services (PSS), product teams, and community would give input.
Exit Criteria
* Top issues resonate with 8 out of 10 practitioners?
* You can easily cross-check in the community and find the same pitfalls?
Questions and Answers
The FAQ section. Product Support Services (PSS), product teams, and community would give input.
Exit Criteria
* Top issues resonate with 8 out of 10 practitioners?
* You can easily cross-check in the community and find the same pitfalls?
Related Scenarios
Related Scenarios point out alternative solutions based on context. If the related scenario is simple to point out a different solution, it can be done inline, otherwise, point to another Scenario and Solution.
Exit Criteria
* Too much implementation detail?
* As precise as can be?
* Better if factored to a separate Scenario and Solution?
Community
Connects to the appropriate newsgroups, blogs, workspaces, forums.
Exit Criteria
* Community references are relevant?
* Community actually discusses the topic at hand?
Related Resources
Cross-referenace relevant blocks, patterns, how tos, scenarios and solutions ... etc.
Exit Criteria
* Warm hand-offs vs. dump of
URLs? * Why you are linking to a specific reference is spelled out?
Downloads
Any downloadable resources specific to this Scenario and Solution module.
Exit Criteria
Feedback
Simple channel/medium for providing feedback.
Exit Criteria
* Easy to give actionable feedback?
Lagash Feedback
* This is a good way to do content!
* Incorporat the community.
* Product Mapping should precide Pattern Mapping
* Use Product names in scenarios where possible (customers identify with products when using MS content)
* Tackle functional requirements in addition to non-functional/operational requirements.
* Scenarios is an overloaded term.
* Add a pattern view.
* Don't tangle scenarios with the solution space.
* Expose the critiera.
Alex
* App / Deployment Architecture Diagram
* Block diagram as visual eye catcher to set the scene
* Characteristics (or Context)
* Describe the key characteristics of the scenario to provide the context – so people know whether or not it’s their scenario
* Decision Points
* Key decisions points when establishing app security architecture – how to authenticate users, how to restrict access to business logic, how to restrict access to system resources, how to connect to the database and so on
* Related Scenarios
* Pointers to closely related scenarios
* Solution Characteristics
* Authentication
* Authorization
* Secure Communication
* Auditing
* Solution Summary
* App / Deployment Architecture Diagram + Key Security Features
* Overlay the security features onto the earlier diagram
* Analysis
* Presents the rationale – explains why things were done in the way they were – highlights the security benefits etc
* FAQ
* Common questions – why did you do this, why didn’t you do that, what if I had this situation etc
* Walkthrough – Securing the Scenario
* Inline where appropriate
* Pointing off to How To articles where appropriate
Return to
HomePage