SOA World Magazine-Enterprise SOA


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SOA World Magazine-Enterprise SOA

  1. 1. THE WORLD’S LEADING MAGAZINE DEDICATED TO WEB SERVICES TECHNOLOGIES OCTOBER 2008 / VOLUME: 8 ISSUE 10The NextParadigm –Multi-Enterprise18 SOA SOA Innovation Applied CHRIS JOHNSON 14 GRACIELA TISCAREÑO-SATO22 Getting an SOA Initiative or Continuing the Journey KADEER BEG
  2. 2. FROM THE EDITOR Give Me a Sign INTERNATIONAL ADVISORY BOARD Andrew Astor, David Chappell, Graham Glass, Tyson Hartman, Paul Lipton, Anne Thomas Manes, Norbert Mikula, George Paolini, James Phillips, Simon Phipps, Mark Potts, Martin Wolf WRITTEN BY SEAN RHODY TECHNICAL ADVISORY BOARD JP Morgenthal, Andy Roberts, Michael A. Sick, Simeon SimeonovO ne of my favorite sayings is, “if you operating solutions. In the modern age, this don’t know where you’re going, any includes capacity on demand, virtualized EDITORIAL direction will do.” While in many containers, and occasionally connected Editor-in-Chief Sean Rhody sean@sys-con.comcases people take that as license to do what- computing. In addition to being the platform XML Editorever they feel like, what it really means is that that the SOA will run on, these foundations Hitesh Sethbefore you embark on a journey, you should often expose services of their own that en- Industry Editorplan your destination. You know, get out the able the creation of more complex business Norbert Mikula norbert@sys-con.commap, plot your direction, find out where you logic or exception handling. Product Review Editorwant to go, and what you want to accom- Other elements are also important on Brian Barbash bbarbash@sys-con.complish along the way. the roadmap. The Enterprise Service Bus .NET Editor SOA is a journey, and also a destination. is a key architectural element – without it Dave Rader davidr@fusiontech.comFor most organizations, SOA is the end you have a point-to-point wiring issue that Security Editor Michael Mosher wsjsecurity@sys-con.comgoal of the IT organization. They’ve begun ultimately becomes even worse than theto realize that SOA is the way that they will problems we were trying to solve in the first Research Editor Bahadir Karuv, Ph.D Bahadir@sys-con.comultimately run their organization’s software place. This is an area where companies seem Technical Editors(and to a certain extent, hardware too). to take detours frequently and one where, Andrew Astor andy@enterprisedb.comTheir vendors have all begun shipping their in most cases, they really should stick to the David Chappell chappell@sonicsoftware.comsoftware as services, and they may even be roadmap. It’s a lot easier to put in an ESB and Anne Thomas Manes Mike Sick msick@sys-con.comusing web-based software as a service such adapt to it when you start then after you’ve Michael Wacey mwacey@csc.comas So it’s now time to under- done a number of implementations. International Technical Editorstand the destination. One area that needs to be considered is Ajit Sagar In order to do that, a wise organization the overall maturity of the organization with Executive Editorcreates a Roadmap. Just as you might consult respect to SOA. There are multiple dimen- Nancy Valentine nancy@sys-con.coman atlas (or MapQuest these days) to see sions of maturity – you can look at technol- Associate Online Editorwhere you are going, understanding what ogy, standards, security, governance, and Lindsay Hock lindsay@sys-con.comthe stops are on the journey toward full SOA management. All of these areas have differ-implementation and planning on how to ent qualifications and levels associated withreach them is also critical. Just as you might them that lead to an overall maturity level. PRODUCTIONdecide to take a scenic detour for your own A typical roadmap identifies these dimen- ART DIRECTORenrichment (who doesn’t like seeing the sions as well as the projects that will be Abraham Addo abraham@sys-con.comchanging leaves on some windswept country undertaken to get to the end goal. In security ASSOCIATE ART DIRECTORroad over the weekend rather than driving it may be a first project toward single sign- Tami Beatty tami @sys-con.comdown a soulless interstate), your company on that will eventually lead to the basis formay very well choose to take a road less security as a service as part of the underlyingtravelled for strategic, tactical, functional, or infrastructure. There may be a discussion EDITORIAL OFFICES SYS-CON MEDIAeven financial reasons. of core IT services that should be provided 577 CHESTNUT RIDGE ROAD, WOODCLIFF LAKE, NJ 07677 It’s one thing to take the road less traveled as part of the infrastructure. There may be a TELEPHONE: 201 802-3000 FAX: 201 782-9637upon careful planning. It’s another entirely rationalization project to help align redun- SOA World Magazine Digital Edition (ISSN# 1535-6906) Is published monthly (12 times a year)to miss the street sign and go off road – it dant business processes or applications. A By SYS-CON Publications, Inc.causes detours and rework, not to mention good roadmap is multi-dimensional and Periodicals postage pending Woodcliff Lake, NJ 07677 and additional mailing officesannoyances and loss of credibility with col- includes a timeline. It may even (dare I say POSTMASTER: Send address changes to:leagues and the executive committee. it) outline the dependencies each project has SOA World Magazine, SYS-CON Publications, Inc. For many reasons, a roadmap for SOA with respect to one another. Finally, a good 577 Chestnut Ridge Road, Woodcliff Lake, NJ 07677is important, perhaps even critical to the roadmap is hard to create. It takes insight, itsuccess of the journey, or at least of the team takes commitment, and it takes leadership.making it. A roadmap for SOA has many Before you take another step, ask yourself: ©COPYRIGHT Copyright © 2008 by SYS-CON Publications, Inc. All rights reserved. No part of this publication may beaspects. It has foundational elements that “Do I know where I’m going?” If not, it’s reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy or any information storage and retrieval system without written permission. For promotional reprints, contact reprintinclude network and hardware, as well as probably time to get out the map. coordinator. SYS-CON Publications, Inc., reserves the right to revise, republish, and authorize its readers to use the articles submitted for publication. All brand and product names used on these pages are trade names, service marks, or trademarks of their respective companies. SYS-CON Publications, Inc., is not affiliated with the companies or products covered in Web Services Journal.About the AuthorSean Rhody is the editor-in-chief of SOA World Magazine. He is a respected industry expert and a consultant with a leadingconsulting services company. www.SYS-CON.com2 OCTOBER 2008 OCTOBER 2008 3
  3. 3. INSIDE 2 Give Me a Sign SEAN RHODY 6 Creating an Effective SOA Service Taxonomy MARK RICHARDS 12 Design Time SOA Governance Needs Some Work… Humans and Tools DAVID LINTHICUM 14 The Next Paradigm - Multi-Enterprise SOA CHRIS JOHNSON 18 SOA Innovation Applied GRACIELA TISCAREÑO-SATO 22 Starting an SOA Initiative or Continuing the Journey KADEER BEG 24 Developing a CICS-based Web Service on an Array of “Complex Datatype” Objects SREE KUSUMANCHI, GIRISH MOKHASI, AND GVB SUBRAHMANYAM 30 Common Pitfalls Around an SOA Implementation – And How to Avoid Them MUKUND BALASUBRAMANIAN 32 Making the Case for Application Service Modeling in SOA Environments BARNEY SENE4 OCTOBER 2008
  4. 4. TAXONOMY CORPORATECreating an Effective President and CEO Fuat Kircaali Senior VP, Editorial & EventsSOA Service Taxonomy Jeremy Geelan ADVERTISING Senior VP, Sales & Marketing Carmen Gonzalez carmen@sys-con.comWhat exactly is a service? Advertising Sales Director Megan Mussa Advertising & Events Manager Corinna Melcon BY MARK RICHARDS Events Associates Krisandra Russo Susan Wechtler I t’s hard to think about Service Oriented Architecture without think- ing of services; after all, services are the main focus of SOA (it’s even in the name). If Service Oriented Architecture is an approach where CUSTOMER RELATIONS the business and technical architecture is oriented around services, Circulation Service Coordinators then what exactly is a service? Unfortunately, the answer to this ques- Edna Earle Russell tion varies greatly depending on whom you talk to and how you’re using SOA in your organization. This variation tends to create quite a bit of confusion when trying to design and implement a SOA-based solution. There are several excellent service-oriented methodologies availabletoday, most of which describe processes for identifying, defining, specifying, implement- SYS-CON.COMing, and governing services. While these methodologies provide the direction and tools Consultant Information Systemsnecessary to help realize SOA in your organization, they don’t address the fundamental Robert Diamond A LT E R N AT I V E T H I N K I N G A B O U T S E R V I C E - O R I E N T E D A R C H I T E C T U R E :question about what a service actually is. Web Designers A service is hard to define because there are in fact many different types of services Richard Walter Joon Kim Rethink The Architecture, Rethink The Service Oriented Architecture. Understanding what types of services exist, how thoseservice types are defined and related, and how they are communicated to the stakehold- (Rethink Your Bottom Line.)ers in your organization are key to any SOA-based initiative. In this article I will describe amethod for building a SOA Service Taxonomy that will help you effectively classify services Alternative thinking is shifting your SOA strategy to focus on business initiativesfor the SOA-based initiatives in your organization. ACCOUNTING rather than technology initiatives. (Head in the game, not on bits and bytes.) Financial AnalystOverview Joan LaRose Taxonomy is a way of classifying things using a hierarchical classification structure. We Accounts Payable It’s using governance to speed the adoption and reuse of services—keepinguse a hierarchical classification system to classify animals into phyla, classes, orders, fami- Betty White everything from getting out of hand.lies, genera, and finally species. Using this classification scheme we can group animals withsimilar characteristics and features, from the very general (phylum) to the very specific It’s building quality and management into every step, from idea through(species). We can apply these same concepts to the way we classify and define service typesin a SOA. However, unlike the binomial nomenclature originally laid down by Carl Lin- SUBSCRIPTIONS execution, to help ensure you’re always up and running smoothly.naeus, there exists no foundational nomenclature for developing a hierarchical classifica- SUBSCRIBE@SYS-CON.COMtion of services in a SOA. Fortunately, creating a classification scheme and categorizing SOA 1-201-802-3012 or 1-888-303-5282 For subscriptions and requests for bulk orders, It’s capitalizing on software that works across platforms, so your businessservices is infinitely simpler than the task Mr. Linnaeus had several hundred years earlier. please send your letters to Subscription Department operates efficiently through mergers and acquisitions and alliances Cover Price: $6.99/issueHowever, we still seem to get it wrong. Domestic: $99/yr (12 issues) and massive growth. Service Taxonomy is a way of classifying various types of services used in SOA. The (U.S. Banks or Money Orders)purpose of a hierarchical service classification scheme is to provide clear, concise, andnon-overlapping definitions for the various types of service you might use and encounter It’s choosing the right SOA partner so you can get on with the businessduring a SOA initiative. An effective service classification will help facilitate communication For list rental information: of the business. (Hello, tomorrow.)between the various groups and individuals involved in a SOA initiative, from business us- Kevin Collopy: 845 731-2684,; Frank Cipolla: 845 731-3832, frank.cipolla@epostdirect.comers to application developers. It does this by providing a common and accepted language,allowing more effective communication between the various stakeholders in your organi- SYS-CON Publications, Inc., reserves the right to revise, republish and authorize its readers to use the articleszation. submitted for publication. Since we don’t have a standard means of classifying the types of services in a SOA, weunfortunately have to create a new classification hierarchy every time we embark on a new Technology for better business outcomes. initiative. Service classifications differ greatly among various companies and SOA ©2008 Hewlett-Packard Development Company, L.P.6 OCTOBER 2008 OCTOBER 2008 7
  5. 5. TAXONOMY essential complexity (complexity that is inherent in the problem Enterprise Services the data needed by the Business Service as defined by the Business domain itself ) while at the same time trying to avoid accidental Services contained in this service type are also considered core Service input and output specification. complexity (unnecessary complexity we introduce ourselves). One SOA services. Enterprise Services are concrete services that imple- A service classification template containing the primary char- way to accomplish this is to start with four basic SOA service types, ment Business Services. The relationship between an Enterprise acteristics for the service type of Application Service might look as and only extend these service types if necessary. Service and a Business Service is either a one-to-one or many-to- follows: one relationship (many Enterprise Services implement a single The Basic SOA Service Types Business Service). Since Enterprise Services have scope across Infrastructure Services When developing any SOA service taxonomy, a good place to application domains, they are typically identified and defined by an This service type classification defines those services that are start is with the four basic service types: Business Service, Enter- Enterprise IT Architect or a shared services team. They are concrete used to support the enterprise. Examples of Infrastructure Services prise Service, Application Service, and Infrastructure Service. This services, meaning they are implemented through some sort of include such aspects as logging, auditing, data access, security, andFigure1 is the simplest possible hierarchy, and in most cases will probably underlying technology or vendor product. Like Business Services, so on. These concrete services are generally shared by the enter- satisfy the needs of your particular domain or initiative. The follow- these services are typically course-grained and represent actions prise and used by Enterprise Services (and sometimes Application ing diagram illustrates the basic service classification structure: against major data entities. Services). The following sections describe the attributes and characteris- Since the relationship between an Enterprise Service and a Busi- What distinguishes Infrastructure Services from Enterprise tics of each of these four basic SOA service types. While you will ness Service is commonly a many-to-one relationship, Enterprise Services is that Infrastructure Services implement non-business most likely find these types sufficient for your particular needs, Services usually require some sort of service orchestration, which functionality. The gray area between Infrastructure Services and you can certainly extend these further if needed. I present some can be implemented through an aggregate service or through Enterprise Services appears when considering such regulatory guidelines at the end of this article on when this makes sense and middleware technology (e.g., Enterprise Service Bus or workflow requirements as auditing and compliance. Although some forms of how to avoid the common pitfalls associated with extending this engine). For example, several Enterprise Services would need to be auditing and compliance are designated as business requirements, basic hierarchy. orchestrated to implement a CreateQuote Business Service, includ- these services do not specifically address a particular user or busi-Figure2 ing createCustomer, checkMotorVehicleReport, calulateQuote, ness function; rather, they support the business requirements. Business Services saveQuote, and so on. Infrastructure Services are typically identified and implemented Services contained in this service type are considered core A common misconception is that Enterprise Services must be by application developers or an infrastructure support team. They services in SOA. They can be derived from use cases, user stories, shared across the enterprise. Although Enterprise Services are gen- generally have enterprise-level scope, which is one reason they are user scenarios, or through the service identification and specifi- erally shared, it is certainly not a requirement. However, Enterprise typically confused with Enterprise Services. cation steps found in many SOA-based methodologies. They are Services should be course-grained and have the ability to be shared A service classification template containing the primary charac- course-grained, usually identified and defined by business users, across the enterprise if needed. teristics for the service type of Infrastructure Service might look as and represent a business process or function. When choreographed Enterprise Services have scope within the context of a Business follows: they represent the manifestation of a high-level use case or user Service, and therefore implement some sort of business logic. For scenario. Business Services are abstract definitions containing a example, an auditing service, although required for regulatory com- Service Taxonomy GuidelinesFigure3 service name, input specification, and output specification inde- pliance, would not be considered an Enterprise Service. Rather, that You can certainly extend the basic four service types either pendent of the underlying technology. In other words, the input type of service would be classified under Infrastructure Services horizontally or vertically to suit your particular needs. However, and output specifications to the service represent data and infor- (described below) because it does not directly serve a specific busi- before considering extending the basic hierarchy, you may want to mation collected and consumed by the service. ness function. consider the following service taxonomy guidelines: For example, to produce an auto quote an insurance com- The potential impedance mismatch between the data (and pany collects specific information from the customer, stores that format) specified in the Business Service and the data (and format) • Start your service taxonomy with the four basic service types information, and then presents the auto quote to the customer. expected by the Enterprise Service implementation is usually ad- described above first. If you think you need an additional service The information the insurance company collects for creating the dressed through message transformation and message enhance- type at the same level, make sure it is non-overlapping with auto quote would be represented in the service input specifica- ment, which are usually implemented through XSLT transforma- respect to other service types. If you think you need an additional tion, and the information it provides back to the customer would tions located in a middleware component or Enterprise Service breakdown of service types below the basic level, then read on.Figure 4 be represented in the service output specification. The name of Bus. this business service might be CreateQuote. It’s important to real- A service classification template containing the primary char- • Avoid the common pitfall of creating domain specific service ize that the input and output data specification for this business acteristics for the service type of Enterprise Service might look as types (i.e., types that are specific to divisions or functional groups service is completely independent of the underlying technology, follows: within your domain). For example, if in the insurance domain, language, or platform used to implement the business service. avoid creating service types such as Claims Services, Policy Technically speaking, while Business Services are typically imple- Application Services Services, and so on. These are not service types, but rather actual mented through standards such as WSDL (Web Services Definition While an Application Service is considered a basic service type, domain service names that are represented through the various Language), they can be implemented in any sort of CDL (Contract services contained in this service type are not considered core ser- types of services. To put it another way, there are many differ- Definition Language), be it WSDL, XML, or some other interface vices within the context of SOA; rather, they are referred to as sup- ent service types that constitute a Claims Service (e.g., Business language. porting services. These concrete services are usually fine-grained Services and Enterprise Services). Don’t confuse an actual serviceFigure5 The name of a Business Service is typically constructed in a and are associated with a specific application. In other words, they name (e.g., Policy Service) with the service type (e.g., Business verb-noun format, with the verb being one of the typical CRUD have application (or silo) scope and therefore are generally not Service).initiatives; some get it right, but most seem to get it wrong. How verbs (Create, Read (or get), Update, and Delete) and the noun shared in the enterprise. Application Services are typically identi-to recognize a good classification and poor classification is part representing one of the major business entities found in a typical fied and defined by application developers and are specific to the • Keep your classification hierarchy taxonomy as simple as possibleof what this article is about; the other part is how to build off of a Business Entity Model. Examples of typical Business Services application scope they are defined under. and avoid accidental complexity; remember one of the goals ofstandard set of service classifications to create a more effective clas- include CreateQuote, ExecuteTrade, GetCustomer, GetPolicy, and Application Services are generally used to perform fine-grained the service taxonomy is to facilitate communication between thesification scheme for your SOA initiative. PlaceOrder. application-specific functions such as validation, data collection, various stakeholders and groups involved in the SOA initiative. An effective service taxonomy is one in which the service type A service classification template containing the primary char- and data transfer. For example, when creating an auto quote the ap- A complex hierarchy of service types will create confusion anddefinitions are clear, concise, and most importantly non-overlap- acteristics for the service type of Business Service might look as plication developer may create services such as addDriver, addAd- hinder the basic understanding of the service types you are When creating a service taxonomy you should try to simplify follows: dress, addVehicle, and so on. These services are used to accumulate A complex hierarchy invariably leads to increased debates and8 OCTOBER 2008 OCTOBER 2008 9
  6. 6. TAXONOMY �� ��� �� ���� ��������� � � � � ������������� ��� ����“An effective service taxonomy taxonomy as soon as the SOA initiative starts by using the basic SOA service types and refining it as necessary during the project � �� ��� ����� � � ��� ��� ���������developed early in your SOA initiation phase of the initiative. ������������ � ��initiative can significantly improve • If you end up with something like a “duck-billed platypus” when creating the service taxonomy, stop and revisit how youyour chances for success” are defining your service types. After all, you are just classifying ������������������������ service types, not something as complex as the animal kingdom. Chances are you are introducing accidental complexity and mak- ing the service hierarchy more complex than it actually needs to ISBN 0-9777622-0-3 lengthy meetings about how deep and wide the hierarchy should be. Keep it simple. ��������������� extend, and also increases the chance for overlapping service types in your classification hierarchy. Summary An effective service taxonomy developed early in your SOA• Consider creating a simple context diagram showing the relation- initiative can significantly improve your chances for success. Com- ship between the different service types in the service taxonomy, munication, clarity, and collaboration between the stakeholders in particularly if your classification hierarchy extends beyond the a SOA initiative are all key to the success of the overall effort. Start ��������������������������������������� basic four service types. This can greatly help in understanding simple, use the four basic service types (Business Service, Enter- where the service types fit into the big picture. prise Service, Application Service, and Infrastructure Service), and �� ������������������������������������������������������������������������������������� only extend the classification hierarchy only when necessary. Make � �����������������������������������������������������������������������������������• Create an agreed-upon template for recording the definition Mr. Linnaeus proud. and attributes of the service taxonomy. In general a tree-graph ��������������������������������������������� ������� coupled with a context diagram and a simple document template About the Author is all that’s needed to effectively document and communicate the ���� Mark Richards is a director and senior solutions architect at Collaborative Consulting, LLC, ������������������������ ���� service taxonomy. Try not to go overboard with complex tools or where he is involved in the architecture and design of large-scale Service Oriented Architec- � ���� UML to describe the hierarchy. If you need such tools, chances tures in J2EE and other technologies, primarily in the financial services industry. He served are your service taxonomy is too complex and should be simpli- as the president of the Boston Java User Group in 1997 and 1998, and the president of the ����������������� fied. New England Java Users Group from 1999 to 2004. He is the author of several technical from the Worldʼs Leading i-Technology Publisher © COPYRIGHT 2007 SYS-CON MEDIA books, and speaks at conferences around the country. Prior to joining Collaborative Consulting• Don’t wait until the SOA initiative is well underway before Mark served as an executive IT architect at IBM with a focus on SOA in the financial services beginning to put together a service taxonomy; start creating a industry. �� ���� �� ��� �� ��������� ���������� �� ����� ���� ��� �������� � � ��� ��� �� ������ ��������������� � �� �� �������������������������� ��������������������� � ������������������� ������������������������������� ISBN 0-9777622-2-X � � ��� � � � � � � � � ����� � � � ����������������� ������������������������ ����������������� ������������ ������������ ������������������������������������������������������������ �������������������������������������������������������������� ���������������������������������������������������������������� ���������������������������������������������������������������� ������������������������������������������������������������� ������������������������������������������������������������������� ��������������������������������������������������������� ������������������������������������������������������������������� ����������������������������������������������������������������������������������������������������������������� ������������������������������������������������������������������������ ������������������������������������������������������������������������������������������������������������������ ����������������������������������������������������������������������� ��������������������������������������������������������������������������������������������������������� ��������������������������������� ������������������������������������� ��������������������� �������������������������������������� ���������������������� ���� ����� ���� ������� ������������������������ ����������������� from the Worldʼs Leading i-Technology Publisher © COPYRIGHT 2007 SYS-CON MEDIA10 OCTOBER 2008 OCTOBER 2008 11
  7. 7. GOVERNANCEDesign Time SOA Governance Needs SomeWork...Humans and Tools BY DAVID S. LINTHICUM Y ou need SOA governance, design time, They don’t consider SOA holistically, but instead focus on the and runtime. However, SOA gover- design and management of new and existing services. That’s a very nance does not come out of a box. small part of SOA, when you get right down to it. Simply put, it’s really a matter of people Another issue with design-time SOA governance technology, and and processes put in place to insure that the as with most SOA technology, is the lack of a standard approach services are designed, deployed, and operated as to design-time SOA governance. While there are a few standards effectively as possible. However, people and SOA emerging, most SOA governance technology providers have gone vendors seem to be dropping the ball around off in their own proprietary directions, using their own approaches,design time, in terms of both people and tools. It’s more about and no two are alike. Thus, not only are you picking a tool, butmissing approaches and missing features, and once again there you’re picking a design approach which may or may not be right forneeds to be some education out there as to how organizations need you. The tools should never dictate the approach; they should sup-to approach SOA. port best and proven practices, as well as drive design that holisti- First of all, those who define SOA governance as a set of tech- cally supports more strategic modeling and simulation features,nologies are missing the boat on this concept. The humans need and supports what SOA be factored into the equation. Second, when you do focus on The whole notion of design-time SOA governance could be �����������������������������������������the tools, many things that are required for good SOA governance getting us off track when it comes to the proper approach todesign are missing, and there are no signs that things will get better. SOA. This is really the fault of the humans who focus way too ������������������������First, let’s deal with the humans. much on the technology and not the processes or approaches, The fact of the matter is that SOA governance, and governance and the fault of the SOA design-time vendors who need to do ain general, is really a people and process thing, with technology great deal more work on their offering, else the SOA architectsonly coming into play to automate the processes and support the will just jump directly into SOA runtime governance, which, as itpeople. If you don’t establish that, you’re going to fail at SOA gov- seems, many are already doing today if you look at the penetra-ernance and thus fail at SOA, no matter how much technology you tion of the technology into the market. I suspect the design-time“invest” in. SOA governance vendors will be fixing a lot of things this year Thus, people rely more on tools and technology than education and next. � � ��� � � � � � � � � ����� � � �when it comes to SOA governance, when it really needs to be theother way around. Indeed, I promote the 80/20 rule when consid- ����������������� ������������������������ ������������������������ ����������������ering SOA governance. 80 percent of the time, effort and money About the Author ������������ ������������ ������������ ������������should be spent on learning how to create and operate an effective David S. Linthicum is an internationally known thought leader in the EAI, SOA, enterpriseSOA governance strategy, in terms of people and processes. Then architecture, and Web 2.0 spaces. He is a sought-after consultant, speaker, and writer, andyou can spend the remaining 20 percent learning about the tools. formed David S. Linthicum, LLC (, a leading consulting organizationMost drive toward the tools first, then to the approach as defined by focusing on enterprise architecture, SOA, and use of the next-generation Web within the en- ���������������������������������������������������������������������������������the tools. In doing that, you assume your tools are correct in their terprise. He is the former CEO of BRIDGEWERX, CTO of Grand Central Networks, as well as CTO ���������������������������������������������������������������������������������������approach and function, which is typically not the case, and my next of Mercator Software (now a part of IBM) and SAGA software (now a part of Software AG).In �����������������������������������������������������������������������������������point. addition, Dave was an associate professor of computer science for eight years, and continues �������������������������������������������������������������������������������������� Now, let’s deal with the technology. to lecture at major technical colleges and universities, including University of Virginia and The issue with design-time SOA governance technology (not Arizona State University. He keynotes at many leading technology conferences, and has sev- ����������������������������������������������������������������������������������������runtime) is how deeply the technology goes to serving the true eral well-read columns and blogs, as well as a weekly Podcast. Dave has authored 10 books, �������������������������������������������������������������������������������������������������notion of “design” as outlined above. The fact is that most don’t go including the ground-breaking “Enterprise Application Integration” and “B2B Application ������������������������������������������������������������������������������������������that deep, and many who design a SOA are left wanting more robust Integration.” You can reach Dave at and functions, including true modeling and simulationcapabilities based on SOA design and development best practices. �����������������������12 OCTOBER 2008 ���������������������� OCTOBER 2008 13
  8. 8. LATEST TRENDS IN SOA toolset. As a result, the most common use of SOA technology is to tecture – and although after 23 years in the world of software I have integrate existing inside-the-enterprise applications. not yet encountered any company that has achieved this goal, it is SOA technology is a fine choice for internal integration projects; I still a laudable one for many practical reasons. don’t mean to dissuade IT from using SOA. The problem is oppor- In contrast to this, when your focus is outside the enterprise, tunity cost – if an organization focuses its SOA efforts (time, budget, not only is a single-service access method an undesirable goal, it management attention, etc.) inside the enterprise, its opportunities is a completely unachievable goal and should not be attempted. for meaningful innovation will be small compared with what could The reason for this is simple math. While a large company may be accomplished outside the enterprise. have 300-1,000 internal systems that require integration and might Doing business in the global arena creates a great number of possibly all designed to use a Web Services interoperability ap- problems and opportunities that can only be solved outside a proach, that same company could have 20,000 suppliers or 20,000 company’s four walls. Trends of industry consolidation (mergers B2B customers, each with multiple process/data integration touch The Next Paradigm – and acquisitions) force companies to be ready to respond quickly points. Attempting to have this population of trading partners con- to major structural changes in their supply chain, demand chain, form to a single technology implementation is grossly impractical. or ownership. The complex demands of a global environment Your customers won’t accept your demands. In fact, if they are big Multi-Enterprise SOA – extended supply chains that must be managed, multiple tax and enough, your customers may demand what technology you must regulatory regimes that must be accommodated, multiple subsid- use – and each customer could demand a different technology. iaries or partners that must be coordinated – all point to the unique Your suppliers may agree to your technology demand, but to do so requirements of and need to address the multi-enterprise environ- increases their costs and increases the price you pay them in some ment. direct or indirect way. Even if by some miracle your community of The practice of SOA is overdue for There are many different multi-enterprise opportunities that trading partners could agree on a single technology, it is logistically can provide substantial return on investment (ROI) if properly impossible for all parties to adopt or upgrade to the same version of addressed. For example, in an AMR Research study that analyzed the same standard simultaneously. a paradigm shift companies implementing demand-sensing solutions, several com- panies achieved amazing results: In a multi-enterprise SOA environment, Web Services are an important option, and you can use them some of the time. But you will also need to support a wide range of other options – AS2, AS3, • 15% reduction in inventory AS4, ebXML, SOAP over JMS, FTP RosettaNet, SWIFT, etc. In the , BY CHRIS JOHNSON • 17% improvement in perfect order performance end, you may not choose Web Services as your preferred chan- • 10% higher revenue and 5%-7% higher margin than competitors nel for multi-enterprise interactions since more tightly defined standards such as AS2 can be easier to govern and manage in a T It’s hard to imagine an internal systems integration project that multi-enterprise environment. Whatever your preferred channel he concept of a paradigm shift was first could deliver business results of this magnitude. might be, being able to support a multi-channel approach is a key popularized by Dr. Thomas Kuhn in his According to a recent Gartner report, “By 2011, midsize-to-large requirement for multi-enterprise SOA. book The Structure of Scientific Revolu- companies will at least double the number of multi-enterprise tions. Kuhn described a phenomenon and interoperability projects they’re managing and will spend at Heresy #3 – SOA will be a legacy technology in which one worldview, or paradigm, is adopted least 50% more on business-to-business (B2B) projects compared For inside-the-enterprise purposes, SOA technology is modern so widely that its concepts, beliefs, terminology, with 2006.” Gartner also says, “Global 2000 companies will double and current. However, in the multi-enterprise environment, SOA values, and techniques eventually become unex- the number of automated multi-enterprise transactions, docu- technologies will need to be managed in much the same way as amined assumptions, leading to a condition of ments and process-execution events between 2006 and 2011.” SOA other legacy technologies.“paradigm paralysis” that prevents people from seeing beyond their concepts and technologies can play a crucial role in making these The reason for this is the different dynamic of technology adop-current mode of thinking. The shift to a new paradigm is triggered multi-enterprise projects successful and can deliver a much higher tion inside and outside of the enterprise. Inside the enterprise,only when the prior worldview is stretched beyond its limits and a ROI than internal systems integration projects. prudent IT management creates the motivation to limit the numberradical new worldview originally seen as heresy disproves central of technologies and versions in use and the rate of change fromassumptions of the prior paradigm and is widely adopted (to begin Heresy #2 – SOA isn’t (only) about Web Services one technology era to the next. Outside the enterprise, you can’tthe cycle again). Another area in which the practice of SOA is somewhat in conflict achieve that degree of control. New technologies – or new versions The concept of Service Oriented Architecture (SOA) has caused with the broader concept of SOA in the multi-enterprise domain or combinations of technologies – will arise in such a way that youa profound shift in the worlds of business and technology, causing is the choice of enabling technologies. While SOA thought leaders can’t avoid adopting them. There are many multi-enterprise wireimportant changes that will stand the test of time in how millions are careful to point out the separation between SOA concepts and protocols, process protocols, and data standards, each of whichof people think and work. However, I believe the practice of SOA is technology for many practitioners the phrase and concept of SOA changes on its own schedule as determined by third parties. Foroverdue for a paradigm shift – a shift of focus away from enterprise has become interchangeable with Web Services: instance, a typical global manufacturer might need to support ANSIarchitectures and applications toward larger, fundamentally differ- X12, EDIFACT, TRADACOMS, CII, RosettaNet, HIPAA, SWIFT, ACH,ent problems that need to be solved in the space between enter- “Even though service-orientation as a paradigm and SOA as a OFTP ... typically 20 or more separate standards. Across the sameprises – a problem/solution domain I call multi-enterprise SOA. technology architecture are each implementation-neutral, their as- manufacturer’s population of suppliers and customers, one might Multi-enterprise SOA manages the flow of business processes sociation with Web Services has become commonplace – so much so expect to find current and older versions of technologies and stan-and data across departmental, organizational, and geo-political that the primary SOA vendors have shaped their respective platforms dards in various combinations – the latest OAGi document formatboundaries, enabling organizations to rapidly adapt to changing Heresy #1 – IT doesn’t matter (as much) around the utilization of Web Services technology.” sent via WS-I Basic Profile 1.0-compliant Web Services, an olderbusiness, technology, and legislative environments and facilitating For many organizations, the current practice of SOA is firmly TRADACOMS document sent via a non-standard FTP protocol, theIT-driven growth in a way that enterprise-internal projects gener- based on the principles and habits of inside-the-enterprise infor- Selecting a single implementation technology such as Web Services latest version of a SWIFT MX message sent via a service bureau us-ally cannot. This concept of multi-enterprise SOA includes several mation technology (IT). As practiced in many companies, SOA is, can be a sensible thing to do when your focus is inside the enter- ing AS2, and any other conceivable combination.principles that SOA practitioners may view as heresy. in essence, just another application development and integration prise. Many companies aspire to have consistent enterprise archi- In the multi-enterprise environment, companies are accustomed14 OCTOBER 2008 OCTOBER 2008 15
  9. 9. LATEST TRENDS IN SOAto supporting a variety of old and new technologies and standards. subsidiaries, it’s usually the case that technology choices – infra-Technologies you consider to be the latest and greatest could be structure, applications, standards, adoption patterns, and so onviewed as legacy by some of your trading partners. And technolo- – are independently determined by each division and have thegies you think of as outdated will be required by some of your same range and complexity of technologies that a similar numbertrading partners for years to come. While this situation would be of external trading partners would present. This is especially trueviewed as undesirable inside the enterprise, it is expected and, to for companies that have grown through a series of acquisitions.some degree, desirable in the multi-enterprise environment. Objec- Enterprise SOA solutions are not well suited to interoperating withtives of multi-enterprise SOA include acknowledging and dealing this wide range of protocols and standards, but multi-enterprisewith the unavoidable complexity of the outside world (rather than SOA solutions are.just reducing complexity) and becoming easy to do business with The same is true for companies that use business process out-(rather than just reducing IT costs). sourcing (BPO) providers that may function like The cost of not being easy to do business a company department or division but bring inwith is simply too great. If a trading partner a different set of technologies. Decisions to addcan’t or won’t integrate with you electronically, or change BPO providers, or bring a BPO func-they will instead submit their purchase orders, tion in-house, causes technology churn similar toinvoices and other transactions by fax, mail changing external trading partners. As enterprisesor phone call – in which case each transaction become more virtual and make greater use of thecan have manual handling costs five times sourcing options available, the line defining thegreater than a fully electronic exchange. Multi- “enterprise” boundary can move very quickly, andply that expense by the number of transactions the multi-enterprise SOA approach becomes theyour company and trading partners exchange only viable way to manage this change and com-over the course of a year and your motivation accommodate a wide range of potentially Lastly, most companies that have SOA infra-legacy technologies (both inbound and out- structures actually have multiple SOA technologiesbound) becomes very clear. and vendors, and these disparate SOA infrastruc- SOA technology in general won’t become tures also need to be integrated. In many cases, the“legacy” until the next major revolution in disparate enterprise SOA technologies will still bearchitecture thinking, but due to the need to able to interoperate. However, with a large enoughsupport a large number of past, present, and technology gap or design philosophy difference, afuture technologies at once in the multi-enter- multi-enterprise-style SOA solution may be a betterprise domain, the way you have to think about choice to address the range of technology differ-and manage SOA technologies will be more ences, even between the multiple enterprise-ori-like how you manage other (including legacy) ented SOA solutions.technologies than the way you think aboutand manage your inside-the-enterprise SOA Conclusiontechnologies. All kidding and hyperbole about “heresies” aside, the multi-enterprise view of SOA is distinctlyHeresy #4 – You need multi-enter- different from the inside-the-enterprise view andprise SOA inside your enterprise has largely been overlooked by many SOA practitio- The same tools and technologies you use to ners. SOA will always play a strong role inside thesolve your multi-enterprise SOA requirements enterprise, but companies shouldn’t focus on it toare, in many cases, the best choice for solving the exclusion of the potentially greater rewards ofyour inside-the-enterprise SOA requirements multi-enterprise well. Most large companies function like a col- About the Authorlection of smaller distinct companies rather Chris Johnson is the vice-president of global product managementthan one large uniform company. Whether the for the Integration Suite product line at Sterling Commerce, an AT&Tdivisions are business units, departments, or company. “Multi-enterprise SOA manages the flow of business processes and data across departmental, organizational, and geo-political boundaries”16 OCTOBER 2008 OCTOBER 2008 17