SOA

SOA is not a product. SOA is not a solution. SOA is not a technology. SOA cannot be reduced to vendors' software products, much as they would like you to believe. SOA is not a quick fix for the IT complexity that has accumulated over 30-plus years. And finally, SOA does not address every IT challenge facing business and IT executives today.


SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. "Services" in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.


ELEMENTS OF AN SOA

The following list represents the essential ingredients of a successful SOA.

Conceptual SOA vision

Services

Enabling technology

SOA governance and policies

SOA metrics

Organizational and behavioral model



Conceptual SOA Vision
An SOA is a business concept, an idea or approach, of how IT functionality can be planned, designed, and delivered as modular business services to achieve specific business benefits. The conceptual SOA vision includes clearly defined business, IT and architectural goals, and a governance model and policies to help enforce standards and technical requirements of the SOA over time. This is the definition of an SOA target state, the goal to be achieved over time


Services
Yes, an SOA needs services, which as we said, means all possible services in the organization. Along with services comes a services design model to assure reusability, interoperability, and integration across all business processes and technology platforms. Services are the central artifact of an SOA. Services are the primary architectural asset of an SOA. As such, they merit significant attention throughout this book and throughout an organization's migration toward SOA through many projects and initiatives, each of which will most likely contribute services to the SOA over time.



Enabling Technology
While the technology of Web services and SOA generates lots of press, it is probably the easiest area to implement despite the vendor flux and standards volatility for various categories of technology solutions. The technology is essential to support realization of your SOA vision. However, the enabling technology is not your SOA. The enabling technology must be implemented to accomplish two objectives: (1) It must allow your services to operate reliably and securely in your enterprise in support of your stated business objectives; and (2) it must enable you to carry forward your existing IT architecture as well as enable your legacy systems to be leveraged to support your SOA goals. In many organizations, legacy mainframe systems and other applications are major contributors of services to an SOA.



SOA Governance and Policies
An SOA conceptual architecture cannot be realized unless it is communicated to the constituents of the SOA—business users, developers, architects, business and IT executives, and business analysts. In addition, communicating your SOA conceptual architecture to close trading partners is also advised. However, telling your SOA constituents what your conceptual architecture, vision, and goals are is one thing. Enforcing conformance to your SOA conceptual architecture, vision, and goals is another matter. SOA is not a big bang implementation model that we expect from large, packaged software applications. SOA is achieved incrementally through time at the project level by continuously defining and enforcing the standards that it will be based on. These standards are the policies that in the aggregate define your SOA conceptual architecture and, when implemented, help your organization achieve its SOA vision and business goals. An SOA governance model defines the various governance processes, organizational roles and responsibilities, standards and policies that must be adhered to in your SOA conceptual architecture.




Metrics
SOAs require a battery of metrics in order to measure the results you are achieving. These metrics include fine-grained metrics, such as service-level agreements (SLAs) for individual services, as well as usage metrics, policy conformance metrics, developer metrics, business and return on investment (ROI) metrics, and process metrics. Plan your metrics early, and don't forget them when you go live with services. You'll want the data, count on it.



Organizational and Behavioral Model
Your current IT architecture is the result of years of organizational behaviors, business decisions, and architectural choices. In order to achieve SOA, behavioral and organizational considerations must be understood and changed first; then over time will come gradual migration toward your SOA vision and goals. New organizational models and behavioral models will be essential to your SOA success.


SOA: BEHAVIOR AND CULTURE
SOAs contain a substantial amount of behavioral content because these initiatives are process-driven and span organizational boundaries. The "soft issues" of an SOA strategy must address the organizational issues and challenges that may help or inhibit SOA adoption, such as services ownership, the business and IT relationship, budgeting practices, and more. Organizational, cultural, and process issues thread through several facets of an SOA initiative. How do you organize your enterprise architecture functions and roles to support an SOA? How do you organize your developer resources to help ensure the realization of the goals and performance of your SOA initiative? What is the optimal IT structure for an SOA? Is centralized IT better? Or is a centralized enterprise architecture team optimal, supported by distributed developers embedded within specific business units? What are the skills, roles, and competencies of your architecture organization that will facilitate migration to and attainment of your SOA?


NEW SOA CONCEPTUAL, ARCHITECTURAL, AND ORGANIZATIONAL MODELS
SOA initiatives will stress and in most cases break current operational and architectural models of IT organizations. SOA will require new ways of modeling and implementing various IT processes we have become accustomed to, such as services design models, integration models, reuse models, architecture processes, and enterprise architecture models. These other models, of course, augment the required SOA governance model.



