/ciol/media/agency_attachments/c0E28gS06GM3VmrXNw5G.png)
Follow UsAs enterprises rush to assess how they can benefit from service-oriented architecture (SOA), many naturally—but mistakenly—focus on the technology aspects of the solution. As an architecture, it’s unfair to paint SOA as a panacea to independent software vendors’ (ISV) most daunting business problems. In order to determine if SOA is right for your development organization, you must first clearly understand what SOA is (and isn’t), how SOA impacts software development, and the importance of best practices and governance.
Once you’ve made the commitment, it’s important to learn how to utilize assessment tools, maturity models and reference architectures to construct a customized SOA roadmap.
SOA: From the Basics, to Addressing Necessary vs. Sufficient Conditions
Despite all the marketing hype and media attention given to SOA, at many initial consulting engagements there is still a significant amount of education that needs to happen, with questions such as: What exactly is SOA? How can it benefit our organization? How do we know if it’s right for us,and where and how do we get started?
SOA is one of many development architectures, like object-oriented, resource-oriented or message-oriented. Considered the next natural evolution of these existing architectural paradigms, SOA is a way of looking at building enterprise systems based on services. One of the key drivers for SOA adoption is companies’ desire to build more flexible and agile systems to support changing business dynamics caused by new customer demands and increased competition. More specifically, SOA is the link between enabling changes to back-end systems, while allowing front-end services to remain intact—and keeping technology out of the equation. Remember, SOA is an architecture, not a technology.
From a provider’s perspective, the key to unlocking SOA’s potential for your enterprise is based upon understanding and evaluating “necessary versus sufficient” conditions for success.
There are “sufficient” characteristics you need, such as systematic adoption of SOA through maturity models, and the selection of a technology stack such as Oracle or IBM, which can be established in order to maximize the chances of success. However, their presence alone does not guarantee success. The failure of many SOA projects can be traced directly back to several missing “necessary” characteristics: lack of understanding about how SOA is different (for example, differentiating service-oriented versus object-oriented versus data-oriented); lack of SOA governance; and the lack of an appropriate software development lifecycle (SDLC) methodology.
The first steps to benefiting from SOA come with the recognition of what results can be reasonably expected. Looking at SOA as an architectural approach to developing software, we strongly believe that SOA can deliver more than just simple problem solving related to cost of development, quality and revenue. It can help organizations achieve new results derived from more agile applications that support new partnerships, drive new revenue streams and create freedom from closed, rigid applications.
Assessing SOA Readiness
Many organizations that think they will benefit from SOA often don’t, or can’t. And while there are no hard and fast rules about what makes a deployment the perfect SOA deployment, there are some general guidelines for assessing SOA-ready environments:
Clearly defined services: Companies must be able to chunk their operations into well-defined services; if you can’t define your services, you don’t need SOA
* Measuring time vs. business value: If the amount of work it takes to orchestrate and choreograph services is significantly more than their value, SOA isn’t for you. The value of services come not from the way they are built, but through the realization of business benefits that only comes through extended usage.
Many organizations benefit from SOA assessment tools that are built to help identify key organizational and technology aspects essential to both mitigate risks and maximize opportunities for SOA. These assessments are used to identify potential areas of improvement and should be used in conjunction with a SOA Maturity Model to focus future efforts. SOA readiness is determined by focusing on key areas such as SOA governance, software development lifecycle and architecture. Combined with a business readiness assessment that includes business sponsorship, strategy and SOA awareness, companies are able to determine their level of SOA maturity. It’s a starting point to constructing a customized SOA roadmap; one size does not fit all.
SOA Pushes Beyond Traditional Software Development Mindsets
SOA changes not only the way in which systems are developed, but who they are developed by. In traditional architectures, business processes and functionality are mostly implemented through developers. For example, when implementing logic that enables client service representative to get access to current work orders, developers often create a series of static method invocations between business objects. Once coded, the project is compiled, tested and deployed. This realization of the new business capabilities is in the hands of software developers.
In the SOA world, new business activities or changes to existing practices can often be implemented directly from the modeling activities performed by business analysts. Through business process choreography, new workflows can be made of out existing services captured as changes made to its Business Process Execution Language (BPEL). This is more of a configuration of process direction rather than customization of business code.
It’s also important to note that in addition to the changes to requirements analysis, design and testing, services need to be well defined, easily discoverable, well-behaved and very reliable. But with emphasis on building these reliable and dependable services comes distinct testing challenges. In traditional software development, it’s easy to test code, but testing their interaction on a large scale can be a problem. As the number of services choreographed within a given environment increase, the number of potential interaction increases exponentially. These composite systems can grow to a point where an emergent behavior is much different than that expected from their composited services.
As of today, SOA moving into a second generation of sorts, powered by more dynamic environments supported by BPEL that focuses on the functional aspects of business processes. Increasingly, the types of applications and systems clients are considering are more dynamic in nature, including those in heavily regulated, transaction-oriented environments, such as financial services, that are looking to address their structured computing environments with a more modern architecture.
SOA and BPEL can help inject workflow into a distributed service environment. As a result, there are increasingly interesting opportunities in highly workflow-oriented environments that have modular components that need to be orchestrated, while dealing with regulations and external governance challenges.
About Jerry Smith:
Jerry Smith is chief technology officer for Symphony Services, a provider of product engineering outsourcing services. Of his degrees, Smith has master's and postdoctoral degrees in computer science from NOVA Southeastern University and a naval nuclear power degree from the U.S. Navy, in which he served as a pilot, nuclear engineer and project engineer.