Low-level resources (like functions) shouldn’t be related to high-level resources (like databases). Resources should be referenced by name so the viewer knows what it actually is.ĭon’t mix levels of abstraction: When adding detail and precision to a diagram, take care not to mix levels of abstraction. An icon isn’t enough nor is labeling a resource by its type (“Lambda”, “DynamoDB”). It sounds obvious, but many visual-aid diagrams (like above) don’t do this. Use named resources: Similar to the above, resources appearing in ESADs should be labeled with their name or identifier. Without arrow labels, it is not clear how these resources are actually related. In virtually all cases, arrows should have a label specifying the relationship between two resources. Label all arrows: An unlabeled arrow between two resources says “these two things are related…somehow.” This lack of specificity is not acceptable in an ESAD. If your diagramming tool allows (see Tools below), high- and low-level views can even be combined:īeyond generally including more details, ESADs should follow these precision rules: Ideally, ESADs should include both high- and low-level views. For instance, visual-aid diagrams commonly show databases as monoliths and omit details like individual tables. In service of truly informing the viewer, ESADs should instead place a premium on precision. Imprecise diagrams are cheap to create, after all.
This is the case not only because the presenter (or accompanying article) can fill in the details but also for efficiency’s sake. Small inaccuracies are also usually acceptable. “Handwaving” is expected, sometimes literally. Visual-aid diagrams intentionally leave out details. The goals of ESADs can be summed up by the “prime directive” of expert system architecture diagramming: When creating expert system architecture diagrams, always strive to truly inform your viewer rather than merely make an impression. ESADs are designed to be clear, precise, and comprehensive. Furthermore, they are intended to provide long-term value. They are meant to be valuable in their own right and aren’t tied to a larger work like an article or presentation. They intentionally lack clarity, precision, and comprehensiveness the accompanying article (or presenter) is responsible for filling in the details and making them clear.ĮSADs, in contrast, are created to be documentation.
They are designed to accompany an article, presentation, or ad-hoc design session delivered in person. Most system architecture diagrams you see online or hand-drawn on a whiteboard are created to be visual aids. ESADs are the product of expertise, clear intentions, and specific goals. ESADs generally do not happen organically. The most important ingredient of ESADs is the intent of the author. In this post, we’ll look at the elements that make up ESADs (Intent, Precision, Comprehensiveness, Maintainability) and the tools and techniques used to create them. Because they are long-term documentation, ESADs are useful both for onboarding new hires and as a reference for established employees. Relative to casual “whiteboard” diagrams, they are more precise, comprehensive, and maintainable.ĮSADs promote and demonstrate clear thinking about technical systems. Expert system architecture diagrams ( ESADs) are diagrams created to deliver long-term documentary value.
0 kommentar(er)
