Chapter 4

It Starts with Architecture

A doctor can bury his mistakes but an architect can only advise his clients to plant vines.

—Frank Lloyd Wright, U.S. architect

When constructing a house, nobody would ever consider not buying materials and tools and hiring resources as the first steps of the building process. Yet, too often in the world of IT we see teams rush to the development phase without a clear vision of what the business and technical requirements are. With cloud computing, the need for a pragmatic approach is even more critical because the risks are greater as more control is shifted to cloud service providers. Whether a company has an official enterprise architecture practice in place or not, success in the cloud is dependent on applying the basics of sound architectural principles and asking these six questions: Why, Who, What, Where, When, and How.

The Importance of Why, Who, What, Where, When, and How

There have been philosophical debates for decades on the value of enterprise architecture (EA). Architecting for the cloud does not require that an official EA organization exists within a company or that any formal EA methodology like The Open Group Architecture Framework (TOGAF) or the Zachman Framework is used. However, architects should perform the necessary discovery steps that most methodologies suggest before diving headfirst into the clouds. A mistake that many companies make is picking a vendor before doing their due diligence. It is easy for a Microsoft shop to automatically default to Microsoft’s Azure even though Platform as a Service (PaaS) might not be the best service model to solve the business challenge. Architects should seek answers to the following questions:

The final question to ask is often overlooked, even though it is one of the most important questions. This question focuses on the current state of the organization and its ability to adapt to the changes that cloud computing brings.

After collecting the information for these questions, architects are in a better position to select the best service model(s) and deployment model(s) for their company. In Chapter 5, “Choosing the Right Cloud Service Model,” we will see how factors like time, budget, and organizational readiness can impact the cloud service model decisions just as much as the business and technical requirements. Other factors that can contribute to the cloud service model and deployment model decisions are whether the project is a greenfield effort being built from scratch from the ground up, a migration of a legacy system, or a combination of the two. Legacy systems can create barriers that make it difficult to use certain cloud service models and deployment models. There are many cloud service providers that offer migration services that should be evaluated if a cloud migration is considered.

The types of users and data have an impact on the cloud architecture, as well. For example, a social networking website where consumers opt in and agree to share their data has very different requirements from a health application capturing and storing medical records for cancer patients. The latter has many more constraints, risks, and regulatory requirements that most likely will result in a very different cloud architecture from the social network platform. We will discuss these decision points in detail in the next chapter.

Start with the Business Architecture

A good first step when starting a major cloud initiative is to create a business architecture diagram. This is important because it provides insights into the various touchpoints and business functions across the enterprise or at least across the part of the enterprise that is in scope for the initiative.

AEA Case Study: Business Architecture Viewpoint

Our fictitious online auction company, Acme eAuctions (AEA), is considering moving its auction platform to the cloud. Its original platform was built in-house several years ago, before cloud computing was a popular concept. AEA has been very successful over the years, but the platform is showing its age and the company is spending too much money just keeping the platform stable, leaving very little time to deliver enhancements such as mobile, social, and rich media functionality. AEA has received approval from the board to build a new platform and believes that leveraging the cloud can help it achieve scale at a lower price point while delivering with greater speed to market. Before diving into the new platform, AEA wisely mapped out its future state business architecture as shown in Figure 4.1.

Figure 4.1 Business Architecture

Using this diagram, the team can see the various points of integration and endpoints within the architecture. Across the top of the diagram, AEA clearly defines who the external actors are in the system and the different touchpoints that users will use to interact with the system. All external access will come through the application programming interface (API) layer. AEA has defined six core business processes that make up the workflow of a product, from its inception to the sale to the close of the transaction. Underneath the business processes are a collection of services. There are services in support of the buyers and another set of services for the sellers. Underneath those services are a collection of shared business services that are used by both buyers and sellers. Underneath those services are utility services such as security, events, and notifications. The bottom layer shows integration points to several other enterprise systems that this platform will feed.

---

