For the long period of time SOA had the attention of many in the software industry. And then it was proclaimed dead, and then reincarnated in the form of cloud computing (kind of). And today Cloud computing is living through the same crazy hype as SOA was several years ago. Do the two have a lot in common? Are they related? In the best tradition of our industry, it depends on whom you ask. According to VMWare’s Rod Johnson:
“I think with respect to SOA, it really was a fad. It was something that is very sound at an architectural practice level, but in terms of selling product, it was really an artificial, marketing created, concept… In the case of cloud computing however there is more substance behind it. However that substance is obscured by the fact that cloud could mean just about anything to anyone.”
Oracle’s Jürgen Kress, on another hand talks about the need for service oriented architecture to enable cloud computing to function at the enterprise level. In Kress’s presentation at the International SOA & Cloud Symposium, he says “you have to build your architecture right,” and that means an SOA underpinning.
In this virtual panel, InfoQ talks to several SOA and Cloud computing experts about relationships between SOA and Cloud computing, principles and technologies they can/should share, the applications that can best leverage combining SOA and Cloud computing and the things that are the most important for Cloud computing success.
The participants:
- Rob High - IBM Fellow and Chief SOA architect
- Miko Matsumura - VP Products Kii, former Sun Chief Java Evangelist, SoftwareAG VP
- William Vambenepe – Architect, Oracle
- David Linthicum – Founder and CTO of Blue Mountain Labs and author “Cloud Computing and SOA Convergence in Your Enterprise” and 12 other books
- JP Morgenthal – blogger / authority on Cloud Computing, Enterprise Architecture, and SOA/BPM.
The questions:
- Where do you see the prevalent use of SOA in Cloud computing - Defining cloud resources as services? Servicing your applications for moving to cloud platform? Both?
- Which SOA principles/lessons are most relevant for Cloud computing? What impact will cloud computing have on SOA?
- What can help cloud computing to avoid getting out of favor with developers analysts the same way SOA did?
- More and more cloud computing APIs are facing the same requirements/issues that Web Services where facing (and solving) several years ago, including asynchronous messaging, metadata exchange, eventing, etc. Do you see come back/reuse of some of the WS* standards for solving these issues?
- What are some of the best applications for SOA & Cloud together?
- What are the top three things a cloud user can do to improve on what they're already doing?
1. Where do you see the prevalent use of SOA in Cloud computing - Defining cloud resources as services? Servicing your applications for moving to cloud platform? Both?
Miko Matsumura: When we made existing apps into services we got no benefit because we were bad at granularity, semantics and reusability. The other problem was some services were running on an old DOS box and would fall over if you breathed on them too hard, which means that scalability becomes a "Race to the bottom" or "Weakest link" problem. Thankfully, cloud gives you a much more flexible bottom end to many services so at least they won’t break physically. They're just breaking logically now, which is equally horrible but a much more interesting set of problems to work on.
William Vambenepe: Mostly the latter. When bringing business applications to a Cloud environment, you need to be able to decompose them in manageable units both from an interaction perspective (how they relate with one another, which is what SOA focuses on) and from an operational perspective (where Cloud Computing brings more formalism and automation). If you’ve already done the work in the context of a SOA effort, and you’ve done it on top of an infrastructure that is SOA-aware, then you’re probably in good shape with regards to the operational decomposition.
If, on the other hand, you don’t efficiently control the interactions and dependencies of your application components, then you’ll have to do it now or your move to Cloud will really just be a move towards virtualization. You’ll get some consolidation benefits but not a real Cloud Computing environment.
David Linthicum: The use of SOA with cloud computing is really about defining your IT assets, including applications, infrastructure (e.g., storage), and platforms as sets of services. Once we’ve done that, no matter if we relocate existing services or create new services, the process is much easier and more logical. So, my answer is both.
Indeed, one can consider cloud computing the extension of SOA out to cloud-delivered resources such as storage-as-a-service, data-as-a-service, platform-as-a-service —you get the idea. The trick is to determine which services, information, and processes are good candidates to reside in the clouds, as well as which cloud services should be abstracted within the existing or emerging SOA.
In addition, SOA is important to cloud computing for a few key reasons:
First, a good approach to architecture deals with the proper formation of the information systems using mechanisms that make them work and play well together, inside and outside of the enterprise.
Second, in order to take advantage of cloud computing, you need to have interfaces and architectures that can reach out and touch cloud computing resources. While many believe they can simply create quick and dirty links between core enterprise information systems and cloud computing resources, the fact of the matter is that you really need an architecture inside of the enterprise, such as SOA, to make the most of cloud computing.
Finally, you need some sort of architectural discipline with guiding principles to document and organize your architecture. Most have ignored this over the past several years to focus on ad-hoc hype-driven stuff. We need to get back to leveraging the best solution for the problem, and SOA is a good approach for doing that if you follow the steps.
JP Morgenthal: Due to the nature of the industry’s perspective on what SOA is, the most prevalent use of SOA is as a component of the middleware of a Platform-as-a-Service offering. However, the nature of SOA lends itself to the creation and delivery of all cloud services, including infrastructure and software services.
Rob High: Cloud computing in general derived its association to SOA by virtue of the characteristics of loose-coupling associated with SOA. In very practical terms, loose-coupling is a major concern within SOA primarily due to the desire to be agnostic of the underlying technology, topology, lifecycle and organization on which any Service is implemented in an information system. This has been the ultimate goal of many of the distributed computing initiatives employed broadly in the IT industry for the last 30 years. XML, WSDL, IDL, CDR, the various Formats and Protocols defined for use within distributed computing have all attempted to enable the encapsulation of technology differences, and by extension to enable heterogeneity amongst the composition for solving computing problems.
Fast forward to Cloud computing and you see the same objectives surfacing from an operational and procurement perspective -- to be able to create and leverage capabilities that have utility to solving end-user needs, without regard to the location and technology on which that capability is implemented. It is natural to presume SOA as a means for achieving that transparency in Cloud computing.
Further, it is common for business people to think about what they offer to their customers and business partners as services -- not in the IT or SOA sense of service, but in terms of their business utility to the marketplace -- and likewise, they also tend to think of the things they consume from other business partners as services. One company may provide Financial services. Another company provides Manufacturing services. And another provides HR services. Acquiring and leveraging business services through the Internet and electronic computing is a natural and obvious evolution of global value-chain networking amongst companies, and with their final consumers.
When you bring these forces together then everything about the Cloud is about services -- service-orientation. The Cloud Infrastructure is itself a service provided to those that want to create software programs to run in the cloud that will in turn offer their programmed function to consumers through service-oriented APIs. The infrastructure services may be exposed for use by software developers for programmatically manipulating the infrastructure -- registering and deploying new services, setting QoS policies, gaining operational awareness, and so forth. The programs running on the Cloud may themselves be implemented using SOA related technologies. Services offered fro the Cloud may be composed with other in-house and public Cloud services to create SOA-based Composite Applications.
So, we see SOA being applied prevalently to Cloud computing at many levels.
2. Which SOA principles/lessons are most relevant for Cloud computing? What impact will cloud computing have on SOA?
Miko Matsumura: Provisioning apps is made new... You used to say "no" to an app because you didn't have the capacity to support it. Now you only have to ask yourself "does it make business sense"?
The harder problem is deciding about the business sense part. The finance guy will tell you that if it makes more money than it uses up, then go for it. Unfortunately the law of platform ecosystem governs here and you need to consider things like "can our sales force sell it" and "would it cause our platform APIs to change too much"?
This will give rise to a new kind of platform leadership where we have to be able to say "no" to platform consumers not based on the availability of capacity, or even the business viability of the transaction, but whether the application is a good fit for the "theme" of a given platform ecosystem.
William Vambenepe: IT service management and SOA Governance have been looking at one another (or making a show of ignoring one another) from opposite sides of the dance floor for a while. Configuration management is hard. Cloud draws a line between the Cloud provider and the consumer. You can either choose to believe this line has magical isolation properties, or you come up with ways to manage and organize dependencies and change policies in a way that allows the provider to perform required maintenance while assuring an acceptable outcome for the consumer. More thoughts on Cloud and SOA governance here.
David Linthicum: Two come to mind: First, the use of well-defined services to interact with the resources (applications and infrastructure). Second, the ability to provide and manage agility.
The use of services is the most relevant considering that, instead of dealing with hundreds or perhaps thousands of incompatible interfaces, we address sets of common services that provide application behavior, data services, and utility services. This abstracts the cloud user away from resources using common services to interact with those resources, services that are pervasive and location independent.
These services are cataloged and known to us, and we can mix and match them to form solutions, and even binding them to processes and composite applications, no matter if the services exist on private or public clouds, or within existing traditional systems.
The concept of agility comes along with the use of services and a SOA. You can mix and match services to quickly form and re-form solutions. This allows those in IT to quickly adjust to changing business processes, for instance creating new applications using composite services or changing business processes, no matter if the services are in clouds or not.
As far as the impact on SOA, SOA provides a very logical path to cloud computing for the reasons I’ve stated thus far, and thus SOA has gone through a bit of a reemergence considering the interest in cloud computing. This was the topic of my book “SOA and cloud Computing Convergence.” SOA has always been a productive way of designing, architecting, and dealing with IT assets. The interest in the cloud has just shined a much brighter light on the use of SOA.
JP Morgenthal: As stated in my recent article on InfoQ.com, the SOA principles of governance and loose-coupling are critical for cloud computing. From a governance perspective, the concept of maintaining a service catalog is extremely important for tracking use of resources and understanding what is deployed in the virtual universes that are being created. Loose-coupling provides cloud computing with an understanding of the best ways to avoid lock-in with a particular cloud service or provider as well as remain agile for incorporating new services as they emerge or change.
Cloud computing provides SOA with a better understanding of operational responsibility. Much of SOA has been focused on development, which is really a focus on the creative problem solving process. It takes a mature operational organization with strong operational processes to deliver that service in a consistent and repeatable manner to end-users.
Rob High: Going back to my previous comments about the role of loose-coupling in heterogenous distributed computing systems, the thing that we've struggled to achieve throughout the years is true encapsulation and isolation of underlying technology concerns. Even now, with robust technologies such as WSDL, XML, REST, and JSON, we still see artifacts of the underlying implementation technology bleeding through where it shouldn't. This is most often because on the one hand it takes some effort to truly hide those aspects, and more often because we let programmers get by with not putting all that much effort into designing and implementing good encapsulation. This lack of diligence often goes unnoticed until its too late because most pilot activities for any project are not that heterogeneous and therefore are not subjected to the intolerances that surface in fully heterogeneous systems. On the other hand, Cloud computing has very little tolerance for poor encapsulation. If you've created hard dependencies on resource location, then virtualization and elasticity becomes fragile. Technology-specific data types will constrain or completely break consumers. Failure to isolate threads of execution will expose one consumer's information to another consumer. Clouds mandate good encapsulation, and lack of encapsulation surfaces very early in deployment cycles. These are basic tenants in SOA, but are critical success factors in Cloud computing.
3. What can help cloud computing to avoid getting out of favor with developers analysts the same way SOA did?
Miko Matsumura: The horses are out of the barn on that one. Cloud already provides the kind of absurdly simple low level APIs that make developers love it, I'm thinking of things like S3. Who wouldn't love a bucket to just throw something? It's like the core design patterns manifesting in the cloud, developers are already mating their applications to it.
Cloud Fatigue happens the same way as SOA Fatigue. Looking down at machine interfaces is beautiful and happy. Looking at Enterprise Integration is hell. Sartre said it best, "Hell is other people". As soon as they have to talk to anyone with pointy hair who could be from a Dilbert cartoon, their life energy bar starts to be drained.
William Vambenepe: It’s a law of nature that over-excitement is succeeded by what comparatively looks like disenchantment. It happened with SOA and will happen with Cloud Computing. Short of preventing the over-excitement (too late already in this instance), there is no way to prevent this. I have no issue with that, as long as the benefits are retained. That means making sure that we apply Cloud Computing in a way that’s focused on maximizing business benefits rather than buzzword-compliance. That’s what remains when the hype washes away, that’s what many enterprise architects are doing with SOA, and I have no doubt that they will do it with Cloud as well.
David Linthicum: Success comes to mind. As long as cloud computing can prove its value within the enterprise, IT will continue to leverage private, public, and hybrid clouds. cloud computing is easier to understand, and now has gone to the mainstream. However, we’re saying “To the cloud!” in TV commercials, and not “To the SOA!”
Cloud computing and SOA are very different. Cloud computing is an approach to computing where we leverage local or remote assets that we can provision and de-provision on-demand. SOA is something you do, or a complex architectural pattern that allows you to create architectures that are easy to change.
Many of the PR issues around SOA have roots in the fact that many in IT did not truly understand it. I suspect that cloud computing as an approach to computing is here to stay, and SOA will come along for the ride as the best architectural approach for moving to the cloud.
JP Morgenthal: Interestingly, I view SOA as design and development of a service and cloud computing as the delivery and operation of a service, but clearly there’s many opinions regarding definition, which is why SOA struggled and what could do in cloud computing. Cementing the understanding for what cloud computing is will better enable the industry to measure it against a set of goals—e.g. cloud computing is x and therefore will delivery y—allows developers and analysts to have qualitative opinions on its value.
Rob High: Every technology initiative I've seen come out of our Industry for the last 30 years has always come down to three things: 1) having a clear business value proposition; not just being glamorous technology, but identifying real value to consumers that are truly interested and willing to pay for that value, 2) being able to remove friction to acquiring and leveraging that technology; that is, easy to use, consume, and to leverage for the value that it promises, and 3) having a community of interest around which an ecosystem can form. Much of what has maligned SOA is not its ability to achieve these principles. The fundamental issue is whether practitioners understood the core value proposition to begin with. We found that too often practitioners of SOA limited their view to only being about a different technique for structuring information systems development -- a sort of glorified form of EAI, or worse, just basic Systems Integration. They never quite understood that SOA had as its primary business value to enable better agility and outcomes from the business itself that could be achieved by rapid re-assembly of application components to meet new market needs. Those that have understood that value have in fact had the most success with SOA because that understanding has helped them prioritize their investments, and their design and governance approaches.
The same thing holds for Cloud. The value of Cloud is not just about how to reduce IT operations costs; it is about enabling businesses to focus more of their attention on innovation in their business. Understanding that and applying that in investment decisions will assure the success of Cloud computing.
4. More and more cloud computing APIs are facing the same requirements/issues that Web Services where facing (and solving) several years ago, including asynchronous messaging, metadata exchange, eventing, etc. Do you see come back/reuse of some of the WS* standards for solving these issues?
Miko Matsumura: WS is the container for everything bad. Don't read it the wrong way, I'm not actually saying that WS *is* bad. I'm saying WS *contains* everything bad. That actually means it's good. The toilet contains crap. That does not mean it is crap. Read on.
Now let’s say you're an iPhone developer and you hook up to Amazon S3. Good for you, you will never need to look at WS anything. Your life is shiny like a cereal commercial and you wake up with fresh breath. Unfortunately, many developers work for the Enterprise.
WS standards are the only practical and agreeable way to deal with the standardization and normalization of policy. So if you do have bad things in your network, you must contain them. So please consider using WS in those cases. Otherwise, please continue living your shiny life.
William Vambenepe: I’ve written a post-mortem on the effort of the last decade to apply WS-* specifications to the problem of IT Management automation (before it was called “Cloud”). This was written over 2 years ago and already it was clear that WS-* technologies were unlikely to be re-used as such from a protocol perspective for Cloud APIs. This is not the place to debate the merits of SOAP versus REST, but in the process of switching from one to the other for IT management some lessons are being correctly applied (like focusing on simplicity for the API consumer) while some features are just being re-invented (like notifications , partial resource manipulation, etc). At the risk of too packing many links to my own blog in one paragraph, here is an analysis of the practical ways to use REST for Cloud Management.
David Linthicum: I hope so. We burned a lot of calories from 2002 to 2009 working on the WS* standards. Many of them were well-defined and I think they provide value to the emerging world of cloud computing. Some of the cloud computing standards groups that are forming today are looking to reinvent the wheel, and they need to consider many of the standards already created. We seem to like to invent new standards when new technologies come along, such as cloud computing. I’m always the guy in meetings who points back to WS* as something that should be considered.
JP Morgenthal: It seems that many of the cloud computing providers have adopted a “REST” approach for delivery of APIs. This is actually an unfair characterization as it confuses many aspects of API implementation over HTTP. In essence, they have decided to leverage POST and GET verbs of HTTP with URL formatting conventions as a means of communicating with their services versus more robust messaging mechanisms that include guaranteed delivery. The reason I clarify is that I firmly hold that REST leverages URL identifiers as a means of operating on resources. That means that identical locators should always return the identical resource. If a URL query results in a response that changes over time, it’s really an RPC mechanism, not REST.
Rob High: SOA was never dependent on any one technology (including WS*) for its success. However, the presence of standards does facilitate the creation of communities, and therefore adoption of technology for sake of creating ecosystems. The thing that has always distinguished WS* related technologies is that they are a standard and has fostered a community, and that it has enabled higher qualities of service as an inherent element of computing. The alternatives offer very basic levels (often, good enough) levels of QoS. But when you need to go beyond that the WS* standards are particularly useful. Having said that, I have always advocated using the right standard for the task at hand. If you can get by with the basic QoS offered by REST and JSON, then use that. If you need to go beyond that then use WS*. I suspect we'll find other technology standards that offer their own differentiation that will be applicable to other needs. The beauty of SOA is that as an architectural style, it is really agnostic to which of the technology standards you adopt in the assembly of composite applications.
5. What are some of the best applications for SOA & Cloud together?
Miko Matsumura: SOA and Cloud are like chocolate and peanut butter. When the chocolate guy crashes into the peanut butter guy, they are very pissed off. But then they both realize how great they taste together and they part as friends.
Why is my answer so stupid? Please imagine the Cloud flavor being chocolate. This is when you have an app that has incredibly spiky behavior and need for elastic scale. That is a class of application. Now picture the peanut butter side, SOA. These are the twisty apps that are all tied together in integration.
To be honest, almost all Enterprise applications that are not hopeless have a bit of both. So I challenge you to find me an app inside the Enterprise that is NOT suitable for SOA and Cloud together. Outside of an Enterprise, please don't bother with SOA.
William Vambenepe: The best applications of this marriage are in optimally choosing deployment options for various application services, while keeping them integrated and, most importantly, managing them as one. For example, this means using SaaS services from a third party for some business applications, possibly in conjunction with custom apps running in a PaaS environment (e.g. as a way to customize/augment the SaaS services or as a way to deliver services to external consumers), all the while retaining some core or differentiated applications on-premise. While SOA is needed to architect such an integration, the conjunction of SOA and Cloud Computing is what allows you manage it efficiently. This requires an IT management infrastructure that is both application-centric and Cloud-capable.
David Linthicum: The killer applications would include the ability to leverage services within composite applications and processes that are delivered over the open Internet as if those services were local. Google APIs come to mind, but there are thousands of APIs that provide all types of services, from mapping to sales tax calculations. Or infrastructure APIs, such as storage and compute services from public cloud providers such as AWS. Check out sites like this to get a sense of the types of APIs you can leverage as SOA services. It’s very powerful.
JP Morgenthal: As I stated above, these work together to deliver the entire service lifecycle.
Rob High: I can't help but be trite about this question. SOA is a good architectural approach to enabling application composition across loosely-coupled systems. Cloud computing enables elasticity and transparent delivery of services. You should use Cloud computing -- private, public or hybrid -- wherever there is an economic advantage to the density and transparent delivery of services offered by Clouds.
6. What are the top three things a cloud user can do to improve on what they're already doing?
Miko Matsumura: I'd recommend diet, exercise and relaxation to anyone. But of course my answer is again stupid. I'll rather try to answer the question: what is the stupidest one thing you see cloud users doing that you wish they wouldn't. The stupidest thing I see cloud users doing is not thinking about dependence. Being dependent on another human being is bad enough, these developers depend on other businesses, for example Amazon EC2. As soon as you are dependent on another business, the other business can fail, or much more likely begin the horrible process of sucking away all of your money. So please practice safe cloud computing and architect your system so that you can "load balance" between two or more cloud providers. This is the first pattern of independence, which is choice. Let's be careful out there.
William Vambenepe:
- Manage from the application perspective. It’s not sufficient to monitor the infrastructure or some basic application metrics (e.g. response time on some safe request). You need to be able to inspect the application in great details, trace requests and drill down into the various tiers, wherever they run. Black-box monitoring (limited to a view from the outside) makes for beautiful dashboards but impossible optimization/investigation. More generally, you should architect for supportability (and use infrastructure providers who do it too). Cloud creates separations between areas of responsibilities. This segmentations is generally empowering and economical, but when issues arise it can create support hurdles. Many roles may be involved, e.g. the end user, the support person within the end user organization (for SaaS), the application admin, the infrastructure admin, the vendor who provides the Cloud environment or application runtime, etc. Make sure that the application infrastructure can produce comprehensive, sharable event reports, which can be correlated to infrastructure management tools. Also, make sure that the support information can be shared while respecting application confidentiality rules and the boundaries they define.
- It’s not just about cool architecture, it’s about meeting the needs of business users. Ensure that you can report on resource consumption, manage quotas, organize chargeback, provide reports, monitor SLAs, plan for future usage, distribute allocations between sub-entities of the organization. In other words, provide tools for managing the business aspects of the application deployment.
- Understand where standards exist (and matter) and where they don’t (and may not matter). Don’t let proprietary requirements and non-standard frameworks creep into your business application. On the other hand, don’t worry too much about some of the glue code that may be needed on the lifecycle management side (e.g. Cloud APIs). Standards just aren’t there yet for that, and it’s ok. As long as you use a well-architected management platform, the operational management won’t get out of hand. The application business logic is the crown jewel that need to be protected by using standards.
David Linthicum: First, make sure there is a sound architecture process around how solutions are defined, developed, tested and deployed. Many IT organizations seem to miss that step, and instead toss things out into the cloud without much planning. Leverage SOA approaches for that process, and learn all you can from my books or books written by others on the proper use of SOA.
Second, make sure to consider both governance and security in the solution. When managing hundreds of services and new security vulnerabilities, these concepts need to be systemic to your cloud computing architecture. For most, it’s an afterthought.
Finally, make sure to consider performance and stability. Leveraging hundreds of services that are in hundreds of physical locations often seems like a good idea. However, this frequently leads to performance and stability issues unless the system is well understood and closely monitored. You have to design performance and stability into solutions, cloud or no cloud.
JP Morgenthal:
- Establish strong metrics for success.
- Ensure the appropriate governance framework is in place.
- Anticipate scenarios that include your cloud service provider going away, scaling beyond your expected audience size, not getting money in the budget for next year. In essence, plan for the unexpected.
Rob High: Cloud users include both the consumers of services -- people that get value from a particular service by itself, or more often that want to combine that service with other things they're doing that creates larger value -- as well as providers of services that are seeking alternatives to achieving better operational economics and delivery. In either case, the key things to focus on are:
- adhering to the principles of loose-coupling; especially in the areas of encapsulation and transparency,
- recognizing that Cloud delivery forms the basis of market-based economics; the transparency of the Cloud-based services also implies that a consumer can easily pick and choose between different providers of that services -- the quality and value of a service becomes increasingly more important in every service implementation, and
- one of the key drivers in Cloud economics is in driving down operational costs which can only be achieved if services are implemented to support the virtualization, elasticity and higher densities that the Cloud infrastructure offers -- in many cases, you will have to build your service explicitly to achieve a certain level of fine-grained multi-tenancy and isolation.
All of these things put a premium of good software engineering.
Conclusion
Surprisingly enough, although often approaching a problem from different angles, most panelists agreed on the set of fundamental things:
- Success of the Cloud implementations is impossible without proper architecture, which means applying SOA principles to both applications - proper decomposition and infrastructure – service-based access.
- The SOA principles most relevant for Cloud computing are loose-coupling, governance and manageability.
- The same way standards were instrumental in shaping SOA, they are important for maturing of Cloud computing.
- Over hyping can only hurt Cloud computing in the long run and as many success stories as possible are necessary to ensure that Cloud computing will not fall out of favor.
About the Panelists
David S. Linthicum is the Founder and CTO of Blue Mountain Labs and an internationally recognized industry expert and thought leader. He is the author and coauthor of 13 books on computing, including the best-selling "Enterprise Application Integration" (Addison Wesley). Dave keynotes at many leading technology conferences on cloud computing, SOA, Web 2.0, and enterprise architecture, and has appeared on a number of TV and radio shows as a computing expert. In his career, Dave has formed or enhanced many of the ideas behind modern distributed computing, including Enterprise Application Integration, B2B Application Integration, and SOA, approaches and technologies in wide use today. For the last 10 years, Dave has focused on the technology and strategies around cloud computing and how to make cloud computing work for the modern enterprise. This includes work with several cloud computing startups. Dave’s industry experience includes tenures as CTO and CEO of several successful software companies, and upper-level management positions in Fortune 100 companies. In addition, he was an associate professor of computer science for eight years and continues to lecture at major technical colleges and universities, including the University of Virginia, Arizona State University, and the University of Wisconsin.
Dave's latest book is "Cloud Computing and SOA Convergence in Your Enterprise, a Step-by-Step Approach." You can follow Dave on Twitter.
JP Morgenthal is a Cloud Evangelist with Smartronix. He has over twenty-five years of information technology experience spread across a wide array of technology and business requirements and a demonstrated ability to design complete systems inclusive of business justifications and risk/reward analyses. Mr. Morgenthal communicates effectively with C-level, non-technical and engineering-level individuals in both written and spoken form and is a respected authority on Cloud Computing, Enterprise Architecture, and SOA/BPM. Mr. Morgenthal has authored three books.
Miko Matsumura is currently Vice President of Products at Kii Corporation through the merger of Servo Software and Synclore. Prior to his current role, Matsumura served as Vice President and Chief Strategist at Software AG. He joined Software AG through their acquisition of webMethods, where he served as Vice President of SOA Product Marketing. He joined webMethods through their acquisition of Infravio where he served as Vice President of Worldwide Marketing. Previously, he was Chief Java Evangelist for the Java Platform at Sun Microsystems. He has worked extensively with software startup companies, raising more than $12 million in capital for Silicon Valley and overseas startups. He has worked extensively with investment bankers, venture capital firms and startups in an advisory capacity. Matsumura holds an MBA from San Francisco State University and a master’s degree in neuroscience from Yale University.
Matsumura was named at Cloud Expo 2009 West as one of the World’s 30 Most Influential Virtualization Bloggers. He is the author of the book “SOA Adoption for Dummies”.
Rob High is the chief architect for the SOA Foundation, an IBM Fellow, Vice President, and member of the IBM Academy of Technology. He is responsible for ensuring an open industry architectural definition of the principles of business and IT alignment enabled by SOA and Business Process Optimization, as well as ensuring IBM's software and services portfolio is architecturally grounded to enable for efficient SOA-based solutions. This responsibility extends across the IBM software portfolio, including WebSphere, Rational, Tivoli, Lotus, and Information Management products relevant to enabling SOA.
William Vambenepe is an architect at Oracle, working on application management and Cloud Computing. He blogs here and tweets as @vambenepe.