I've created the Software Component Canvas to get a quick overlook of a broader software system landscape. It helped me to create kind of an inventory of almost all the software systems within a company.
This is a slightly polished version of the original. It's not documented in detail yet, but even so, I think the canvas will have more value to you this way than if it's just laying around on my hard drive.
- Fill out all the canvas areas while interviewing people who know something about the system or its creation. Alternative: research existing documents and artifacts
- Connect all the systems based on the information of the individual systems (e.g., by using the context diagram or collaboration information).
- Get a kind of inventory, including relationships between the systems.
- Be happy because now you know what systems there are!
And then? You have a good starting point to dig deeper! E.g. start thinking about which systems to improve or get rid of, align the team organization or begin to document the software architecture. Those steps depend heavily on your specific context and problem situation.
unfinished for now, but better than nothing
Write down the official name of the component. Write also down possible abbreviations or nicknames of the component. This is important because later on, you'll talk to different people and see different artifacts that may mention this very same component under different names.
Write down in 1-2 sentences what this component is roughly. It should be enough to remind yourself later on if you want to get more details about it. Also, make sure you add a hint what this component is (system, module, batch process etc.)
Here I list where all the ideas from the sections come from (roughly in order of appearance)
- Component name
- Short description
- Main stakeholders
- Responsibility / accountability
- Top 3 quality goals
- Context diagram
- Top 3 challenges
https://github.com/ddd-crew/bounded-context-canvas
- Strategic classification -> Importance for the business
- Provided capability
- Collaboration with other compoments
- Visibility on C-level
https://medium.com/wardleymaps
- Visibility for customers (adopted value chain)
- Evolution of the component
- Development process, teams and activities -> Personalities
- Development process, teams and activities -> Process, Drive Mode, Organization
- Development process, teams and activities -> Types
- Technical key facts
- Development process, teams and activities -> Teams key facts
https://www.devops-research.com/research.html
- Development process, teams and activities -> Teams key facts
- Technical key facts
- Development process, teams and activities -> Best Pracitices
* actually kind of, because cards42 is partly my own work, too
Probably! Depending on the abstraction level of the component, one team can be responsible for multiple components or a component can have multiple teams that are responsible for it. You can use the canvas then by referencing the sections regarding the teams for multiple components or vice versa.