Click here to close now.




















Sound Business Principles for Executives & Business Owners

The Role of Business

Subscribe to The Role of Business: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get The Role of Business: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Business on Ulitzer Authors: Bob Gourley, Shelly Palmer, RealWire News Distribution

Related Topics: The Role of Business

Blog Feed Post

Using CMU/SEI Quality Attribute Workshop (QAW) while developing an Architecture Vision

Business Scenarios are a proven technique to link business requirements to architectural models. According to TOGAF a Business Scenario is a description of:
  • A business process, application, or set of applications that can be enabled by the architecture
  • The business and technology environment
  • The people and computing components (called "actors") who execute the scenario
  • The desired outcome of proper execution"
Recently I have been working with another technique which is commonly used by Software Engineering People but mainly for Software Architecture: Quality Attribute Workshops (QAWs) from CMU SEI (Carnegie Mellon Software Engineering Institute. This technique make use of interactive workshops with the main stakeholders of a project. Where you the solution is to be developed either internally or externally (not a COTS), then this technique could be combined with the Business Scenario.
A Quality Attribute Workshop (QAW) is a systematic approach to elicit the needed requirements. This will ensure that all quality attributes are included in the final design. To This end it:
  • is a facilitated method that engages system stakeholders early in the life cycle to discover the driving quality attributes of a software-intensive system
  • provides a way to identify important quality attributes and clarify system requirements before the software architecture has been created (Implementation Governance)
  • is based on the qualities and the non-functional requirements that may be captured in the Architecture Vision document, the team will identify and elaborate specific quality attribute scenarios and document them
  • produces a documentation that includes most of the quality attributes specified by the stakeholders
QAW defines two kinds of architectures:
  • System Architecture: the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviours
  • Software Architecture: the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them
The TOGAF specification considers the Enterprise as a System, however the term System in QAW is more related to IT Systems. QAW provides an opportunity to gather stakeholders together to provide input about their needs and expectations with respect to key quality attributes that are of particular concern to them. A similar concept to what we try to achieve with the TOGAF Business Scenario but with a focus on IT systems quality attributes.

It is also a purpose of identifying scenarios from the point of view of a diverse group of stakeholders which can then be used by the system engineers to analyse the system’s architecture and identify concerns. QAW is mainly addressing non-functional requirements and there is still needs to understand the problems we try to solve, gather functional requirements like in Business Scenarios.

clip_image002
Quality Attribute Workshops ensure that quality attribute scenarios are identified, prioritized, and refined before the software architecture is completed. Individual requirements are viewed in a forum in relation to one another in the context of the overall problem. Architecture is based on complete set of requirements that add up to a whole problem description.

Technique requires involvement - at an early stage in architecture project
  • Business stakeholders (end users)
  • Systems stakeholders (installers, administrators, DBAs; network, training, acquirers, system and software engineers, etc.)
  • Other stakeholders (such as Operations amongst others)
The QAW provides:
  • Increased stakeholder communication, an informed basis for architectural decisions
  • Improved architectural documentation, and support for analysis and testing throughout the life of the system
And the results include:
  • A list of architectural drivers
  • Raw scenarios
  • A prioritized list of raw scenarios
  • Refined scenarios
During the workshops the Stakeholders receive a “participant’s handbook” providing example quality attribute taxonomies, questions, and scenarios.

Below are the steps of the QAW.

clip_image004
clip_image006
clip_image008
clip_image010
Business and/or mission drivers for the system (goals and drivers), plan, strategies, high-level functional requirements, constraints, artifacts and quality attribute requirements should be presented to the stakeholders. Using Business Scenario in conjunction with QAWs can be an appropriate approach.

A QAW lends itself to the capture of many architecturally relevant materials:
  • Software architectural documentation is a collection of view packets plus any documentation that applies to more than one view
  • Each view packet contains a primary presentation, a catalogue of the view’s elements (including element behaviour), use case diagrams, sequence diagram, context diagrams, collaboration diagram, a variability guide, architecture background (rationale, analysis results, and assumptions about the environment), and other information including mapping to requirements
These elements may also be produced in a Business Scenario or produced later in the ADM phases A : Architecture Vision, C: Information Systems Architectures (stakeholders management and taxonomy of artifacts).

clip_image012
The outputs from the QAW can be summarised as:
  • A list of architectural drivers
  • Raw scenarios
  • A prioritized list of raw scenarios
  • Refined scenarios
  • Questionnaire
Quality attribute requirements are the means by which a system is intended to meet its business goals and QAW helps to document them.

Software architectures must be designed so that their quality attributes are met.

The QAWs technique can be utilised as a complementary approach to gather all sort of requirements including those from Software Architectures when appropriate.

Read the original blog entry...

More Stories By Serge Thorn

Serge Thorn is currently developing and delivering new Enterprise Architecture consultancy and training services, implementing Governance and managing IT Operations.

Before he was in charge of International Governance and Control, implementing different best practices around IT Finance/Procurement, Audit/Risk management, Vendors Management (with Service Level Management) in a Bank.

Previously Serge worked in a Pharma in charge of the Enterprise Architecture worldwide program and Governance, the IT Research & Innovation, following the reorganization of the IT Department, implementing Service Management based on ITIL Best Practices and deploying new processes: Change, Configuration, Release, and Capacity/Availability Management, responsible for the Disaster Recovery Plan and for the System Management team.

Prior to this, he was responsible for the Architecture team in an international bank, and has wide experience in the deployment and management of information systems in Private Banking and Wealth Management environments, and also in the IT architectures domains, Internet, dealing rooms, inter-banking networks, Middle and Back-office. He also has been into ERP and CRM domains.

Serge's main competencies cover the perfect understanding of banking activities, and industry, the design of new systems, IT strategies, IT Governance and Control, Innovation, new technologies, Enterprise Architecture (including BPM and TOGAF 9), Service Management (ITIL V 3), Quality System ISO 9001:2000, team management, project and portfolio management (PMI), IT Finance, organization and planning.