Designing for Accessibility

Depending on the processing a system performs, a designer may need to create an interface that maximizes user access or may have to lock down the system and control when users can access specific features. For a public solution, such as a consumer website, maximizing user access not only makes great marketing sense, but it also may be required by law (see the Americans with Disabilities Act website at www.ada.gov). In contrast, for a secure site, controlling user access can range from ensuring the security of the login process, to some type of biometric user authentication.

Designing for Audit

Chapter 15, “Governing the Cloud,” examined the cloud’s impact upon the IT governance process. As you design a cloud-based solution, you must first identify critical processing points at which you will want to place an internal control to confirm that the solution’s processing is correct and free from outside manipulation. You may design such controls to be active, meaning the code may generate a processing exception should unexpected results occur, or the control may be passive, possibly logging events to a file or saving snapshots of data.

In either case, it is important that you identify your audit processing needs early so that the appropriate controls can be integrated into the implementation process and you can discuss and confirm your processing needs with a potential cloud-solution provider.

Designing for High Availability

Most cloud-solution providers, within their service-level agreements (SLA), will guarantee the system availability, normally with a percentage of uptime, such as 99.9 percent. For most applications, 99.9 percent uptime is acceptable (99.9 percent uptime means that the system is down 0.1 percent of the time, or 525 minutes each year). It is important that you identify your system’s uptime requirement and then, likely through the use of redundant collocated servers, design a solution that meets your needs.

Designing for Backup

With the myriad of inexpensive high-capacity data-storage solutions available within the cloud, loss of user data should not occur. If you are designing your own solution, you must consider not only ways to back up your data (and databases), but also the impact of each method on your system availability, should you need to bring down the system to restore a backup.

Designing redundant data-storage solutions will always involve a cost versus risk trade-off. The issue is not whether you back up data—data backups should be a given, always. The issue is aligning acceptable risk mitigation with cost.

If you are designing a solution for which a third party (such as an SaaS provider) will manage your data, you need to understand the company’s backup policies and procedures, and even then you will probably still want to integrate your own.

Designing for Existing and Future Capacity

Chapter 19, “Application Scalability,” examines the capacity planning process. If you are moving an existing on-site solution to the cloud, you should monitor the application closely to fully understand its processing attributes, such as user demand, CPU utilization, RAM use, and data-storage consumption. Knowing your system’s current resource use, you can better guess (it is difficult to predict system demand accurately), your system’s cloud resource needs.

And with this knowledge, you can design for scalability—the ease of integrating additional computing resources. You will learn about scalability in Chapter 19. There are two primary ways you can scale an application. First, you can scale the application up (called vertical scaling) by moving the application to a faster, more powerful processor. Second, you can scale an application out (called horizontal scaling) by distributing different tasks across different servers. As you design a solution, you should identify opportunities to leverage horizontal scaling. At a minimum, you should design your solution in such a way that you do not restrict future horizontal scaling potential.

Designing for Configuration Management

Ideally, cloud-based solutions may be used at any time, from any place, with any device. In practice, however, this means that developers must consider a variety of operating systems, browsers, and device-specific graphical-user interfaces. Operating systems and browsers often require patches to address security issues, and, eventually, each will face new version releases. If you are designing your own solution, you will want to layer configuration solutions on top of your system. In this way, you will reduce the impact to a computer-based user when changes are made to a handheld device interface or vice versa.

If your system design includes the use of a SaaS provider, you need to know that company’s patch management and versioning policies and procedures.

Designing for Deployment

Chapter 8, “Virtualization,” examined ways that desktop virtualization is changing how solutions are delivered. From an operating system on demand, to thin-client (browser-based) solutions, developers have a myriad of ways to deploy a system. As you design a solution, you should identify each potential user type and its environment attributes (such as operating system, device type, and browser). Then, you need to consider not only how you will deploy the initial solution to the user, but also how you will deploy system upgrades.

Designing for Disaster Recovery

