Many diagrams notations can depict who and what, like a system context diagram or UML use case, but I prefer using a solution user diagram.Ī solution user diagram is simple it is barely a diagram. Knowing who and what is usually enough for an architect to design a solution without having detailed requirements. Therefore, the first and most critical view for describing an architecture is one that clarifies who is using the solution and what they are using it for. All technology solutions are designed to address people’s needs: all architecture is people-centric. Nobody designs technology solutions in a vacuum. Without further ado, here are the four views I recommend. While it seems counter-intuitive, using multiple fit-for-purpose views is more understandable than trying to jam everything onto a single diagram. You will note that I said diagram s and not a diagram. Finally, the diagram becomes a historical record of the architecture (even a dated design is better than no design).Īfter decades of designing solution architectures, I have landed on a set of views that I use to depict any solution architecture. Firstly, a solution architect can use them to effectively think through an architecture design because the diagrams help to structure thinking and because the architect can put the diagram down and come back to it later with a “fresh set of eyes.” Secondly, a solution architect can use the diagrams to effectively facilitate the conversations required to share the design, gather feedback, and gain approval. *** these products may evolve to support more capabilities.Diagrams are a powerful tool for solution architecture design. Orbus Software - supports Conceptual, Logical, Physical diagrams ()Ĭ4 model - for visualizing software architecture (modeling not diagraming, another approach). Here are some useful vendor diagramming products Systems Context Diagram / Context Diagram - shows the systems involved and excludes systems that are not. While the logical and conceptual diagrams could be familiar to business stakeholders, this is where this diagram is very useful for business user’s understanding. For example, the exact steps and responsibilities of components for OAuth 2.0 using PKCE. This is one of the best diagrams to hand off to the software implementation team. Sequence Diagram(s) - This illustrates the steps required to complete a process you vertically list the components and use horizontal lines to show the interactions as steps (hence “sequence”) between the components with accompanying textual descriptions of the action taken. The value is correct and accurate implementation including proper security implementation, and documentation for troubleshooting.įurther diagrams that many find to be truly useful include: This is the last diagram of the three and will not be readily understandable by business users but familiar to solution architects and some developers. It is generally the responsibility of a Infrastructure Architect. Physical Infrastructure Architecture Diagram - This depicts physical elements that enable the infrastructure team to do their work including server models/VMs/Containers, databases/storage, network, zones, systems and sub-systems, and connectivity. This is very detail oriented in order to successfully implement the physical architecture. * some organizations combine Conceptual and Logical diagrams Logical Architecture Diagram - This is the next step after the Conceptual diagram(s). Logical diagrams describe how a solution works in terms of function and logical information. It illustrates connectivity between applications and therefore the flow or sequence between components. The value is that this helps instruct the software development teams on how to implement a solution but without reference to code, coding or related implementation techniques. And, it forms the basis for the physical architecture and documents the system for troubleshooting, upgrades and even potential future migrations. It is the responsibility of a Solution Architect. In my experience over the last 10 years, I have used the following diagrams.Ĭonceptual Architecture Diagram - this is a basic / abstract, lightly-technical diagram that highlights the relationships between key components and is often workflow oriented. Simply stated, it depicts the strategy of the solution within a context. This is valuable because it forms the basis for a viable solution implementation and a way to get initial agreement of the direction of the solution and isolate domain areas. It forms the basis or structure for the Logical Architecture diagram. It is the responsibility of a Solution Architect. Hi All, I am posting a few items I hope may help someone understand digital architecture, or accelerate their work by useful templates.
0 Comments
Leave a Reply. |