How To: Design Your Architecture
J.D. Meier, Alex Homer, David Hill,
Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
- Understand the inputs required for the architecture design process.
- Understand the typical results of the architecture design process.
- Learn the key steps to iteratively design a suitable architecture for your application.
- Learn the guidelines to follow when designing the architecture.
- Learn an effective approach for reviewing the architecture.
A successful approach to architecture design requires you to follow a series of steps that ensure that you consider all of the relevant factors affecting the architecture, and then repeat these steps as you refine your design. This chapter recommends a series
of five main steps, each of which breaks down into individual processes that will be explained in greater detail throughout the remainder of the guide. These steps are meant to be iterative; you will produce candidate solutions that you can further refine
by repeating the steps, finally creating the architecture design that best fits your application.
The following list represents assets that are useful to have in hand when designing your architecture:
- Use cases and usage scenarios
- Functional requirements
- Non-functional requirements including quality attributes such as performance, security, reliability, and others.
- Technological requirements
- Target deployment environment
The steps in this chapter should result in the following assets:
- Architecturally significant use cases
- Architecture hotspots
- Candidate architectures
Figure 1 shows the five major steps for designing your architecture.
Figure 1 Core Architecture Design Activities
These steps are:
- Step 1: Identify Architecture Objectives. Clear objectives help you to focus on your architecture and on solving the right problems in your design. Precise objectives help you to determine when you have completed the current phase, and when you are
ready to move to the next phase.
- Step 2: Key Scenarios.** Use key scenarios to focus your design on what matters most, and to evaluate your candidate architectures when they are ready.
- Step 3: Application Overview.** Understand your application type, deployment architecture, architecture styles, and technologies in order to connect your design to the real world in which the application will have to operate.
- Step 4: Key Hotspots.** Identify key hotspots based on quality attributes and the architecture frame. These are the areas where mistakes are most often made when designing an application.
- Step 5: Candidate Solutions. Create a candidate architecture or architectural spike and evaluate it against your key scenarios, hotspots, and deployment constraints.
This architectural process is meant to be an iterative and incremental approach. Your first candidate architecture will be a high-level design that you can test against key scenarios, requirements, known constraints, quality attributes, and the architecture
frame. As you refine your candidate architecture, you will learn more details about the design and will be able to further flesh out key scenarios, your application overview, and your approach to hotspots.
You can iteratively flesh out your architecture as you work through your design and discover more details that impact your architecture. You should not try to build your architecture in a single iteration. Each iteration should add more detail. Don’t get lost
in the details, but instead focus on the big steps and build a framework on which you can base your architecture and design.
Step 1: Identify Architecture Objectives
Architecture objectives are the goals and constraints that shape your architecture and design process, scope the exercise, and help you determine when you are finished. Consider the following key points as you identify your architecture objectives:
- Understand your architecture goals at the start. The amount of time you spend in each phase of architecture and design will depend on these goals. For example, are you building a prototype, testing potential paths, or embarking on a long-running
architectural process for a new application?
- Understand who will consume your architecture. Determine if your architecture will be used by other architects, by developers and testers, by operations staff, or by management. Consider the needs of your audience to make your architecture more successful
- Understand your constraints. Understand your technology options and constraints, usage constraints, and deployment constraints. Understand your constraints at the start so that you do not waste time or encounter surprises later in your application
Scope and Time
Based on your high-level goals for the architecture process, you can scope the amount of time to spend on your design. For instance, a prototype might only require a few days to design, while a fully detailed architecture for a complex application could potentially
take months to complete. Use your understanding of the objectives to determine how much time and energy to spend on each step and to gain an understanding of what the end result will look like.
Use your architecture objectives to clearly define the purpose and priorities of your architecture. Possible purposes might include:
- A complete application design
- Building of prototypes
- Identification of key technical risks
- Testing of potential paths
- Shared models and understanding of system
Each of these purposes will result in a different emphasis during design and varying time commitment, and will impact the results and design documentation that emerge from the process. For instance, if you want to identify key risks in your authentication architecture,
you will spend much of your time and energy identifying authentication scenarios, constraints on your authentication architecture, and possible authentication technology choices. However, if you are building a larger design, authentication will be only one
of many other concerns you address and document solutions for.
Some examples of architecture objectives are:
- Build a prototype to get feedback on the order-processing UI for a Web application.
- Test three possible ways to map location data to search results.
- Build a customer order-tracking application.
- Design the authentication and authorization architecture for an application for the purposes of security review.
Step 2: Key Scenarios
Understand your key scenarios in order to shape your application to meet these scenarios, and later to use as tests of candidate architectures and architectural spikes. Key scenarios are those that are considered the most important scenarios for the success
of your application. Key scenarios can be defined as any scenario that meets one of the following criteria:
- It is an architecturally significant use case.
- It represents the intersection of quality attributes with functionality.
- It represents a tradeoff between quality attributes.
For example, your authentication strategy is a key scenario because it is an intersection of a quality attribute (security) with functionality (how a user logs into your system). Another key scenario is how your security requirements impact your application’s
performance, because it represents the intersection of two quality attributes.
Architecturally Significant Use Cases
Architecturally significant use cases have impact across many aspects of your design. These use cases are especially important in shaping the success of your application. They are:
- Business-Critical.** The use case is business-critical, has a high usage level compared to other features, or implies high technical or technological risk.
- High Impact.** The use case intersects with both functionality and quality attributes, or represents a cross-cutting concern that has an end-to-end impact across the layer and tiers of your application. An example might be a Create, Read, Update,
Delete (CRUD) operation that is security-sensitive.
Architecturally significant use cases are those that are important for the success and acceptance of the deployed application, and that exercise enough of the design to be useful in evaluating the architecture. These use cases can be categorized as system scenarios
and user scenarios. System scenarios
are those that primarily impact the internal operations of the application and infrastructure, such as message communication between layers, connecting to data stores, and performing input and data validation.
are those initiated by or controlled by the user, such as creating an order, viewing a product, or updating a customer record.
User Stories, System Stories, and Business Stories
Use stories from multiple perspectives to help expose the key scenarios for your system.
describe how your users will interact with the system. System stories
describe how the system will work and organize its functionality.
describe how the system will meet business needs or work within business constraints. Examples of these stories include:
- User story.** A user places an order and gets a license key within 30 seconds.
- System story.** The license process system will be able to process 100 license requests per minute.
- Business story.** The system will require no more than two servers for deployment.
Use system stories and user stories to measure your requirements against specific, testable instances of use cases. A good story will intersect the user view, the system view, and the business view of the architecture. Use stories to test your design and determine
where any breaking points may be. For instance, you would create stories around usage, and evaluate against your quality attributes. You should be able to complete development of the features to implement a story within a single iteration. You might need to
develop new stories as you create and update your architecture model.
Consider the following when planning your stories:
- Early in the project, reduce risk by creating a candidate architecture that supports architecturally significant end-to-end scenarios that exercise all layers of the architecture.
- Using your architecture model as a guide, make changes to your architecture, design, and code to meet your scenarios, functional requirements, technological requirements, quality attributes, and constraints.
- Create an architecture model based on what you know at the time, and define a list of questions that must be addressed in subsequent stories and iterations.
- After you make sufficient significant changes to the architecture and design, consider creating a story that reflects these changes. Batch together the small changes in the architecture and design and address them together.
Step 3: Application Overview
Summary of Steps
Build an overview of what your application will look like when it is complete. The application overview serves to make your architecture more real, connecting it to real-world constraints and decisions. An application overview consists of the following steps:
- Determine your application type.** First, determine what type of application you are building. Is it a mobile application, a rich client, a rich Internet application, a service, a Web application, or some combination of these types?
- Understand your deployment constraints. Next, understand your targeted deployment environment and determine what impact it will have on your architecture.
- Identify important architecture styles.** Determine which architecture styles you will be using in your design. Will you build service oriented architecture (SOA), client/server, layered, message-bus, or a combination of styles?
- Determine relevant technologies.** Finally, identify the relevant technology choices based on your application type and other constraints, and determine which technologies you will leverage in your architecture.
Choosing the right application type is the key part of the process of designing and architecting an application. Your choice of an appropriate application type is governed by your specific requirements and infrastructure limitations. The following considerations
will help you to choose the appropriate application type.
Key Application Types
- Mobile applications. These applications can be developed as thin client or rich client applications. Rich client mobile applications can support disconnected or occasionally-connected scenarios, while Web or thin client applications support connected
scenarios only. The device resources may prove to be a constraint when designing mobile applications.
- Rich client applications. These applications are usually developed as stand-alone applications with a graphical user interface (GUI) that displays data using a range of controls. Rich client applications can be designed to support disconnected and
occasionally-connected scenarios because the application runs on the client machine.
- Rich Internet applications. These applications can be developed to support multiple platforms and multiple browsers, displaying rich media or graphical content. Rich Internet applications run in a browser sandbox that restricts access to devices
on the client.
- Services applications. These applications aim to achieve loose coupling between the client and the server. Services expose complex functionality and allow clients to access the service from a local or remote machine. Service operations are called
using Extensible Markup Language (XML)–based message schemas passed over a transport mechanism.
- Web applications. These applications typically support connected scenarios, and are developed to support multiple browsers and multiple operating system platforms.
Choosing Application Types
Choose the appropriate application type by considering your requirements and the infrastructure limitations. Use the table below to make an informed choice based on the benefits and considerations for each application type.
Table 1 Application type considerations
||Can support handheld devices.
||Input and navigation limitations
||Provide availability and ease of use for out
||Limited screen display area
||Can support offline and occasionally
|Rich Client Applications
||Can leverage client resources.
||Deployment complexity; however, a range of installation options are available, such as ClickOnce, Windows Installer, and XCOPY
||Provide better responsiveness, rich UI functionality, and improved user experience.
||Can be challenging to version over time
||Provide highly dynamic and responsive interaction.
||Can support offline and occasionally connected applications.
|Rich Internet Applications (RIA)
||Provide the same rich UI capability as rich clients.
||Larger application footprint on the client machine compared to a Web application
||Provide support for rich media and graphics display.
||Restrictions on leveraging client resources compared to a rich client application
||Simple deployment and the distribution capabilities (reach) of Web clients.
||Requires deployment of the .NET or Microsoft Silverlight® run time on the client
||Provide loosely coupled interactions between client and server.
||No UI support
||Can be consumed by different and unrelated applications.
||Client is dependent on network connectivity
||Has broad reach, and a standards-based UI across multiple platforms.
||Dependency on network connectivity (must be connected all of the time)
||Offers ease of deployment and change management.
||Difficulty in providing a rich UI
When you design your application architecture, you must take into account corporate policies and procedures, together with the infrastructure on which you plan to deploy your application. If the target environment is fixed or inflexible, your application design
must reflect restrictions that exist in that environment. Your application design must also take into account Quality-of-Service (QoS) attributes such as security and maintainability. Sometimes you must make design tradeoffs due to protocol restrictions and
Identify the requirements and constraints that exist between the application architecture and infrastructure architecture early in the design process. This helps you to choose an appropriate deployment topology and to resolve conflicts between the application
and infrastructure architecture early in the process.
Distributed and Non-distributed Architectures
Applications are typically deployed in one of two ways: non-distributed deployment
, where all of the functionality and layers reside on a single server except for data storage functionality; or
, where the layers of the application reside on separate physical tiers. In most cases, the recommendation is to use non-distributed deployment. Whenever a process must cross physical boundaries, performance is affected because
the data must be serialized. However, there are some cases where you need to split functionality across servers. In addition, depending on where servers are located, you can often choose communication protocols that are optimized for performance.
With the non-distributed architecture, presentation, business, and data access code are logically separated but are physically located in a single server process. Figure 2 illustrates the non-distributed scenario.
Figure 2 Non-distributed deployment
- Non-distributed architecture is less complex than distributed architecture.
- Non-distributed architecture has performance advantages gained through local calls.
- With non-distributed architecture, it is difficult to share business logic with other applications.
- With non-distributed architecture, server resources are shared across layers. This can be good or bad. Layers may work well together and result in optimized usage because one of them is always busy. However, if one layer requires disproportionately more
resources, another layer may be starved of resources.
Distributed deployment allows you to separate the layers of an application on different physical tiers. Figure 3 illustrates the distributed scenario.
Figure 3 Distributed deployment
- Distributed architecture has the ability to scale out and load-balance business logic independently.
- Distributed architecture has separate server resources that are available for separate layers.
- Distributed architecture is flexible.
- Distributed architecture has additional serialization and network latency overheads due to remote calls.
- Distributed architecture is potentially more complex and more expensive in terms of total cost of ownership (TCO).
An architecture style is a set of principles. You can think of it as a coarse-grained pattern that provides an abstract framework for a family of systems. Each style defines a set of rules that specify the kinds of components you can use to assemble a system,
the kinds of relationships used in their assembly, constraints on the way they are assembled, and assumptions about the meaning of how you put them together. An architecture style improves partitioning and promotes design reuse by providing solutions to frequently
There are many factors that influence the architecture styles that you follow. These include the capacity of your organization for design and implementation, the capabilities and experience of developers, and the infrastructure constraints and available deployment
You will typically combine multiple styles to define a complete architecture. For example, a layered architecture can be used with component-based, object-oriented, or service-oriented architecture styles. The following are some points to consider when choosing
Architecture Style Frame
Architecture styles can be organized by their key focus area. The following table lists the major areas of focus and the corresponding architecture styles.
Table 2 Architecture style frame
||Client/server, 3-tier, N-tier
||Component-Based, Object-Oriented, Layered Architecture, Model-View-Controller (MVC)
||Domain Model, Gateway
||Service-Oriented Architecture (SOA), Message Bus, Pipes and Filters
These styles are not exclusive, and you will often choose multiple overlapping styles to suit your architectural needs. For example, you might design using object-oriented code principles, organize as a layered architecture, use the Domain model for data access,
communicate with services using SOA, and deploy using an N-tier style.
Key Architecture Styles
The following table lists common architecture styles, along with a brief description of each style or pattern. Later sections provide more detailed descriptions of each style, as well as guidance to help you choose the appropriate style for your application.
Table 3 Architecture styles
||Segregates the system into two computer programs where one program, the client, makes a service request to another program, the server.
||Decomposes application design into reusable functional or logical components that are location-transparent and expose well-defined communication interfaces.
||Partitions the concerns of the application into stacked groups (layers).
||Is a software system that can receive and send messages that are based on a set of known formats, so that systems can communicate with each other without needing to know the actual recipient.
||Separates the logic for managing user interaction from the UI view and from the data with which the user works.
|N-tier / 3-tier
||Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.
||A programming style based on division of tasks for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to that object.
|Service-Oriented Architecture (SOA)
||Represents applications that expose and consume functionality as a service using contracts and messages.
You will typically combine multiple styles to define a complete architecture. For example, a layered architecture can be used with component-based, object-oriented, or SOA styles. Consider the following points when choosing architecture styles.
Consider the client/server architecture style if:
- Your application is server-based and will support many clients.
- You are creating Web-based applications exposed through a Web browser.
- You are implementing business processes that will be used by people throughout the organization.
- You want to centralize data storage, backup, and management functions.
- Your application must support different client types and different devices.
Consider the component-based** architecture style if:
- You already have suitable components, or can obtain suitable components from third-party suppliers.
- Your application will predominantly execute procedural style functions, perhaps with little or no data input.
- Your application is relatively simple, and does not warrant a full layered architecture.
- Your application has specific requirements that do not include a UI or business processes.
- You want to be able to combine components written in different code languages.
- You want to create a pluggable architecture that allows you to easily replace and update individual components.
Consider the layered architecture style if:
- Your application is complex, and you want to mitigate that complexity by grouping functionality into different areas of concern.
- You want to improve the maintainability and extensibility of the application, by minimizing dependencies.
- You already have applications that expose suitable business processes through service interfaces.
- Your application must support different client types and different devices.
- You want to implement complex and/or configurable business rules and processes.
Consider the message-bus architecture style if:
Model-View-Controller (MVC) Architectural Style
- You have existing applications that interoperate with each other to perform tasks.
- You are implementing a task that requires interaction with external applications.
- You are implementing a task that requires interaction with applications hosted in a different environment.
- You have existing applications that perform specific tasks, and you want to combine those tasks into a single operation.
- You want to perform operations asynchronously, such as order processing or workflow.
- You are implementing a publisher/subscriber application.
Consider the Model-View-Controller architectural style if:
3-Tier/N-Tier Architectural Style
- You want improved testability and simpler maintenance of UI functionality.
- You want to separate the task of creating the UI from the logic code that drives it.
- Your UI view does not contain any request-processing code.
- Your UI processing code does not implement any business logic.
Consider either the N-tier or the 3-tier architectural style if:
- The processing requirements of the layers in the application differ. Processing in one layer could absorb sufficient resources to slow the processing in other layers.
- The security requirements of the layers in the application may differ. For example, the presentation layer will not store sensitive data, while this may be stored in the business and data layers.
- You want to be able to share business logic between applications.
- You have sufficient hardware to allocate the required number of servers to each tier.
Consider the 3-tier architectural style if:
- You are developing an intranet application where all servers are located within the private network.
- You are developing an Internet application, and security requirements do not restrict implementing business logic within the public-facing Web or application server.
Consider using more than three tiers if:
- Security requirements dictate that business logic cannot be deployed to the perimeter network.
- The application makes heavy use of resources and you want to offload that functionality to another server
Consider the object-oriented architecture style if:
- You want to model the application based on real-world objects and actions.
- You already have suitable objects and classes that match the design and operational requirements.
- You need to encapsulate logic and data together in reusable components.
Consider the service-oriented architecture style if:
- You have access to suitable services or can purchase suitable services exposed by a hosting company.
- You want to build applications that compose a variety of services into a single UI.
- You are creating Software plus Service (S+S), Software as a Service (SaaS), or cloud-based applications.
- You need to support message-based communication between segments of the application.
- You need to expose functionality in a platform-independent way.
- You want to take advantage of federated services, such as authentication.
- You want to expose services that are discoverable through directories and can be used by clients that have no prior knowledge of the interfaces.
When choosing technologies for your application, the key factors to consider are the type of application you are developing, and your preferred options for application deployment topology and architectural styles. The choice of technologies will also be governed
by organization policies, infrastructure limitations, resource skills, and so on. For example, if you are building an SOA-style application, then Windows Communication Foundation (WCF) is a good choice. If you are building a Web application that will make
calls into a WCF service, then ASP.NET is a good choice. Your technology choice is directly tied to your application type.
Consider the following questions:
- Which technologies help you support your chosen architectural styles?
- Which technologies help you support your application type?
- Which technologies help you support key quality attributes for your application?
The following presentation-layer technologies are available for creating mobile applications:
- .NET Compact Framework. You can use the .NET Compact Framework to create a rich client mobile application that supports connected or occasionally connected scenarios.
- ASP.NET mobile controls. You can use ASP.NET mobile controls to create a thin client mobile application. ASP.NET mobile controls is a set of server-side controls and special page classes that render output specific to the type of device accessing
- Silverlight. You can use Silverlight for Mobile Devices to provide rich media support and an improved user experience.
The following presentation-layer technologies are available for creating rich client applications:
- Windows Forms. You can use Windows Forms to create applications that provide rich functionality and user experience by utilizing the resources of the client PC.
- Windows Forms with WPF user controls. You can use Windows Presentation Foundation (WPF) user controls in Windows Forms applications to provide enhanced rich graphical support within the UI.
- WPF. You can use WPF to create a rich client application with UI support for 2-D and 3-D graphics as well as animations and media (both video and audio). WPF also includes a two-way data-binding engine.
- XAML Browser Application (XBAP) using WPF. You can create an XBAP that provides all the features of the stand-alone WPF application but is hosted in a browser.
Rich Internet Client (RIA)
The following presentation layer technologies are available for creating rich Internet applications:
- Silverlight. You can use Silverlight to create applications that provide a rich user experience that includes graphics, audio, and video.
The following technologies are available for creating Web applications:
- ASP.NET Web Forms. You can use ASP.NET Web Forms with a wide range of server controls that render HTML in Web browsers.
- ASP.NET Web Forms with AJAX. You can use AJAX in your ASP.NET Web Forms application to improve the user experience by reducing the number of postbacks required.
- ASP.NET Web Forms with Silverlight controls. You can use Silverlight controls in your ASP.NET Web application to provide a rich user experience and support media streaming.
- ASP.NET MVC. You can use ASP.NET MVC to create Web applications with built-in support for the Model-View-Controller (MVC) design pattern. MVC simplifies developing, modifying, and testing the individual components within the application.
- ASP.NET Dynamic Data. You can use ASP.NET Dynamic Data to create functional data-driven Web applications based on a LINQ to SQL or Entity Framework data model.
The following technologies are available for creating service applications:
- Windows Communication Foundation (WCF). When possible, use WCF to create services n order to benefit from maximum feature availability and interoperability.
- ASP.NET Web services (ASMX). Use ASMX for simplicity, and only when a suitable Web server will be available.
Whiteboard Your Architecture
It is important that you are able to whiteboard your architecture. Whether or not you share your whiteboard on paper, slides, or other visuals, the key is to show the major constraints and decisions in order to frame and start the conversations.
Figure 4 Example of an architecture whiteboard
Step 4: Key Hotspots
Identify the hotspots in your application architecture to understand the areas where mistakes are most likely to be made. Key hotspots can be organized around quality attributes and cross-cutting concerns.
The architecture frame represents cross-cutting concerns that will impact your design across layers and tiers. These are also the areas in which high-impact design mistakes are most often made. Use the architecture frame to identify hotspots in your design
that require additional attention to get right.
You can use the following architecture frame to identify cross cutting concerns in your design.
Table 4 Architecture frame
|Authentication and Authorization
||How to choose an authentication strategy
||How to choose an authorization strategy
||How to flow identity across layers and tiers
||How to store user identities when not using the Microsoft Active Directory® directory service
|Caching and State
||How to choose an appropriate caching technology
||How to determine what data to cache
||How to determine where to cache the data
||How to determine the expiration policy
||How to choose appropriate protocols for communication across layers and tiers
||How to design loose coupling across layers
||How to perform asynchronous communication
||How to pass sensitive data
||How to choose a composition pattern for the UI)
||How to avoid dependencies between modules in the UI
||How to handle communication between modules in the UI
|Concurrency and Transactions
||How to handle concurrency between threads
||How to choose between optimistic and pessimistic concurrency
||How to handle distributed transactions
||How to handle long-running transactions
||How to determine what information needs to be configurable
||How to determine where and how to store configuration information
||How to protect sensitive configuration information
||How to handle configuration information in a farm/cluster
|Coupling and Cohesion
||How to choose an appropriate layering strategy for separation of concerns
||How to design highly cohesive components and group them within layers
||How to determine when loose coupling is appropriate between components within a layer
||How to manage database connections
||How to handle exceptions
||How to improve performance
||How to handle binary large objects (BLOBs)
||How to handle exceptions
||How to log exceptions
||How to provide notification when required
|Logging and Instrumentation
||How to determine which information to log
||How to make the logging configurable
||How to determine what level of instrumentation is required
||How to improve task efficiency and effectiveness
||How to improve responsiveness
||How to improve user empowerment
||How to improve look and feel
||How to determine where and how to perform validation
||How to validate for length, range, format, and type
||How to constrain and reject input
||How to sanitize output
||How to choose the appropriate workflow technology
||How to handle concurrency issues within a workflow
||How to handle task failure within a workflow
||How to orchestrate processes within a workflow
are the cross-cutting concerns that affect run-time performance, system design, and user experience. Quality attributes are important for the overall usability, performance, reliability, and security of software applications. The quality
of the application is measured by the extent to which the application possesses a desired combination of these quality attributes. When designing applications to meet any of these requirements, it is necessary to consider the impact on other requirements.
You need to analyze the tradeoffs between multiple quality attributes. The importance or priority of each quality attribute differs from system to system; for example, in a line-of-business (LOB) system, performance, scalability, security, and usability will
be more important than interoperability, while in a packaged application, interoperability will be very important.
Quality attributes represent areas of concern that have the potential for application-wide impact across layers and tiers. Some attributes are related to the overall system design, while others are specific to run-time, design-time, or user-centric issues.
Use the following table to help you organize your thinking about the quality attributes, and to understand which scenarios they are most likely to affect.
Table 5 Quality attributes
||User Experience / Usability
Quality Attribute Frame
The following table describes the quality attributes covered in this chapter. You can use this table to understand what each of the quality attributes means in terms of your application design.
Table 6 Quality attribute frame
||Availability defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. Availability will be affected by system errors, infrastructure problems, malicious
attacks, and system load.
||Conceptual integrity defines the consistency and coherence of the overall design. This includes the way that components or modules are designed, as well as factors such as coding style and variable naming.
||Flexibility is the ability of a system to adapt to varying environments and situations, and to cope with changes to business policies and rules. A flexible system is one that is easy to reconfigure or adapt in response to different user and system requirements.
||Interoperability is the ability of diverse components of a system or different systems to operate successfully by exchanging information, often by using services. An interoperable system makes it easier to exchange and reuse information internally as well
||Maintainability is the ability of a system to undergo changes to its components, services, features, and interfaces as may be required when adding or changing the functionality, fixing errors, and meeting new business requirements.
||Manageability defines how easy it is to manage the application, usually through sufficient and useful instrumentation exposed for use in monitoring systems and for debugging and performance tuning.
||Performance is an indication of the responsiveness of a system to execute any action within a given time interval. It can be measured in terms of latency or throughput.
Latency is the time taken to respond to any event. Throughput is the number of events that take place within given amount of time.
||Reliability is the ability of a system to remain operational over time. Reliability is measured as the probability that a system will not fail to perform its intended functions over a specified time interval.
||Reusability defines the capability for components and subsystems to be suitable for use in other applications and in other scenarios. Reusability minimizes the duplication of components and also the implementation time.
||Scalability is the ability of a system to function well when there are changes to the load or demand. Typically, the system will be able to be extended over more powerful or more numerous servers as demand and load increase.
||Security defines the ways that a system is protected from disclosure or loss of information, and the possibility of a successful malicious attack. A secure system aims to protect assets and prevent unauthorized modification of information.
||Supportability defines how easy it is for operators, developers, and users to understand and use the application, and how easy it is to resolve errors when the system fails to work correctly.
||Testability is a measure of how easy it is to create test criteria for the system and its components, and to execute these tests to determine if the criteria are met. Good testability makes it more likely that faults in a system can be isolated in a timely
and effective manner.
||Usability defines how well the application meets the requirements of the user and consumer by being intuitive, easy to localize and globalize, able to provide good access for disabled users, and able to provide a good overall user experience.
Each quality attribute can be expanded into its own frame to cover the areas where mistakes are most often made. For example, the security frames define a set of pattern-based categories that organize repeatable problems and solutions. You can use these categories
to divide your application architecture for further analysis, and to help you identify application vulnerabilities. The categories within the frame represent the critical areas where mistakes are most often made.
Table 7 Security frame
||Description / questions
|Auditing and Logging
||Who did what and when? Auditing and logging refer to how your application records security-related events.
||Who are you? Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a username and password.
||What can you do? Authorization refers to how your application provides access controls for resources and operations.
||Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings protected? Configuration management refers to how your application handles these operations and issues.
||How are you handling secrets (confidentiality)? How are you tamper-proofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality
||When a method call in your application fails, what does your application do? How much information do you reveal? Do you return friendly information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?
Exception management refers to how you handle exceptions within your application.
|Input and Data Validation
||How do you know that the input your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing. Consider constraining input through entry points and encoding output
through exit points. Do you trust data sources such as databases and file shares?
||How does your application handle sensitive data? Does your application protect confidential user and application data? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent
||How does your application handle and protect user sessions? A session refers to a session of related interactions between a user and your Web application.
You can then use the security frame to determine key security design decisions for your application.
Figure 5 Typical Web application security architecture.
Step 5: Candidate Solutions
After you define the key hotspots, you can create your first high-level design and then start to fill in the details to produce a candidate architecture. You then move back to Step 2 of the process to validate the candidate solution design against the key scenarios
and requirements you have defined, before iteratively following the cycle and improving the design.
are a design prototype you use to determine the feasibility of a specific design path. Use architectural spikes to reduce your risk and quickly determine the viability of different approaches. Test architectural spikes against key
scenarios and hotspots.
Consider the following guidelines when creating your architectural spikes:
- Understand your key risks and adapt your design to reduce these risks.
- Optimize your deliverables for effective and efficient communication of design information.
- Build your architecture with flexibility and refactoring in mind. You might need to modify your architecture a number of times, so optimize around this possibility.
What to Do Next
After you complete the architecture-modeling activity, you can begin to refine the design, plan tests, and communicate the design to others. Keep in mind the following guidelines:
- If you capture your candidate architectures and architectural test cases in a document, keep the document lightweight and avoid over-formatting so that you can easily update it. Include the following key content in the document:
- Your objectives
- Application type
- Deployment topology
- Key scenarios and requirements
- Quality attributes
- Use the quality attributes to help shape your design and implementation. For example, developers should be aware of anti-patterns related to the identified architectural risks, and use the patterns to help address the issues.
- Use the architectural frame to plan and scope your architectural tests.
- Communicate the information you capture to relevant team members. This may include your application development team, your test team, and your network and system administrators.
Reviewing Your Architecture
Reviewing the architecture for your application is a critically important task in order to reduce the cost of mistakes and find and fix architectural problems as early as possible. Architecture review is a proven, cost-effective way of reducing project costs
and the chances of an architectural failure. Create your architecture to make it as easy as possible to communicate and review. Build your architecture with common review questions in mind, both to improve your architecture and to reduce the time required
for each review.
The main goal of an architecture review is to verify that the architecture correctly links the functional requirements and the quality attributes with the proposed technical solution. Additionally, it helps you to identify issues and areas of improvement.
Scenario-based evaluations are a powerful method for reviewing an architecture design. In a scenario-based evaluation, the focus is on the scenarios that are most important from the business perspective, and which have the greatest impact on the architecture.
Consider using one of the following common review methodologies:
- Software Architecture Analysis Method (SAAM). SAAM was originally designed for assessing modifiability, but later was extended for reviewing architecture with respect to quality attributes such as modifiability, portability, extensibility, integratibility,
and functional coverage. SAAM is also used to review the performance and reliability aspect of the architecture.
- Architecture Tradeoff Analysis Method (ATAM). ATAM is a refined and improved version of SAAM that helps you review architectural decisions with respect to the quality attributes requirements, and how well they satisfy particular quality goals.
- Active Design Review (ADR). This architecture review technique is best suited for incomplete or in-progress architectures. The main difference is that the review is more focused on a set of issues or individual sections of the architecture at a time,
rather than performing a general review.
- Active Reviews of Intermediate Designs (ARID). This architecture review technique combines the ADR aspect of reviewing in-progress architecture with a focus on a set of issues, and the ATAM and SAAM approach of scenario-based review focused on quality
- Cost Benefit Analysis Method (CBAM).** This architecture review technique focuses on analyzing the costs, benefits, and schedule implications of architectural decisions.
- Architecture Level Modifiability Analysis (ALMA). This architecture review technique evaluates the modifiability of architecture for business information systems (BIS).
- Family Architecture Assessment Method (FAAM). This architecture review technique evaluates information system family architectures for interoperability and extensibility.
Communicating Your Architecture Design
After your architecture design is complete, you must communicate the design to the other stakeholders. These stakeholders will include the development team, system administrators and operators, business owners, and other interested parties. There are several
well-known methods for describing architecture to others, including the following:
- 4+1. This approach uses five views of the complete architecture. Four of the views describe the architecture from different approaches: the logical view (such as the object model), the process view (such as concurrency and synchronization aspects),
the physical view (the map of the software layers and functions onto the distributed hardware infrastructure), and the development view. A fifth view shows the scenarios and use cases for the software. This allows stakeholders to see the aspects of the architecture
that specifically interest them.
- Architecture Description Language (ADL).** This approach is used to describe software architecture prior to system implementation. It addresses the following concerns: behavior, protocol, and connector. Behavior corresponds to the types, hierarchies,
properties, and rules. Protocol corresponds to the communicating entities and rules. Connector corresponds to the connections, interface, and constraints that exist between components in an object-oriented system. ADL is designed to be both human- and machine-readable.
Therefore, ADL has both the textual form and a formally defined syntactic and semantic form. The main advantage of ADL is that you can analyze the architecture for completeness, consistency, ambiguity, and performance before formally beginning use of the design.
- Agile Modeling.** This approach follows the concept that “content is more important than representation.” This ensures that the models created are simple and easy to understand, sufficiently accurate, detailed, and consistent. Agile model documents
target specific customer(s) and fulfill the work efforts of that customer. Each agile model document is designed to fulfill a specific purpose, and the way it is expressed can vary. A class diagram, problem statement, use case diagram, sequence flow, and other
approaches can be used to express an agile model document. The simplicity of the document ensures that there is active participation of stakeholders in the modeling of the artifact.
- IEEE 1471.** IEEE 1471 is the short name for a standard formally known as ANSI/IEEE 1471-2000, “Recommended Practice for Architecture Description of Software-Intensive Systems.” IEEE 1471 enhances the content of an architectural description, in particular
giving specific meaning to context, views, and viewpoints. Context corresponds to the stakeholders of the system (such as clients and vendors) and their specific concerns (such as reliability and security). The view corresponds to the system concerns, and
the viewpoint corresponds to conditions on the completeness, well-formedness, and analyzability of views. IEEE 1471 allows the document to be formulated by using existing ADLs, or from within the framework it provides. IEEE 1471 also allows UML diagrams (see
below) to be used as viewpoints.
- Unified Modeling Language (UML).** This approach represents three views of a system model. The functional requirements view (functional requirements of the system from the point of view of the user, including use cases); the static structural
view (objects, attributes, relationships, and operations including class diagrams); and the dynamic behavior view (collaboration among objects and changes to the internal state of objects, including includes sequence, activity, and state diagrams).