Chapter 10, “Disaster Recovery and Business Continuity and the Cloud,” examined considerations for reducing the risk from a disaster and increasing the likelihood that a business is able to continue operating after such an event. When designing a solution with respect to disaster recovery and business continuity, you must balance risks and costs. It is likely impossible and unnecessary to protect a system from all potential events. Instead, you must determine each event’s likelihood and business impact and then seek to provide an affordable solution that mitigates risks. Fortunately, the cloud’s affordable and distributable resources provide developers with considerable flexibility.

Designing for thev Environment (Green Computing)

Green computing describes environmentally friendly IT operations. For example, replacing an application that prints reams of paper reports with a browser-based performance dashboard is an example of a green-computing initiative. As you have learned, within a data center, the biggest environmental impact is the power consumption to drive devices and air conditioners. As more companies migrate to PaaS and IaaS providers, many smaller (and possibly less efficient) data centers are being accumulated into larger, state-of-the-art facilities.

As the capabilities of cloud-based collaboration tools continue to increase, travel for face-to-face meetings will decrease, resulting in a lower, business-related carbon footprint. That said, as solutions are made available any place, any time, and from any device, the net result is a huge number of handheld devices that are never powered off.

As green-computing practices continue to emerge, designers will be pressured to consider the environmental impact of their designs.

Designing for Interoperability

Cloud-based solutions are emerging for a wide range of applications. Whereas just a few years ago, a company might have used one cloud-based solution for a customer relationship management (CRM) requirement, or a solution for an human resources application, today, many companies use a wide range of cloud-based solutions. To simplify the user interaction with such solutions, many companies strive to integrate the solutions and often, even to share data across solutions. In the past, companies would buy and install middleware software to facilitate the exchange of data between solutions. Today, cloud-based middleware solutions let companies tie together two cloud-based solutions, often without the need for programming development.

As you design cloud-based solutions or when you work with an SaaS provider, consider ways you may need to integrate data between applications and then design accordingly.

Designing for Maintainability

Designing and building software solutions is an expensive process. Usually, the most-costly phase of the software development life cycle is the system maintenance phase. To maximize code reuse and to increase code maintainability, software engineers are taught to create highly functional (cohesive) and independent (loosely coupled) software modules. Chapter 12, “Cloud-Based Service-Oriented Architecture,” discussed the role of cloud-based web services to make solutions readily available to a variety of applications. By decomposing an application into highly cohesive, loosely coupled modules and then deploying those solutions to applications such as web services, developers not only increase component reuse, but also make the resulting systems easier to maintain by centralizing key processing as a distributed solution.

If you are using a SaaS solution, you need to keep the long-term nature of your relationship in mind. Many people argue that cloud solutions are initially inexpensive, but they may cost you more in the long run.

Designing for Performance

Speed matters. Across the cloud, you can find a myriad of companies that will monitor your system performance and will estimate a percentage of users who will leave your site if the pages do not load within 2 to 3 seconds. As you design the performance aspects of your solution, first you need to identify the 20 percent of your system that will be used 80 percent of the time. Then, you need to focus your initial performance optimizations there. Chapter 19, “Application Scalability,” looks at ways you can scale a solution to meet user demand. Designing for performance and designing for scalability are two different issues. Designing for performance means optimizing what you have. Designing for scalability means designing for the future integration of additional computing resources. The following are some ways that you can design for performance:

• Reduce the use of graphics on key pages.

• Optimize the graphics file format for all images.

• Compress large text blocks before downloading the text to a browser.

• Utilize data and application caching.

• Fine-tune disk and database input-output operations.

• Reduce, when possible, network operations.

• Fine-tune secure data communication transactions.

As you design solutions, evaluate your solutions for potential bottlenecks as well as for optimization points. Understand that you may not have, due to time or budget constraints, the ability to optimize everything.

Designing for Price

Budgets are a fact of life. As you design, you must be aware that your design decisions have financial implications. A solution that was inexpensive to deploy may prove costly to maintain or vice versa. Just as you would consider the performance or security aspects of each component you design, you must also consider each component’s short-term and long-term budget impact.

