Service-oriented architecture (SOA) is gaining momentum and companies worldwide are turning to the promise of agility and interoperability a SOA strategy can deliver. As a professional software developer, a thorough understanding of the benefits a SOA approach can deliver is critical – helping you examine when and where a SOA is appropriate and how to build a business-case for SOA in your organization when the time is right. In this paper, we take an objective look at the benefits of SOA, as well as the costs and risks of this architectural approach, and arm you with a list of key questions that will help you determine if SOA makes sense for your project.
The SOA model, leveraging the power of Web services and service orientated development, has captured the attention of organizations worldwide with its promise of interoperability between legacy systems and new applications, and IT decision-makers are turning to this promising technology to enable their business applications to adapt to customer needs and market changes over time. In March 2004, Westbridge Technologies released the results of a survey of 273 Global 1000 and public sector institutions showing that 43 percent of respondents are structuring their development roadmaps to use SOA principals.
More recently it was reported that many companies of all sizes have already adopted SOA or have it on their radar for 2019, according to a report from Forrester Research Inc., in which 116 North American corporate decision makers were surveyed. The Cambridge, Mass.-based research firm found that more than 70% of large enterprises, 28% of medium-sized enterprises and 22% of small to midsized businesses (SMBs) are using SOA today. When factoring in those firms expecting to adopt SOA by year’s end, the numbers soar to 89%, 61% and 40%, respectively. Survey respondents diverged on a number of issues related to how they use SOA. They primarily used SOA for internal integration (37%) and much less for external integration (15%). They also used SOA for multi-channel applications (9%) and strategic business transformation (9%).
So, what exactly is SOA and how does it compare to traditional architectures? SOA isn’t contrary to object-oriented (OO) architectures. Rather, SOA can be viewed as “macro” OO because both models are based on the same key principles. OO introduced the concept of encapsulation – hiding the implementation details of an object behind a well-defined interface. However, in OO, what an object does (its functionality or behavior) is intrinsically tied to the data itself. Over time, professional developers recognized the limitations of this approach and envisioned an alternative in which behavior could be duplicated and evolved outside of data over time. This vision led to the evolution of SOA, an approach where each coherent piece of business logic is split into a specific service at the design stage. Each service isolates behavior from data and has little knowledge of other services beyond what functionality they provide, making it significantly easier to deal with change and delivering agility, re-usability, and integration at the business level. The SOA project lifecycle also differs from that of a traditional application. In contrast to a traditional application, building a service-oriented application requires considerably more discipline and upfront focus on the application design. Skilled architects must think through the best approach to solving the business problem, the most beneficial way to partition functionality into services and the ideal coupling of these services into a working application. This increased focus on the design phase of the project means that it will likely take more time and resources to deliver the first version of a service oriented application. However, the rapid integration and re-usability benefits gained by making this initial investment mean that future enhancements to the SOA application can be delivered faster and with less risk and cost.
Business Case for SOA
While SOA promises agility and a number of other benefits, it is important to look at the full picture, including any trade-offs you will need to make to achieve these benefits. In this section, we’ll take a closer look at the benefits of SOA as well as the costs and risks involved in using this approach to application development.
Benefits of SOA
SOA is gaining momentum because it offers substantial benefits to organizations, including:
- Business agility
- Interoperability with enterprise systems
- Deployment flexibility
- Reusability
- Phased rollout
- Improved end-user experience
Let’s examine each of these benefits in more detail.
Business Agility
By increasing the focus on the design phase of the project, SOA leads to better application design and better design leads to business agility. In contrast to traditional applications, the solid design of SOA applications makes it considerably easier and more efficient to enhance, modify, and extend functionality as needs change over time. Because SOA applications are designed from the start for change, software development teams can adapt them to meet new business requirements in days or weeks rather than in months or years.
With SOA, it is very straightforward to add a new service to enhance your business process or to modify the flow of information between services to reflect a change in work flow. For instance, many organizations today are faced with an increasing barrage of regulatory issues such as meeting Sarbannes-Oxley requirements. This climate is causing constant adjustments in day-to-day processes and controls. As an example, assume that a “hole” in an order-entry process is discovered, requiring an additional audit/approval step prior to shipping a product. Using SOA, the solution can be as simple as inserting one additional notification/approval “node” into the current process, fully addressing the new requirement.
Interoperability with enterprise systems
The purpose of any SOA implementation is to “tie together” existing legacy and new software assets. Organizations can no longer afford the “total rewrite” approach popular in the 1990s, yet they must adapt to constant changes in the competitive and business landscape. SOA offers a unique ability to support this capability. Several technologies exist to interoperate with legacy enterprise systems, including:
Web services exposed by most popular packaged software vendors (e.g., SAP, Oracle Financials, Peoplesoft, etc.). With the rapid expansion of such published interfaces, it becomes increasingly easy to adapt new business processes that incorporate functionality from installed applications. For example, a customer look-up to an ERP application can be used in a SOA-enabled business process design to enable validation and follow-up of sales leads. Several existing tools enable Web services access to legacy applications, including those that run on IBM mainframes, iSeries, and other mid-sized computing platforms. In many cases, programmatic APIs allow legacy developers to expose functionality directly as Web services; in others, intelligent “screen scraping” can be used to expose services via terminal emulation. While direct access is often more efficient, terminal access is the least invasive, and guaranteed to conform to existing application functionality and established security requirements.
Deployment flexibility
Another key benefit of SOA is deployment flexibility, the technical counterpart to business agility. In the SOA model, what the application does is separate from how it is deployed. Optimally, functionality decisions and deployment decisions are almost completely unrelated. This means that developers can code and test on a single machine and deploy on an army of machines without changing code. There’s no need to go back to the development drawing board if deployment requirements change – the services can be adapted “in the wild.” With the advent of the SOA model, vendors have delivered a host of tools to improve the efficiency of service-oriented development. These tools handle many of the complex infrastructure issues that developers had to deal with directly in earlier models, including:
- Message creation and decomposition (understanding the message)
- Message and user authentication and validation
- Message transmission (networking, HTTP, queues, enterprise service bus, etc.)
- Service location management
Because they handle these details, SOA development tools make it very straightforward for developers to deal with technical requirements that frequently occur over the lifecycle of the application such as new hardware platforms, methods of accessing data or load requirements. For example, developers can easily move specific services to new Linux-based hardware or scale the application to handle a 25% increase in users.
Reusability
Re-use can’t be an afterthought – it must be built into a project from the start. To achieve re-use, development teams must consider issues that could hinder reusability during the design phase of the project. The SOA model emphasizes solid application design, and this focus on the design phase means that development teams can take the time to consider issues that will affect reuse. In addition, the use of services enables developers to take advantage of legacy applications, which may house core data and system functionality, but can’t be leveraged in building new applications unless they are exposed as services. The ability to reuse core logic and functionality within legacy applications saves a good deal of time and cost in building new applications that work cooperatively with legacy systems.
Phased rollout
Because SOA applications are modular, they can be developed and deployed in a series of small steps. Rather than postponing deployment until the full feature set is completed, organizations can use a phased approach to deployment, rolling out discrete pieces of functionality as they are finalized. This modular method helps companies bring new services online rapidly, reducing the time to market for even complex projects. For example, consider a call-center application designed to improve efficiency of call-routing and response times. Rather than re-write the entire application, such an organization can start with a single phase of the project, such as caller identification and matching to an existing customer record. Based on this information, the call can be more effectively directed to the right agent, after which the remainder of the process can continue to depend on the existing application functionality.
Improved end-user experience
By delivering business agility and the option to roll out functionality in phases, SOA applications can provide a better experience for end users. With the SOA approach, development teams can quickly deliver enhancements to help ensure that the application closely mirrors the business process as it evolves throughout the lifecycle of the application. In turn, this helps end users of the SOA application do their jobs better and more productively. Why? Because they have access to tools that automate the business process as it exists today rather than having to manually work around a tool that doesn’t support the latest work flow. Many organizations use the “swivel desk” approach to application integration, meaning that a customer service representative must switch between two or more applications in order to handle a customer request. This is common in telecom environments, especially considering the rapid amount of industry consolidation, forcing the use of multiple disparate applications by a single end user. Using SOA tools, developers can create a single work flow for the end user, spanning several distinct applications to provide a unified user experience. This “composite application” paradigm is not new to SOA, but SOA assists in making such capabilities far easier to develop and deliver.
SOA cost and risks
While it’s clear that SOA offers a number of valuable benefits, it’s important to balance the discussion by examining some of the key costs and risks associated with moving to SOA. These include:
- Increased reliance on developer tools and infrastructure
- Higher design costs
- Speed-to-market sacrifice
- New development frontier
- Performance considerations
Let’s examine each of these costs and risks in more detail.
Increased reliance on development tools and infrastructure
In preparing for a SOA environment, many architects quickly come to understand that the efficiency and speed at which a SOA is designed and built relies heavily on the planning and selection of the tools supplied to the development team. The limitations of these tools will inherently affect your SOA design requirements – just as tools engineered to reinforce best practices in design will help preserve your infrastructure standards and extend the longevity, functionality, and flexibility of your SOA. In choosing tools upfront for SOA implementation, it is important to note:
Tools that reinforce good design principles are worth the upfront investment, both to extend the life and usefulness of your SOA and to eliminate the need to spend valuable time writing the infrastructure for your SOA.
Services platform and development tools are much more important in a SOA than in traditional architecture; they play a critical role for the duration of a SOA project development and deployment where transitions are more gradual and done in phases to accommodate a more flexible timeframe and where variables and limitations need to be defined prior to building your application.
SOA development tools can handle much of the infrastructure needs for your organization – which means they can make or break your application. If you clearly understand what tools can and can’t do, you can select tools that meet your project requirements and avoid re-tooling later as your business requirements change.
Higher design costs
A successful SOA deployment relies on a sound and well-thought out approach to application design and construction. It demands attention to detail in areas that developers have not always had the forethought to incorporate. Because flexibility and adaptability to business requirements is the key goal of SOA, applications must be designed to weather change as efficiently as possible. This precipitates the ongoing involvement of the software architect in the early planning and building of a SOA project. These are duties that can’t be offloaded to development resources who do not understand the organization’s business requirements intimately. As you may imagine, the need for these highly-skilled senior architects and professional developers can cause the initial release of a SOA application to be more costly than non-SOA designs. However, this upfront effort will often save money over the life of the application as requirements can be more readily incorporated to meet future needs, and, can greatly ease the maintenance, upkeep, and integration demands often thrust on developers down the road.
Speed-to-market sacrifice
With an increased focus on design and infrastructure, it is not unusual for the first release of a SOAapplication to take additional time to reach the market. As it takes longer to design and architect an application to adapt to change over the life of your business and account for various variables and limitations in your processes, the initial release of a traditional application may be delivered faster than the initial release of a service-based application. That said, as noted above, the likelihood that this time will be made–up over the life of the application is high, and the investment in the initial design of the application will allow for less time-consuming and more efficient modifications and extensibility in the future.
Where additional time-to-market becomes a critical issue in SOA adoption within your organization is in setting up-front expectations with executive management. As it is much easier for a development team to receive approval for a prototype budget or proof of concept that can quickly demonstrate application usefulness, it is more difficult to educate your organization on the long-term benefits and short-term sacrifices SOA brings.
New development frontier
SOA allows for increased agility and helps break-down the barriers to system integration, however, it is also a new and pioneering approach to development. In the early period of any new discipline, it can be difficult to anticipate all of the challenges it may bring, and to find skilled, professional developers who have experience building SOA applications. There are many new elements to a SOA approach, and often times there is a learning curve for developers and architects alike. This is where an experienced consultative tools vendor can be an invaluable asset – helping to identify potential stumbling blocks in the design process and providing best practices and guidelines to help your development team avoid pitfalls. Understanding how a consulting team can help your team take advantage of the tools provided to them, and building in timelines for ramping the team up, are essential steps in preparing for SOA deployment.
Performance considerations
While the SOA model is promising because of its compelling flexibility and agility benefits, these benefits often come at the expense of performance. In a traditional application, messages can be processed almost instantaneously because they occur within the same application – there’s no need to encode/decode the message or send it across the network. In contrast, the services in an SOA application must deal with:
- Encoding – services must speak the same language or undergo costly transformations
- Networking – services need to send messages over the wire
- Reliability – services must validate that messages are properly received and correctly structured
These remote message delivery requirements of SOA can dramatically degrade application performance, particularly when your application involves many messages or huge payloads. While there is no way to avoid the performance overhead of SOA entirely, careful design-time decisions – such as grouping performance-sensitive logic so that it can operate as a single service or as a closely-located set of services – can help reduce the impact. You can also alleviate this problem by selecting SOA development tools that help optimize performance in the key areas of encoding, networking and reliability.
Where does SOA make sense?
So far in this paper, we’ve given you a lot of high-level things to think about as you consider whether or not SOA makes sense for your organization. Now, let’s get down to more concrete questions that will help you determine if SOA makes sense for your specific project. In this section, we’ll raise some questions that will help you determine if SOA makes sense for your particular project. You can use this information to help craft a case to get approval to use SOA for your project or to show that it isn’t the right approach for the situation.
What is the anticipated lifespan of your application?
Because the chief return on investment for SOA design comes as an application evolves over time, SOA may not be appropriate for short-lifespan applications. If you are uncertain as to whether the project at hand involves an application that will be used long enough to reap the rewards of SOA agility, you should consider whether SOA is right for this project. Generally, a good rule of thumb is to ask:
- Will the application be used to solve an ongoing business problem?
- Could the application be used in other areas of the business to solve a similar problem, even if it isn’t needed for a long period of time?
- Will the application be used as an integral part of a larger, more time consuming project?
How critical is this application to your business?
If the SOA application you are designing is intended to enhance your business in a way that directly increases your ability to serve your customer, overcome performance barriers, or break new and innovative ground in accomplishing your company’s primary business objectives, chances are, you are designing an application that is critical to your business. Specific questions developers might ask to this end are:
- Is the application directly tied to customer service or interaction?
- Does your organization require or anticipate a significant increase in message volume thatthe application must process?
- Are the messages processed by the application critical to vital operational areas of the organization?
How much change do you anticipate during the lifespan of this application?
If the application in question is, for the most part, isolated from many of the other systems in your business, or if, over the life of the application, the requirements and demands of the application are relatively stagnant, SOA may not be the most appropriate approach for your project. Where business needs are stable and don’t greatly affect other areas of your operations, an application doesn’t need to grow and evolve substantially over time – the key area of strength for SOA – and a traditional approach may be adequate.
Do you anticipate that your technical requirements for this application will change over time?
SOA is exceptionally valuable when building applications that may undergo significant change in:
- Platform requirements – such as new OS or new hardware
- Load requirements – like an increase or decrease of the volume of users or the volume of transactions
- Integration requirements – including legacy data sources, new business rules and new partners
- Access control requirements – namely secure, stable and multiple levels of data and functionality access
- Scalability – such as use by new areas of your business or modified to meet similar but distinct business challenges
- Business dynamics – including changes to business logic to incorporate new regulations, new industry challenges or new competitive threats
Where IT requirements are concerned, the nature of SOA allows services and software to scale in ways that are less resource and cost prohibitive than continually adding new hardware. And, in today’s business climate where performance and through-put demands grow exponentially each year – the limits ofhardware capacity, governed by the law of physics, will be unable to accommodate these changes the way that software optimization can.
Does your application have an end-user component or is it purely back-end application?
If the application you are designing has an end-user component, it probably has a good deal more moving parts and pieces, and is subject to additional volatility and requirement changes than a backend application. In addition, while the application user interface may need to be adjusted frequently, it may rely on core, stable applications for a majority of its processing and logic power. In this instance, SOA can aide in both easing the pain of frequently changing business flow or logic in applications, while leveraging existing systems and core applications where appropriate.
Conclusion
Service-oriented architecture (SOA) is a powerful method to realize agility and interoperability in software development. Armed with a clear understanding of the business benefits of SOA, as well as when and where a SOA will best fit your organization’s development needs, you can act as a catalyst for innovation and help promote adoption of this useful methodology. Building a business-case for SOA in your organization is critical to help your team understand the costs, risks and long-term value of SOA. By asking smart, insightful questions about the appropriateness of SOA for your specific project at the start of design, you can maximize SOA development efforts. Today, development teams are often faced with changes in business and technical requirements while an application is being designed and built. Architecting an application for change has become just as critical as any other application feature. Many companies are turning to SOA to help them achieve application agility. However, this benefit often comes at the expense of performance. SOA requires remote message delivery, introducing encoding, networking and reliability issues that can dramatically degrade application performance. There are tools on the market today that help address these performance bottlenecks – many of which can also help you achieve efficiencies in building and deploying your SOA applications. In evaluating your application project for SOA appropriateness, you may also want to consider tools of this nature at the onset.