The concept of a services-oriented architecture has been around for more than a decade, and it’s now so entrenched in our vernacular that it’s almost short-hand for what constitutes a smart enterprise environment. Over the past few years, however, “the Cloud” has gotten a lot of attention as a platform, and in some corners, there has been confusion over where an SOA starts and the Cloud begins.
At this point in the evolution of enterprise IT, an SOA is seen as providing a stable foundation, and one that allows for a great deal of flexibility for integration and adaptation for all different types of applications and legacy systems. And as an extension of that, SOA is adaptable to the structure of the platform, how applications are accessed and how data is transacted. And what platform is optimized to produce the best results in this environment? You guessed it – the Cloud.
In our view, there really is no point at which an SOA ends and something else “takes over”. Rather, we see that an SOA and cloud architecture are complementary, and that to be successful at having an effective architecture, you really need to think about what will optimze your services-based infrastructure. And if you’re going to deliver or transact with Cloud-based services, it probably makes sense to keep SOA as the foundation for everything, and putting a cloud-based system on top of that. The benefits will be mostly from the interoperability among all the different services that are transacting through the cloud, but are optimized because the SOA allows them to communicate and work with one another seamlessly (this, of course, is subject to your implementation).
Each component in a cloud-based application should be considered a separate Enterprise Service, even if they are not hosted by your IT organization. To get a cloud-based application working right, and assuring that it will perform as expected over time, one needs a single point of governance over these highly virtualized Enterprise Services throughout the entire service lifecycle.
Starting at the planning stage, creators of a cloud-based application need to develop and track the inventory of cloud services that are available or under construction. Business analysts, architects and developers need to be able to compare their enterprise SOA roadmap and desired slate of cloud applications with the Enterprise Service inventory, which consists of both cloud-based and traditional Enterprise Services. Planning governance gives these stakeholders the ability to assign development priority to the cloud services that are most urgently needed, as well as determine the applicability of cloud technology to the problem. For instance, is the application subject to “speed-of-light” concerns?
A development governance solution will provide seamless management of “the cloud” as a development target. It will provide a set of guidelines, policies, processes and even source control management for the development of cloud applications. The goal is the make sure that enterprise services running in the cloud conform to the same quality, performance, and security policies as any other enterprise service running on any other platform.
Operational governance for cloud services should ensure two important governance factors: First, it should ensure that the services themselves implement and enforce relevant policies for data protection, security, and service levels. Then, it should ensure the federation of externally provided cloud services into the enterprise network. This is similar to the way externally provided SaaS services need to be federated for policy and message exchange pattern mediation.
Cloud services are subject to the same governance process as any other enterprise service, and as such need the same levels of policy governance. Policy governance for cloud services includes the ability to define cross-cutting policies during the planning process and validate and enforce these policies through development and operations.
SOA Software’s product suite manages SOA Governance throughout the plan-build-run service lifecycle, anchoring the process with strong policy governance. In planning, SOA Software’s Portfolio Manager allows planning stakeholders to develop an SOA roadmap, compare it to existing and planned services, and assign priority to selected services. In development, SOA Software’s Repository Manager makes sure that enterprise services confirm to appropriate standards and guidelines, providing powerful change management capabilities. It also governs the consumption process, facilitating controlled and measurable asset reuse. When services are deployed, SOA Software’s Service Manager implements and enforces defined policies for security, performance, and reliability to ensure that enterprise services function as intended. SOA Software’s Policy Manager works in concert with these products to keep policy definitions, and associated metadata, consistent as the service matures from planning through development and then into operation.