Sunday, August 19, 2007

SERVICE-ORIENTED BUSINESS: SOA = BUSINESS-ORIENTED ARCHITECTURE

Although many organizations are seriously considering SOA, some are doing it from a pure IT perspective while others are really looking at a new way of running their businesses. They are pursuing the concept of service-oriented business, or the idea of running all aspects of their organization from a "services" perspective. This has broad ramifications for an organization.

IT is a major budget item in many firms, especially for financial services organizations. IT affects all aspects of these organizations in profound ways. IT affects the cost of everyday business transactions, which over time equates to billions in efficiencies. IT allows interdisciplinary collaboration across a business enterprise, which means better cooperation, better sharing of information, and a more united capability to compete in your markets. IT improves many diverse business processes and increases productivity across the organization. IT amplifies the productivity and efficiency of all business processes, both internally as well as those that are exposed to trading partners and customers.

Business Impact of SOA
The potential business impact of SOA is significant to an organization, but only if the appropriate business modeling and business context are considered during the planning and implementation of SOA. The range of business benefits is broad, and includes both specific and tangible benefits as well as less tangible yet more compelling benefits. Of these, one of the most interesting concepts is the notion of the SOA Network Effect. This concept was first developed in a ComputerWorld column to describe the importance of the soft issues relating to achieving service-oriented architectures, such as cultural issues, behavioral issues, and organizational dynamics. [2] Are these as important as the technology of SOA? The answer from the field is that these soft issues are more important than the technology, and thus they are not all that "soft" as we would suppose. These soft issues are among the most difficult aspects of achieving SOA. Yet they are the key to an SOA's ultimate success or demise.

Characteristics of a Service-Oriented Business
A service-oriented business is an organization that has progressed with its SOA efforts such that its business really does operate using an SOA. SOA as an IT architectural strategy actually uses services as the "operating system" for the business and its business processes.

What if your CEO could acquire another firm and integrate its information and operations into the existing business and IT architecture without integration challenges? What if the acquired firm's business processes could integrate seamlessly with yours with zero latency? What if there was no integration effort required at all? What if the IT systems were "preintegrated," meaning that they could exchange information with one another without any incremental integration expenses and effort? What if business processes could be more quickly combined into new composite processes that represent the combined business entity better than those of the two individual business processes?

Imagine how business would be without two factors that have become ingrained in our expectations of IT today: the IT integration hurdles that attend every business initiative and the inevitable time lag between the need for the business initiative and the ability of the IT organization to deliver it on time and, more important, with zero time-to-market latency. This is the zero integration business enterprise.

How would this enhance the business case for a mergers-and-acquisition strategy? How would this improve the return on investment equation for any IT or business initiative? What is the value of faster time to market for any information-based initiative? That's the business case for a service-oriented business.

Exhibit 1.9 is a vision of how SOA becomes the foundation for a service-oriented business. It depicts how SOA can enable significant strategic business benefits through many tangible contributions. These include IT benefits, such as reuse and asset optimization that are often initial target benefits of most SOA efforts. However, as we progress from the IT level to business processes, organization and structure, and ultimately the strategic level where business and financial goals are critical, SOA has value to offer there as well.

Exhibit 1.9: Service-Oriented Business





CHARACTERISTICS OF A ZERO-INTEGRATION ENTERPRISE
Implementing SOA will allow tremendous reduction in integration expense and maintenance, such that we go so far as to call it the "zero-integration enterprise." A zero-integration enterprise is an organization whose business and IT teams are committed to the precepts of SOA. These organizations see the business value and strategic advantages of SOA, and are migrating their organization, processes, applications, and skills to support the concept of services, specifically Web services. This organization has eliminated traditional integration models in favor of SOA and standards-based integration. Some characteristics of a zero-integration enterprise follow.

This organization can launch new business initiatives faster than its competitors because less IT integration is required to support various business projects. This time-to-market benefit allows faster response to business conditions, customer requirements, competitive threats, and increased innovation.

This organization has a higher return on assets and greater IT productivity than its peer companies due to the asset-related benefits of SOA, such as software component reuse, services reuse, and extending the capabilities of existing IT systems and infrastructure.

This organization launches new software applications 35% faster than before with reduced quality assurance and testing effort due to component and services reuse. Building on proven software and services capabilities, the organization spends less time developing new code and more time focusing on business process issues.

This organization uses the 30% of its IT budget previously used for integration projects to solve strategic business problems, such as improving customer satisfaction, reducing time to market for new products, and increasing sales through various IT initiatives.

This organization implements concepts of agility and flexibility through its SOA initiatives. Agility is reality, and is measured by clear unambiguous metrics.

This organization has an agile business model that can quickly respond to business challenges, competitive threats, and customer needs.

This organization has greater customer focus deriving from reduced effort spent on internal integration and more effort spent on customer satisfaction, partner communication, and efficient business processes.

