Communication is key and communicating abstract concepts is difficult. In a remote working world, communicating effectively is more important than ever.
This is essential to a group making good software together. The audience will have various levels of skill and function, how to you get them what they need?
Who are you communicating to?
First we need to consider the audience, and provide correct context. For a developer the audience usually falls into the groups that surround you on the day to day:
- An operations person deploying and monitoring the software
- A developer needing to configure the software and environment around it to add features
- A quality engineer testing the the features
- A product manager understanding cost and limitations to figure out what can go on the road-map.
- A user, using your application to solve a specific problem.
Context
When illustrating the solution, the context would be the problems the solution is solving. Good communication takes into account the audience and what they need to get out of it. If I'm testing software, I don't need a lengthy explanation of the computer science behind an algorithm, but if I am deploying and monitoring the software this would come in handy in explaining why some operations take a long time or use a lot of resources.Who is the audience for the design and how does an Architect deliver the design to them?
In a software project or product, it essential to formulate the design for the audience and in a software there are 3 groups that consume the design to make the final deliverable.
Product and Engineering delivering Solutions
Engineers validating, deploying and monitoring Applications
Programmers building Containers and Components
In a software project or product, it essential to formulate the design for the audience and in a software there are 3 groups that consume the design to make the final deliverable.
Product and Engineering delivering Solutions
- Use the Quality Model (https://en.wikipedia.org/wiki/ISO/IEC_9126)
- Understand and define the value of the software in the context of the experience of the audience using it. This defines how the functionality and aesthetics combine to deliver value.
Engineers validating, deploying and monitoring Applications
- Use the 12-factor model (https://12factor.net/)
- Validate the design and operation of the software on the machine for the user so its structurally sound
Programmers building Containers and Components
- One current approach for expressing structure that I have got a lot of value from is the 'C4' model (https://c4model.com/) This separate the Context, Containers, Components and Classes.
- Build the software in the context of the users and machine so its functional
What is Software architecture?
The architecture of software is explained in many ways, sometimes verbally, but as it grows the complexity of the system is such that some formalized description is needed. This can be done with a whiteboard, or a diagramming tool that makes boxes, lines and whatever the author sees as necessary to describe what the system is.In any case, it is really important to write things down and operate for a common source of truth
This is the structure of software, and is valuable on its own, but its incomplete until you have been able to describe the behavior of that structure in a given context.
These can be problems from the user, the domain, or constraints from the environment.
Using a format like BDD really helps formalize the behaviour so you can build and test with a more accurate understand of what the user will do
This is the structure of software, and is valuable on its own, but its incomplete until you have been able to describe the behavior of that structure in a given context.
Structure
While hand-waving and white-boarding got us far, there was an understanding early on that a standardized language would help. This became the Unified Modelling Language and has given a good foundation to formalizing architecture. Like any standard, it is only as good as its acceptance as a standard. So use UML pragmatically, I have seen pictures of hand-drawing on a whiteboard go quite far!Behavior
The behavior is what the structure does with the inputs it is given. This is really what the users do and what you test for.These can be problems from the user, the domain, or constraints from the environment.
Using a format like BDD really helps formalize the behaviour so you can build and test with a more accurate understand of what the user will do
- user scenarios (understand the problem from user perspective, functionality and usability)
- domain requirements (validate solutions with domain/business rules, functionality and domain rules)
- environment constraints (cross-cutting concerns that all features have, context that feature share)
Just enough architecture...
When thinking about architecture, its natural to think of architecture in other technologies. Houses, Cars, and Reactors need architecture; and for those technologies the architecture is an output that is needed before any building happens.Software development doesn't have this constraint, you can just start building and the architecture will just happen by consequence. While this is possible, and done quite often in a fast moving startup; its a symptom of a problem that will manifest itself eventually. By not defining the architecture along the way the design of the system grows organically; and like a garden that never gets weeded this will grow in complexity until its out of control.
Design often, but only when needed; and keep it consistent.
No comments:
Post a Comment