9780137080205

Authoritative answers To The 100 most important SOA questions that business, technical, and operational leaders ask bull; bull;Provides fast access to answers about SOA's business value, organization, methods, applications, architecture, infrastructure, and more. bull;Written by top SOA architects who've participated in hundreds of projects and have filed more SOA-specific patterns than anyone else. bull;For a broad business and technical audience: respects its readers without assuming detailed technical knowledge. 100 SOA Questions brings together authoritative answers To The most crucial questions business, technical, and architectural decision-makers ask about SOA. it draws on the immense experience of two senior architects who've participated in over 100 SOA projects, and have filed more SOA-specific patents than anyone else on Earth. Organized to reflect the Open Group's Open Services Integration Maturity Model (OSIMM), this book provides fast, convenient access to information about business impacts, organization, methods, applications, architecture, information, and infrastructure. Readers will find detailed and realistic answers to questions such as: bull; bull;How does SOA and Service-orientation provide business flexibility? bull;How does SOA integrate into my existing business and IT strategies. bull;Can you show me specific examples of SOA solutions reducing time to market and lowering costs? bull;How is SOA different from previous approaches? bull;What is the role of enterprise architecture in SOA? bull;How do I prevent and manage service proliferation? bull;How do I address SOA performance challenges? bull;How do I infuse and sustain greater flexibility in my SOA deployments? This book will be an invaluable resource for executives and senior architects making plans and decisions; as well as operations and software engineering professionals who must deliver and manage systems for maximum value.

Kerrie Holley has a wealth of experience in application development, software engineering, systems engineering, IT consulting, and enterprise architecture. Mr. Holley has operated as Chief Architect, Strategist, Consultant, and Designer on more than fifty SOA projects. In his current role, he oversees hundreds of SOA projects in their technical direction, strategy, and successful deployment. Mr. Holley’s current focus is on the convergence of business rules, business process management, analytics, and SOA in making businesses more agile. Mr. Holley holds several SOA patents and has a BA in mathematics from DePaul University and a Juris Doctorate degree from DePaul School of Law. Mr. Holley has worked in a senior capacity for several companies, including Bank of America, Tandem Computers, Ernst & Young and is currently an IBM Fellow.

Dr. Arsanjani is a rare mix of industry hands-on consulting and academic research that he leverages in his Chief Technology Officer role as advisor to high-profile companies. Through his experience as strategist, consultant, and architect, he has helped companies achieve business performance through leveraging and changing IT. His current area of focus is to enable companies to achieve higher levels of business performance and enable them to optimize their business through the agility gained in concert with IT and business operations. Ali Arsanjani has chaired standard bodies such as The Open Group and is responsible for co-leading the SOA Reference Architecture, SOA Maturity Model, and Cloud Computing Architecture standards. In his role as Chief Architect, he and his team specialize in harvesting and developing best-practices for the modeling, analysis, design, and implementation of SOA and Web Services on hundreds of projects.

He is a hands-on, sought-after architect around the world on large SOA projects, and he is the principal author of the industry first Service-Oriented Modeling and Architecture (SOMA) method for SOA. His work on variation-oriented analysis allows companies to build less software but achieve higher gains, and his patterns for service- oriented software architecture combine SOA with business process management, business rules, and analytics to achieve higher levels of maturity for organizations.

Preface xvii

Introduction 1

Chapter 1: SOA Basics 5

SOA Basics: Q&A 5

1. What Is SOA? 5

2. Is SOA an Architectural Style? 7

3. What Are the Fundamental Constructs (the DNA) of SOA? 9

4. What Is the Difference Between a Web Service and an SOA Service? 14

5. What Makes a Project an SOA Implementation? 15

SOA Basics: Key Concepts 16

Chapter 2: Business 19

Business: Q&A 21

6. Why Should Business Stakeholders Care About SOA? 21

7. How Should SOA Be Sold to the Business or Business Stakeholder? 25

8. What Is the Return on Investment (ROI) of SOA Adoption? 28

9. How Should the Business Measure the Effectiveness of SOA? 29

10. What Are the Criteria for Selecting a Project for SOA Adoption? 33

11. What Is Flexibility and How Does SOA Deliver on This Promise? 34

