The Agile Architecture Team
This team translates the Business Domain into the Technology Domain.
It creates the initiative’s Logical and Physical models and drives the specifications for development.
The Architecture Team is responsible for ensuring the Architecture, Designs and Development conforms to the Ubiquitous Language’s Lexicon of Terms.
If a term changes this team must propagate the change all the way down to the refactoring of the current code base.
This will help lower the cost of maintenance of the deployed solution over its life cycle.
Team Justification
The Architect Team consists of the Architects and the Designers.
The Architects, with support of the Business Analysts, Designers, Product Owner and Program Manager use the Ubiquitous Language to create a Technology Domain Model that, as closely as possible, represents the defined Business Model.
The Technology Domain Model drives the Architecture design.
The Architects define technologies and platforms, driven by the Domain Entity Model, to be implemented by the Designers to create the Statement of Works (SOW) for the Developers to use for their solution development.
The Architect team converts the Business User Stories and Child Stories Business Acceptance Criteria into Technology Acceptance Scenarios as Backlog items are selected for a Sprint iteration.
Detailed Sprint SOWs are created by the Designers for each User Story pulled from the Backlog for the upcoming Sprint.
The Sprint SOW is used to convert the Story Points into Developer capacity hours for daily development.
Roles and Responsibilities
Applications and Systems Architects – The primary role of the Systems Architects is to ensure that the information and understanding of the Client’s Business Domain Model is translated into a Technology Domain Model representation.
Designers are Architects and possible Developers assigned to create tangible Statement of Works from the Business Acceptance Criteria from Backlog User Stories for an upcoming Sprint iteration.
During Sprint Planning, Architects and Designers convert the Business User Stories Acceptance Scenarios into Story Points.
The Sprint SOW, along with the Agile Tracking tool, is used to convert the Story Points into Developer directives that can be set to Development capacity for daily development.
Generally no task duration assigned should exceed the maximum hours that the Development resource has agreed to as the daily capacity.
There can be exceptions but this should be the goal during Designer task assignments.
Designers – The Physical Model is created by the Designers.
Creating the road map for the Data Domain Entity Model, System Module Design and the Technology overall architecture along with the Presentation Architecture is the responsibility of the Designers.
The designers must be intimately aware of the required Control Structures and Rule Designs that have been defined by the Business Team during the Statement of Work (SOW) development process.
Designers are Architects assigned to creating tangible Statement of Works from the Technology Acceptance Criteria within a selected Business User Story selected from the Backlog for an upcoming Sprint iteration.
During Sprint Planning, Architects and Designers convert the Technology User Stories and Child Stories Acceptance Scenarios into Story Points.
The Sprint SOW is used to convert the Story Points into Developer capacity hours for daily development.
A Sprint preparation activity defines the estimation and the assigned Developer accepts the tasks as part of Sprint Planning.
Generally no task duration assigned should exceed the maximum hours that the Development resource has agreed to as the daily capacity.
There can be exceptions but this should be the goal during Designer task assignments.
Data Architect and Database Analysts – The architecture of the Information Repository Structure and its related Data Repositories is the responsibility of the role of Data Architect.
Creating an Information Repository Structure that supports the Technology Business Domain Entities, as it has been mapped from the Business Domain Entities, is a collaborated effort between the Data Architects and Database Analysts.
The collaboration between the Data Architect and Systems Architect will help ensure that the Business Domain Entities will be correctly represented under the System’s Data Abstraction Layers and consumed efficiently above the Data Repository Layers.
There are many “Titles” to the roles in this category as detailed in a Blog on database job titles:
What is in a job title? by Paul Randal.
Areas of Participation
System Model – The System Model defines the Logical Data Model that transforms the Business Data Semantic Model into the Technology Domain Entity Model.
The Application Architecture defines the processes for the functionality that support the User input and output views that define the User experience.
The System Architecture creates the Distributed Architecture Model that delivers the Domain Entities to the Application Architecture in a Bounded Contextual format with a single Aggregate Root entry point, through RESTful representation, of the Aggregated Domain Entity context.
The Human Interface Architecture defines the User Roles and the content authorization schema.
The Process Structure creates the Application and System Workflow that will consume the Business Rule Model.
The Business Rule Model contains the constraints defines by the Business Domain that governs the workflow of the distributed system and the application content delivery model.
Technology Model – The Technology Model defines the Physical Data Model and System Design that will be developed from the System Model logical models.
The required engagement Technologies and Development tools are selected, purchased and deployed.
The Designers create the System Designs from the selected Sprint User Stories and the Technology Hardware and supporting systems are defined and deployed to support the Development, QA and Production releases.
The User Interface Presentation Architecture, along with the System Designs, is created as part of the Statement of Work (SOW) that will be delivered to the Development Team.
A detailed Control Structure is defined in a Sequence Diagram that defines the Workflow of the SOW.
All Business Rules for the Workflow are defined as filter criteria for the SOW design requirements.
Participation Requirements
-
Logical Domain Entity Model
-
Systems Architects
-
Application Architects
-
Designers
-
Data Architects
-
Database Analysts
-
-
Physical Domain Entity Model
-
Systems Architects
-
Designers
-
Data Architects
-
Database Analysts
-
-
Application Architecture
-
Systems Architects
-
Application Architects
-
Designers
-
Data Architects
-
Database Analysts
-
-
Distributed System Model
-
Systems Architects
-
Application Architects
-
Designers
-
Data Architects
-
Database Analysts
-
-
Technology Architecture
-
Systems Architects
-
Application Architects
-
Designers
-
Data Architects
-
Database Analysts
-
-
Human Interface Architecture
-
Systems Architects
-
Application Architects
-
Designers
-
Data Architects
-
Database Analysts
-
-
Presentation Architecture
-
Application Architects
-
Designers
-
-
Processing Structure
-
Systems Architects
-
Application Architects
-
Designers
-
Data Architects
-
Database Analysts
-
-
Control Structure
-
Systems Architects
-
Application Architects
-
Designers
-
-
Business Rule Model
-
Systems Architects
-
Application Architects
-
Designers
-
Data Architects
-
Database Analysts
-
-
Rule Design
-
Systems Architects
-
Designers
-
Data Architects
-
Database Analysts
-
-
Daily Scrum Stand Up Meeting
-
Architecture Team Representative
-
-
Sprint Design Reviews
-
Designer – Owner of the Reviewed Design
-
-
Sprint Development Reviews
-
Designer – Owner of the Reviewed Design
-
-
Sprint QA Release Reviews
-
Designer – Owner of the Reviewed Design
-
Wisdom Pearl # 114 – Planning Ahead with Road Maps
Road Maps are Great
… But They Don’t Have Potholes Marked
…… Be Prepared for Changing Plans
Latest posts by Brad Huett (see all)
- DevOps: A Bridge to Your DevOps Culture - March 25, 2016
- Embracing Test Driven Development (TDD) - March 25, 2016
- DevOps: Delivering Agile Projects - March 25, 2016