Goal of inception is to create common understanding of the product and define high-level execution plan of how we can deliver it. Align product and engineering on what we are building and how. Establish basic information about the project, needs of the client.
This is very important step because it helps everyone on the team understand the scope of product, assumptions and constraints.
This stage usually involves a number of activities that depend on a context a lot. For example, activities for starting "Greenfield" project may differ from Brownfield.
We'll dive deeper into activities below:
Understanding starting point
Where are we at now, and where we want to go from here.
The goal of this activity is to understand whether the project is possible taking into account technical (questions below) and financial (can this type of project be achieved within the budget and on schedule) sides of the story
Investigating feasibility requires information from multiple sources: code review, interviews, analysis of situation
Here are some of the questions we ask when we investigate feasbility:
Do we implement new feature in existing application or new application
- If application is existing, is the technology choice would be the right technology to solve problem?
- Are there are any architectural trade-offs we need to think about?
Do we build product from scratch?
Do we implement new application in existing architecture or fairly isolated?
Do we build product that needs to integrate with legacy system?
Are we migrating product from legacy?
What are the boundaries of the new system and existing system?
Existing code assessment
Are there tests in application?
- What are different types of tests exist: unit tests, functional tests, integration tests, specification examples
Is there a CI pipeline?
Is the application in production?
How often are releases deployed?
State of the code: quality, versions of the dependencies, secrets in git repo, unsanitized data in the repository
Infrastructure: dockerized? Kubernetes? Infrastructure as code? How many environments?
SDLC: what are roles and responsibilities within the team?
Access patterns: is the traffic evenly spread throughout the day? Does it have spikes around particular hours? Does it serve users from around the world or one specific region?
Scalability: what is the unit of scale of the application?
Datastores: SQL or NoSQL databases, cache stores, object stores. How many of different types are used and for what purposes?
Types of communication:
- Sync communication: what protocol is being used for synchronous communication? HTTP with JSON REST? gRPC? Thrift?
- Async communication: is there a queue processing? If so what's used for queue state?
Techniques used throughout inception
It is important to communicate all these findings, and they can be tedious and complex
Designs that schematically illustrate the ideas in response to the issues raised during feasibility and code assessment stages. May lack details, but describes high-level situation.
Feasibility gives initial constraints while initial schematic design will explore what’s possible within those constraints.
Outcome of inception
Defined high-level scope and user stories
Based on this, we can work on next items outlined below
Explains overall approach and scale of the proposal. All details remain flexible as architecture continues to evolve.
Research and PoC development
This provides high-level view of the software system in question. Easy way to validate unknowns, verify technology and approach are good for this problem