 | Level: Introductory Editorial staff (dwinfo@us.ibm.com), developerWorks, IBM
15 Nov 2005 Tune in to the insight and outlook of IBM visionaries and leading technical practitioners as they comment on issues facing IT architects today and in the future. This month they respond to the question, Why should you care about SOA, and when is it the right choice and when is it the wrong choice?
Welcome to the Insight and outlook column
Welcome to the debut installment of Insight and outlook, the developerWorks column where IBM technical experts provide guidance on the pressing issues IT architects need to solve to get their work done. Every month or so, we poll the internal IBM architect community -- including our best-known visionaries, contributors to standards groups, architects on our product teams, and consultants who work with customers every day -- and we invite them to share their ideas about the most important questions facing today's IT and software architect.
Their answers are intended to help you, to intrigue you, and to involve you -- whether you are the architect of a large team that is spread out across the globe or whether you are just starting to learn the art and practice of IT architecture. They are not meant to be comprehensive. For additional guidance on topics covered here, you'll want to look at the IT Architecture resource round-up, another part of the developerWorks Architecture area. Also, if you have specific questions for the experts or want to continue the conversation started here, go to the developerWorks IT architecture discussion forum.
Introduction
Service-Oriented Architecture (SOA) has become a de facto standard for developing component-based applications that can be accessed over the network (whether the Internet or some other network) using standard interfaces. At least that's what IBM executives say, along with many other platform vendors, analysts, consultants, and software developers. They would also tell you that the entire industry is adopting SOA, and that if you haven't begun SOA development, you'll soon be left behind.
Stirring words. But are they compelling enough to convince you to start down the path toward your own SOA? Take the question of an architect attending an SOA conference hosted by the Open Group. During the question and answer period following IBM Global Services Vice President Michael Liebow's keynote address, the architect asked, "Is SOA the only architectural style we need to know about?" (By the way, Mr. Liebow answered, "Yes.") Later during the event, another architect wondered aloud: "SOA sounds a lot like the component architectures we've heard about for years. If we adopt it are we just adding one more technical silo -- another development dead end -- that will require more integration down the road?" (By the way, the answer by attendees -- including platform vendors, enterprise IT architects, consultants, systems integrators, and others -- was a resounding "No.")
Which takes us to the question posed to our experts this month. If you're like many architects IBM has talked to recently, you are somewhere along in the process of evaluating and even adopting SOA. But you are probably still wondering if this is just the architectural style du jour, soon to be replaced by something more fashionable, or if this is The Real Thing.
Our experts' responses include many of the arguments you've heard before: that SOA promotes reusability, provides a level of abstractions between interfaces and implementation to minimize dependencies, aligns business needs with IT functionality, gives you a mechanism to translate business requirements into programmatic services to automate processes, provides flexibility required in today's competitive, quickly changing business environment, and so on. But these experts also provide fresh ideas based on their practical experience working with development practitioners inside and out of IBM's confines, perspectives that will help you understand when, how, and even why SOA can fit in to your IT architecture and development plans.
A quick note of thanks to Holt Adams, the contributing editor for this month's column. Holt, an experienced IT architect on the IBM Software Group team, guided the internal IBM community to provide the responses you are about to read. He also contributed his own answer, "When -- and when not -- to pursue SOA."
Without further ado, I'll stand back and let our experts speak. (For more information about our respondents, see About the experts at the end of this column.) We invite your comments about SOA. You can either visit our IT architecture discussion forum, or e-mail me at pdreyfus@us.ibm.com.
Paul Dreyfus, Editor
developerWorks SOA and Web services
When -- and when not -- to pursue SOA
One of IBM's goals is the development and adoption of open standards within its products. This enables the value proposition of SOA to be realized within your company's IT infrastructure. SOA promises to optimize the alignment of business needs with IT, decouple business process activities from service implementations, and reduce operational costs. These capacities can only truly be accomplished without vendor lock-in, when technologies targeted for SOA implementations are able to integrate seamlessly (Think: "open standards") to construct comprehensive end-to-end solutions.
|
The decision to implement SOA should not be taken lightly. It is similar to committing to a lifestyle change because the IT governance to which your development and operational teams adhere to will be quite different.
-- Holt Adams
|
|
On whiteboards and on paper, the concepts of SOA can be very compelling and more easily justified when strategic business goals and initiatives are taken into consideration. However, the decision to implement SOA should not be taken lightly. It is similar to committing to a lifestyle change because the IT governance to which your development and operational teams adhere to will be quite different. I'm an advocate for business-driven development. The process involves refining business needs to IT requirements, and then IT requirements to IT capabilities in order to identify technology to address the needs. Based on my experience during the past four years in developing Web services-based solutions and more mature SOA-based solutions, the following are relevant factors that often guide me to recommend a Service-Oriented Architecture:
- Integration costs continue to grow without being offset by new business opportunities that provide a real return on investment (ROI).
- Mergers and acquisitions are central to your company's business model for growing market share and pursuing new opportunities.
- Solutions require the integration of business capability from disparate systems and programming models.
- Livelihood of your business depends on your ability to adjust quickly to changes in the marketplace or immediately respond to competitive threats.
- Impact of our global economy necessitates that your company does more with less and that your company relies on business partners to provide non-core business functions.
- Efficiency of working with business partners is critical for your company in driving revenue.
- Value of your company's business assets are diminished because they are not assessable for reuse outside their original purpose.
- Efficiency of your company's employees is in question because they don't spend the majority of their time delivering capabilities or services that are core to your company's business model.
- Your company's business thrives on opportunistic business endeavors.
- Your company develops new applications from scratch. (My belief is that SOA should be a default architectural style to position new applications for the future, unless business conditions dictate otherwise.)
In an ideal world where there are no budget constraints, schedule deadlines, skill gaps, and priority differences between you and your business partners, I think it's safe to say that everyone would be adopting SOA, or at least, would have plans to adopt it. However, in the real world our choices are often influenced and limited by past decisions (for example, investment in technology, adoption of programming models, contractual agreements of services). As a result, we are not always at liberty to make what appears to be the perfect choice for addressing a business need or technical requirement. The following considerations steer me away from not recommending a Service-Oriented Architecture or indicate marginal benefits from implementing SOA today:
- A small percentage of your company's IT budget is spent on integration activities.
- A majority of your company's processes are manual or document-centric, with little opportunity for automation.
- A large majority of your company's application development utilizes the same programming model.
- The operation of your company is managed by one or two customer relationship managment (CRM) and enterprise resource planning (ERP) applications with little integration requirements.
- There is a significant mismatch between your company's existing skill base and that which is needed to implement an infrastructure to support SOA.
- A clear business need or opportunity has not been identified that would benefit from the IT capabilities offered by SOA.
- An existing revenue stream would be adversely affected due to the availability of new business services.
- Business partners with whom your company relies upon have different priorities about automating intercompany processes.
- Your company's primary business revolves around extremely high-volume, synchronous, real-time transactions.
The preceding lists are only a sampling of reasons for whether SOA is either the right choice or possibly not the best choice for your company. Of course, every engagement or project brings unique requirements, so the decision about when to adopt SOA depends on your company's business situation. The value proposition of SOA is hard to trump, but choosing when to commit your company to embrace SOA must be balanced by the reality of your business environment. The adoption of SOA doesn't have to be one large leap, but typically is done in small steps. Finding a project where you can leverage the concepts and principles of SOA and then measure its value with key performance indicators is powerful in cultivating a community of stakeholders.
Aligning business and IT
SOA is more than a development paradigm. It is about bringing business and IT together in a neutral zone where both can agree on a set of business-aligned IT services that collectively fulfill an organization's business processes and goals. This paradigm provides an unprecedented degree of flexibility: It enables isolation of the structural composition of business processes from the services that provide functionality for each activity in the flow. It also enables separation of the implementation of a service from its description. This separation allows a business to incrementally change its back-end legacy systems and add new capabilities to support new requirements, without having to be locked into a vendor decision. So packages and custom applications can be replaced with minimal impact on business processes and IT systems.
SOA is the next step in the effort to decouple the means of accessing functionality from its implementation. What's more, beyond this functional aspect, we can externalize nonfunctional aspects. For example, we can determine who should have access to a given piece of functionality, based on established business policies. We can also define how to manage a technical resource we want to access in a flexible and recomposable manner.
|
Real-time or reactive systems typically are not a good choice for implementation using SOA technologies, since current technologies preclude the use of SOA for real-time systems with high-volume concurrent usage. The modeling of those systems, however, may benefit from the decoupling and separation of concerns that SOA provides.
-- Ali Arsanjani
|
|
This architecture is the next step in the evolution of software engineering. It takes us from structured objects to distributed objects and components, and then to aligning business and IT around a common set of services that collectively fulfill an organization's processes and goals. SOA also allows the exposure of parts of a company's business process to partners in an ecosystem.
SOA is applicable when IT flexibility to support business flexibility is the goal. Thus, a good fit for SOA would be an industrial application where two programs need to communicate and access composite business processes.
Real-time or reactive systems typically are not a good choice for implementation using SOA technologies, since current technologies preclude the use of SOA for real-time systems with high-volume concurrent usage. The modeling of those systems, however, may benefit from the decoupling and separation of concerns that SOA provides.
SOA is ideal for eliminating redundancy and aligning business and IT functionality that is not tightly coupled to specific realizations of a service. It can allow a service consumer to choose alternative service providers based not only on functionality (I need similar functionality but without the extra dependencies present in this version of the service), but on a choice of design and runtime policies and Web services management capabilities.
Companies whose enterprise architecture is based on SOA have a solid basis for conceptually abstracting business capabilities from existing systems. They also have a foundation for allowing business-driven IT transformation to incrementally occur as new packages, systems, and assets are made available and as new requirements come to light.
An important but insufficient mechanism
In the enterprise space, a considerable amount of innovation is happening in two dimensions: on the edges of the enterprise and in the spaces between enterprises. On the edges, we see energy being spent in frameworks that live above middleware (domain-independent ones, such as Ajax, as well as domain-specific ones, aligned around specific industries) and those that work in conjunction with devices [classical mobile devices and devices with Radio Frequency Identification (RFID) tags]. In the spaces between, we see the formation of systems of systems (both legacy and new systems).
|
On the edges, services deliver behavior in a manner that transcends the underlying technology. In the spaces, services provide a powerful means of semantically rich communication between systems of various kinds.
-- Grady Booch
|
|
In the context of such Web-centric systems, services have proven to be an essential mechanism in both dimensions. On the edges, services deliver behavior in a manner that transcends the underlying technology. In the spaces, services provide a powerful means of semantically rich communication between systems of various kinds.
That being said, services are an important but insufficient mechanism for the construction of systems. This statement is a gross simplification, but in general, services are less well-suited for high-frequency or very small-grained connections. Furthermore, services are certainly not the only mechanism of decomposition suitable for the architecture of individual systems.
SOA, Web services, and maintaining your advantage
SOA is an overloaded acronym which is used (and abused) by a spectrum of people from executives to developers to convey multiple (and sometimes, inconsistent) semantics. From my perspective, a Service-Oriented Architecture is a framework for integrating business processes and the supporting technology infrastructure as standardized and well-managed components -- services -- that can be composed, reused, and adapted to address changing business priorities.
The novice SOA practitioner thinks that SOA and Web services are equivalent. There can be valid SOA-based solutions that do not leverage a single Web service and instead use existing IT assets ranging from mainframe transactions to object-based systems. Additionally, I have seen several Web service implementations sprouting at departmental levels that are not valid SOA applications. These islands of Web services typically do not adhere to all the core SOA principles and characteristics -- they may not be loosely coupled, abstracted, reusable, componentized, or platform- and protocol-neutral, and most important, they may not provide true business value.
Since Web services provides a level field for infrastructure and application vendors to innovate and interoperate, a slew of specifications, profiles, buzzwords, has claimed enough limelight to propagate this confusion. Web services is merely a collection of standards and technologies, among many other technology-enabling options, to realize SOA-based solutions.
With the fast-paced global economy, an enterprise must be flexible and agile to maintain its competitive advantage. Aligning IT infrastructure with the core enterprise processes using SOA principles can provide and sustain this edge. So the question of understanding and adopting SOA is not of how or why, but when? SOA-based enterprise solutions have proven to streamline business operations, improve productivity, reduce costs, and remove redundancies.
|
We are at a cusp of revolutionizing all aspects of a solution life cycle and SOA has been a critical catalyst. However, if we're not careful, this abstraction and ease-of-use could, in the long run, make IT architects or developers unable to reconnect with the fundamental foundations of computer science and technology.
-- Sanjay Bose
|
|
However, to reap these benefits, SOA has to be applied correctly. It must accompany an enterprise-wide vision and transformation roadmap, be nurtured by business executive funding and commitment, and propelled to deployment by seasoned architects in an incremental and iterative fashion. These incremental steps should initially target the critical business issues and the resultant solution should deliver business value. This helps to sustain and fuel end-to-end enterprise transformation using SOA. And along the adoption path, SOA will constantly meet severe challenges, including the political and cultural variety.
From a pure technology standpoint, the SOA platform (both tooling and runtime) is also undergoing tremendous transformation. The development tooling environment has a wide palette of modeling facilities, industry-hardened scenarios, reusable patterns, recipes, and rich visual representation and controls, along with simulation techniques. The runtimes are also keeping pace by providing enhanced qualities of service, declarative and policy-based administration, and eye-catching management and monitoring dashboards (for both IT and business events), and instrumented with autonomic, self-healing facilities. We are at a cusp of revolutionizing all aspects of a solution life cycle and SOA has been a critical catalyst. However, if we're not careful, this abstraction and ease-of-use could, in the long run, make IT architects or developers unable to reconnect with the fundamental foundations of computer science and technology.
[Editor's note: Additional views on this subject can be found in a book recently coauthored by Sanjay Bose,
SOA Compass: Business Value, Planning, and Enterprise Roadmap
, part of the developerWorks series of books jointly published by IBM Press and Prentice-Hall.
Model-driven development and the virtual enterprise
You have probably already chosen SOA. Most middle- to large-size companies have applied elements of SOA in their application design. Well-structured CICS® and IMS™ programs often conform to SOA. Many companies have built distributed systems composed of message-driven applications. Session Enterprise JavaBeans are "SOA like." Many ISV systems surface service-like constructs; for example, SAP IDocs. SOA codifies guidance on well-structured distributed systems, and it is a natural evolution of structured programming, a subset of object-oriented (OO) concepts and message-driven processing.
|
In a very short time, our industry has achieved an unprecedented level of runtime interoperability and interoperability between development tools. This interoperability reduces the cost of moving to SOA, making its benefits easier to obtain.
-- Don Ferguson
|
|
Web services are a set of standards for building SOA solutions. Infrastructure vendors (IBM, BEA, Microsoft) and application vendors (SAP, Oracle) are adopting Web services as rapidly as any software technology. In a very short time, our industry has achieved an unprecedented level of runtime interoperability [Simple Object Access Protocol (SOAP), HTTP, WS-Security, WS-ReliableMessaging] and interoperability between development tools [Web Services Description Language (WSDL), WS-Policy, Business Process Execution Language for Web Services (BPEL4WS)]. The interoperability reduces the cost of moving to SOA, making its benefits easier to obtain.
What are these benefits? Space precludes discussing them all or any individual benefit in detail. I will focus on a brief summary of two benefits:
- SOA enables model-driven development and solution monitoring from a business perspective. We have made significant progress with WebSphere® Business Modeler by producing a tool that allows analysts and business professionals to reason about and design their business processes. SOA operations are a natural rendering of tasks or steps in a process, and composite service implementations (BPEL4WS, business state machines) are natural representations of the processes. WS-Policy and implemention of services according to simple business rules, which we enable with WebSphere Process Server, are approaches that are natural representations of business policies.
- Web services enable the "virtual enterprise." Previous technologies like MQ and Common Object Request Broker Architecture (CORBA) were optimized primarily for intra-enterprise computing. Web service protocols and WSDL work over the Internet and internal networks. This allows simple, rapidly developed, opportunistic business-to-business over the Internet in the same model previously used for intra-enterprise application integration.
 |
An issue of governance
SOA is similar to the other software modularization processes that have been around the IT industry for 30 years or more. The difference with SOA is that the hardware and the network have matured enough to support this standards-based technology. From all appearances, SOA is not the buzzword technology of past juggernauts that have burned through the industry, but has a broad base of industry standards and support.
SOA provides an enterprise with the opportunity to identify its core competencies and to decide whether or not to offer those core competencies as services to its industry and business partners. The flip side is also true; an enterprise can identify those processes and applications that it uses as part of its core infrastructure that are not core competencies and decide to purchase them. Note that some of these services, offered or purchased, could be business processes only. The enterprise architect can lead the engagement to find business and IT processes that have common sets of function across the enterprise. Those functions can be packaged into components with a low degree of external dependencies and offered as services. This makes the job of the business process creator or application developer streamlined to focus on the unique function that satisfies the business drivers of the stakeholders.
| Making SOA work is largely not a technical issue. Making SOA work is a business governance and IT governance issue.
-- David K. Jackson |
|
Making SOA work is largely not a technical issue. Making SOA work is a business governance and IT governance issue. The technical specialists can construct an implementation of SOA from the many successful patterns that exist. Getting the enterprise to use those services instead of recreating their own is another matter. Proper architectural governance will identify those projects where services are available for use by a new application. Having the executive commitment to control the budget or in some other manner keep the lines of business from "doing their own thing" is the only way to make the investment in SOA pay off. The IT architect also needs to report to the executive stakeholders on the value the business has received from its investment and commitment to SOA.
Making SOA work with business partners is about the established relationships an enterprise already has. Very few, if any, customers today are offering or buying services to partners outside their established contractual relationships. Matters of service-level agreements and dispute resolution make a contractual closed-loop system necessary. The Organization for the Advancement of Structured Information Systems (OASIS) standards for trust and security have come a long way in the past two years, but the legal and business sides of the equation still favor doing this kind of business with people the enterprise already knows.
No magic here
There are three simple reasons why you should care about SOA:
1. This is the one of the hottest areas right now; don't get left behind.
2. The tools, infrastructure, and standards are coming together to support the end-to-end SOA life cycle. Check out our end-to-end programming model. Follow the step-by-step recipes and draw on the success stories and experiences you'll find there.
3. If you are like us -- constantly being asked to do more with less -- then SOA can help you. Look around for things you can use again; don't go do everything from scratch. Look for existing services, adapt, and consume. Then share some of your services. Help create an ecosystem so that more interesting solutions can be assembled more quickly in the future.
| Common sense applies. If your project is on a critical path and your team has to go through a steep learning curve with the tools and the APIs, SOA is probably the wrong choice. If you can pilot SOA in a small project, then it is a good choice.
-- Christina Lau
|
|
Getting into SOA is no different from getting into any other technologies or architectures. Common sense applies. If your project is on a critical path and your team has to go through a steep learning curve with the tools and the APIs, it's probably a wrong choice. If you can pilot SOA in a small project, then it is a good choice; use that experience to help you define and scale to the next bigger project. Small incremental steps...no magic here.
It is simply business
Proponents of SOA continuously and relentlessly drive home the main technical impetus of SOA as being loosely bound, with the ability to encapsulate reusable business functions through components, and last -- but not with the usual fanfare -- providing greater integration.
Include me as one of the proponents of SOA, but I keep asking myself, Do customers really care about this technical reasoning?
For the last two years, I've been working solely with customers who are trying to get their arms around the value proposition that SOA yields. In many instances during my dialog with customers, I've determined that customers believe that there are many alternative architectures that provide much of the technical value that I just mentioned. Some would conclude passionately that a very skilled and experienced architect and development team could obtain much of the value using traditional enterprise application integration (EAI) architectures. Many would argue that those approaches are proven and the implementation risk is not nearly as great as architecting simply around SOA.
|
We should look at each problem objectively, as though we have no idea what the solution might be. Determine whether SOA should or shouldn't be the answer based on both its technical and business merit.
-- Calvin Lawrence
|
|
This view might cause an architect to consider that there are circumstances when SOA is the wrong choice or at least, not the best choice. Is the technical viability of SOA the reason for selecting it as the architectural approach to solve a set of business problems? I would say not: Many business- and IT-related hurdles, like the lack of a strong enterprise governance model and policy, will slow down or halt the implementation of any well-thought-out technical SOA initiative.
A chief technology officer (CTO) in the automobile industry recently told me the following during a three-day SOA workshop: "My SOA mantra is 'It is simply business.'" He told me that his drivers for SOA adoption are:
- Increasing the speed at which he and his team can implement new products and processes or change existing ones
- Reducing implementation and ownership costs
- Enabling flexible pricing models by outsourcing elements of the business or moving from fixed to variable pricing, based on transaction volumes
- Simplifying the integration work that is required by mergers and acquisitions
- Achieving better IT utilization and return on investment
The CTO and his team only cared about how they could reach these goals within budget, within schedule, with their existing skills, and without having to abandon their existing infrastructure. They had already made a tremendous investment in their existing EAI infrastructure.
The words of this particular CTO are not unlike many others. They only care about the bottom line: How do I provide returns back to my stakeholders?
Of course, as an experienced architect (I'm smiling), I had a few architectural alternatives to solving this problem:
- Extend their existing EAI infrastructure
- Propose more of an event-driven architecture (totally decoupled, publish/subscribe, and so on)
- Maybe SOA
Since this was an SOA workshop and the customer was paying (I'm smiling again), my initial thoughts were on option three. Actually, for this one, I used a little EAI, a little event-driven, and a lot of SOA. SOA allows for the inclusion of both EAI and event-driven approaches when necessary.
With the fast-paced automobile industry, the enterprise had to be agile and flexible to maintain its competitive edge and deliver products on time and under budget. The customer's pain points centered on managing and amalgamating their business processes. As my colleagues point out elsewhere in this discussion, aligning IT infrastructure with the core business processes was critical to getting to the end of the job. The principles around SOA are proven to streamline business operations by reducing redundancies that many times have very little to do with actual code, but instead center around human interactions and activity. In this capital-limited business climate, few customers have unlimited funds to throw at solving a particular business problem, and fewer have the time and desire to revamp their governance processes. Doing so sounds good, but it won't happen.
The key is leveraging and extending existing infrastructure, processes, and the existing governance model. Existing SOA principles, when properly used, allow for the management of the complete design and implementation process, as follows:
- Identify the problems.
- Identify the processes that make up your business and represent the pain.
- Model those processes in hopes of streamlining them.
- Identify existing services and write others that represent those processes.
- Deploy those services in an environment that provides runtime capabilities with operational efficiencies.
- Monitor those services and processes to gain further efficiencies.
The net? We should look at each problem objectively, as though we have no idea what the solution might be. Determine whether SOA should or shouldn't be the answer based on both its technical and business merit. When appropriate, use it. When not appropriate, don't use it. SOA concepts and principles will always find their way into your architecture in some way or fashion.
The road ahead
We should all know by now the industry mantra for the ROI and adoption of SOA -- loose coupling, greater reuse, faster time to market, ease of integration, and greater interoperability. However, it is important to understand that our current focus on SOA is just one important step in the journey toward a plug-and-play enterprise -- or rather, an on demand enterprise.
As we move toward the next decade, we will begin to realize a significant reduction in the amount of work needed to combine products or components from different IT vendors into a viable and valuable end-to-end solution. Vendor-provided business components will be infrastructure agnostic and will execute on a variety of platforms. As a result, software developers will be more focused on effectively integrating vendor components and ensuring effective interoperability.
|
The individuals who will staff the IT business operations department will belong to the evolving disciplines of the business and enterprise architecture professions. No matter your definition of a business or enterprise architect: The industry will need many more individuals that have a background in IT and enterprise architecture in order to realize this vision.
-- Andras Szakal
|
|
Customer's IT operations departments will be primarily concerned with selecting the runtime platform that best suits the needs of the business; that is, the platform that provides the necessary qualities of services and runtime support needed to properly deploy and manage the business components.
Conversely, the IT business operations department will focus on realizing the organization's business strategy by defining the business rules contained in business components that will be deployed and managed by their operations counterpart. This will be accomplished through business process management systems like WebSphere Business Process Server.
The individuals who will staff the IT business operations department will belong to the evolving disciplines of the business and enterprise architecture professions. No matter your definition of a business or enterprise architect: The industry will need many more individuals that have a background in IT and enterprise architecture in order to realize this vision.
As compelling as this vision may be, there are significant risks we must carefully mitigate before we can continue to move down the path toward component nirvana. Arguably the most important method to mitigating risk as we embark on the mission of realizing a Service-Oriented
Architecture requires a strong well-managed governance processes and policies. Only through strong enterprise service governance polices will we avoid change management problems, semantic mismatches between services, and difficult-to-debug problems that arise from functional cohesion between systems. IT departments can mitigate these risks through disciplined governance policies that are sponsored and supported by an executive oversight team that includes the CIO, CTO, and line-of-business executives.
Improving information
OK, you've heard about SOA. You've heard about Web services, the importance of business processes, model-driven architecture, and all these funky WS-* standards.
But perhaps you're an information person. Someone responsible for the integrity and analysis of an organization's information. Someone concerned about the performance and stability of the databases that represent the state of the business. You know, the really important stuff. And so you might ask, "Why should I care about SOA?"
|
SOA represents a contract that is not just between service providers and consumers, but also between the information providers and consumers.
-- Dan Wolfson
|
|
As an information person, I care about SOA. I care because SOA has the potential for both direct and indirect impact on the information management systems -- and, in fact, on the information itself. To be successful, we need to think about business services in the context of the information they touch. We need to know that the information being retrieved is accurate. That the information being updated is validated. That the information being exchanged means the same to both the service provider and consumer. If we ignore these things, then the value and reusability of the services diminish.
From a direct point of view, as we do SOA, we need to formalize the information contract between providers and consumers so that we promote convergence of information meaning, yet support heterogeneity -- in other words, we have to assume that the world is messy and take the opportunities that we have to clean it up to enhance the value of the information, to understand the relationships between divergent structures and meanings, and to agree on common objects where possible.
Exposing information as a service also will influence us to have additional topologies of information servers to accommodate increased load. It will also cause us to establish points at which we can virtualize access to the information (so that users don't need to know where the information really is or how it is organized). It will also introduce methods that will enable us to combine this information efficiently -- through aggregation or federation. If we don't establish more commonality or introduce improved cleansing, then we can easily be forced to spend a huge amount of additional money and resources to clean it up later -- and reduce our future flexibility.
There are many ways to implement the information contract. One that is becoming increasingly important is the area of master data management (MDM). MDM systems provide clean, consolidated, domain-specific information to business applications or services. The most common MDM systems serve as information hubs for customer and product information. Each hub serves as a central point at which information can be added, updated, audited, cleansed, searched, and queried. The hubs are places where changes can be propagated to related databases or events can be generated to interested services. MDM systems can be transactional (update in the mainline of operational business processes) as well as referential (providing a coherent source of information referenced by business processes). But most important, we can view MDM systems as themselves providing a consistent set of services to be used and reused within a variety of business processes.
Explicitly implementing the contract between information providers and consumers through approaches such as MDM can help us to implement the flexible business processes and service reusability promised by SOA -- and at the same time provides us the opportunity to improve the quality of the information we manage.
The good, the bad, and when to be careful
SOA is an organized approach for applying to application architecture a combination of service orientation and distributed object computing. Let's break that down. Application architecture is the broad organization of parts of an application, often realized as layers or tiers. The architecture specifies what those parts are and how they work together. Service orientation encapsulates functionality into services -- broad, reusable tasks that run without any prior context other than the current domain state of the system hosting the services. A service's context is provided as parameters passed from the caller, much like the parameters in a function call. Distributed objects run in separate processes in such a way that an object in one process can invoke a method on an object in another process.
| Services enable access to well-encapsulated functionality that is exposed through a well-defined API of broad tasks, enabling high reuse of functionality through a low frequency of invocations. SOA is, perhaps, the best of all worlds.
-- Bobby Woolf |
|
SOA adds service orientation to distributed objects, enabling a service to be invoked between processes. It is an approach for architecting applications so that parts of the application can run in different processes and so that different applications can share and reuse running parts. It is an evolution of distributed object computing that seeks to better balance several opposing forces: applications need to access each others' functionality; applications need to encapsulate their own functionality; applications need to limit the commitments expressed in their application program interfaces (APIs); and interacting applications need to limit distributed invocations. Services enable access to well-encapsulated functionality that is exposed through a well-defined API of broad tasks, enabling high reuse of functionality through a low frequency of invocations. SOA is, perhaps, the best of all worlds.
Here are some quick tips for when SOA tends to be a good idea or a bad idea and when you need to be careful.
First, the good:
- When your data is highly distributed, use SOA. Locate the code that manipulates the data close to the data, then wrap it as services to make it accessible from anywhere.
- When you want functionality to be highly available, use SOA. Deploy the functionality as services in multiple, redundant providers so that some are available even when others are not.
- When parts of an application need to be developed, maintained, and updated independently, use SOA. Each team, such as two different business-to-business (B2B) companies, can develop and redeploy each part using its favorite technology and do so on its own schedule, as long as the interfaces between parts are maintained.
- When multiple applications need to reuse functionality and data, use SOA. Shared code reuses functionality only; services enable separate applications to reuse a shared set of enterprise data without having to distribute the data to all applications.
Now the bad:
- When you want your development to be as simple as possible, don't use SOA. An application implemented in a single language, running in a single process, and with no remote access issues is less complex, so it's easier to build and debug.
- When you want your operational environment to be as simple as possible, don't use SOA. Loosely coupled, event-driven, distributed applications are much more difficult to troubleshoot, requiring a thorough understanding of the application implementation details and details about the operational environment's configuration and its current state.
- When your network is unreliable or slow, don't use SOA. Service components run on separate computers and communicate across the network, and therefore are only as fast and reliable as those other computers and the network that connects them.
(Note: Distributed, redundant services can help compensate for hardware unreliability and network latency.)
- When prototyping, don't use SOA. Prototype development should be simple, which SOA is not.
As for when you need to be careful, frankly, you always need to be careful. Here are some specifics:
- When your service interfaces are uncertain, use SOA cautiously. Service interfaces enable consumers and providers to change independently, but the interfaces themselves must be stable. Evolution of interfaces is more complex in SOA than within a single application, especially an undistributed application, because so many otherwise unrelated development teams must coordinate on changes to the interfaces.
- When security is paramount, use SOA cautiously. Each service is a new point of vulnerability that must be secured. The more people who can more easily access the service, such as one that can be invoked on the public Internet, the more people who can attempt to hack the service.
- When performance is paramount, use SOA cautiously. Each service invocation between processes is much slower than an in-process method invocation.
- When you want functionality to be highly available, use SOA cautiously. As stated, redundant services can increase reliability; but at the same time, more moving parts create more opportunity for failure. An SOA application is only as reliable as its services.
These lists are far from exhaustive, but I hope they help give you a better idea of what SOA is and what it's good for. If you need skilled help with this, check out IBM Software Services for WebSphere where you can find a variety of resources.
Good luck!
About the experts
Holt Adams
Holt Adams is an Executive IT Architect on the IBM Software Group Emerging Technology team where he's currently supporting IBM's jStart Program and Customer Innovation Team. As a Solution Consultant IT Architect, responsibilities include combining customers' business requirements with emerging technologies yet to be incorporated or newly incorporated into IBM products. During his tenure in the jStart Program and other services-related jobs, his technology portfolio has included Wireless/Pervasive Computing, Internet Infrastructure, Java/J2EE, XML, Web Services/SOA, Rich Internet Applications, and LAMP technologies. He is also the Contributing Editor to this month's Insight and Outlook column.
Ali Arsanjani
Ali Arsanjani, PhD, is Chief Architect for the SOA and Web Services Center of Excellence within IBM Global Services, specializing in harvesting and developing best practices for the modeling, analysis, design and implementation of SOA and Web services. He leads the internal IBM worldwide SOA and Web Services Community of Practice (4000 members) and is the principal author of the (Service-Oriented Modeling and Architecture) SOMA method for SOA. He is currently focusing on SOA Tooling with support for Modeling (SOMA), Assessments, Strategy and Planning, Governance, Architecture and Realization and their practical application to engagements inside and outside of IBM. Read his blog, Best Practices in Service-Oriented Architecture.
Grady Booch
Grady is an IBM Fellow who has served as architect and architectural mentor for numerous complex software-intensive systems around the world in just about every domain imaginable. Grady is the author of six best-selling books and has published several hundred articles on software engineering, including papers published in the early '80s that originated the term and practice of object-oriented design. Read his blog, Software architecture, software engineering, and Renaissance Jazz.
Sanjay Bose
Sanjay Bose works for the IBM Software Strategy division and leads the Enterprise Integration Design Center to identify IBM Software portfolio requirements, and develops solution components and assets by engaging enterprise clients and IBM Software product development laboratories. He has more than 12 years of IT industry experience, primarily focused on creating product architecture and design, articulating technical strategy, and designing enterprise application systems using distributed technologies. His areas of expertise include SOA, Enterprise Service Bus (ESB), Web services, Java™ 2 Platform, Enterprise Edition (J2EE), and e-business technologies. He has coauthored the book, SOA Compass, and has published articles on IBM developerWorks and Systems Journal. He lives and works in Pittsburgh, Pennsylvania, and his spare time is spent with philosophical ramblings, books, movies and his Sony PlayStation. Read his blog, SOA, ESB, and beyond.
Donald F. Ferguson
Donald Ferguson is one of 53 IBM Fellows (IBM's highest technical position) in IBM's 200,000 employee technical team. Don is also the Chief Architect for IBM Software Group. Don chairs the SWG Architecture Board, which oversees the architecture and integration of WebSphere, DB2®, Lotus®, Tivoli®, and Rational® products. Don was the original Chief Architect for the WebSphere family of products. He joined IBM Research in 1985. His interests include raising and playing with his children, distributed systems, simplifying application development, systems management, Web services, transaction processing, performance and karate. Read his blog, Middleware and tools.
David K. Jackson
David K. Jackson is a Consulting IT Architect with IBM Americas Software Sales and is the IT architect in residence at the New York Technical Exploration Center. He is also Vice Chair of The Open Group Architecture Forum. The Open Group is an IT industry standards body formed from the combination of X-open and the Open Software Foundation. The Open Group Architecture Forum has developed and published the only industry standard Enterprise Architecture Development Method. The Open Group also established an IT Architect Certification program in 2005, defining what it means to be an IT Architect in the IT Industry.
Calvin Lawrence
Calvin Lawrence is an executive architect on the IBM Software Group Emerging Technology team. His responsibilities include advancing strategic IBM architectures, technologies and products in support of key strategic initiatives and ensuring the success of customer implementations using IBM technologies. He is former Chair of IBM Software Group Worldwide Technical Leadership Council.
Christina Lau
Christina Lau is an architect on the On Demand Development team. Her current projects include creating Pattern Solutions using Rational Software Architect and piloting business innovation and optimization functions. Christina is a Senior Technical Staff Member and a member of the IBM Academy of Technology. She is also a coauthor of a new book:
Introduction to IBM Rational Application Developer.
Andras Robert Szakal
Andras Robert Szakal is chief architect for the IBM Federal Software Group and is a distinguished engineer and Senior Certified IT Architect. He is also serves on The Open Group Board of Directors.
Dan Wolfson
Dan Wolfson is the Chief Architect for Master Data Management products in IBM Software Group. An IBM Distinguished Engineer, Dan has worked extensively with teams across IBM around business integration, metadata, and information integration. Dan has more than 20 years of experience in research and commercial distributed computing ranging over transaction and object-oriented systems, programming languages, messaging, and database systems.
Bobby Woolf
Bobby Woolf is a member of IBM Software Services for WebSphere, consultants who help customers achieve success with WebSphere products. He is a coauthor of
Enterprise Integration Patterns
and
The Design Patterns Smalltalk Companion
. Read more at Bobby's blog on developerWorks.
Resources
About the author
Rate this page
| |