Even though the first phase of the project may only focus on a single component of the architecture, it is important to understand how that component fits into the entire business architecture. Too often we build things with a limited view of the enterprise and wind up deploying solutions that are difficult to integrate within the enterprise. It is like planning to install a door in the front entrance with a limited understanding of what the rest of the house looks like. Sure, we can successfully install the door within the doorframe, but what if the door opens out and we did not know that another worker was putting a screen door in front of the door? It doesn’t matter if the screen door is getting installed now or a year from now; either way we would have to replace the original door to open in. The same applies to building cloud services. The architects should have some level of visibility into the overall vision of the enterprise before they start installing doors.

Identify the Problem Statement (Why)

The question, “What problem are we trying to solve?” (the why) is the single most important question to answer. What are the business drivers for leveraging cloud computing services within an organization? The answer is different for every company, every culture, and every architecture. For example, for start-ups, building new in the cloud is a no-brainer. In fact, if a start-up decides to build and manage its own infrastructure, it better have a very compelling reason for selecting physical infrastructure and data centers over cloud computing, because most venture capitalists (VC) and angel investors will question the management team’s leadership.

On the other side of the equation are large established enterprises with huge amounts of physical infrastructure on the balance sheets and many different technology stacks and legacy architectures deployed in production environments. Figuring out how to best leverage cloud services is a much more complicated decision to make in enterprises. If one of the business drivers is to “reduce IT infrastructure costs,” a start-up can easily achieve that goal by building its greenfield applications in the cloud without investing in data centers and infrastructure and all the people to manage them. An established enterprise will have to evaluate every single component of the existing enterprise separately to determine what can be moved to the cloud and which deployment model (public, private, hybrid) makes sense for each component.

A large organization may choose to reduce costs many different ways and leverage different service models. For example, it may be supporting numerous commercial software products to manage noncore competency business processes like payroll, human resources tasks, accounting, and so forth. The organization may decide to replace these solutions with Software as a Service (SaaS) solutions. At the same time it may not be as easy to migrate legacy applications to a PaaS or an Infrastructure as a Service (IaaS) cloud provider because the underlying architecture does not support web-based or stateless architectures and the cost of rearchitecting makes it unfeasible. Instead, the organization may choose to leverage the cloud for specific purposes like backup and recovery, provisioning testing and development environments on demand, or integrating with an external API for a specific set of data (maps, Zip code lookups, credit check, etc.). Every piece of the overall architecture should be evaluated independently to ensure that the optimal cloud service and deployment models are selected. With the exception of greenfield start-ups, rarely does it make sense to select one cloud service model and one deployment model. Use a hammer when you have nails and a screwdriver when you have screws.

Evaluate User Characteristics (Who)

The who question identifies the users of the system, both internal and external. Users may be people or systems. Identifying the actors helps discover what organizations (internal and external) interact with the overall system. Each actor within a system may have its own unique needs. It is possible that one cloud service model does not meet the needs of every actor.

Once the actors are identified, it is important to understand the characteristics of these actors, such as demographics (age group, how tech savvy they are, what countries they are in, etc.), type of actor (person, business, government, etc.), type of business (social media, health, manufacturing, etc.), and so forth. The who question uncovers numerous functional and nonfuntional requirements. In the case of cloud computing, actor characteristics drive important design considerations in the areas of privacy, regulations, usability, risk, and more.

Identify Business and Technical Requirements (What)

The what question drives the discovery of many functional and nonfunctional requirements. Functional requirements describe how the system, application, or service should function. Functional requirements describe the following:

• What data the system must process.
• How the screens should operate.
• How the workflow operates.
• What the outputs of the system are.
• Who has access to each part of the system.
• What regulations must be adhered to.

Nonfunctional requirements describe how the architecture functions. The following list contains the categories of nonfunctional requirements that should be evaluated to assist in selecting the appropriate cloud service and deployment models:

• Usability. Requirements for end users and systems that use the platform.
• Performance. Ability to respond to user and system requests.
• Flexibility. Ability to change at the speed of business with minimal code changes.
• Capability. Ability to perform business functions both current and future.
• Security. Requirements around security, privacy, and compliance.
• Traceability. Requirements around logging, auditing, notifications, and event processing.
• Reusability. Level of reuse required both internally and externally.
• Integrability. Ability to integrate with various systems and technologies.
• Standardization. Specific industry standards to comply with.
• Scalability. Ability to scale to meet demands of the business.
• Portability. Capability to deploy on various hardware and software platforms.
• Reliability. Required uptime and SLAs, along with recovery mechanisms.

