Chapter 9

The Architecture Design Process in the Organization

Outline

• Architecture Design and the Development Life Cycle– Architecture Design During Pre-Sales– Architecture Design During Development and

Operation• Organizational Aspects– Designing as an Individual or as a Team– Using a Design Concepts Catalog in Your Organization

• Summary

Background

• Two important phases occur in most development projects

The two phases• Pre-Sales: the scope of the project and a business case are

established– This occurs in every organization, whether they engage in “sales” or not– An important product is an estimation of the cost and duration of the

project which is used to decide whether to continue with the project or not

• Development and Operations– Occurs when the pre-sales proposal has been accepted– Development can be performed using different methodologies (e.g.

Agile, RUP, TSP)– Once the system is developed it is put into operation.– Newer approaches such as DevOps intend to reduce the gap between

development and operation

Architecture Design During Pre-Sales

• In many types of projects an initial estimate of the time and cost of the project must be provided, typically within a short time period and with limited information

• The estimate frequently has a lot of uncertainty, as illustrated by the “cone of uncertainty”

Architecture design usually occurs laterin the project timeline

Architecture Design During Pre-Sales

• Architectural practices can be applied during pre-sales to improve estimation– Initial “high-level” drivers can be identified early– A few ADD iterations can be used to produce an initial

architecture used for estimation purposes. – Sketches of the initial design are useful for communication

with the customer and other stakeholders• The standard components technique can be used for

estimating. This requires identifying the components of the application and using historical data to estimate the effort required to build them

Using ADD to identify “standard components”

• The approach is similar to the one recommended for the design of greenfield systems– Initial iteration goal: establish an overall system structure. The

reference architecture dictates the type of standard components (for example: DAOs). Technologies are also selected if they are needed for estimation

– Second iteration goal: identify standard components (modules) to support all of the functionality, and not only the primary use cases, as you need to estimate the whole system (or part of the system) that will be developed

– Additional iterations: Make design decisions regarding initial quality attributes. Favor decisions which impact the estimate (e.g. Introduction of redundancy if availability is needed)

Example

• From the case study in chapter 4 (iteration 1 step 6)– The modules shown can be used

for estimation purposes– The example in chapter 4 only

identified modules for the primary use cases, modules for all of the use cases associated to the system to be released would need to be identified during pre-sales

Architecture Design During Development and Operation

• Development can be performed using different methodologies but architectural design is independent of the development methodology that is used

• An architectural design method such as ADD can be used in conjunction with different development methodologies

ADD and Agile

• Agile software development and architectural design are not incompatible

• However, one of the principles of the agile manifesto states that “The best architectures, requirements, and designs emerge from self-organizing teams”– We are unaware of cases where an architecture has

succesfully emerged in a large project with complex requirements and distributed development

– Software architecture design is “up-front” work except, maybe, for smaller less complex projects

Three Different Approaches• A) Big Design Up Front (BDUF): all of the design is performed

initially, before the system is built– Associated with the Waterfall approach– Design problems may be discovered late and require costly rework

• B) Emergent approach: Minimal up-front design– This is what some people conceive from the agile manifesto

principle– Useful for small systems, throw-away prototypes or system with

unclear requirements• C) Iteration 0 approach: The fundamental parts of the

architecture are designed initially– Initial ADD design iterations are performed during the first project

iteration (Iteration 0)– Additional design iterations and / or spikes are performed during

subsequent project iterations. Spikes are time-boxed tasks created to answer a technical question or gather information.

ADD and the RUP• The Rational Unified Process (RUP) is a software development process

framework that puts strong emphasis on architecture (see chapter 7)• The life cycle of a project is divided in 4 phases

– Inception: This is similar to the pre-sales phase– Elaboration: One goal is to baseline the architecture of the system and

produce an architectural prototype– Construction: The system is developed incrementally.– Transition: The system is transitioned from the development environment to

the operation environment• From the elaboration phase until the end of the project, RUP follows

an “Iteration 0” approach • ADD design iterations can be performed during elaboration and

construction

ADD and the Team Software Process

• The Team Software Process (TSP) strongly emphasizes quality and measurement

• A TSP project is developed in cycles. Within each cycle, activities associated to requirements, “high-level” design, implementation and testing are performed

• The TSP does not give full consideration to architecture development– No architect role– No emphasis on quality attributes– No guidelines on how to design the architecture during “high-level” design

• As with RUP, ADD can be used with TSP by performing a number of ADD design iterations within each cycle.

ADD and DevOps• DevOps refers to a set of practices that help achieve continuous

delivery of software. Such practices are intended to reduce the time between making a change to a system and the change being placed into normal production, while ensuring high quality

• DevOps (combination of development and operations) is not inherently tied to architectural practices but the architect needs to make design decisions that facilitate achieving DevOps activities that include– Continuous build integration– Automated test execution– High availability– Scalable performance– Monitoring

ADD and DevOps

• Example: a tightly coupled (monolithic) architecture may hinder devops because a small change may require to rebuild and redeploy the entire system

• This may be solved by using a DevOps “friendly” architecture– E.g. Microservices– Interfaces for testing and monitoring

• The principles used for designing a software architecture can also be applied when designing a deployment pipeline to support DevOps

Organizational Aspects

• Supporting architectural practices goes beyond selecting a development methodology and deciding whether to introduce ADD into it

• Performing good architectural practices requires support at an organizational level

Designing as an Individual or as a Team

• Having more than one person participate in the design process yields important advantages

• Ideally one person should lead the effort, the others can be observers or participants. Some benefits include– Two (or more heads) can be better than one– Different people can have different areas of expertise, either technical or about

the domain– Design decisions can be reviewed as they are made– Less experienced people learn from the process

• However– “Analysis paralysis” may occur if no consensus is achieved– The cost of design increases– Managing the logistics can be complex– One person may influence heavily the design (“design by bullying”)

Using a Design Concepts Catalog in the Organization

• As we saw in chapter 3, the selection of design concepts is one of the most challenging aspects of the design process

• This problem is exacerbated by the fact that information is scattered in many places: Architects usually need to consult several pattern and tactics catalogs and do extensive research to find the design concepts that can be considered and used

• One possible way to resolve this issue is the creation of design concepts catalogs which group collections of design concepts for particular application domains

Using a Design Concepts Catalog in the Organization

• Benefits– Identification and selection of design concepts is facilitated– They can help enhance consistency in the designs across the

organization– They are useful for training purposes

• An example of a Design Concept Catalog appears in Appendix A– This catalog is oriented towards the design of enterprise applications– Similar catalogs can be created for other domains such as Big Data

• Creating and maintaining these catalogs requires a considerable effort but the effort is worthwhile as they are a valuable organizational asset

Summary

• ADD can be used from the project’s inception, that is in the pre-sales phase to improve the initial design of the proposed solution and for estimation purposes

• During development, ADD can be used with different development methodologies ranging from agile approaches to more traditional “waterfall” ones

• Measures can be taken at an organizational level to help improve the way architectural design is performed