Designing for Privacy

As discussed throughout this book, many users are not comfortable with the idea of putting their data in the cloud. Cloud-based solutions must protect a user’s data privacy. If you are developing a healthcare solution with HIPAA requirements, an education solution with FERPA requirements, or an e-commerce solution that stores credit card information, you will need to design your solution in a way that protects data not only from external access, but also from internal users, such as developers and administrators.

Most designers understand the importance of backing up user data and replicating key databases. It is important to note, however, that each data backup creates a potential opportunity for a user, administrator, or hacker to gain access to the data.

Designing for Portability

Portability is a measure of the ease of which a solution can be moved, typically, from one platform to another. Ideally, you should design your system so that you can easily move the solution from one cloud provider to another. Many developers argue that by using open-source tools to create an application, you increase the application’s portability. In reality, within the cloud, developers using .Net will find many hosting opportunities beyond Microsoft—it’s a big cloud and solution providers want to service all developers. If you are designing your own solutions, be aware that using a provider-specific application program interface (API), which may not be available through other providers, may create a form of vendor lock-in. Likewise, if you use a SaaS provider, be aware that each unique or custom capability integrated into your solution may bind you to that provider.

Designing for Recovery

We have discussed the need to design a solution to support disaster recovery and business continuity needs. Additionally, you should design your solution with consideration for how you will recover from more common events, such as server failure, user error, power outages, and so on. Your recovery design should tie closely to your backup design and your system redundancy design.

Designing for Reliability

Computing devices (disks, servers, routers, and so on) will eventually fail. You have learned that many devices have an associated mean time between failures (MTBF) attribute that you can use to estimate the device’s potential life expectancy. As you design your solutions, you must identify potential signal points of failure and then design potential system redundancy or establish an acceptable system downtime.

Designing for Response Time

When you design a solution, you should keep the user experience in mind. As discussed, users are conditioned to expect fast system response. In fact, a large percentage of users will leave a site if they must wait more than a few seconds for pages to download and display. As you design a solution, you need to consider not only the page download times, but also the system response time after a user performs an operation, such as submitting a form. Across the cloud, companies specialize in testing the user experience. These companies will evaluate a system from different geographic locations, using different connection speeds, and with a variety of browsers. Your response time design efforts may be closely related to your site’s capacity plan design.

Designing for Robustness

Robustness is a measure of a site’s ability to continue operations in the event of an error or system failure, such as a server failure or database error. Again, as you design, you should strive to identify and eliminate single points of failure. Furthermore, you should consider automating a system resource utilization monitor that alerts administrators before a system’s resources become critically low.

Designing for Security

Chapter 9, “Securing the Cloud,” looks at a variety of cloud-based security issues developers must consider. Following are some the security issues that developers must consider:

• Software patch installations and software version management

• Human resource vetting of cloud-based personnel

• Early awareness of security incidents and appropriate responses

• Data privacy issues and considerations

• Jurisdictional issues for a remote cloud-service provider

• Multitenant solution issues

• Cloud-provider failure or collapse

• Defense mechanisms for common low-level network attacks

• Data wiping for shared-storage space

• Physical security considerations

For each component you design, you must evaluate the component’s potential security exposure. Again, in some cases, you will need to balance risk and cost.

Designing for Testability

Cloud-based solutions will likely have a large number of functional and nonfunctional requirements. As you design a solution, you need to keep in mind how you will test various aspects of your design. As you might guess, the system’s nonfunctional requirements are often the most difficult to test. Depending on a system component’s purpose and functionality, some developers will use a methodology called test-driven design by which they first design and implement one or more test cases, and then, build a solution that can satisfy the test.

Designing for Usability

A system, to be of use, must be usable. Usability, in the world of IT, is understood as a measure of a system’s ease of use. As you design a solution, you must keep the user foremost in your mind. Because of the importance of meeting system usability requirements, many designers will model or create a prototype of the user experience so they can receive user feedback early in the design process.