Visualize the Service Consumer Experience (Where)

A good building architect would never build a plan for a house if he had no idea where the house was going to be located, how big the lot is, what the zoning restrictions are, what the climate is like, and all of those constraints that come with the location of the building. For example, in Florida, much of the architecture of a house focuses on withstanding high winds during hurricane season and extreme heat during the summer. The architecture for a new house in Toronto will likely avoid the design costs associated with withstanding hurricane-force winds but instead focus more on holding up to cold temperatures and distributing heat evenly throughout the structure.

With cloud computing, it is critical to understand the impact of laws as they relate to the locale where the cloud services are being consumed and where the data is being stored. Laws and regulations have different constraints across countries, provinces, states, and even counties. For example, in the couponing industry, marketing campaigns focusing on tobacco, alcohol, and even dairy must comply with laws against promoting these categories within certain counties.

The 2013 Global Cloud Computing Report Card, published by Business Software Alliance (BSA), stated, “Cloud services operate across national boundaries, and their success depends on access to regional and global markets. Restrictive policies that create actual or potential trade barriers will slow the evolution of cloud computing.” Some countries, like Japan, have modernized their legislation around privacy law, criminal law, and IP protection to facilitate the digital economy and cloud computing. On the other end of the spectrum are countries, like China, that have complex laws that discriminate against foreign technology companies and restrict the types of data that can flow in and out of the country. Countries that have restrictions on data transfers outside of their country create challenges for technology companies trying to build cloud solutions.

Perhaps one of the most controversial laws impacting cloud computing is the USA Patriot Act of 2001. The Patriot Act was signed into law shortly after the 9/11 terrorist attacks on the World Trade Center in New York City. This new legislation gave the U.S. law enforcement and intelligence agencies the ability to inspect digital data from any U.S. company or any company that conducts business in the United States. Many non-U.S. countries storing sensitive data fear that the U.S. government might seize their data and therefore choose to store their data in-house and opt out of the cloud. What many people don’t know is that many countries have similar laws that give their intelligence agencies the same type of power and access that the Patriot Act has in order to help protect against terrorism.

Architects need to become familiar with the laws and regulations that pertain to their business and their data. The impact of these laws can influence decisions like public versus private cloud, cloud versus noncloud, and local vendor versus international vendor. Often, hybrid cloud solutions are used to address these concerns. Companies often leverage public IaaS or PaaS service models for the majority of their processing needs and keep the data they do not want subject to seizure under laws like the Patriot Act in a private cloud or in an in-house noncloud data center.

A more exciting where question is: What devices and touchpoints are these cloud services being accessed by? Today’s users consume data through channels on many touchpoints. We consume information on the web, on mobile devices and tablets, with scanners, and with medical devices, to name a few. Even our cars, refrigerators, home security systems, and almost anything with an IP address can interact with end users in this day and age. Knowing up front what all of these touchpoints are can drive some important decisions.

SaaS vendors like Apigee, Mashery, and Layer 7 Technologies provide cloud services for building APIs to publish to third parties. These SaaS tools provide security, transformation, routing, web and mobile analytics, and many other important services that allow the developers to focus on their business requirements. Like the mobile PaaS tools, the API SaaS tools increase the developers’ speed to market and reduce maintenance because the vendors take care of supporting new technologies, standards, and patterns. For example, if a new device becomes popular or a change is made to a standard like OAuth, the mobile PaaS and API SaaS vendors update their products, allowing the developers to focus on their business needs.

Identify the Project Constraints (When and with What)