Over the years, your IT architecture has accumulated layer upon layer of complexity. When client-server architectures dominated the IT industry, client-server applications were layered over your mainframe platforms. When the Internet era rose to ascendance, Webcentric platforms were added on top of client-server solutions. And as these evolved into n-tiered architectures, the layers of IT complexity built up, building more modern complexity on top of legacy complexity.



Although IT architecture through the years is accretive, and nothing seems to ever go away, there are ways to "architect" your way out of this conundrum. One approach is to rip out all the legacy applications and replace them with modern ones. This rip-and-replace model is too expensive for most organizations. In addition, often it is not worth the risk and effort of replacing these still-working legacy systems with new software

Another approach is to rewrite or refactor your legacy systems for modern application server platforms, such as J2EE or .NET. Even though rewriting systems is also very expensive, at least you know they will match your business processes when you are through. Like the rip-and-replace model, this approach usually is avoided, however, not because it is not the right thing to do, but because it is expensive and difficult to cost justify to the business.


But there is a way out of this mess that avoids big bang system rewrites and expensive enterprise software projects. The way is service-oriented architecture. SOA is a simple concept, one that has the potential to alleviate many long-standing IT challenges and enable many coveted business goals that have until now been very elusive. SOA, by introducing a services layer into an existing IT architecture, can provide opportunities to isolate areas or elements of the architecture that are problematic, failure prone, or cost prohibitive. The services layering approach can enable the isolation, replacement, and/or potential consolidation of these architecture challenges while enabling the flexibility of reusable services. How often have business executives pronounced a desire to become more agile? When has time-to-market not been a mission-critical business requirement? Yet more often than not, these lofty business goals are constrained by outdated IT systems and incapable business processes that are subservient to tradition as well as to the digital concrete of today's enterprise software applications.



Why SOA Now?

SOA has also achieved trend status because of the degree of dissatisfaction that IT and business executives share with the current state of IT within their enterprises. Chief executives (CEOs) are fed up with hearing why they cannot expand into a new geographical location because the IT systems are not ready yet. They don't want to hear why the enterprise resource planning (ERP) system that cost $30 million will not support the new business process targeted to launch in six months. Chief financial officers (CFOs) are tired of waiting for regulatory compliance issues to be resolved, and they certainly are not pleased with an overbudget IT organization. Chief operating officers (COOs) resent being told they cannot get a report because data are spread across three different systems, all on different computing platforms. Chief technology officers (CTOs) are fed up with vendors pushing more new technology when the old technology is still underutilized and operating as islands of functionality. They are tired of the endless need to keep integrating systems when the integration models themselves become part of the problem—more legacy silos to maintain. And chief information officers (CIOs)? They are tired of explaining the same problems time and time again. They're tired of having their budgets cut. They wish they had more funding for strategic projects instead of being hamstrung by having 80 to 90% of their budget committed to maintaining legacy systems. CIOs could do much more for the business if they could shed their legacy systems and focus on forward-looking strategic solutions for the business. There has to be a way out of this quandary. SOA could well be an answer. SOA is not new, but it's here to stay. SOA is finally achievable thanks to three major factors:

Standards consensus. Microsoft and IBM agreed, and the rest fell in line.

SOA enabling technology. Finally, implementing standards-based services is possible and affordable.

Integration fatigue. There has to be a better way to achieve application and business integration.




Standards Consensus
For the first time in the history of IT, there is widespread agreement on major SOA and Web services standards by all IT vendors. This nearly unanimous agreement means that whether you move now or later, you most certainly are going to be using services in your organization. Your software and platform vendors are going to take you there whether you want to go or not. Our advice? Preempt your vendors with your own SOA strategy and roadmap. Rapidly accumulate SOA experience. And be prepared to fend off any proprietary platform-specific approaches to services. Implement industry standards in your SOA governance model and in specific policies that will govern services identification, design, and implementation. You may have to dedicate some internal resources to tracking relevant standards, but the ROI on standards will be well worth it.




SOA Tools and Infrastructure
With the advent of new tools and infrastructure solutions that enable SOA and services in a cross-platform, reusable, and interoperable fashion, SOA is real. This is perhaps the most significant departure from previous SOA implementations, such as CORBA (Common Object Request Broker Architecture), COM/DCOM (Common Object Model/Distributed Common Object Model), DCE (Distributed Computing Environment), and other proprietary schemes for reusable services. Interoperability for services is largely due to the standards for Web services, primarily SOAP for messaging and WSDL (Web services description language) for service descriptions. The variety of tools for legacy systems enablement, services development and exposure, Web services management, and multiple run-time environments for services have made the SOA industry very interesting to watch. There are as many ways to enable services and SOA as there are legacy systems and platforms in your architecture. Of course, bear in mind that we refer to the general case of "services" in this book. Some of your services will be Web services based on XML (eXtensible Markup Language), SOAP, and WSDL, as well as the extended WS-* standards. However, do not limit your SOA total value by examining and considering Web services only. Think services first, and then specific implementation models later.




Integration Fatigue: "There Has to Be a Better Way"
IT "business as usual" is over. Business and IT executives are frustrated with the lack of integration of their internal systems, with their business processes, with their trading partners, and with their customers. We call this integration fatigue. The business is demanding change, and IT executives know there has to be a better way. The frustration with IT as we know it is at an all-time high. IT budgets continue to be stressed, and they rarely increase. The majority of IT budgets are focused on maintaining current systems and keeping the lights on; very little IT budget is focused on strategic initiatives that may pay future dividends. It is a do-more-with-less environment.

Business continues to change while IT is saddled with maintaining the systems and architectures of the past. IT doesn't have the luxury of eliminating its legacy or underperforming assets. Those very IT assets contain business logic that is most likely running a mission-critical portion of the organization's business. Yet while the business logic is mission critical, nonetheless the logic and data are locked up within individual silos of systems and technology. You cannot afford to rewrite the application, and your integration strategy has proved to be supremely costly to implement and maintain. There has to be a better way, and there is. It's called service-oriented architecture.



SOA: EVOLVED ENTERPRISE INTEGRATION


A major impetus for SOA initiatives is solving the age-old problem of integration. For many executives, SOA holds the potential to eliminate, via industry standards and modern tools, the proprietary integration model they've become accustomed to. According to many analyst estimates, up to 30% of a typical IT budget is allocated to integration activities. What would business be like if there was less integration, or, rather, if the integration that was performed was directly related to process integration, enterprise integration, and mergers and acquisitions (M&A) integration? In other words, value-added integration. How would spending less money on integration change an organization's competitive advantage? Could that budget be shifted to more strategic projects?




Origins of the Integration Problem
Where did all this IT complexity come from? Why is 80 to 90% of your IT budget focused backward on maintaining the past rather than looking ahead to supporting the future? This "rearview mirror budgeting" problem is legendary among CIOs and is partly responsible for the lack of strategic IT investment by CIOs today. How backward committed is your IT budget? What percent of the IT budget is allocated to maintaining your legacy investments rather than focused on forward-facing initiatives that may move the organization ahead? This is a real challenge for both business and IT executives today. If you feel as if you're managing your IT budgets using a rearview mirror, you're not alone.

The demand for IT and process integration is driven by business requirements, such as:

Increased M&A activity

Corporate reorganization or restructuring

Application and/or system consolidation

Data integration and data warehousing initiatives

New business strategies leveraging current systems for new processes

Achieving regulatory compliance (e.g., Sarbanes-Oxley, or HIPAA, the Health Insurance Portability and Accountability Act of 1996)

Streamlining of business processes to improve productivity

Addressing the business drivers for integration is a great impetus for SOA and Web services. At what point does IT complexity become an obstacle to business goals and an impediment to achieving IT's goals? We believe that complexity becomes intolerable when organizations are considering or taking these actions:

Hiring a chief architect

Creating a central architecture team

Acquiring or developing your own enterprise application integration (EAI) software

Creating an internal integration team, or a middleware organization, to help solve the integration challenges for your organization

Now, this does not mean that hiring a chief architect is a bad thing. More than likely it is a good thing. Chief architects can help address the architectural complexity and pain your organization is facing. The other actions just listed also can help address these areas. The problems are symptoms of the IT challenges that SOA could address. If you have considered or taken one or more of these actions, your organization is at the point where the integration burden is consuming IT resources, compounding the existing complexity problem, and inhibiting business and IT effectiveness. You most likely have a rearview-mirror IT budget, and you are ready to try a new approach.



Stop Integrating; Service-Enable Instead
Stop integrating now. What we mean is stop integrating the way you have been using proprietary middleware solutions, homegrown point-to-point integration techniques, and tactical integration approaches that are doomed from the outset. These techniques are almost always going to break and require a significant ongoing maintenance burden from the organization.

An organization should integrate without integrating. Eliminate all point-to-point integration projects in your enterprise and rearchitect these initiatives from an SOA point of view. Inventory the integration solutions in your organization. Identify the IT budget allocated to these solutions and projects, including support staff, maintenance, and infrastructure. Determine how many of these integration efforts can be eliminated using reusable services in an SOA.