Throughout this book, we have seen that adopting cloud computing is not only a technological change, but that it has a far-reaching impact. Signposts like business technology, new ways of (self) provisioning and the importance of enterprise architecture can be found throughout the previous chapters. In this final chapter, we’ll survey and add directions and concrete suggestions that will help you take the next step. The chapter will help you build your roadmap to the cloud.
Of course, the one universal roadmap for cloud computing does not exist. The exact steps you will take all depend on your organization, your goals and, to a lesser extent, on your current technology. Even the order in which to take the steps may be different from organization to organization. One might choose to start with server virtualization as a step to more responsive IT, where another might jump ahead by signing up for Salesforce.com. Some might choose to quickly embrace cloud as the default option, while others will use it sparingly where risks are low and return almost immediate.
As long as the considerations around cloud computing remain abstract, it is very hard to define any action or even quantify its real value. Early on, you should make an effort to discuss some specific applications of cloud computing, cloud services or even the separate concepts that make up cloud. For example, you could examine virtualization or chargeback on its own, to see if it makes business sense to adopt it. Or you could look into the specific opportunities for embracing web-based email. At the same time, keep an eye on the bigger transformation towards cloud that is taking place, too.
When cloud computing is embraced in its entirety, there will be new initiatives across the whole organization: there will be activities to change IT, activities to bring change to the business side and, most of all, there will be changes to the interaction and collaboration between business and IT.
Figure 9.1: Changes due to cloud computing
In the ideal world, you would take steps towards cloud computing in all areas simultaneously, right from the start. Ideally, business and technology will work closely together to craft a new way of leveraging technology in business. It is the best way to build the readiness and skills needed. More flexible IT without a business process to apply it will not produce the desired business agility. Or, vice versa, business users who are self-provisioning their IT from the cloud but do not interact with the IT team will ultimately run into trouble. Reality in your organization may dictate that one of these areas has to be addressed first, but activities in the other areas should follow shortly thereafter.
Figure 9.2: Business changes due to cloud computing
As discussed in Chapter 3, information technology is changing into business technology. In organizations that fully realize the role and importance of IT, the business side of the organization takes control and is becoming more tech savvy. This does not happen automatically, and requires the initiation of some new processes or one-time activities.
The activities that help the business adopt cloud computing are:
It is quite possible that there is already rogue cloud IT in the organization. For example, users may have found an online tool that suits their needs for one particular process. This would be a good starting point to help the business understand the complete reality of using cloud resources: the benefits and the issues. If there is very little or no use of cloud services yet, you can initiate some experimentation on the business side. For example, try some new tools for marketing, project support or communication (yammer.com or IBM Lotus Live come to mind). This way, some business users will get the experience of choosing and signing up for their own IT, and will learn the issues that come with it. In the process, they may actually find some business relevant services that they want to keep for real!
A longer-term strategy will be increasing the technology skills of business executives. Perhaps taking a well-known piece of technology like the smartphone as a starting point, the discussion should encompass the reality of connecting to other companies through technology, user-driven innovation and the role digital services play in the core products and processes of the company. Establish a “digital first” vision that describes how the digital realm will be used to be competitive and customer oriented. The goal here is not to train executives in the finer details of database construction, but the overall concepts of strategy for and with technology should be clear.
When IT conforms more to the pay-per-use model, the business budgeting should change accordingly. After cloud computing starts to gain some momentum, the practices around budgeting and financial management as a whole should be ready for a model where costs are calculated per transaction, per user or whichever granularity is relevant for the business. Make special note of the upward flexibility in case of unexpected success: if for example there is a sudden increase in the number of orders placed, the overall cost of IT will increase accordingly. In that case “breaking” the budget would be good!
Extending the discussion around business intelligence, the business plans and ambitions should start to take into account the value and potential of data inside and outside the company. As discussed in Chapter 8, sharing data and using shared data is growing fast, and the organizations that will benefit most are the ones that learn fast and use the data to their benefit. Discover hidden value by finding out which data could actually be valuable to others, and figure out which partners could have data that would improve your own processes or decisions. This could be one step on the path to becoming an organization that is turning into an ecosystem player, using other parties to help create the end experience, product or service best and most efficiently.
Figure 9.3: Business-IT interaction changes due to cloud computing
As we discussed in several of the previous chapters, the interaction between business and IT is an area where many developments occur as you’re adopting cloud computing. The most important interactions of enterprise architects take place in this area, and this is where the strategic decisions for IT are being made. In this strategic dialogue long-term and short-term considerations need to be addressed and here you sort the standard, infrastructural elements of the business from the unique, innovative and competitive parts.
There are several activities you can undertake to improve the business-IT relationship while discovering the opportunities of cloud computing:
Let a group of IT and business people meet face-to-face and discuss your business drivers and how the different new IT developments can help. In a workshop format, a shared vision can be created that gives a clear direction and prioritization of possible options. Areas where cloud could be valuable and viable can be identified, and usually a workshop like this is a great opportunity to tighten the relations between business and IT people. Such a workshop is valuable for alignment around any IT innovation, but especially in the case of cloud computing.
The real business drivers are sometimes surprisingly hard to find or formulate on the spot, so some preparation is needed here. Also, the IT people should be prepared to present the different elements of cloud, as they can be valuable to business. In most cases, some related technologies are included, too: for example, mobile computing or web technology in general. This exercise is often done with help from external consultants who do the workshop preparation, moderation and reporting,1 but it can also be executed completely by your own team.
This discovery exercise might include, after discussing the business drivers, presenting a range of cloud services, introducing them briefly and seeing how they can match up with the business drivers. It could be the first step to the creation of a cloud portfolio.
After finding some areas where cloud computing might be useful, a business case can be made. In some instances it will be fairly straightforward to calculate costs and returns, while in other cases the best you can do is establish a rationale or vision as to how cloud would be valuable. If no hard ROI can be proven, it does not necessarily mean no ROI will be attained in the end. It may be a business decision to invest in an area that looks promising, but currently is not mature enough for a solid business case: perhaps adopting an industry-specific cloud solution or choosing a relatively new startup company to provide business process integration online.
An easy business case can be calculated for things that are more or less standardized: virtualization as part of your private cloud initiatives, email in the cloud or collaborative platforms in the cloud. Weighing cost, benefits, opportunities and risks of a traditional solution against the cloud solution should give a good indication whether cloud, in this situation, is the smart thing to do. As mentioned before, in the case of a pay-per use service, these calculations need to have some scenario-planning variables in them, too. What will happen over time, and how would that change the outcome of your comparison? Finally, even though these business cases are relatively straightforward, unless you have a real understanding of your current costs of operations, housing, power, people, recruitment, etc., and also the value of your current level of quality, support and IT dedication, it will be hard to make a fair comparison. In the case of a new solution, these comparisons will be easier than in the case of migrating existing systems or infrastructure. When you are looking for an easy project to start, a new application is therefore the preferred option.
An important part of the dialogue between business and IT should address what is a good way to get started with cloud? Which project will you start with? Naturally, you will look for something that is not too large and complex, that demonstrates the value of cloud computing, and that can create some visibility inside the organization. You have the choice of starting in the public cloud, “outside in,” or starting with the private cloud, “inside out.” Quite a few private cloud projects primarily aim at reducing costs and improving the agility of internal IT, but do not aim to offer new functionality. As a result, the business visibility could be less than what would be achieved with a more functionally oriented public cloud project. Still, some private cloud projects will offer new and highly desirable features to the business. Examples are data mining, analytics or searches.
If you are really looking for innovation and want to experience the collaborative and connected nature of some cloud solutions, you could look for an internal system that is most related to one or more of your important trading partners and look for a cloud solution that could enhance the process: for example, by increasing automation, providing better information, bringing together multiple parties, offering better functionality and lowering costs for both parties, etc.
At IBM, workloads have been identified that offer the most favorable entry points for public and for private cloud delivery models (IBM 2010). These workloads are based on the analysis of study data and experience with actual cloud implementations. For organizations interested in piloting a public cloud service, the workloads listed in Table 9.1 are the projects that would likely pose the lowest risk and offer highest potential return. The same holds true for the workloads listed as top candidates for private cloud implementation.
| Public cloud entry points | Private cloud entry points |
|---|---|
| Audio/video/web conferencing | Data mining, text mining, or other analytics |
| Webhosting | Data warehouses or data marts |
| Test environment infrastructure | Test environment infrastructure |
| VoIP Infrastructure | Business continuity and disaster recovery |
| Variable storage | Developer platforms |
| Software as a service | Long-term data archiving/preservation |
Table 9.1: Workload recommendations
Not everything is suited for the cloud yet. Mission-critical applications, highly sensitive data workloads (such as employee and healthcare records), multiple codependent services (such as high throughput online transaction processing) and workloads requiring a high level of auditability and accountability (such as those subject to Sarbanes-Oxley) are not the preferred entry points for cloud computing (IBM Smart Business 2010).
A joint discovery workshop is a good start, but even better would be to have a continuous dialogue about the company, strategy, projects, IT strategy etc. This strategic dialogue can have many forms. It can be embedded in frequent individual contacts between many different people, or it can take the form of regular meetings of an “innovation board.” There could be online support tools, collaboration spaces and even crowdsourcing initiatives where a large number of people are invited to think about innovation and strategy. By including IT in this process, the organization will come closer to the business technology ideal and be better positioned to take advantage of new technology first. What would you have done if the iPad had been on your horizon from the day it was announced? Could you have created an app or complete application that would have used the mobile, connected, location-aware, personal nature of this new computing device? The same goes for many upcoming cloud services: if you are the first to use them, you’ll have an advantage, provided you can weed out the ones that are not going to make it.
Looking at how and where cloud can be useful is not a one-time exercise. Your enterprise IT strategy will continuously redefine where the boundary between internal and cloud lies. Over the years, new developments will keep changing that boundary. Things that were too costly to move to the cloud will have become cheaper, applications that were once deemed unfit for cloud may find a good cloud alternative, and concerns that cannot be addressed today may no longer be problems for new services or service providers. All of this can be part of the innovation process, or the enterprise architecture dialogue; probably they are one and the same, since the people who would be involved in innovation are the same people who would be involved in enterprise architecture.
If your company is not ready for any of this, the easy low-key start would be for the CIO and enterprise architects to occasionally invite someone from the business for a one-on-one lunch or late-afternoon casual brainstorm on how IT could ideally be used in your organization. This would build a network of supporters who could, in a later stage, help bring about change.
Cloud computing has the inherent risk of losing control. As mentioned in Chapter 6, this is not a bad thing, as long as the risk is an informed one and the biggest risks are countered by some preventive measures. Long-term and short-term success are not opposites, but it takes careful maneuvering to achieve both.
Enterprise architecture is essential in guiding the development of the IT landscape when implementing cloud solutions and making sure the technology is continuously in line with the business drivers (see Chapter 6). EA makes it possible to define the functionality, the quality and the structure of solutions, regardless of the manner of implementation. From this perspective, the technical implementation of these solutions is guided by the oversight that is needed when the components that realize those solutions can reside everywhere. To apply enterprise architecture well in the case of cloud computing, the following activities are relevant:
| 1. | Reverse architecture the existing landscape, in order to discover the services and patterns in use by the organization and the variants of these services and patterns deployed. | ||||||||||
| 2. | Define the future state (to be) of services and patterns that are eligible for (partial) cloud implementation and realization. For every feasible scenario, an architectural study and impact analysis should be provided, using pattern variants as an outline to define and construct these artifacts. | ||||||||||
| 3. | Establish which deployment options are optimal, appointing feasible cloud candidates for delivery of services involved. This is based on a cloud classification approach that weighs the business value and commodity factor of each pattern and/or service variant. This step should be carried out in tandem with establishing the service portfolio and mapping the business capabilities onto services. | ||||||||||
| 4. | Guide the composition of request for proposals by providing functional descriptions of each pattern and service variant that
is a cloud candidate. This description should contain:
|
||||||||||
| 5. | Provide the same descriptions for services and patterns that remain the responsibility of the organization, but are affected by the deployment of facilities in the cloud. This provides a full overview of the changes that take place when implementing cloud services. | ||||||||||
| 6. | Guide the implementation, testing and deployment of cloud services and the (re)design and testing of internal facilities that are affected by cloud implementation. |
If you have no mature enterprise architecture practice, establishing one would be recommended for many reasons, and especially for making cloud computing a success.
Figure 9.4: IT changes due to cloud computing
In the IT department, cloud computing has two distinct areas of impact: one is the technology itself, what technology we use and how it integrates. The other is the process of creating, provisioning and operating IT: the inner workings of the IT department.
Figure 9.5: IT process changes due to cloud computing
Including external cloud services in the corporate IT domain will have an impact on other dimensions of IT. Cloud may offer new or different functionality for the same process, the quality of the service may be different, or more practically, simple things like the way backups and restores are done could be entirely different. Also, for private clouds, there will be an impact on the IT processes.
You can initiate changes to prepare the IT process for cloud computing:
Embrace enterprise architecture in IT
Having enterprise architecture as a practice and as a process for aligning business and technology will only work if conforming to architectural principles is part of everyday life in the IT department. EA should be geared towards making the architecture guidance easy to digest and receptive to projects and other IT activities, but strong commitment is needed on the part of, for example, project managers and (senior) IT management.
For example, the infrastructure architecture methodology introduced in Chapter 6 should give you concrete tools to talk about the cloud from the infrastructure up, but it will only work if the people who actually work on infrastructure projects use it to guide their decisions.
Define and fulfill the cloud broker function
If the IT department wants to coordinate the journey to the cloud, it should at least function as a broker between business and end-users on the one hand and cloud service providers on the other hand (see Chapter 5). This much-discussed broker function is, on the one hand, very straightforward (simply match supply and demand) and, on the other hand, it may turn out to be the difference between winning and losing market share.
In essence, the broker function has an internal side, of knowing the demand and potential future demand, and it has an external side, of pro-actively scouting for possible services that can be relevant to the business. To start the broker function, all it takes is some time for people to initiate both sides: define expected demand and do a market scan of potential new services.
But once the number of services managed by the broker function starts growing, there will be additional demands on the broker: guaranteeing quality, continuity, reducing risk and watching for legal issues. If you use a broker-selected cloud service, you should be able to trust the parties who deliver services that may be business-critical or who store data that might be sensitive. This trust should be underpinned by proper legal contracts and service agreements. When setting up the broker function for the cloud, it is advisable to set up profiles of potential provider companies, containing criteria regarding financial and legal aspects, compliance, security, personnel, location, etc. These profiles can be used when including new services into the corporate set of solutions.
As a long-term goal, it may be useful to keep the concept of a corporate app store in mind: a self-provisioning portal where users can sign up for applications and services that are relevant to them. In this app store, you would present the complete portfolio of internal and external applications in a user-friendly way. Populating the app store would be the responsibility of the cloud broker.
Start using a service portfolio
To fulfill the role of broker well, a consistent, extensive and dynamically maintained service portfolio is indispensable. The IT department builds such a portfolio with internal and external services selected for their functional excellence, innovation, service excellence and cost characteristics. Managing this portfolio is a new IT capability that goes beyond traditional supplier management. To set up a portfolio, you make an inventory of business capabilities (see Chapter 6) and map them onto the services they need. This way, a good understanding can be obtained about the use of services, the way they are re-used or shared, and the importance of the services for the proper operation of business processes (service priority).
Define and describe services in a technologically agnostic manner, in order to provide a clear overview of the functionality, quality and features of the services that are being delivered by the IT department, regardless of the way they are realized. At the same time, these definitions provide the requirements that architects can use to select feasible solutions, determining whether valid cloud candidates exist or not. In their turn, architects can provide input for the description of services by providing pattern definitions that describe the functional appearance of solutions.
Become more specific in cost allocation
To implement a service portfolio, the cost per service is important information. Since internal IT will in some ways be competing with external providers, transparency about cost is essential. To enable a pay-per-use costing model, with the correct chargeback to the business, you need good insight into the metrics of IT. You need insight into the cost of operating IT, but also into how that cost is related to business relevant metrics such as transactions, products or users. Integration and orchestration costs of cloud services should be included in this model. Establish a cost allocation structure and charging model that covers all services, regardless of whether it is a cloud, a non-cloud or a partial cloud implementation, and you’ll be ready for whatever cloud solution will be implemented along the way. Even if you will never adopt a true pay-per-use model in your organization, the insight is indispensable for proper financial control and justification.
Renew service management to guide delivery
When services are delivered by the cloud, it impacts both technical and operational processes (see chapters 5 and 6). The way a solution is realized changes, so this needs to be guided by architects. But what also changes is the responsibility for operational processes, their character or nature, and methods of service delivery and control. This means that service management is highly impacted by the cloud. Due to the dynamic nature of cloud computing, service portfolios become more dynamic and at the same time this leads to the existence of more underlying contracts. Services from different providers and of different types need to be presented to the business as a consistent set. Incident, problem and change management all need to be carried out in different forms, depending on the nature of the cloud services and the underlying service-level agreements. When renewing service management to make it ready for the cloud, at least the following processes should be changed to be capable of carrying out the task:
| • | Service portfolio management → as mentioned above, a service portfolio with standardized services defined in business terms. The necessary steps to establish this portfolio are already described above. The responsibility for keeping this portfolio up to date resides within service management. |
| • | IT service continuity management → ensure service operation continuity. Distributed implementation of solutions (to different cloud providers) can put continuity at risk, if it is not guarded carefully. |
| • | Help desk, incident and problem management → a governance structure and organization that are prepared for a high level of automation, the alignment of help desks with cloud providers, incident and problem management processes and agreements on problem management processes with cloud providers in order to be able to trace and solve problems (root cause analyses). |
| • | Change and release management → mature and standardized processes that can be automated to support the rapid provisioning of cloud-related services. |
| • | Availability and capacity management → a capacity forecasting model that can take into account the characteristics of cloud-related services. |
Figure 9.6: Technology changes due to cloud computing
After talking about all the changes to process and business, one could almost forget that there is a technical impact as well. If you embrace cloud as an internal model, the technical focus might be on virtualization first. If you focus on using a public service, you might start with addressing security or integration. And there are some other concrete actions that lie ahead in the technology space:
Experiment!
Try some things out. Create a solution with the API’s of public cloud. Self-provision some Amazon compute power and run an app on it. When experimenting, take the cloud concepts for a test drive and look in particular at the characteristics that will matter most:
| • | Security and performance. |
| • | Managing and operations. |
| • | New features, new possibilities. |
Most developers love experimenting with the latest online platform, so if you give them half a chance they will come up with creative solutions. And if you can find a contained business-relevant experiment, involve the business in your experiments.
Virtualize your datacenter
It is one of the low-hanging fruits that most organizations have already grabbed: start a project to find redundant hardware and reduce the number of physical machines. This will bring down the cost and increase your agility right away. It has fairly limited business visibility, if you do it right, and it will help you prepare for the addition of external resources, too.
Automate manual IT processes
When the pressure on cost remains high, and competition from cloud service providers increases, the cost of basic IT operations needs to approach that of the external providers. The most important way to do this is to automate as much as possible in the IT operations domain. Look for the manual processes, the exceptions or the recurring tasks that have not yet been automated.
Migrate existing applications
In a number of cases, you will find a business case to actually migrate some existing applications to the cloud. If a cloud service is available that offers the functionality currently offered by the existing application, you would enter into a data-migration project. If no ready-made alternative is available, you can port the existing application to a cloud platform. In this case, a review of the application architecture is in order: how does the application handle threading, scaling, transactions, storage etc. Then select the cloud platform that fits the application best, and still conforms to the business case.
Get ready for integration
If you already have an SOA, you will probably have some sort of enterprise service bus. When adopting cloud computing, integration will become one of the core technical skills of the IT department. Providing a stable, mature integration platform that can scale to the demands that cloud may bring will be critical to the core function of IT. At least consider master data management, identity & permission management, policy management, workflow orchestration, messaging facilities and reliable network connectivity. If your integration approach is not yet perfect, this is the time to address it. It prevents the creation of a patchwork of unmanageable, incompatible platforms. Without a sound integration approach, anarchy and chaos stand waiting at the door bearing their gift of increased complexity, which will lead to reduced flexibility and higher costs.
Generally, adoption of cloud computing comes from two sides. One is the IT optimization path, looking to reduce cost and increase agility. The other is from the outside-in, where complete user-ready solutions are introduced because they address an urgent business need. The two different types of adoption can, to some extent, be combined.
The first approach is the simplest one in the beginning. It means that an organization eclectically picks services and apps from the (public) cloud that provide simple commodity or isolated niche services. Examples of commodities are email and teleconference services. Examples of niche services are human resource test tools or collaboration portals from the cloud. These applications can be acquired easily, mostly by subscription to a service. In many cases, all one needs is a web browser and a credit card. The functionality offered is often closely related to specific user groups who carry out specific tasks. However, integration of these applications with other applications is zero or close to zero. Although initial implementation is simple, lack of integration and possible issues regarding data security and legal obligations make this approach not suitable for all purposes. And, in the long run, a complex patchwork of disconnected applications and facilities made up with services from all corners of the cloud isn’t exactly a tempting scenario for most organizations.
The second approach is much harder in the beginning, but seems to be more future-proof in the long run. With this approach, internal facilities are transformed into (private) cloud services by using virtualization techniques, service orchestration and integration facilities, automated management facilities, self-service portals and charging mechanisms, to name some important cloud ingredients. This requires a complete revision of the IT landscape, to become a landscape built upon the principles of service orientation. Once internal services are in place (including orchestration and integration facilities), external cloud services can be obtained and incorporated into the total set of IT services of an organization. These might be application platforms and storage facilities that extend beyond the firewalls of the organization’s own data center, for disaster recovery, developing and testing or peak-load handling purposes. They might be external service routines that handle portions of data processing jobs in a real SOA fashion. This approach is thorough and only provides clear benefits further down the road. It might be hard to explain to business representatives and difficult to interest them. At a minimum, a concise set of principles and reference models is needed to support decision making.
If an IT department would ignore cloud altogether, the outside in approach would silently chip away at the core function of IT. Over time, less and less would be asked from the IT department, but at the same time integration and process integrity would probably suffer. A complete inside-out approach might feel very safe and robust, but can suffer from the same ills that ultimately gave SOA a bit of a bad reputation in the end: a lot of internal preparation that does not directly create new business opportunities. Cost saving is wonderful, and increasing agility is much desired, but nothing creates excitement like new business opportunities. That is why a combined approach would be ideal: aim for the biggest improvements internally while scouting the public cloud for new opportunities. Apply good architectural principles to whatever decision you make, and over time the two approaches will have reached the desired end state of a portfolio that consists of a mix of internal and external services, brokered by an internal broker function.
Throughout the organization, more learning and exploration is probably in order to creating a better understanding of cloud computing and its full impact. There are many ways to do this, some of which were mentioned before. There are some other concrete actions you can initiate:
| • | Visit cloud computing events or training. There are many events that explain cloud and share best practices. CloudCamp is a so called “unconference” that comes recommended for enterprise architects and technical people (see http://cloudcamp.org). |
| • | Get the legal team on board by initiating the discussion now. Help them explore the regulatory hurdles around cloud and find ways to overcome them. |
| • | Do an IT or EA maturity assessment, to get third-party feedback on the strengths and weaknesses of your current IT or EA organization. Did you implement SOA? Is the EA process working well? Learn where you are in need of improvement before embracing the changes that come with cloud. |
| • | Do a security scan, to find out if risk management, security policies and technologies are good enough to start thinking about integrating into a cloud ecosystem. |
| • | Do a round of fact finding around the (im)possibilities of cloud computing. Visit the QA and testing teams, the people who operate existing applications. Their input and even objections can be very valuable to establish the impact cloud computing will have for you. |
Many of the concepts are not new, and often it is the case of simply applying what we already know. The discussion about cloud gives you the opportunity to set some things straight where correction was sorely needed. Spreading knowledge of how IT could and should work is an important part of that: establish the ideal to initiate the journey towards it.
Figure 9.7: Summary of changes due to cloud computing
Technology is the basis of cloud, but the changes span the organization. The priority and depth at which the different aspects will be executed will vary from place to place. In general, you’d adopt everything in the diagram roughly from left to right, allowing some experimentation and initial steps before starting the cloud initiative in earnest. And though your exact order of adoption might differ, there are of course interdependencies, for example between virtualization and chargeback, or between automation and self provisioning.
In the end, cloud will follow the path of SOA: SOA is no longer in the public eye as an important theme, but it is still the leading model for designing distributed systems. Cloud is fast becoming simply “one more option” for IT, but its true value will be found by the companies that turn an IT trend into a business opportunity. Along the way, cloud will have pushed IT to a new level of professionalism, making it an organic part of the business at the same time. But its promises are not fulfilled without effort. It requires hard labor, coordination, collaboration and creativity, together with clear milestones and acknowledged and celebrated successes. The steps suggested do not stand alone, nor can they be taken separately. They are related to each other and need to be carried out in an iterative process that slowly incorporates processes, people and technology. Remember, it’s not a migration, it’s adopting a new paradigm, a journey. Choose your destination and pace. And then set sail, if you are not under sail already. Good luck!
| 1 | Sogeti offers this service under the name of TechnoVision™ (Hessler). |