It is important to understand the budget and the expected delivery dates. Time may be a critical factor in choosing cloud service models. If there is a business reason to implement a new CRM solution in the next month, then leveraging a SaaS solution is probably the only way to meet that time constraint. Sometimes dates are artificially assigned. How many times have we seen projects with a January 1 due date? Usually there is no business driver for this date other than somebody is assigned a goal and objective to deliver a project by year-end. But other times dates are critical to the business. For example, a business that generates most of its revenues before the Thanksgiving and Christmas holidays may have an urgent need to deliver a new product or service or improve the overall system performance before the traffic peaks. In either case, the date is critical to the business’s bottom line. Regardless of whether the time constraint is real or artificial, it is a constraint that must be taken into consideration when making architecture decisions. Sometimes what is best for the architecture is not best for the business. It is critical that all architecture decisions are made with business goals in mind first and foremost.

There may be other constraints that impact the cloud service and deployment models. Management or customers may create artificial constraints. For example, they may dictate, without performing the proper due diligence, that all public cloud options are off-limits. Whether that decision is good or bad, it is a constraint that can be accounted for and the focus can shift to private cloud and SaaS solutions. A company might decide it wants to drastically reduce its infrastructure footprint and reduce the number of its data centers. In this case, architects should look at public cloud options as well as SaaS and PaaS options. Another scenario may be that there is a mandate to use a certain vendor. Whatever the constraints are, it is important to identify them up front before major decisions are made.

Understand Current State Constraints (How)

Organizational readiness is the main theme when asking the how questions. Does the company have the skills in-house? Are accounting and finance willing and able to shift from a capital expenditure (buying up front) model to an operational expenditure (pay-as-you-go) model? What is the mind-set of the culture? Are they resisisting the change? Are they capable of change?

Organizational change management is critical to the success of any transformational change initiative within a company. Whether a company is trying to implement a new business strategy, a new development methodology, or adopt new technologies, there is always the element of organizational change that must be addressed. In many cases, the change is more challenging than the new technology or the new strategy that is being implemented.

People need to understand why change is necessary and how that change will improve things in the future. John Kotter, the author of numerous books on organizational change management, categorized the following eight errors common to organizational change efforts:

A common mistake that I have seen through the years is that companies often neglect to involve human resources (HR) in the process. New initiatives often require a change in behaviors, but if the HR processes still reward the old behaviors and do nothing to encourage the new desired behaviors, then there are no incentives for employees to change.

Companies that have a long legacy of building and deploying on-premises systems are likely to experience resistance within the ranks. No matter how good the IT team may be when it comes to building software, without buy-in throughout the organization, delivering in the cloud will be a challenge. Don’t forget to address the how question.

Summary

As with implementing any technology, it is highly recommended to focus first on defining the architecture before rushing to decisions on vendors and cloud service models. It is important that the technology decisions are driven mainly from business drivers rather than technology preferences. Ask the who, what, why, where, when, and how questions early in the project so that informed decisions can be made about cloud service models and deployment models. Understand the constraints, both artificial and real, up front before decisions are made. By no way does this recommendation dictate the process in which an organization answers these questions. On the surface it might sound like I am recommending a waterfall approach, which I am not. Agile practitioners can work these discovery tasks into their sprints in any fashion that they like. The point is that these discovery questions should be asked and the answers should have an impact on the design decisions and ultimately the overall architecture.

References

Kendall, K., and J. Kendall (2003). Systems Analysis and Design, 6th ed. Upper Saddle River, NJ: Pearson Prentice Hall.

Kotter, John P. (1996). Leading Change. Boston: Harvard Business School Press.

Ross, J., P. Weill, and D. Robertson (2006). Enterprise Architecture as a Strategy: Creating a Foundation for Business Execution. Boston: Harvard Business School Press.

Ross, J., Weill, P. (2004). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Boston: Harvard Business School Press.

Schekkerman, Jaap. (2008). Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice. Victoria, BC, Canada: Trafford Publishing.

Galexa Consulting. (2013). “BSA Global Cloud Computing Scorecard: A Blueprint for Economic Opportunity.” Retrieved from http://portal.bsa.org/cloudscorecard2012/assets/PDFs/BSA_GlobalCloudScorecard.pdf.

Whittaker, Z. (2012, December 4). “Patriot Act Can Obtain Data in Europe, Researchers Say.” Retrieved from http://www.cbsnews.com/8301–205_162–57556674/patriot-act-can-obtain-data-in-europe-researchers-say/.