Cloud Computing and SOA Convergence: Where We Are, How We Got Here, and How to Fix It
- How Things Got Off Track
- SOA to the Rescue?
- What the Heck Is SOA, and Why Should I Care?
- SOA Meets Cloud Computing
- Defining Cloud Computing
- The Components of Cloud Computing
- The Dream Team of Cloud Computing and SOA
- What SOA Can Learn from Cloud Computing
- What Cloud Computing Can Learn from SOA
- Making the Leap
- Being Positively Disruptive
This chapter is from the book
This chapter is from the book
This chapter is from the book
- There are painters who transform the sun to a yellow spot, but there are others who with the help of their art and their intelligence, transform a yellow spot into the sun.
- —Pablo Picasso (1881–1973)
It is Thursday morning, you are the CEO of a large, publicly traded company, and you just called your executives into the conference room for the exciting news: the board of directors has approved the acquisition of a key competitor, and you are looking for a call-to-action to get everyone planning for the next steps.
You talk to the sales executives about the integration of both sales forces within three months, and they are excited about the new prospects. You talk to the human resources director, who is ready to address the changes HR must make within two months. You speak to the buildings and maintenance director, who can have everyone moved who needs to be moved within three months. Your heart is filled with pride.
However, when you ask the CIO about changing the core business processes to drive the combined companies, the response is much less enthusiastic. "I'm not sure we can change our IT architecture to accommodate the changes in less than 18 months, and I'm not even sure if that's possible," says the CIO. "We simply don't have the ability or the capacity to integrate these systems. We'll need new systems, a bigger data center. . . ." You get the idea.
As the CEO, you are nonplussed. While the other departments are able to accommodate the business opportunity in fewer than four months, IT needs almost two years?
In essence, IT has become the single-most visible point of latency when a business needs to change. Thus, the ability to change is limited by IT. In this case, the merger is not economically feasible, and the executive team is left scratching their heads. They thought IT was about new ways to automate the business and had no idea how slow the IT folks are to react to change.
However, it does not have to be this way. The survival of many businesses will depend on a fundamental change in the way we think about and create our IT infrastructure going forward—that is, if you are willing to admit where you are and are willing to change. There is much work to be done, and reading this book is a great first step.
How Things Got Off Track
IT issues are best understood by understanding its general history over the last 30 years as well as your company's specific IT history. History tells you why things are they way they are. Examining your company's IT history is almost like participating in a 12-step program: you admit you have a problem and are willing to look at how you got here.
It is also important that you check your ego at the door. IT folk typically do not like to talk about mistakes made in the past. Indeed, many will defend until the day they die all IT-related decisions that were made in the past. But the point of examining the IT history is not about placing blame—it is about recognizing what you are currently dealing with and discovering ways to fix it. If you cannot open your eyes and mind to the existing problems, then reading the rest of this book will do you very little good.
If there is one issue that comes to mind each and every time we look at IT's past mistakes, it is managing-by-magazine. In essence, those charged with building and managing IT systems often did not look at what was best for the business but looked instead at what was most popular at the time or at what was being promoted in the popular computer journals as the technology "required" to solve all problems.
Another issue is managing-by-inertia, or failing to do anything just because it is new and unknown. This problem is opposite to managing-by-magazine: Instead of doing something just because it is popular, we simply sit on our existing IT architecture. Typically, this lack of action is rooted in the fear of change and the risks associated with it.
We had the structured computing revolution, which became the object-oriented computing revolution, which became distributed objects, which became component development, which became enterprise resource planning, which became customer relations management, which became service orientation—you get the idea. Of course, I am missing a bunch of other technologies that we "had to have," including data warehousing, business intelligence, business process management—the list goes on and on.
Not that these technologies were bad things; most were not. However, they had the effect of distracting those in IT from the core problems of their business and focusing their attention more on the productized technology than on the needs and requirements of the business. The distraction was easy because analyzing and documenting business requirements was not as fun as experimenting with new technologies and was not a résumé-enhancing experience.
This focus more on the solution than on the problem caused a layering effect within the enterprise architectures. In essence, the architectures grew more complex and cumbersome because the popular products of the day were being dragged into the data center and became another layer of complexity that both increased costs and made the enterprise architecture much too fragile, tightly coupled, and difficult to change.
Today we have IT infrastructures and enterprise architectures that are just too costly to maintain and difficult to impossible to change. As business needs change, including upturns and downturns in the economy, IT is having an increasingly harder time adjusting to meet the needs of business. As in our example at the beginning of this chapter, CEOs are finding that IT is typically the latency within the business that causes delays and cost overruns, and IT does not add value to the enterprise as it once did. Remember when IT was the solution and not the problem?
IT departments were more productive when they were coding applications in COBOL on mainframes because it required them to be lean and cautious with their use of resources. Today, we have almost too much technology and too many options. We gave IT enough rope to hang themselves, or at least to get their IT architectures in a state that makes them much less valuable to the business.