In most cases, a standard SOA environment won't fail too badly if forklifted into a cloud. SOA’s weak decoupling works fairly well as a starting pattern in a cloud environment. There is another step to decoupling applications for cloud environments, something I'm going to call “Cloud Oriented Architecture.”

(This is Part 2 of Matt’s series. To read part one, click here.) If SOA is intended to build a distributed application environment whose data sources are far from the end user with processing somewhere in between, then the next logical step is extending that processing onto a cloud resource. In fact, the Ocean Observatory Initiative is already leveraging current commercial cloud providers within their distributed framework. SOA and MOM (message oriented middleware) are two of the key paradigms used in the design of the OOI Cyber Infrastructure. While this architecture incorporates cloud resources as a component of the overall distributed application, similar approaches can be used to migrate resources from local systems to a cloud provider.

Within service delivery circles, Service Oriented Architecture (SOA) has moved from buzzword to staple over the past 5 years. The ideas of loosely coupled services that hang together instead of a bespoke monolithic application has changed the software landscape. Decoupling sources and consumers of data provides flexibility and scalability in application and infrastructure design. The hype may have moved on, but what's left behind is a solid, practicable architecture. Asynchronous, message based interfaces extend the time and space divide further. Reusable components increase the speed of delivery and creation of new services. Diverging application resources drag diverging data sources along the path. Accessing unrelated data sources from a SOA based environment requires some unifying view, be it a consolidated hub that replicates data from different sources or a data federation service that manages abstract aggregation logic. Monolithic siloed applications can be leveraged while being decomposed into component functional service areas.

I hope that you enjoyed our series on ERP Trends in technology for 2010 and beyond. We’ve, hopefully, given you something to think about and to consider as you plan your IT strategy going forward. One of the more interesting things that we’ve deduced from observing these trends is the increase in services & support. At first glance you would think that this would be counter-intuitive given the advances in software. That is, with the newest versions of software being mostly self-managed—e.g. OEM, Cloud Computing – you would think that the need for specialized labor would decrease but in fact it has increased. Why is that?