Design Authority – Architecture and Design Standards

In a previous post Become a Master of Your Domain I talked about the four major domains of the Design Authority (DA) V-model and how together they help ensure that our systems are designed as architected, and that the systems are implemented as designed. In this post we will start sharing some key ideas around the first domain: Architecture and Design Standards.

 In this domain, the DA develops the early-stage design methodologies.  The DA leads stakeholders to agreement on architecture standards and high level design blueprints for applications, information, infrastructure, service management and security.

Throughout the program lifecycle, the DA conducts reviews, mediates design negotiations and communicates design decisions to ensure that the designs meet business goals and minimize late-stage changes to product requirements.

Below is a sample list of DA responsibilities around Architecture and Design Standards.

  • The DA is responsible for ensuring the quality of all program architectural, design and business deliverables prior to signoff. The DA has ownership of any periodic audits of the documentation.
  • The DA performs architecture analysis and communicates the direction of the program’s architectural and business views with regard to process, deliverables and timelines.
  • The DA interfaces between all program solution design architects (including vendors) and co-ordination with business analysts and stakeholders.
  • The DA verifies that the entrance criteria are met before work streams move into each stage gate review. If not, the DA documents the increased risk due to non-approved architectural design or other issues. The DA provides risk mitigation suggestions for the program.
  • The DA verifies that the exit criteria are met before the project moves to the Implementation phase. If not, the DA documents the increased risk due to non-approved design or other issues. The DA provides risk mitigation suggestions for the program.
  • The DA owns the development of architectural and business work plans, coordinating between program work stream leads and analyzing the consolidated plan to ensure the program is leveraging each individual work stream appropriately (e.g., no duplication and adequate coverage for each work stream)
  • The DA identifies, plans and coordinates successive, continuous streams of potential work for the program given an understanding of next set of domain capabilities
  • The DA establishes and enforces “best fit” development methodology and design standards for the program.
  • The DA aligns project work with domain level design to validate against logical target architecture.
  • The DA contributes to technical design trade off analysis, threat and risk reviews (Architecture and design review)
  • The DA aligns lifecycle processes across all program work streams.
  • The DA identifies any design/implementation risks relevant to each phase of development and determines which require mitigation plans.
  • The DA evaluates previous design/implementation risks to identify those that no longer apply or that have changed priority based on changes in probability or impact.
  • The DA checks that preventive measures and/or contingency plans exist for all identified design risk items and that the risk, with mitigations in place, is acceptable for moving to the Implementation phase.

On the next post, I will discuss Requirements Engineering. Thank you for reading.

Andre Michel Vargas

PA Consulting Group

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: