How does a platform take form? Where does the idea come from? How do people materialize those ideas into software? What is the process in which a software is designed?
If you think a platform is a large piece of software (more precisely a bundle of software), think of a service, like a message broker — that’s simple enough, right? Now lets see how do we try to systematically think through designing these kinds of systems, and what challenges does our way of thinking help solving.
Before going any further, lets be clear about what kind of software we are talking about. What we focus on is the kind of software that facilitates business application development, like identification/authorization service, credit calculation, message brokers, subscription engines, comprehensive distributed logs, historical data store, etc. What these software all have in common, are the ability to be distributed, scaled, reliable, and — as you might have guessed — easy to maintain and monitor. So the following content might not be suitable for designing every and all kinds of software. And it’s definitely not a one-rule-fits-all thing.
Every practical and useful system starts with hope to find an answer to a problem, and depending on how big the problem is, the answer may vary. One thing is common among all the possible answers though, they should all target a specific scope. Whether your particular problem is about managing a large immutable data store or a message broker or an identity verification service, you have to define a scope of what your solution MUST provide, and more importantly, what it MUST NOT. There are however some areas which do not quiet fall into the MUST and MUST-NOT categories, at least at the begging of the scope definition process. That’s why we, at clay-one, define a third “MAYBE” column and put those areas of ambiguity in that. most of the scope definition time is then spent brain-storming new scope aspects, and presenting proof for either the MUST-NOT column tenants, or the MUST column.
The MUST column is pretty simple to prove. Well, they are essentially the critical topics of your targeted problem, right? However the MUST-NOT and the MAYBE columns are trickier. You — as a software developer/architect — have to refrain from creating a god-system! (refer to the God object anti-pattern in Object Oriented paradigm)
During a number of brain storming sessions — usually not more than three or four — a service scope definition document is drafted. The document comprises of 4 major sections which are roughly defined as follows:
General Definition
This section tries to provide a definition of the service and a 1000-mile overview of its purposes.
Responsibility Matrix
The categorization of the “MUST”s, “MAYBE”s and “MUST-NOT”s. Usually you start with a more populated “MAYBE” column and categorize its contents during the discussions. Here is a good example of what a matrix would look like mid-way through the design.
Instances / Variations
A rough estimation of the final deployed product, how many instances it might have and whether or not it has variations of instances. For instance is it a monolith or a collection of micro-services. Are those services deployed on one machine? is it a single node deployment? These kinds of questions are addressed in this section.
Open Issues / Problems
This sections contains the problems that the current design has not addressed; Or they have not been talked about thoroughly enough. This is merely for keeping track of the challenges and/or issues the product might face during it’s design/development life-cycle.
