These Architecture Diagramming Guidelines are intended to facilitate the communication of technology architecture. This can either be as a part of an Enterprise Architecture Governance process or simply in the flow of information from business requirements to systems architecture to technical design to implementation to operation.
Whatever the reason, communicating architecture is important to any large technology infrastructure and core to any Enterprise Architecture Governance Process. In order to communicate and concept, particularly complicated ones, both the presenter and the audience must speak a common language and that language should be descriptive enough, flexible enough and precise enough to get the point across..
They say “a picture is worth a thousand words” and where technology architecture is concerned, the old adage is pretty much true. As opposed to inventing something brand new, these Guidelines start with an existing, fairly widely used diagramming language called the UML (Unified Modeling Language).
UML is widely used, extensible and flexible. But with flexibility comes a degree of imprecision. In addition, UML is generally used as a language for communicating design rather than architecture and many of its constructs are moving in the direction of “model driven design” or models that are precise enough so that code can be generated directly from the model (or nearly so).
Architecture on the other hand is more abstract than design, which is more abstract than implementation. As such, we intend to use diagrams to draw out larger relationships between systems and reproducible patterns, rather than designs and implementations. We can use the flexibility inherent in UML quite effectively as long as we define which UML constructs we intend to use, how we intend to use them and what they mean in our context.
When we define architecture, whether it is the architecture of a service, an application or a combination thereof, we divide the architecture into four main parts:
Information Architecture – A systems agnostic view of content as it exists across the technology landscape. The scope covers: entities, relationships, data sets, categorization (ontology), content organization, flow, search, navigation, etc.
Functional Architecture – The modules (organized logically not physically) across the technology landscape proving the features and functions. Often this is decomposed into Services and Solutions. But even on a smaller scale there is usually some separation between shared system-level modules and product specific modules and the glue that binds them.
Service – Coarse grained reusable infrastructure that is live and operational and accessed via loosely coupled interfaces. A service is responsible for handling load and scaling itself as appropriate. You don’t build a new one when you run out of capacity
Solution – Application, Product, etc that either monolithically delivers required business benefit (architecturally bad ) or aggregates multiple services together in order to do so, adding the necessary business logic and glue (architecturally good )
Physical Architecture – The systems (e.g. computers, disk arrays, back-up units, etc), networks (switches, routers, Load balancers, DNS, etc) and houses (data centers, power, cooling, etc) that represent the physical manifestation of the production environment.
Business Process Architecture – The processes that support the underlying business model for which the technology was built. This could be related to getting “hits” on a website to support an advertising model or it could be a full blown order processing/shopping cart/authentication/authorization/billing process supporting a paid subscription. Whatever the Business model is, there should be a Business Process Architecture defined to support it (no matter how simple).
In this context, the following diagramming guidelines (UML style guide) apply solely to the aspect of Functional Architecture.