12. How Is Reuse Accomplished Using SOA? 36

13. What Should the Business or Business Stakeholders Do Differently Because of SOA? 37

14. Can SOA Be Applied to Business Architecture or Should It Be Used Solely for IT? 40

15. What Are the Common Pitfalls from a Business Vantage Point in Adopting SOA? 42

Business: Key Concepts 43

Chapter 3: Organization 45

Organization: Q&A 46

16. How Does Business / IT Alignment Change Because of SOA? 46

17. Which Joint Business / IT Processes Change Because of SOA? 49

18. What Organization Structures Should Be Established for SOA? 50

19. What Is the Role of Organizational Change Management to SOA? 56

20. How Can Organizational Barriers to SOA Success Be Removed? 58

21. How Should Organizations Address Funding for Services? 59

22. How Should Organizations Address Prioritization for Shared Services? 63

23. What Are Service Owners? 64

24. What is the Value of Classifying Services? 65

25. Who Owns Service Reuse? 66

26. What Are the Common Organizational Pitfalls When Adopting SOA? 67

Organization: Key Concepts 68

Chapter 4: Governance 71

Governance: Q&A 72

27. What Is SOA Governance? 72

28. How Does an Organization Get Started with SOA Governance? 75

29. What Is the Role of Change Management? 79

30. Does Implementation of SOA Tools and Infrastructure Equate to SOA Governance? 81

31. Should Service Development Be Centralized in Service Centers? 83

32. Does SOA Require Centers of Excellence, Architecture Boards, or Design Boards? 84

33. Why Do Organizations Need to Focus on SOA Governance When There Is an Effective Enterprise Architecture Activity? 87

34. Is SOA Governance Required for SOA Projects to Be Successful? 89

35. How Can You Measure Whether SOA Governance Is Effective? 90

36. What Is the Difference Between Design-Time and Runtime Governance? 91

37. What Are Common Pitfalls of SOA Governance? 92

Governance: Key Concepts 93

Chapter 5: Methods 95

Methods: Q&A 96

38. Should an Organization Continue to Use Agile or Object Development Methods for SOA Projects? 96

39. What Changes in System Development Result from SOA? 98

40. Does SOA Require Service Modeling? 101

41. How Should Services Be Identified or Specified to Maximize Reuse? 103

42. How Should the Granularity of a Service Be Determined? 106

43. Should SOA Be Used Only for Custom Development Projects? 107

44. Are Any New Development Roles Introduced by SOA Methods? 109

45. Does SOA Change Testing Methods? 110

46. How Do SOA Methods Accelerate Application Development? 112

47. How Do SOA Methods Reduce the Lifetime Costs for Applications? 114

48. What Are the Common Pitfalls in Adopting SOA Methods? 115

Methods: Key Concepts 116

Chapter 6: Applications 119

Applications: Q&A 121

49. Do Applications Still Exist with SOA? 121

50. Do Applications Get Replaced with Composite Services/Applications? 121

51. Is a Certain Type of Business Problem Best Suited for SOA Adoption? 123

52. Is a Certain Type of IT Problem Best Suited for SOA Adoption? 127

53. What Changes with Application Development When SOA Is Introduced? 128

54. What Is the Relationship of Business Process Management to an Application? 133

55. How Does SOA Make Applications or a Portfolio of Applications More Flexible? 137

56. Should an Application Portfolio Be Managed Differently Because of SOA Adoption? 139

57. Can Existing Systems or Legacy Applications Be Leveraged When Adopting SOA? 140

58. How Are Services Built That Will Deploy in a Cloud? 142

59. Does It Make Sense to Adopt SOA for One Application Versus the Enterprise? 143

60. What Are Common Pitfalls for Application Teams Adopting SOA? 144

Applications: Key Concepts 145

Chapter 7: Architecture 147

Architecture: Q&A 149

61. How Does Architecture Change as a Result of SOA Adoption? 149

62. How Does SOA Differ from Earlier Approaches, such as DCE or CORBA? 156

63. How Do Web Services and SOA Differ? 157

64. Is SOA Too Complex and Enterprise-Level Only? 158