This organization has a business-focused IT organization that no longer must concern itself with assuring interoperability issues but rather can focus on forward-looking strategic issues.

This organization has a flexible IT architecture, based on SOA and services, that facilitates superior business performance, enables world-class business processes, and is highly efficient with all corporate resources.

This organization integrates without integrating, both internally and externally with customers and partners. This organization does not integrate, it service-enables instead.




WHAT ARE THE CHALLENGES OF SOA?
Now, with all of these benefits, where's the catch? Simple. SOA is difficult to implement, manage, and control. Not because of the technology, mind you, but due to the organizational, cultural, and behavioral aspects of SOA that contribute to success. And technically, although there has been great progress with regard to the standards, supporting tools, and development and run-time platforms, there are still issues to be resolved. These issues include support for long-running transactions, security concerns, and many others. However, the organizational, cultural, and governance issues far outweigh the technical aspects of implementing SOA. That's not a reason to avoid trying to achieve SOA, but it certainly is a reason to pay attention to many of the softer aspects of technology initiatives to ensure you can reap the rewards. A discussion of major SOA challenges organizations will face as they migrate to SOA follows.

Enterprise Architecture Model May Need Tuning for SOA
As many organizations consider their SOA approach, they will realize that the organization, processes, and disciplines of their enterprise architecture organization may require tuning to suit the requirements of SOA. Often the process of enterprise architecture is somewhat flawed, which helps explain the current state of IT architectures today: rigid IT architectures characterized by heavy carryover legacy systems, inflexible "digital concrete" of enterprise applications, and a portfolio of applications that demand integration software to make them work together.

Perhaps architects have been too focused on building things and getting them to work as opposed to building things that are flexible, reusable, and support the business: the things that are now most important for businesses today as they grapple with change and global forces. These are the new requirements of SOA.

SOA will fail unless the process of architecture is changed from one of static advice, creation of presentations, application blueprints, and architecture road maps to one of actively shaping and implementing flexible and reusable IT assets that support business processes. In other words, SOAs. A model for tuning the enterprise architecture process is presented in Chapter 8.

SOA Is Spatially and Temporally Distributed
One of the challenges of SOA is that it is not implemented all at once. Rather, it is achieved through many discrete projects across both space and time. This temporal and spatial distribution of SOA projects makes governance all the more critical to SOA success. SOA governance and enforceable policies are the keys to managing conformance to the SOA across geographic and time horizons.

SOA Is Organizationally Complex and Behaviorally Challenging
SOA is a complex goal to achieve. It is organizationally, behaviorally, and culturally challenging for most organizations. We describe an SOA behavioral model in Chapter 7 to help you anticipate and create the behavioral pattern your SOA will require.

SOA Requires Governance to Achieve and Manage
SOA requires a robust SOA governance model, clear and enforceable policies, and a way to implement SOA governance across all the life-cycle processes of an organization: enterprise architecture, services design, publishing, discovery, and run-time. SOA governance is essential to realize the ultimate business value of SOA.

SOA Is All About Services
Implementing SOA requires new approaches to identifying, modeling, and implementing reusable, interoperable services. Repeatable processes for determining appropriate granularity, version management, and enforcing design-time policies for services are essential. In fact, even the definition of services is important for many organizations.

The fundamental architectural unit of an SOA is a "service." Services, per our definition of SOA, are units of business capabilities, processes, or functions that are delivered in a repeatable way to consumers of those services. Consumers of services in an SOA can be developers, architects, and analysts, or they can be external customers, business partners, and internal business customers.

Without services, there is no SOA, and an SOA with services is useless unless there is actual consumption of the services that are available. Therefore, an organization can deliver or realize no SOA value unless the services in an SOA have real consumers using them for business reasons.

Services Identification, Modeling, and Design Challenges
Services are critical to an SOA. However, the process of identifying the right services for your organization is challenging. And what makes these services the "right" ones? This discussion is further complicated by questions about granularity, reuse, and other related services modeling and design issues. Chapters 3, 4, and 5 address these concerns using some innovative services modeling concepts. These chapters will help you achieve the "SOA Three Rights": Identify the "right" services; build those services the "right" way; and run them on the "right" enabling technology stack.

Where Are We Headed?
SOA is an iterative business approach. There is no single correct path to achieving SOA. Instead, there are multiple routes to the SOA goal. It is important to recognize the fundamentally iterative approach that SOA requires to achieve its stated goals objectives and business results over time. This approach, which we call an SOA business iteration model, is depicted in Exhibit 1.10.

Exhibit 1.10: SOA Business Iteration Model







This model builds explicit business context into the SOA strategy and planning process, recognizing that SOA must be aligned to business and IT objectives as well as to the current urgencies of the organization at that particular moment in time.

Remember: SOA is a lifestyle change. It is a long-term commitment to achieving specific business objectives. That is why we wrote this book, and that presumably is why you are reading it: to learn how to plan, design, and implement SOA via reusable services to achieve clear business results.

No comments: