(Reading Time: 2.5 minutes)
I design to avoid waste.
Waste in building something:
- nobody wants
- can use effectively
- can afford
That is, design is a process that helps maximize the value of systems we create.
The design process is also critical to understanding whether we should build them at all. Some systems will have low or even negative value. Try to avoid those.
You may recall that I’m researching secret delivery, audit, and usage analysis processes. (Please complete the survey if you haven’t already!) I have a hypothesis that many people aren’t satisfied with their delivery and audit processes and would like something better. We’ll see.
Based on this research my team and I are designing “something better.” We’ve completed one pass of market research, design and review. This research, thinking and feedback is helping the design converge to a way better place than if we’d ‘just started building.’
My original ideas were off the mark. Hopefully no one is surprised.
Designing ‘Secret Threat Analytics’
The QualiMente design template (free!) leads designers through coverage of the following areas:
- Problem Statement
- Expected Benefits of Solution
- Key Use Cases
- Context and Requirements
- Logical Architecture
- Physical Architecture
- Sequence Diagrams of Key Use Cases
- Availability and Fault Tolerance
- Maintenance
- Scalability
- Performance
- Security
- Verification and Monitoring
- Risk Summary
- Cost
- Resources
Interviews with potential users or partners and survey results are the primary tools we are using to improve the description of the problem, solution benefits, key use cases, and requirements.
We are currently focused on designing the ‘Secret Threat Analytics’ portion of the system. This system will observe secret usage, analyze that usage for threats or abuse, and (only) notify people when there’s a problem.
As we have captured more detail on the solution, we’ve identified a few critical attributes of this system:
- Problem Statement: better data on why this problem is likely to be important to customers decomposing from monoliths to microservices or serverless: secret usage is going to go up by 10x or more, likely overwhelming the solution you have now
- Scalability: how the system scales in response to customer’s primary input, which is secret usages per second
- Cost: a ballpark estimate of the cost to operate the system in terms of secret usage: 3x what I had in my mind a week ago, but I think still worth it to many people
- Tradeoffs: some ideas for where and how we might be able to eliminate low-value data flowing through the system in order to reduce its cost
This information is incredibly useful because in our next round of conversations we can ask potential customers:
- How many secret usages per second/hour/day do you have (or application starts)? Need to build for the right scale.
- Would you be willing to spend X to get real-time threat analysis of that usage? Need to determine if the service is commercially viable.
- Would you tradeoff Capability X for a lower price? (e.g. full copy of usage data in the analytics database)
So far, my team’s total investment is probably 3-5 days of effort and the proposed service has changed quite a bit. Now I feel much more comfortable proceeding with some prototyping, which I’ve ballparked at a month for an Architect (myself) and Engineer. In the prototyping, we can intentionally explore some of the scalability and cost questions as well as produce a system that customers can give us feedback on before proceeding to an MVP.
I think this is a great demonstration of how ‘technical’ architecture activities should be incorporated into product development in an agile way. The bulk of this design process has taken less than a week and has identified critical questions to answer in the next round of customer and technical investigation.
If you’re interested in learning more about this project or would like a copy of the design doc, reply to this email and I’ll set you up.
Stephen
#NoDrama