65. How Do Interfaces and Contracts Differ? 160

66. Should Applications Choose WSDL or REST? 162

67. What Is the Relationship Between Enterprise Architecture and SOA? 165

68. How Do EAI, SOA, and SOI Differ from One Another? 167

69. What Is the Role of Standards in SOA Implementations? 168

70. How Should Standards Be Applied to Enable Successful SOA Implementations? 169

71. What Are the Common Pitfalls When Adapting an IT Architecture for SOA? 170

Architecture: Key Concepts 172

Chapter 8: Information 173

Information: Q&A 174

72. What Is the Relationship Between Information Architecture and SOA? 174

73. What Are Information Services? 175

74. How Are Information Services Classified? 176

75. Do Information Services Differ from Other Services? 178

76. How Should Information Services Be Identified? 180

77. When Should Information Services Perform Create, Read, Update, and Delete (CRUD) Operations? 181

78. Are Enterprise Information Models Required for Effective SOA Implementations? 182

79. What Is a Canonical Message Model? 184

80. How Should a Canonical Message Model Be Created? 186

81. Can SOA Improve Data Quality? 187

82. What Are the Common Pitfalls with Information Architecture and SOA? 188

Information: Key Concepts 189

Chapter 9: Infrastructure 191

Infrastructure: Q&A 193

83. What Are the Building Blocks of an SOA Infrastructure? 193

84. What is an Enterprise Service Bus? 199

85. What Are Best Practices for Creating the SOA Infrastructure? 200

86. What Makes an Enterprise Service Bus Different from Integration Technology? 201

87. How Does an ESB and Registry Relate? 203

88. How Does an SOA Infrastructure Support Events? 204

89. How Does the SOA infrastructure Evolve to Realize the Increased Loose Coupling? 205

90. How Does SOA Infrastructure Support Policy Management? 209

91. How Is Management of the Infrastructure Affected by SOA? 212

92. What Is the Role of Cloud Computing in an SOA Infrastructure? 213

93. What Are the Common Pitfalls in Creating an SOA Infrastructure? 214

Infrastructure: Key Concepts 217

Chapter 10: The Future of SOA 219

Future: Q&A 220

94. Is SOA Dead, Stagnant, or Moving Forward in its Adoption? 220

95. What Is the Future Trajectory of SOA? 221

96. What Are Context-Aware Services? 224

97. What Role Does SOA Play in Embedded or Real-Time Systems? 225

98. What Is the Relationship Between Event-Driven Architecture and SOA? 225

99. How Does the Slow Maturation of Standards Affect the Future of SOA? 227

100. Do WOA and Web 2.0 Affect the Future of SOA? 228

Future: Key Concepts 229

