As software and system architects, there are a lot of responsibilities that we end up having to shoulder during a design process. Many of these are obvious:
- What is the function of the system/service to be designed?
- How can we leverage existing systems or services?
- Is the design scalable?
What is sometimes less obvious is that the considerations for design should include all consumers of the service.
Often when one considers the design of a system, it is from the perspective of the consumer that service is geared toward. After all, they are the reason for designing and building the service, right? The important thing to keep in mind is that they are not the only consumer (or, in UML parlance, “actor”). There will almost certainly be other users of the service although they may not use it in the same way as the consumers for whom the service is intended.
In the case of services and systems at Dyn, there are two fairly obvious actors:
- The customer: the folks who pay for the service. In the context of design, this actor could represent an individual interacting with our Web based UI or a piece of software interacting with our API or SMTP servers.
- The third party consumer: those that issue requests to us for DNS data or who receive an email.
However, there are a number of other actors that we need to consider with our systems. The better we can cater to all these actors, the less we will have to spend time supporting the system. Other actors that we try to consider include:
These are the great folks that help out our customers when any difficulties arise. As smart as they are, if we don’t design our system to give them what they need, they won’t be able to effectively do their job. Our development team interacts with the folks in Support on a regular basis and a portion of our job is to make their job as easy as possible.
Our operations team is tasked with measuring the health and performance of our services and systems and to act as a front line in case any problems arise. If they are not able to see into our software systems, how would they be able to do their job? The short answer is “ineffectively”. This means that any system to be put into production use must not only provide methods of inspection, but they must be as granular as possible.
Without sufficient entry points into the system, it will be very difficult to discover where any issues might lie.
One of the consumers of our software and services is our own software and services. Interaction between different systems is an inevitability once the service base gets to a certain size. If work is not done in advance to make the interfaces for a system consumable by software as well as humans, this sort of interaction becomes inordinately more difficult. Consistency and documentation of interface, consistency of data representation; these are musts.
Don’t forget about these folks! I’m not just talking about things like verbosity of comments, code formatting and using meaningful variable names. Does the code lend itself to debugging? Profiling? Unit/functional/integration testing? Is the flow easy to follow?
For those that haven’t heard this umpteen million times already, keep in mind that you might just be the poor person who will have to decipher a system…and potentially long after the design has been flushed from your in-brain cache.
Do you have specific actors that you consider when designing systems that I didn’t talk about here? I’d like to hear about it, so email me with the details!