- 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
SOA to the Rescue?
While there are many attempts to fix the badly broken IT architectures within our enterprises, most "solutions" just put another technology layer on top of the existing technologies in hopes that the technology will somehow fix the issues. As you may have guessed, it just makes things more complex. Few enterprises were willing to take the risk and address the core issues.
Service-oriented architecture, or SOA, is really about fixing existing architectures by addressing most of the major systems as services and abstracting those services into a single domain where they are formed into solutions. Simple in concept—and really nothing new—SOA is our best approach to fixing the broken architectures. With the wide use of standards such as Web Services, SOA is being promoted as the best way to bring architectural agility to your enterprise—that is, if you do SOA correctly. There is no magic bullet here.
SOA is a valid approach to solve many of the architectural problems that enterprises face today. However, those who implement SOA typically look at SOA as something you buy, not something you do. Thus, many SOA projects are again about purchasing some technology that is sold as "SOA-in-a-box," which turns out to be in-a-box but not SOA, and thus only adds to the problems.
SOA, as the A implies, is architecture. And thus it is the orderly arrangement of systems that best serve the service needs of the business. Taken in its literal context, enterprise IT can succeed with SOA. However, most often it does not succeed, and much of that failure occurs because SOA implementers view SOA as something other than architecture, and most often those implementers are not architects.
SOA is a valid architectural pattern and one that is leveraged throughout this book, but you need to look at SOA as a journey, not a project, and clearly not a product. At the same time, you need to break SOA down into small, incremental successes that also move the enterprise toward the core value proposition of SOA, which becomes even more powerful when leveraged with emerging concepts such as cloud computing, the other focus of this book.
We can call this "small SOA" and "big SOA." Big SOA encompasses the larger strategic objectives of SOA: simultaneously moving all the enterprise IT assets to something much more agile and easy to change. An example would be breaking down all relevant enterprise systems to a functional primitive, building them up again as services, and adding a process configuration layer to form solutions. Considering that such an enterprise typically means hundreds and sometimes thousands of systems, this project could take many years.
Small SOA is just an instance of a big SOA. Small SOA is still SOA but has well-defined objectives, a time box, and a core return on investment that must be met. The lesson here is to leverage small SOA to get to big SOA. For instance, you could build a partner portal using SOA approaches that you can stand up in 6 months, with a return on investment of only three months—clear benefit and a small and doable project that occurs within a year's time.
While small SOA seems to be working, big SOA has largely been abandoned as too complex and too expensive to pursue. The reality is that you need both, but you need to know how to leverage both. Hold on to that thought for now. The topic of SOA is revisited many times in this book.