Index 231

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Preface Preface Almost two decades ago, I completed a project to develop and deploy a teller and sales application for a large U.S. bank. Enhanced business capabilities, technology upgrades in the branches, and a pending bank merger were the business drivers. Some months after the production roll-out, as the Chief Architect, I was invited to a meeting with the Vice Chairman of the Retail Banking who wanted to understand my perspective on how the bank should address challenges in meeting future demands that required extending the reach of the teller and sales platform functionality to other parts of the bank. The Vice Chairman was responsible for all retail functions of the bank and expansion was hot on the agenda. The bank was growing, entering new market places, acquiring banks, opening branches, and rapidly attracting new customers. We sat down and discussed cross selling, expansion goals, and the need for several parts of the Bank such as credit card processing, wholesale banking, and loans, to be able to access and use functionality contained in the teller application we had just built and deployed. Obtaining customer information, account balance inquiries, and address updates were just a few of the basic pieces of functionality needed by these other departments but there were more complex pieces of business functionality required, too. When wholesale banking or credit card processing needed to access data or functionality in the teller system, they needed to go through a development cycle that necessitated waiting in a queue with others, whereby the IT department could prioritize and satisfy the multiple requests and requirements. The Vice Chairman expressed this current situation as a problem; it impacted the bank's capability to get more products out the door faster and his ability to meet sales and revenue targets. He asked two questions: How can we do this better and how can the bank provide access to previously built and deployed business functionalities to other parts of the bank without going through IT development queues? Addressing this question and others by senior business executives has been top of mind for me for two decades. Over the last decade, I have met with corporate executives from hundreds of companies across the world whose enterprises are characterized by disparate and siloed systems and applications; horizontal integration is the goal as businesses seek greater agility in the global marketplace. Corporate managers are asking how do to make the IT system more flexible so that it is easy to connect across the enterprise and so it is inexpensive in both time and cost. The story of the bank occurred two decades ago, but I find CEOs and other corporate executives asking this same question over and over again, decades later. Everyone is searching for flexibility as competition intensifies. Everyone sees this albatross around their neck getting uglier and negatively impacting goals for growth and limiting the responsiveness and agility required as the cost of maintaining, integrating, and supporting systems is rising. Less capital is available for innovation, changing the business, and delivering new capabilities. Just a few years ago, I met with a corporate manager responsible for a payments business. His frustration was apparent as we discussed the need to change his three-year-old IT system to accommodate new channels (phones, kiosks, and other mobile devices) and new market segmentations. He was frustrated because although he was not a technologist or software engineer he knew something was not right. He wanted to know why after millions of dollars of investment in a creating a new payment system, built three years earlier, it was not easy to change his payment system to accommodate small and medium businesses or to allow access to payments using handheld devices.. He asked this question because his payment system was built with modern software engineering best practices yet flexibility was evasive: adding new channels and new customer segments would take too long and cost too much money as if he were building the system from scratch versus just changing the system. I responded and the short answer is that applying best practices and modern system engineering practices is not sufficient if agility is the goal. I further stated that there is a considerable amount of data that shows this problem is not isolated that most applications become difficult to change within 3 to 5 years after the first production deployment. Recently, I was in Mexico City working with a large logistics company. It was just finishing an 18-month project to reengineer a core IT system that was no longer responsive to the business. The new system was engineered like the bank system two decades earlier, with the best software engineering practices and tools available. I was asked if this new system would suffer the fate of past systems in its capability to be responsive. That is, would this system become brittle in the future and if so, why? Would this new system be built for change such that flexibility was an attribute of the system and not a platitude? Again I answered no, stating that applying best practices alone will not achieve the goal of agility. I know this is true because his team and teams just like his around the world have been using modern and best practices of software engineering for years with the same results. The result is that three to five years after the system has been deployed it is difficult to change, and is expensive in time and money. It is not only the commercial world that sees a problem but the public sector. we have met with various public sector organizations over the years and my interactions confirm that they are confronted with the same challenges we see in the private sector. :Public and private sector managers see the rising cost of support, integration, and maintenance of the systems as a ball and chain that is a huge drag on cost reduction and as a result, it puts a limit on monies available for creating new capabilities in the theater as the available dollars are limited. It is these questions and their answers that prompted us to write this book about service-oriented architecture (SOA). This is not a technology book, but a book for technologists and business stakeholders. We hope to demonstrate, that SOA and service-orientation in general, is not solely a technology play but a paradigm and architecture that calls for business and IT collaboration and when understood and applied, it can change the course of your business, where flexibility and lower total cost of ownership become realities. Total cost of ownership and flexibility are different sides of the same coin. There is less flexibility when funds are not available to spend or when providing new capabilities is constrained because resources are consumed in integration, maintenance, and support. Flexibility is evident when the business, not IT, has the power to deploy new business features without IT development queues or when new capabilities can be provided in weeks or months instead of years, and when two or more capabilities can be composed at will to create a new, enhanced capability that directly supports business drivers and alleviates painpoints. If we make the right choices, we will have a chance to escape from the boxes that frustrate us today. The escape will not be easy we will be constantly challenged to question conventional assumptions and comfortable practices. Many will not even see the opportunity. They will continue to remain closed in the boxes that make every day more frustrating. Some will see the opportunity but will either try to move too quickly or fail to stay the course. They will blame the technology for its failure to produce results. For those few who succeed, the rewards will make the journey well worth the effort. Jo

Amazon no longer offers textbook rentals. We do!

100 SOA Questions Asked and Answered

100 SOA Questions Asked and Answered

0137080204

Summary

Author Biography

Table of Contents

Supplemental Materials

Excerpts

Write a Review