![]() ![]() Middle - below each user action are the architectural elements that support the action and the interactions between them.Top - from left to right, are the user’s actions, which are part of a customer journey.This service blueprint consists of three ‘layers’: Here’s an example of a service blueprint (courtesy of Indu Alagarsamy - see below): They are, however, rather technical and can be difficult for non-technical stakeholders to understand.Ĭonversely, scenarios often don’t clearly communicate the complete user experience to technical stakeholders.Ī really good way for all stakeholders to gain a shared understanding of both end-users and the application architecture is to use service blueprints.Ī service blueprint is a diagram that shows the interactions between the user, and the architectural elements. ![]() Scenarios (sequence diagrams) are a good way to connect architectural elements to requirements. Using service blueprints to connect architectural elements to users Without these scenarios, you typically have a lifeless architecture that’s difficult to understand and discuss in a meaningful way. Since the scenarios are derived from user stories, an additional benefit of using scenarios to document dynamic behavior is that connects the architectural elements to the requirements. Scenarios connect architectural elements to requirements You typically need text explaining each step in the scenario. It’s important to remember that, as with architectural views, diagrams are necessary but often insufficient. There are a couple of different ways of visualizing a scenario including UML sequence diagrams and C4 dynamic diagrams. The scenarios are the +1 of the classic 4+1 view model of software architecture. You must also describe its dynamic behavior, which is how architectural elements collaborate during a scenario. Documenting an architecture’s dynamic behavior is essentialĪs I described in Using scenarios to reinvigorate your microservice architecture it’s insufficient to merely describe the static structure of an architecture.structure. In this article, I want to focus on describing the dynamic behavior of an architecture connecting architectural elements to user and describe what I think it is a valuable addition to an architect’s toolbox: service blueprints. In earlier articles OMG are you still using Rational Rose? and Using scenarios to reinvigorate your microservice architecture describe some key architecture and architecture documentation concepts. In particular, if you want to modernize a legacy application you need to understand its architecture as well as your target architecture. In other words, in order to reason about your application you need to understands its architecture. The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. Len Bass and colleagues at the Software Engineering Institute define software architecture as follows: Service blueprints: creating a shared understanding of your architecture ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |