Introduction
Roles play a central role in socio-technical systems as they serve as bridges between social elements (people) and technical elements (artifacts). Furthermore, roles can be considered as services: we can formulate requirements for them, outline their APIs, and execute test scenarios. Let's delve into these concepts individually.
Roles as responsibilities for artifacts
There are multiple ways to define roles. Here are a couple of common approaches:
Defining roles by activities: overseeing projects, writing code, testing software, leading teams, etc.
Defining roles by required skills: strong leadership, analytical thinking, proficiency in Java, Kubernetes, AWS, etc.
Defining roles by responsibilities for processes or people: accountable for project X's governance, responsible for employee business development, in charge of test automation, etc.
However, these approaches come with several disadvantages:
They lack specificity when specificity is required. What exactly does it entail to 'oversee something'? What defines an 'analytical mindset'? What does being 'responsible for test automation' encompass?
They can be overly constraining and exclusive when not necessary. Is central oversight truly indispensable, or can we cultivate an environment where self-organization prevails? Are Kubernetes skills an immediate requirement, or can they be acquired swiftly?"
I intend to address these drawbacks. In one of my earlier posts, I defined roles as responsibilities for artifacts. For instance, the role of 'Software Architect' holds the responsibility for a set of artifacts termed 'Software Architecture Documentation'(SAD). It becomes immaterial what specific tasks a Software Architect undertakes. It doesn’t matter whether they possess familiarity with Kubernetes and AWS or not. The sense of responsibility towards the software architecture process is also irrelevant. What takes precedence are the artifacts that the role is responsible for. These artifacts entail other roles as stakeholders — roles such as 'Software Engineer,' 'Product Owner,' 'Platform Architect,' 'QA Engineer,' and so forth. These stakeholders harbor concerns, which evolve into requirements for the artifact’s owner role.
One could posit that the role functions as a service to the stakeholders invested in the artifacts for which the role bears responsibility. The actual individual working on the artifact holds little relevance. Roles simply outline responsibilities. Skills and activities constitute what engineers often call 'implementation details'.
The subsequent diagram provides a glimpse into a subset of roles, artifacts, individuals, and the interconnections among them.\
Please note: Roles can be allocated to 0..N individuals, like services to computing instances. I suggest using the phrasing 'The role of Software Architect is allocated to Cassandra' instead of 'Cassandra is a Software Architect.' This approach ensures that if Cassandra takes a vacation, the Software Architect role either experiences downtime or can be reallocated to another individual (instance), maintaining uninterrupted operation. The first phrasing enhances transparency in decision-making regarding this matter.
Requirements for roles
In the preceding section, I introduced the concept of roles functioning as services. Let's now embark on the task of formulating requirements for these services. These requirements emerge from the concerns voiced by stakeholders. The following table offers a couple of illustrative examples.
Stakeholder Role | Concerns | Requirements |
Software Engineer | Component interfaces, system decomposition, security aspects, etc. | Software engineers anticipate documentation outlining functional allocation and component interfaces when they begin working on related functionalities. Software engineers also anticipate documentation containing guidelines for meeting security requirements. |
Product Owner | Technical enablers, Availability of the role. | The Product Owner anticipates that the Software Architecture Documentation (SAD) will furnish information about necessary technical enablers. These enablers must be incorporated into the backlog to facilitate the smooth execution of the product roadmap. The Product Owner also anticipates that the architectural decisions documented in the SAD can be made independently at any time, without reliance on any single individual. |
QA Engineer | Testing Architecture | QA engineers expect to find instructions on constructing a test harness for the system being tested. |
This table is far from complete. In reality, artifacts like Software Architecture Documentation encompass a considerably broader array of stakeholders. These stakeholders harbor numerous concerns that subsequently give rise to a substantial number of requirements. Individuals to whom the role of Software Architect is allocated may find themselves accountable for addressing dozens of requirements.
Role API
Roles serve as services responsible for the creation of artifacts. When contemplating the APIs of these services, the artifacts themselves function as the payload of the API. The manner in which the role's owner (or co-creator) generates the artifacts, communicates them, and seeks feedback constitutes the interaction style of the API.
Unless specified otherwise, I would recommend embracing the API-first principle. This approach entails that the stakeholders of the artifacts are the client side of the API. They articulate the information they require, designate the preferred delivery method for this information (whether it be a git repository, a project's wiki, or a document management tool like Polarion), and define their desired level of involvement in the co-creation and review process. They can even formulate testing scenarios to validate their requirements.
Testing Scenarios for roles
If requirements represent one side of the coin, acceptance tests are the other. If we adhere to the metaphor of "Roles as a Service," we can enhance and validate requirements by introducing testing scenarios in BDD style.
Examples 1: Stakeholder - Product Owner. Concern - Availability of the role.
Scenario: Decision making during Cassandra's vacation
Given that the role of Software Architect is allocated to Cassandra,
When Cassandra is on vacation,
Then the team is authorized to make technical decisions independently,
And the team possesses all the essential architectural guidance required for their ongoing tasks.
Please note: The methodology for fulfilling this testing scenario remains inconsequential. Whether the role is allocated to multiple individuals, or the role is reallocated before Cassandra's vacation, or all necessary decision-making inputs are documented beyond Cassandra's personal knowledge — these aspects pertain to implementation details.
Examples 2: Stakeholder - Software Engineer. Concerns - Component decomposition and interfaces.
Scenario: On-time delivery of component decomposition and interfaces documentation for software engineers.
Given that the role of Software Architect is responsible for Software Architecture Documentation, When a Software Engineer commences work on a current backlog item, Then the Software Engineer can readily locate all pertinent details about interfaces and functional allocation to system components within the Software Architecture
Examples 3: Stakeholder - QA Engineer. Concern - Testing Architecture Documentation.
Scenario: On-time delivery of testing architecture for QA Engineers
Given that the role of Software Architect is responsible for Software Architecture Documentation, When a QA Engineer intends to test functionality X, Then the QA Engineer can access comprehensive instructions on how to construct a testing harness tailored to the system under test.
These examples are merely a subset. In practice, each requirement can undergo refinement through various testing scenarios. These scenarios can be conducted periodically, and the outcomes of their execution can contribute to enhancing the quality of service provided by the role.
How you can use roles as services
The consideration of roles as services holds extensive practical applications and can streamline your development process. I recommend employing the following multi-step approach:
Firstly, compile a list of the artifacts your organization is expected to produce.
Secondly, outline the potential roles of artifact owners and stakeholders.
Thirdly, gather stakeholder concerns to formulate requirements for the roles of artifact owners.
Fourthly, role owners and artifact stakeholders can collaborate to establish a Role API, encompassing the payload and interaction style for artifact creation and delivery.
Fifthly, devise testing scenarios to manifest and refine requirements and the Role API. These testing scenarios can be executed to evaluate the quality of service and aid in its enhancement.
If you're interested but require assistance in carrying out this exercise, please don't hesitate to reach out to me. I'd be delighted to provide support.
Conclusion
There are numerous approaches and tools available for role description. For instance, consider the Role Canvas, Role Model Canvas, or RACI Matrix. However, these approaches and tools primarily emphasize the activities, communication, and skills of the role's holder. They offer an intricate white-box perspective of the role. The concept of treating roles as services enables us to view roles as black boxes initially, gradually delving into the specifics of white-box implementation. We commence by establishing requirements for the role, and then progressively enhance these requirements through the formulation of a Role API and the design of testing scenarios.
This approach can be effectively employed to comprehend your existing roles and artifacts landscape, to bring about changes to it, or to construct a completely new one.
Comments