The role of enterprise architecture (EA) was already touched upon in the previous chapters. As stated in Chapter 2, the enterprise architecture team is an absolutely essential group to help guide the adoption and governance of all things “cloud.” It is an essential part of the broker function discussed in Chapters 4 and 5. It has to make sure that different cloud services will be adopted in a coherent and well-integrated fashion. In this chapter we will further explain the role of enterprise architecture. We will make the point that without EA, cloud computing is expected to have a negative effect on costs and agility. We will also dive into what makes up an EA practice and we will introduce dynamic enterprise architecture as an effective way to manage architecture in an organization. As a good EA practice depends heavily on people, we will discuss some of the dilemma’s these people have to deal with such as continuously balancing the short and long term effects of any change. Finally we will discuss some EA-deliverables such as principles, reference models and patterns that can be of great help in making decisions as to what might be candidates for cloud services and what would definitively not be.
Cloud computing is more than just infrastructure. It’s a way of obtaining anything as a service, whether it’s software, data or infrastructure, from different kinds of providers via the Internet. In this context, a service is a reusable component: a piece that supports a business process executed by the business to create value.
Cloud computing is a very attractive model for users. It’s quite easy for them to purchase services. The big value of enterprise architecture in this context is that the total landscape of services and solutions of an organization remains or becomes well integrated. Enterprise architecture is the discipline that guides the organization towards a coherent and well-integrated set of services and solutions—not just technology, but also business processes and applications. If you don’t pay attention to EA, a couple of years from now your corporate data may be spread across many places, your company may be relying on way too many unreliable partners, the whole conglomerate of internal and external IT may have become impossible to change and the expected benefits of the cloud will have turned into a liability. If you are serious about adopting cloud computing, it requires a long-term vision and strategy: moving into the cloud is not a short-term visit, but a long-term structured journey.
The expected effect of EA on the adoption of cloud computing is shown in the Figures 6.1 and 6.2. Though not scientific, these figures are based on our many years of experience with EA and the adoption of other technologies and models such as SOA. The graphs show an effect that we expect to happen with cloud too: agility and lower cost of ownership in the long run do not happen automatically.
Figure 6.1 demonstrates the expected impact on agility of adopting cloud computing in two scenarios: one with EA and one without EA. If cloud computing is adopted without attention to coherence and integration, agility may improve in the very short term, but unfortunately it will deteriorate. Agility deteriorates because of the ever-increasing complexity of the landscape, because of services that are not integrated, and because of the increasing difficulties of switching from one cloud provider to another. On the other hand, if cloud computing is adopted within an EA context, agility improves dramatically over time. The effect will even be bigger if you already have a well-established EA practice.
Figure 6.1: Effect of EA on agility when adopting cloud computing
The expected effect on costs (of running IT) is visualized in Figure 6.2. By applying cloud computing, the costs of running IT (operations and maintenance) are likely to decrease dramatically. If users are allowed to buy whatever cloud services they like, without looking out for coherence and integration, the effect can be even bigger in the short term. But after some time, the IT costs will start to rise dramatically, due to the increasing complexity and difficulty of changing services and solutions. If cloud computing is adopted in a structured fashion where the EA team sets the principles and standards for cloud adoption, the cost of running IT will also start to decrease, but in a steady and prolonged fashion.
Figure 6.2: Effect of EA on IT costs after adopting cloud computing
It might be clear from the foregoing that EA is geared to the long term by providing principles, standards and patterns for integration and coherence. But what should an effective EA team look like in the cloud era? Self-provisioning users want support, guidance and training rather than policing by a policy department.
The EA team in the organization should become supportive and proactive, famous for saying “yes” instead of “no” and for accelerating the business and coming up with business ideas.
How to make EA more supportive and pro-active? Figure 6.3 contains a model where EA is positioned as a support process instead of an autonomous process that is not aligned with the rest of the organization. Doing enterprise architecture like the model suggests ensures the integration and coherence of cloud initiatives, on the one hand, while on the other hand it guarantees that architects are involved from the beginning, in the strategic dialogue where they can help the organization take the right steps to the cloud at the right moment. The architects are thus being supportive and proactive instead of hindering and reactive.
Figure 6.3: DYA model
DYA is a set of best practices to achieve an effective enterprise architecture (Wagter 2005; Berg and Steenbergen 2006).
At the heart of DYA is the DYA model that consists of four (sub-)processes covering the entire process of change, from strategy formation to realization:
| • | Strategic dialogue—through which the business goals are established and elaborated into concrete project proposals by means of business cases. The business goals are discussed in a dialogue between business and IT. |
| • | Architectural services—the processes in which the architecture is formulated and then made available for the strategic dialogue and development with architecture. |
| • | Development with architecture—in which the business goals are achieved within the stipulated time frames and in accordance with the anticipated quality and costs—in the DYA process, development with architecture is the standard. |
| • | Development without architecture—a deliberate choice in special circumstances, perhaps involving extreme time pressure, to deviate from the architectural framework. |
In this model, architectural services (such as the development and maintenance of architecture) clearly constitute a support process. Architecture is not a goal in itself, but a tool for managing the changes formulated in the strategic dialogue and realized in development with(out) architecture. It aligns these changes so they can best serve the business goals of the organization. Because the DYA model clearly identifies the key factors involved in architectural practices, it has been adopted by many organizations.
Using the DYA model as a basis for doing EA in the cloud era tells us:
| • | Cloud computing is not a goal but a means to achieve a business objective. Cloud computing is a model that can function as an enabler. The advantages and opportunities of cloud computing must be discussed in the strategic dialogue. The role of EA in the strategic dialogue is to improve decision making by creating scenarios for cloud adoption. It’s not the enterprise architect who makes the decision but business (and IT) management. Enterprise architects combine knowledge of current business (and IT) structures with business objectives and IT possibilities to guide the organization in the right direction. |
| • | Cloud computing is implemented using the “just in time, just enough” principle, as this is driven by the organizational business objectives. DYA provides a model in which the business objectives drive the cloud implementation and not the other way around. |
| • | Since EA is involved in the change from the beginning, it can create principles, standards and patterns for cloud adoption in an early phase. This allows EA to help projects in an early stage instead of arriving too late and trying to correct missteps, thereby being perceived as hindering the development. The so-called project start architecture (PSA) has turned out to be a great tool in helping projects in an early stage to apply the right EA principles and standards (Luijpers 2009). |
| • | Within this model, EA principles and standards are created only when there is a business objective that needs architecture. This minimizes the risk that EA will produce an ivory tower fortified against the implementation of cloud computing. |
| • | There is the flexibility to embark on a cloud computing project without architecture, but there needs to be proper consideration of the fact that the deployed cloud services will need to be brought within architecture at a later stage. Of course this should not be the default scenario. |
The following six statements can be used to see whether you already have an effective EA practice in place that is capable of helping to adopt cloud computing. These checks are founded on the DYA model. For each statement, indicate if you agree. Use a scale from 1 (“I don’t agree at all”) to 5 (“I fully agree”). After scoring all statements, check your total below.
| # | Statement | 1 to 5 |
|---|---|---|
| 1 | Our EA team has a significant impact on our IT investment portfolio | |
| 2 | Our EA is described in a concise set of principles, standards and patterns (instead of thousands of pages of blueprints) | |
| 3 | Our EA team is recognized by business (and IT) leaders for providing clear guidance from the very outset of change | |
| 4 | Our EA team succeeded in reducing complexity significantly | |
| 5 | The way we incorporate anything as a service is part of our EA | |
| 6 | All our projects comply with EA | |
| Your total score |
Table 6.1: Assess the effectiveness of your enterprise architecture practice
| • | You have 6-14 points: you may have some short-term success using stand-alone cloud services, but in the long run it is very likely that you will run into integration problems that will prove costly. You are not in the right position to achieve a coherent and integrated set of services. Consider how to build an effective EA practice. |
| • | You have 15-24 points: you may have some success using cloud services in limited areas, but the long-term risks of running into integration problems are still high. You are on the right track with your EA practice, but there is still room for improvement. Addressing the remaining steps will help you to achieve a coherent and integrated set of services. |
| • | You have 25-30 points: you are in an excellent position to take full advantage of the opportunities cloud computing provides. You are in the best position to achieve a coherent and integrated set of services. Give your EA practice a leading role in exploring the cloud. |
Organizations are becoming increasingly complex. They have become more and more connected and are operating in a very volatile world. The number of new options that cloud computing is offering will make it even more complex. The EA practice has to deal with this complexity and find ways to cope with it. This requires the EA practice to be composed of people who have the ability to understand the drivers for this complexity and who can explain to senior management what the options are in for example interacting with customers or designing the operations process. Enterprise architects have to be able to handle tough dilemma’s, like balancing the short term effect against the long term effect, the opportunistic versus the structural. Although well-integrated solutions might be everybody’s wish, in some circumstances a point solution might be the best choice. In all cases the enterprise architect should be able to explain the consequences and guide the organization to help achieve its objectives in a coherent and integrated way while at the same time coping with its complexity.
Another important role for an EA practice in the cloud era is to scan the market for cloud services. This market research role fits into the broker function of an internal IT department. By playing this role enterprise architects can proactively engage with the business to help them benefit from the opportunities cloud computing offers instead of waiting for initiatives elsewhere in the organization. This will help them to become famous for saying “yes” instead of notorious for saying “no”.
Here are the main requirements for an effective enterprise architect:
| • | Excellent communication skills. |
| • | Highly creative. |
| • | Skills to both analyze and synthesize. |
| • | Ability to separate the “what” from the “how.” In other words, has the skills to design services from a function point of view instead of a construction point of view. |
| • | Sound understanding of business drivers, objectives and processes. |
| • | Sound understanding of the latest IT trends and developments. |
| • | Sound understanding of the organization’s IT landscape. |
| • | Ability to create a vision. |
| • | Ability to connect a vision with measurable business benefits and costs. |
| • | Ability to think outside-in instead of inside-out. |
| • | Leadership. |
| • | Proactive instead of reactive attitude. |
It will be nearly impossible to find all of these in one person. But in a team, these skills and abilities can and must be present.
Architecture principles are a widely accepted starting point for describing enterprise architecture. Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. They define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future (IT) decisions (The Open Group 2009). Similarly, architecture principles provide an excellent starting point in the case of cloud computing. They can be used to decide on and communicate the future place of cloud services in the organization. Principles can also be used to point out the strategic advantages to adopting cloud computing.
| Name: | Cloud First | ||||
|---|---|---|---|---|---|
| Statement: | If sourcing decisions will be made about non critical services, cloud computing is the first option to consider | ||||
| Rationale: |
|
||||
| Implications: |
|
| Name: | Design anything as a service | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Statement: | Our business and IT is designed in terms of services | ||||||||
| Rationale: |
|
||||||||
| Implications: |
|
| Name: | Commoditize business services unless | ||||||
|---|---|---|---|---|---|---|---|
| Statement: | IT will commoditize business services to a large extent unless the business has a business case not to do so | ||||||
| Rationale: |
|
||||||
| Implications: |
|
Principles, standards and patterns are at the heart of enterprise architecture and important EA artefacts to guide cloud adoption. Reference models can also add value in cloud adoption. These models can be used to decide which components could be deployed in the cloud and which could not. A reference model is not a design to strive for but a model for basing decisions upon. It functions as a map for cloud adoption. In the case of cloud computing, it is important to create a reference model that is composed in a service-oriented way. That makes it easier to discover available services somewhere in the cloud that match the required services. A reference model is broad in scope and encompasses more than the cloud: it can be used as a roadmap for service adoption irrespective of the source of these services.
The risk of creating reference models is that enterprise architects can get lost in their models. Be careful to create these models only when there is clear objective. Providing guidance for cloud adoption is such a reason.
Below we will introduce two different approaches that you can use to create reference models. One is based on capability modeling and the other on essential modeling. You will see that there are differences, but also that the approaches can be complementary.
In this section three different reference models will be discussed:
| 1. | Business reference model |
| 2. | Application reference model |
| 3. | Application area reference model |
Business reference model
This model is the foundation and starting point for architecture reference modeling. The most valuable type of model for cloud and SOA is the capability model (Berg et al. 2007). Figure 6.4 shows the basic structure of such a model.
Figure 6.4: Business reference model
The value chain perspective is important for putting the business processes into a context. The next step is to divide the value chain into relevant business processes or domains. Next, divide those business processes into capabilities. Capabilities say on a high level what a business does.
The model is not a detailed distinct process model, but a model with components that can be used to build real business process scenarios. The idea of capability modeling is to provide a structure that promotes future business agility. If IT solutions are built on detailed processes they will (sooner or later) hinder strategic business changes. If they are built on capabilities, they will support and enable changes.
The business reference model should be used in all business development discussions. This helps to steer towards the cloud and fuels a dialogue based on SOA. It also creates a common language and view of the future business. When designing this model it is necessary to involve business stakeholders. This in itself is an opportunity for the architects to strengthen the relationship and build trust within the business.
The most comprehensive and proven support for business capability modelling is the Component Business Model (CBM) from IBM. CBM also consists of ready-made industry models open for reuse.
Application reference model
The first very tangible value from a cloud perspective comes when the application reference model is defined. This reference model consists of application areas, which are a set of large application components. It is useful for finding software services in the cloud that match these components. Figure 6.5 contains a simple example that shows the modeling principle.
Figure 6.5: Example of an application reference model
Once the business reference model is established, the task is to sort the capabilities into application areas. It may seem easy, but don’t take it too casually. This is a very important foundation for all forthcoming cloud architectural work. If the division is wrong, you may end up in a situation where there are no services available in the cloud that match with the defined application areas, or even no standard products available at all. The idea is that the areas, as far as possible without destroying the business model, shall match services and applications available on the market, while fulfilling the strategic IT goals.
In the example above, two typical application areas are derived from the business model: Product Lifecycle Management (PLM) and Customer Relationship Management (CRM). The connection with the business model is important because it clarifies once and for all which business functions are supported by which application areas.
Another interesting aspect when working with business and application reference models is that common service areas may come to surface. In the example above, sourcing is a potential common service. Common means that it may be used in more than one business process. Sourcing is a capability under product management in the figure above, but it will also be a capability in new product supply, after market management and plant maintenance processes. As a common service, sourcing is a possible cloud service.
Application area reference model
The application reference model consists of application areas, which are further detailed in application area reference models. The important thing about these models is that they clearly show the information and services perspectives. Figure 6.6 is an example of what to aim for.
Figure 6.6: Application area reference model for CRM
Figure 6.6 demonstrates:
| • | What business capabilities the application area shall support, or in other words, what basic functionality it shall contain. |
| • | What key data the application needs to be able to handle autonomously (application data model). An application area can be the master of certain data objects. |
| • | The information interface describes the needed information flows in and out from the application area. Information flows are of two main types: information flows connected to more or less automated business processes (process services) and information services that are related to real-time demand-response behavior. |
| • | Common services are services that are shared by many application areas. In the CRM example above, a common service from Dun & Bradstreet (DnB) for cleaning customer data is a typical example. |
Application area reference models of the style described above are very useful in cloud assessments. When analyzing the use of an application as a service, the functional and information context is sufficiently clear. The requirements for integration can easily be derived. The information interfaces and common services may also be interesting to analyze from a cloud perspective. To buy one enterprise service from DnB instead of many locally agreed services is very likely a business case. One global health care provider used a cloud-provided information service for transformation to and from the global HL7 standard format. That’s another tangible example of using cloud for a small service in the daily operations.
Application area reference models are also very valuable tools when working with standardization and consolidation efforts around the application map within an enterprise. The models are the structure to aim for, and the information interfaces are the first level to achieve in the standardization roadmap. If an enterprise has many different systems supporting one application area, the first step is to harmonize the information interfaces. The second step is to replace the applications. This is a simple strategy to achieve as seamless a transformation as possible. When the interfaces are standardized, it naturally opens up the question about the application area as a cloud service.
The next approach is based on modeling the essential processes of an organization.
The term “cloud services” implies service orientation. Service orientation requires thinking in services, not just in shaping IT, but fundamentally and more importantly, in shaping the business. This shaping should be done in such a way that requisite supporting services are identified and defined in the resulting (business) model. In these reference models it is still undecided whether a particular service will be obtained from the cloud or in some other way.
Thinking in services also requires overview and insight to be able to define a consistent and coherent set of services, at an appropriate level of granularity: at the business level. The total set of services required in a specific business context must be clearly identified and for each identified service it should be clear how, why and when it is used, from a business perspective.
Business processes are key in shaping the business of an organization. However, the commonly used process models are based on flowcharts with lots of operational details. These models are not very well suited for shaping the organization. Instead we prefer to view the processes at the essential level as a basis for service orientation and for many other purposes such as controlling and steering an organization or doing impact analyses before starting projects.
The notion of essential processes and its contribution to using cloud services in an effective way is explained below using a simple example. Essential processes do not replace existing (operational) processes, but represent a view of these processes based on what is essential for doing business. Essential processes also provide structure and coherence across all relevant processes, which is too often absent, and are by nature a “coat rack” for the more detailed processes (the coats). Essential processes focus on the use of business processes as a steering aid for management.
Imagine a simple Online Book Store. The essential model for this book store starts with its rationale for existence: there are customers who want to buy books over the Internet.
Figure 6.7: Essential model
In order to get the book to the customer, the Online Book Store needs to do business with other “parties” (business domains). In this case the business domains are the book distributor (where the books are in stock) and the delivering party (which could be part of the Online Book Store or some third party). Also, the customer needs to pay before the book will be delivered (Figure 6.8).
Figure 6.8: Essential model including business domains
The model basically shows the accountable business domains involved in handling the customer request and the way these domains work together.
Doing business is indicated by the transaction symbol: the customer needs something, the supplier provides it (or not) and the customer accepts the result (or not).
In addition to being connected through transactions, parties can also be connected by the exchange of information. When looking into the “essentials” of a transaction (such as buying books) information requirements pop up (for example, the need to register customer information). This in turn identifies the need for an information object (customer), which will also be used by the delivering party to obtain the delivery address (Figure 6.9).
Figure 6.9: Essential model including information objects
These elements (business domains, business transactions and business information objects) to a large extent shape the essential business processes. There is more to the concept of essential processes, but for the purpose of this example the above is sufficient to illustrate its use in relation to cloud services:
| 1. | Each transaction by nature is a business service: one party needs something and the other provides it (and the transaction defines how business is done). |
| 2. | Each link (dotted arrow) to an information object also indicates a business (information) service: the nature of the service (e.g. register name, address and bank account number of a customer) is defined in the arrow. |
The set of services appearing in all essential process models of the enterprise is a perfect starting point for acquiring these services, whether via the cloud or otherwise (Noorman 2006).
As can be seen above different approaches can be followed to create reference models. Essential modeling might be the right approach when working from the outside. Capability modeling works better if the perspective is from the inside. When analyzing opportunities for the cloud, both approaches can be used next to another: the outside-in approach to derive the right set of (future) services, the inside-out approach to discover which current systems and services to migrate to the cloud.
On the journey to obtain services from the cloud, it is very important to know what functionality is required by those services, with what quality and how these services fit in an organization’s landscape as a whole. However, it is often seen that foremost and most attention is paid to the (technical) construction of services. This is encouraged by many cloud providers, who have put their proposition in technical terms, combined with service-level characteristics. Of course, at a certain point in time during the integration of cloud services, the way the services are technically constructed becomes important. At least in order to safeguard reliability, consistency, interoperability and user friendliness, to name a few aspects.
But before focusing on the “how” of cloud and the many (different) propositions that are offered from the many corners of the cloud, a concise architectural overview of the organization’s landscape is indispensable as a compass on the cloud journey. It facilitates the identification and classification of functional components and patterns that deliver business services and, as such, are present in the IT landscape. On an architectural level, functions and patterns are technologically “agnostic” and therefore very stable. They are independent of the current and even future way of implementation. This means that these functions and patterns stay the same in a “cloud world.” Of course, obtaining a service from the cloud might lead to a more important role for integration functions (like identity and permission validation). But essentially, these functions and patterns stay the same. This is especially valid for infrastructure or technical architecture, but is not limited to these architecture domains. This way of working is also recommended in the areas of business and information architecture in order to determine what might be deployed in the cloud and what should definitely not be. This was illustrated in the previous chapter.
What is a pattern?
A pattern is a typical and repeatable way a solution is commonly provided or a problem fixed. Patterns exist at several levels of abstraction, from architecture to engineering and construction. At the architectural level, sheer functionality is targeted, defined in such a way that it is technologically agnostic. A pattern consists of a combination of functions that together provide a solution. In fact, the whole IT landscape could be regarded as a pattern. For practical reasons, this pattern is divided into sub-patterns that are interrelated. Each sub-pattern describes a part of the landscape that offers some (recognizable) sort of solution. An example of an infrastructure architecture (sub-) pattern is given below:
Application hosting pattern type
Definition
The pattern type application hosting describes the architectural layout of solutions that accommodate applications by providing a runtime environment and a set of additional facilities that support the execution and integration of applications in the IT landscape.
Graphical overview
Figure 6.10: Pattern type application hosting—ArchiMate visualization
Composition
This pattern type is made up of the primary building block types listed in Table 6.2.
| Building Block Type | Purpose | Character |
|---|---|---|
| Application Platform | Provides a runtime environment for application code, by means of system resources and a library of standard routines. | Mandatory |
| Permission Validation | Checks user permissions regarding access and usage of application parts and/or data. | Optional |
| Presentation | Delivers output of applications towards application clients (screen handling), and handles input from those clients (most commonly by keyboard and mouse). | Optional |
| Web | Delivers handling of application input and output in the form of webpages. | Optional |
| Load Balancing | Distributes client connections between separate instances of the same application. This kind of functionality can be applied during data transport or be carried out by these application instances themselves. | Optional |
Table 6.2: Building block types for pattern application hosting
The adjacent pattern types listed in Table 6.3 provide facilities that realize the integration of application hosting within the IT landscape.
| Adjacent Pattern Type | Building Block Types | Purpose |
|---|---|---|
| Data Management | Data Collection Management | Organization and logical deposition of application data. |
| Centralized Data Storage | Physical storage of application data on a centralized facility. When used by application hosting, in many cases the physical storage is not in use by the application itself, but by the data collection management facility. | |
| Data Transport | Network Access | Access to data transport resources to all systems/platforms that are involved in providing facilities of the pattern type application hosting. |
| Load Balancing | Distributes client connections between separate instances of the same application. This kind of functionality can be applied during data transport or be carried out by these application instances themselves. | |
| Access and Usage Control (optional) | Identity Validation | Checks if provided identity claims (for example, logon names that identify a certain user, together with passwords or other types of credentials) can be validated against stored credentials. |
| Application Orchestration (optional) | Distributed Transaction Management | Direction of data processing that is being carried out by more than one application (instance). |
| Application Task Management | Directs at what time and/or in what order an application should process tasks. | |
| Service Repository | Automated overview of, and pointers towards, (external) application routines. |
Table 6.3: Adjacent pattern types for pattern application hosting
All patterns at the architectural level of abstraction are formed by a combination of typical, technology agnostic functions. A complete collection of generic definitions of infrastructure functions and patterns of this type can be found at Sogeti’s DYA Infrastructure Repository (see Sogeti in the Reference section of this book).
Based on a functional overview of an organization’s landscape, the cloud journey can be planned responsibly. It is possible to determine which functions, in which usage context, are feasible candidates to obtain from the cloud. Clearly, it will be easier to find a very common application hosting service than a very specific scientific computing solution. And although it makes sense to give standard office workers access to office automation solutions by means of a web server, it might not be a good idea to try to provide a check-in kiosk at an airport by means of cloud services. So, to be sure that you get the right services from the cloud, you should first examine what functionality is needed, with what desired quality, and then start looking for feasible solutions. What used to be good practice on occasion needs to become the norm as more and more possible solutions are deliverable from the cloud. And by discussing functionality over technology every stakeholder can play a part in the discourse.
An enterprise architecture practice is invaluable in successfully adopting a service-oriented approach and therefore also in adopting cloud computing. When cloud computing is adopted without EA the risk is high that costs will increase over time and that agility will deteriorate rather than improve. Cloud computing, as any IT element, requires integration and coherency. This is the main task for EA and has everything to do with helping the organization cope with its complexity. Cloud computing also offers an opportunity for EA’s. When they take on the market research role for cloud services, they can proactively help the organization to quickly adopt the most business valuable cloud services.
In order to be successful EA must be implemented in a dynamic fashion, populated with the right set of skills, designed with a concise set of principles and reference models, and focused on the function of services instead of the construction. Capability modeling and essential modeling are powerful ways to discover the right set of services as a starting point to research the market for providers of these services. Design patterns are very useful in searching the right cloud services because they focus on the function of IT instead of the construction.
If done right, enterprise architecture will help to overcome cloud barriers like integration. However, there are other cloud barriers to overcome. These will be discussed in the next chapter.