SOA A View from the Trenches

618 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
618
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SOA A View from the Trenches

  1. 1. SOA: A View From The Trenches A Research Report Prepared by EMA August 2006
  2. 2. Table of ContentsExecutive Summary ..............................................................................................................................................................................1SOA In The Marketplace: Hype Or Reality? ...................................................................................................................................1Methodology ..........................................................................................................................................................................................3Analysis....................................................................................................................................................................................................3Key Takeaways .......................................................................................................................................................................................4 Summary of Key Takeaways.........................................................................................................................................................4Case Studies ............................................................................................................................................................................................5 Case Study #1: MedicAlert ...........................................................................................................................................................5 Overview .................................................................................................................................................................................5 The Challenge: Business Drivers for SOA .......................................................................................................................5 Implementation Details ........................................................................................................................................................5 SOA Products Currently in Use: .......................................................................................................................................6 Product Selection Process ....................................................................................................................................................6 Results ......................................................................................................................................................................................7 Issues ........................................................................................................................................................................................7 Advice to New Users ............................................................................................................................................................7 Key Takeaways .......................................................................................................................................................................8 Case Study #2: Lockheed Martin.................................................................................................................................................8 Overview .................................................................................................................................................................................8 The Challenge – Business Drivers for SOA .....................................................................................................................8 Implementation Details ........................................................................................................................................................9 SOA Products Currently in Use..........................................................................................................................................9 Results ......................................................................................................................................................................................9 Issues ........................................................................................................................................................................................9 Advice to New Users ............................................................................................................................................................10 Key Takeaways .......................................................................................................................................................................10 Case Study #3: TrueCredit ............................................................................................................................................................10 Overview .................................................................................................................................................................................10 The Challenge – Business Drivers for SOA .....................................................................................................................10 Implementation Details ........................................................................................................................................................11 SOA Products Currently in Use: .......................................................................................................................................11 Product Selection Process ....................................................................................................................................................12 Results ......................................................................................................................................................................................12 SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  3. 3. Issues ........................................................................................................................................................................................12 Advice to New Users ............................................................................................................................................................12 Key Takeaways .......................................................................................................................................................................12 Case Study #4: Thomson Learning.............................................................................................................................................13 Overview .................................................................................................................................................................................13 The Challenge – Business Drivers for SOA .....................................................................................................................13 Implementation Details ........................................................................................................................................................13 SOA Products Currently in Use: .......................................................................................................................................14 Product Selection Process ....................................................................................................................................................14 Results ......................................................................................................................................................................................14 Issues ........................................................................................................................................................................................15 Advice to New Users ............................................................................................................................................................15 Key Takeaways .......................................................................................................................................................................15 Case Study #5: Financial Services Organization ......................................................................................................................16 Overview .................................................................................................................................................................................16 The Challenge – Business Drivers for SOA .....................................................................................................................16 Implementation Details ........................................................................................................................................................16 SOA Products Currently in Use: .......................................................................................................................................17 Product Selection Process ....................................................................................................................................................17 Results ......................................................................................................................................................................................17 Issues ........................................................................................................................................................................................18 Advice to New Users ............................................................................................................................................................18 Key Takeaways .......................................................................................................................................................................18Summary Tables: Drivers, Issues, Advice to New Users ...............................................................................................................19 Drivers ...............................................................................................................................................................................................19 Issues .................................................................................................................................................................................................20 Advice to New Users .....................................................................................................................................................................21Case Study Summaries..........................................................................................................................................................................22How Do I Do It? One Approach To SOA Implementation........................................................................................................25Conclusion ..............................................................................................................................................................................................27SOA: A View from the Trenches©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  4. 4. Executive Summary Service Oriented Architecture (SOA) is a hot topic at the moment, and for that reason EMA chose to devote a three part research series to the subject during 2006. The first paper in the series, entitled “Service Oriented Architectures: Coming of Age in the Enterprise and the Marketplace,” was published in February. It discussed SOA’s evolution in detail, along with SOA concepts and current direction. The second paper in the series, entitled “SOA Market and Products 2006: Current State, Future Directions,” was published second quarter, and provided a detailed product landscape of SOA solutions in the marketplace. Much of the information in that paper will also be included in EMA’s online SOA Solutions Guide, which will be available late summer of 2006. This paper is the third and final paper in the series. It offers a point- in-time perspective on how SOA is being used in today’s enterprises to solve today’s business problems. This paper is being written in part as an answer to the articles appearing in the trade news questioning whether SOA is “real.” In fact, EMA recently attended an analyst conference sponsored by one of today’s largest vendors at which an analyst actually asked that same question. Our industry is bombarded with “news” and “technologies du jour,” many of which come and go with little or no impact on the industry over time. Our industry has been bedeviled by smoke and mir- rors during its somewhat short history, and it is little wonder that analysts and customers alike have become skeptics. In the course of producing the landscape paper referenced above, EMA briefed with a wide range of vendors who dis- cussed their customer success stories in the SOA space. After those discussions, we were prompted to follow up with our own customer interviews to get a first-hand perspective on what is required to roll out SOA services in 2006. Vendors are telling us that SOA is real – is it? We are hearing that SOA implementations are going beyond prototypes and conference room pilots, are being implemented as production deployments, and are scaling to huge transactional numbers – is this true? The early adopter case studies and analyses presented in this paper help answer these questions. In navigating through end user stories, we discovered that SOA is in fact real, but that it’s hard. We found that SOA implementations can yield enormous business benefits, but not without visionary leadership and a healthy dose of orga- nizational commitment. Especially at the beginning, when SOA is an unknown quantity, it requires an enormous shift in skill sets, a long learning curve and an investment in organizational change – so it’s not for the faint of heart. Companies succeeding in deploying SOA services, however, are positioning themselves for competitive leadership in their industries and significant new revenue opportunities. SOA offers a glimpse of a very intriguing technology future. Its complexity and its promise will bring the industry full circle. In recent years, pundits have discounted the value of technologists and the technology they build in favor of busi- ness vision. SOA drives home the reality that we’ve entered an era when business can’t be successful without technology. The early adopters profiled in this paper underline the fact that in most industries today, business success is dependent as never before on the skill, creativity and talent of the IT technologists who are bringing these services to market. SOA In The Marketplace: Hype Or Reality? Estimates on SOA spending vary, but a conservative estimate is that spending worldwide on technology and services will be upwards of $40 billion dollars by 2010. Vendors and consulting firms are getting in line for a slice of this pie and there will clearly be a lot of room for both, as a majority of organizations indicate that they plan to roll out SOA initiatives during 2006. SOA is clearly being billed as the next great opportunity for both vendors and businesses, and this is undoubtedly one of the reasons why it is continually in the news. However, a bigger reason why we’re hearing so much about SOA is because it is reported as being capable of delivering startling benefits in terms of business agility and ROI (Return On Investment). Organizations interviewed for this paper reiterated this fact over and over: those organizations that have started down the SOA path, then abandoned it as “too hard” or “too expensive” are the reason why SOA is still viewed as a pipe dream in some quarters. This is definitely a case where a high initial investment in terms of time and money yields expertise,page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  5. 5. assets and infrastructure that enable subsequent rollouts 80%to be implemented much more quickly than would bepossible using traditional legacy architectures. SOA’s 70%payoff comes with reuse, not during ramp up, which is 70%one reason why it is so important that SOA rollouts haveexecutive sponsorship. 60%SOA isn’t simple to implement. You can’t buy a product 50%and roll out an SOA. You can’t adopt industry standardsor Web Services and “do” SOA. SOA is just an architec- 40%ture, and fleshing it out into an organizational strategyrequires technology expertise, organizational gover-nance, executive sponsorship and a fairly hefty up-front 30%investment. The touted cost savings don’t start until thefirst few implementations are in place. Because of this, 20%businesses with short-term IT strategies are wary of 10%SOA because of the risk of investing a lot of money and 10%potentially ending up with little to show for it.How pervasive is SOA? We’ve seen published figures 0% Research Estimate Vendor Estimateranging from an astonishing 70-80% to a more realistic10-25%. We use the word astonishing because the 70- Figure 1: SOA Adoption in 2006: Published80% figure is obviously way off the mark and probably Estimates versus Vendor estimatesreflects a misunderstanding of the difference betweenSOA and Web Services. Are 70-80% of companies using some form of Web Services? It is conceivable, since any com-pany that is using XML-enabled products is using Web Services. But that doesn’t mean they are doing SOA.The 25% figure is closer if you include companies that are experimenting with SOA in pilot projects or with small initialrollouts. However, the vendors we surveyed were unanimous in estimating the number of companies that have actuallyrolled out production grade SOA deployments at this point in time as probably less than 10%. Our estimate is that thisis probably closer to the mark.Who are these companies? The telco, financial and insurance industries, and surprisingly, government, have been earlyadopters, as have Web-based retail companies. Why have they done so? Primarily because alternative architectures werecosting too much in terms of development time, lack of business agility, and high risk of development project failure.The organizations currently leveraging SOA in production environments are savvy, understand the short-term cost aswell as long-term payoff, and have one BIG requirement in common – they HAVE to integrate.One of the vendors interviewed for this paper, a provider of registry and repository products, provided an excellentillustration of how SOA is being used in today’s business. The example involves a telecommunications company thatprovides a multitude of services, including trouble ticketing, billing, etc. to very large customers. Customers want to havethese services integrated into their own systems. For example, trouble ticketing has to integrate with monitoring andalerting systems already in-house.Typically, each new customer used the same 90% of the telco application’s base code. Only the remaining 10% variedfrom one customer to the next. However with traditional integration efforts, the telco invested approximately 3,000person hours in each new integration effort. This time was required to go through the entire development lifecycle frombusiness plan through analysis, design, coding, testing and, finally, implementation.Using policies, a registry and SOA development techniques, the telco was able to move much of the 10% of require-ments that varied between customers into configurable metadata, that is, into policy-based operational parameters. Now,customer connections run through the registry, which acts as an intermediary between systems and transparently executesSOA: A View from the Trenches page 2©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  6. 6. each customer’s policies. The result is that the telco was able to reduce new customer integrations from an average of 3,000 hours per customer to an average of 160 hours per customer. Obviously, the ROI in situations like this one is expo- nential. Not only can each customer be integrated to the telco base system in a fraction of the time required previously, but more customers can be provisioned in the same amount of time. Obviously, telecommunications companies are among the leading edge market leaders in terms of technology capabili- ties. Getting that first customer on board using SOA required an investment in products, training, services, and a pilot project. The first few implementations required a learning curve as well. Once that initial investment was made, however, the ROI was very rapid. This is characteristic of SOAs and this scenario is being played out across the industry as SOA implementations proliferate. With these kinds of results, it becomes clear that SOA isn’t vaporware, isn’t a fad, and isn’t going to go away. In fact, many industry experts predict that this is the direction the entire industry is taking, and when you look closely at the kinds of returns that SOA is producing, it looks more and more as if they are correct. Methodology To gather information for this paper, EMA did in-depth interviews with five organizations with between 2 and 6 years of experience with Service Oriented Architecture. Currently, EMA sees SOA as cresting the “early adoption” phase, and this presents difficulty in terms of locating interviewees that both have a good understanding of SOA and have used it in production. Once interviewees were located and contacted, EMA used a standardized questionnaire for each interview that followed the format of the interview results detailed in this paper. These interviews provided the raw data for the Case Study profiles in the “Customer Stories” section of this paper, as well as for the “Drivers,” “Issues,” “Advice to New Users” and “Key Takeaways” summaries. The “How Do I Do It? One Approach To SOA Implementation” section is a step-by-step implementation strategy cre- ated by summarizing EMA’s 2006 SOA research series. It condenses all three of EMA’s 2006 SOA studies, including the “Advice to New Users” from our five case study interviewees, into a single step-by-step methodology that represents our current recommendations as to a potential strategy for SOA adoption. This strategy will be updated in years to come as SOA is more widely adopted and becomes more mature. Analysis Each case study includes the following sections: • Overview • The Challenge – Business Drivers for SOA • Implementation Details • SOA Products Currently in Use • Product Selection Process • Results • Issues • Advice to New Users • Key Takeaways Drivers, Issues, Advice to New Users, and Key Takeaways are summarized by interviewee in a series of tables at the end of the Case Studies section. However, the section immediately following this one provides a high level summary of findings for those readers interested in summarized versus detailed information.page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  7. 7. Key TakeawaysSummary of Key TakeawaysThis section represents EMA’s summary of the key messages gathered during the course of this research. • Once SOA services are in place, expect exponential growth. • Consider governance from day one. If you don’t, growth quickly forces governance and you’ll have to go back and address what is already in place anyway. • Talk to the business, understand it, and make decisions based on its unique needs. • Don’t use a “big bang” approach to SOA adoption; instead, evaluate each new project to weigh the value of implementing it using SOA versus more traditional methodologies. • Consulting can help organizations determine whether SOA is the best option at a given point in time. However, interviewees were split on the consulting issue, with most recommending vendor consulting over general SOA consulting. • Planning pays off. Some of the interviewees spent months in the planning and design phases before they ever rolled out a service, and believe that is a major reason for their success. • Don’t get sidetracked by “religious discussions” about technology, such as SOAP versus REST. SOA isn’t just technology – in fact, it is technology-agnostic. • Where possible, shift functionality from hard-coded services to policy-based execution. One interviewee estimated that his organization saves up to an estimated 85% of development cost by doing this, while reducing the risk inherent in development projects. • Taking advantage of automated recovery and other automated capabilities in management solutions can improve performance and significantly reduce support costs. This typically is a hard sell to support staff, who may feel that they are losing control. However, choosing policy-based solutions that provide an audit trail can help mitigate this issue, since technicians set the policies and can refer to the audit trail if necessary. • Learn about loose coupling and learn how to use it – it is at the heart of SOA and one of the foundations for managing change. • The debate over fine-grained versus coarse-grained services continues to rage. However, our early-adopters indicate that, although they tend to start with fine-grained services, they combined them over time to make them more closely resemble “real” business services. • SOAs are designed for massive scalability. However, they may require performance enhancers such as XML acceleration appliances and load balancers to be viable performance-wise. • Keep it simple at first, and where possible, use home-built products or those that are already in-house. • Don’t invest in products until you see a clear need for them and understand specific requirements. Corollary: Use products already in-house until you outgrow them. • Regarding products, try before you buy. • SOA isn’t as much an end state as it is a development style. • Be aware that the reuse concept requires changes to development styles and techniques. • After the initial SOA services are rolled out and technologists have gotten through the learning curve, the benefits of SOA adoption can be significant. • The first few projects take much more time and are much more expensive than subsequent projects. • Although initial costs are high, subsequent rollouts become easier and yield considerable payoff. • The up-front investment required, aside from staff ramp-up, is to establish the minimum infrastructure including the Web Services stack, UDDI, and lightweight governance foundations.SOA: A View from the Trenches page ©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  8. 8. • Once the initial services are rolled out, the question of how services are paid for will become an issue, as business units across the organization will want to reuse services developed, and paid for, by other business units. Early on, the organization needs to address how this works as part of their governance process. • Keep abreast of standards as they are the route to interoperability. • If your company is too large and/or diverse to standardize on products, consider standardizing on standards. • SOA gives organizations the ability to create new services and bring new product offerings to market very quickly. • Although SOA implementations are initially easier to justify in terms of cost reduction, going forward, revenue generation becomes an additional driver. • Each new service becomes an asset that can be leveraged by multiple future projects. Case Studies Case Study #1: MedicAlert Company Name MedicAlert Number of Employees 150 Industry Vertical Healthcare Services Interviewee Jorge Mercado, Senior Engineer overview MedicAlert® is a private, non-profit medical informatics organization that provides personal health record services. Specifically, the company stores computerized medical records for each of its members, including key information such as medical conditions, medications, allergies and insurance information. In the event of a medical emergency, medical personnel can access this information and utilize it for proper diagnosis and treatment. the challenge: Business drivers for soA Medical information is stored in a variety of data stores including insurance companies, doctor’s offices, hospitals, and pharmacies. MedicAlert integrates this data, including that of other healthcare information providers, into a unified information view for each subscriber. MedicAlert requires the ability to integrate with an almost unlimited number of organizations creating, in effect, a “federated” view of patient medical information. While many of their integration partners still exchange information via scheduled FTP feeds, MedicAlert made the decision to leverage SOA to position them for real-time data exchange opportunities and to do this in a flexible, agile manner. An additional requirement was that they needed a faster way to respond to the dynamic business requirements so char- acteristic of the healthcare field. Given enough time, the IT group could have addressed evolving business needs using scalable systems, legacy architectures and traditional development techniques. However, a critical issue for MedicAlert is that they need to bring new business services to market very rapidly. Legacy software development methodologies and architectures simply require too much time to deploy. In the healthcare industry, flexibility and agility are key differentiators for industry leaders. With these requirements driv- ing them, Jorge Mercado’s group leveraged SOA to contribute to the business bottom line and help the company to gain marketplace leadership. Implementation details MedicAlert started their SOA initiative in April, 2004, and have been evolving their services ever since. They leverage SOA services for internal company use and to integrate with external customers and business partners. While external users need to be able to access subscriber medical records in real time, the business also uses the same data internally to create and submit orders. At present, they have approximately 20 SOA services in place.page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  9. 9. Jorge heads the Architecture team, which is composed of a total of 4 technologists. The team is responsible for theoverall enterprise architecture, including the SOA. While Jorge or someone on his team is responsible for design work, aseparate team is responsible for component development, and a third for Quality Assurance (QA) testing.As chief architect, Jorge is leading the SOA effort. MedicAlert chose to do all of the design and development workinternally, without general consulting assistance. However, they did use vendor consultants to assist with training andproduct implementation. Jorge believes that this vendor presence helped them to understand and deploy products fasterand to use them in more sophisticated ways, than would have been possible without this assistance.They shied away from bringing in general consultants for high-level SOA guidance. Jorge’s experience has been thatcompanies that do this tend to become consulting-dependent instead of developing necessary skills in-house. Theirapproach was to use technologists already on staff and give them the opportunity to thoroughly understand both SOAand the business. SOA needs to be implemented differently for each business, and from MedicAlert’s perspective, generalconsultants tend to apply “cookie cutter” solutions to very diverse business problems.soA products currently in Use:Microsoft BizTalk, Forum Systems, AmberPointMedicAlert uses Microsoft BizTalk as their integration platform. They use BizTalk to build their SOA services from start tofinish, from process models through execution. By moving processes and business logic into BizTalk, they save develop-ment time, and they appreciate the fact that BizTalk uses standard protocols such as SOAP over HTTP.They use Forum Systems solutions for perimeter security and gateway access. Since MedicAlert is dealing with sensitivemedical information, security is extremely important and all of its services are behind multiple security layers.In addition to classic SOA, MedicAlert also uses Web Services for simpler deployments, with a ratio of approximately50-50 between BizTalk-based SOA services and standard Web Services. They use Web Services as “glue” to wire prod-ucts together for those transactions that do not require specific business processing. Specifically, they use XML to tiethe “pieces” together, but when business processing is required, they run the services through BizTalk. Initially, gettingeverything to work together was challenging, however now that they have mastered the use of Web Services they appreci-ate their flexibility, especially the fact that services can be changed without breaking consumers.MedicAlert uses AmberPoint to manage their business services. AmberPoint’s governance capabilities give them visibilityand control over the SOA environment and enable them to monitor and manipulate production services as they execute.AmberPoint can report, for example, on how many times a given service is called, and can do service provisioning anddeprovisioning as well. It can also be used as part of a security solution. For example, if an encrypted message is sent intoan SOA service, AmberPoint can decrypt it.One of AmberPoint’s major contributions to MedicAlert’s SOA environment is that it promotes reuse by enabling policy-based, virtualized services. In virtualized services, information in the SOAP header is used to determine how servicesexecute. Using content-based transformation and routing, policies are executed based on SOAP header content.For example, a Web Services Descriptive Language (WSDL) description can be made available to multiple consumers,and messages can be transformed into requests tailored to each individual consumer. This is called “transformationrequest response management” and enables the service to respond and “act” differently for different consumers. Pushingpolicies and parameters to AmberPoint helps eliminate coding, reducing the time required to develop SOA services.From Jorge’s perspective, AmberPoint is the Web Service. The internal software, or service, feeds AmberPoint, but this isonly 5 to 15% of the overall execution that takes place. AmberPoint’s policy-based management does the rest.product selection processInitially, they used AmberPoint Express, which is available as a free download, during development. After seeing itsvalue in the development environment, they decided to purchase AmberPoint SOA Management System for use in theirproduction rollout.SOA: A View from the Trenches page 6©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  10. 10. Regarding BizTalk, they saw right away that they needed an integration platform. They did a buy versus build analysis, tried to write their own solution in-house, and quickly found that it would be cheaper to buy. Results MedicAlert has been using SOA as their production architecture for over a year and are finding that the benefits of SOA are huge – in Jorge’s words, “glaring.” It gives them the flexibility to implement and retire services transparent to consum- ers and positions their company for future agility to move quickly to create new services and integrations. From Jorge’s perspective, their SOA implementation has certainly not been without challenges, but they have achieved excellent results. Policy-based reuse dramatically cuts development time. Rapid service assembly promotes quick time to market and enables the business to become more nimble in terms of adding new capabilities and new product offerings. Jorge is a big proponent of SOA and feels the challenges are worth it, as they can roll out new business processes very quickly. Issues • Not easy to do. There is a learning curve associated with SOA in which the architect has to learn to understand both SOA and Web Services. Part of the learning curve is getting a good grasp, via trial and error, on what works and what doesn’t. • SOA designs require careful planning and can get complex very quickly. There is a huge misconception that simply putting a Web Service in front of an application is SOA. This isn’t the case, as there are multiple additional considerations. • Security is an issue, not because it’s difficult to implement, but because it has to be carefully architected to deploy it appropriately. What is the best way to secure a SOA service? How do you decide when enough security is enough? • Monitoring and management of running services. MedicAlert relies on AmberPoint to provide much of this functional- ity. For example, SOAP fault exception management can be a big problem. When twenty services are linked together, it is difficult to track down the source of a problem without specialized tools. AmberPoint helps by trapping SOAP faults and, via policies, triggering a sequence of recovery events when faults occur. A related issue is to make sure that SOAP faults are censored, so they aren’t sending out potentially sensitive information to other systems. Advice to new Users • Start small. Crawl, then walk, then run. Start by putting a Web Service in front of an application and go from there. Some companies have tried to bite off more than they can chew by deploying SOA with little or no under- standing of the big picture. They are overwhelmed and unsuccessful, then blame SOA for their failures. • Develop a delivery strategy as early as possible. Weigh a top down (business model to technology) versus bottom up (technology to business model) design approach. If the business demand is that the service be rolled out quickly, you may not initially have the luxury of the top down approach. But at some point, you need to analyze from this perspective to align services to the business model. • Don’t be afraid to reengineer and simplify business processes. As you analyze business processes, ask the question, “Does it have to be this way?” View the analysis phase as an opportunity to improve business processes or align them to better fit technology. • Use care in designing policy-based services. Designing policy-enabled services requires careful thought. What functional- ity should be hard-coded and what can be pushed to policies? This is a different design paradigm that requires careful analysis of message granularity – how coarse or fine does the service need to be? MedicAlert has found that services that are too fine-grained are often not as reusable as more coarse-grained services, and reuse is key.page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  11. 11. Key takeaways • Use policies to tailor the way services run and save on coding. This can be a significant source of ROI, as well as a way to reduce risk. • SOA benefits are “glaring.” • SOA gave them the ability to quickly assemble new services and bring new product offerings to market very quickly. • If your management solutions offer automated recovery and other automated capabilities, take advantage of them.Case Study #2: Lockheed Martin Company Name Lockheed Martin Integrated Systems and Solutions (ISS) Number of Employees 130,000 overall 15,000 in ISS Industry Vertical 100% Government Interviewee Tim Vibbert, Sr. Systems EngineeroverviewLockheed Martin provides us with a look at SOA from the “big consulting” perspective. Lockheed Martin is, of course,a multinational company and its Integrated Systems and Solutions organization (ISS) is a Systems Integrator. Much ofits practice is SOA-related. Currently, most ISS clients are in the government sector, with representation at the federal,state and local levels.Lockheed Martin has committed multiple millions of dollars to SOA research, and customer response to its SOA initia-tives, including their Center for Innovation in Suffolk, Virginia, has been “phenomenal.” The ISS architecture anddesign group provides business assessments and consults to determine whether SOA is the right option for customerprospects, and to provide an analysis of alternatives. There is a separate implementation group that executes the designsproduced during the architecture assessment.ISS views itself as the customer’s trusted advisor. As such, their consulting projects focus on developing business andtechnical assessments, as well as possible implementation options. This gives customers tools to assess and prioritize theirrequirements in transforming to an SOA, based upon specific business and technical criteria.Lockheed Martin started investigating and testing SOA in 2001 and began providing SOA solutions to customers in 2002.Over time, ISS has developed its own assessment tools for use in customer engagements. While other large consultingorganizations such as IBM and BEA have similar assessment tools, they tend to be more commercially oriented and, fromthe ISS perspective, often don’t fit well into the requirements of the government domain. In many cases, governmentrequirements for life, safety, and security are more critical and real-time, necessitating 100% availability and reliability, andsecond and sub-second response times, which is seldom the case with commercial applications.the challenge – Business drivers for soAGovernment agencies at all levels are moving to SOA because they are facing massive integration challenges. Althoughin the past government has typically not been known for “leading-edge” solutions, they have adopted SOA as probablythe only way to solve their multiple business challenges. The vision, at least at the federal level, is a global informationgrid incorporating applications from multiple agencies. The end result would be a massive federated data store andprocessing engine.Another key driver is the need to share information with partners and suppliers that are on different technology plat-forms. Because of its size, the federal government has enormous procurement challenges that, if addressed effectively,can result in significant economies of scale, especially when compared to the average commercial enterprise.SOA: A View from the Trenches page ©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  12. 12. Implementation details The ISS strategy for SOA implementation, and one of the reasons why an up-front assessment is critical, is because their approach is vendor agnostic. Actual implementation is designed based on the specific requirements of the agency they are working with. They make every effort to leverage existing products and use solutions already in place to build out SOA designs. As a partner with government, Lockheed Martin faces a major challenge – one of connecting systems designed and implemented as stand-alone entities. At this point in time, there are few or no viable alternatives to SOA for addressing these massive integration requirements. soA products currently in Use Lockheed Martin is very focused on standards-based solutions and, in fact, the federal government’s direction requires a standards-based approach. Traditional Enterprise Application Integration (EAI) solutions, which are often based on proprietary technology, don’t meet this criterion. Lockheed Martin is very much engaged with standards development bodies and, not only do they specify the specific standards to be employed when they specify architecture for a given project, they also proactively plan for the standards they will support in the future. Typically, architecture projects provide high-level product specifications which are then left up to implementers to select. Most customers prefer or require that ISS not divulge exact implementation details. Deployments utilize technology from well-known vendors across multiple platforms and architectures. Projects include a combination of open and pro- prietary systems, many of which are utilized because they are already in-house. As government organizations transform themselves into service based entities, Lockheed Martin concentrates on leveraging products in place, where possible, to maximize business value. Results Customers have realized the benefits of becoming more agile with their information sharing and more responsive to business needs. In addition, they are seeing reductions in subsequent development and operational costs. Issues • Governance: SOA Governance is a critical component of any SOA deployment, probably more so in the govern- ment space than any other. As customers transform to service-based entities, visibility of information and sensitivity issues surrounding data usage are key governance challenges. Other governance issues are security requirements, runtime SLAs (Service Level Agreements) and QoS (Quality of Service). • Architecture and technology implications: ◦ Business process and organizational changes are required to support SOA. ◦ Service change governance quickly becomes an issue: One key factor is governance related to changing services in step with changes to internal business processes. This is especially an issue once services have been reused. ◦ Funding questions: One of SOA’s key differentiators, and a major source of cost savings, is service reuse. When service components are reused, 90% of the service functionality can often be leveraged towards a new service. However, most organizations don’t have models in place to specify how the remaining 10% will be funded. In the federal sector, an example is where multiple agencies want to use a single service. One agency creates the service and puts it into production. A second agency wants to use it. If they do so, should the agency creating the service be reimbursed by the second agency? ◦ Service reuse also introduces additional dependencies and therefore risk.page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  13. 13. Advice to new Users • Plan before you leap: Prior to rolling out SOA, develop an SOA roadmap that specifies how the SOA will evolve over time. In the roadmap, include training and cultural transformations as well as business and technical transformations. • Start small. • Conduct assessments at frequent intervals (every 3 to 6 months) to monitor progress in relation to the roadmap. • Define a common set of semantics: One of the main benefits of ITIL is that everybody in the organization under- stands what an “Incident,” a “Problem,” and a “CMDB” are. Similarly, semantic definition within a company is key. If one group calls itself a “Business Unit” and a similar entity calls itself a “BU,” misunderstandings can arise as SOA services are reused and as organizational entities attempt to reuse services developed by other groups. • Develop a reference architecture/model that all SOA products build upon: This will ensure consistency and provide gover- nance throughout the SOA transformation.Key takeaways • Consulting can help organizations decide whether SOA is their best option: Don’t move to SOA for SOA’s sake. Move to SOA because it’s the right solution. ISS consulting projects provide customers with a third-party perspective on business and technical readiness and possible implementation options. • Standards are important: Lockheed Martin is very focused on standards-based solutions and participates in standards development at many levels. Especially in large organizations, while it is difficult to standardize on products, it’s simpler to standardize on industry standards. Products that support common standards will likely provide fewer integration challenges than products built over proprietary technologies. • SOAs are being designed for massive scalability: The federal government is focused on developing a very large, inte- grated SOA. Our research has shown that SOA deployments scale well, although performance tends to be an issue.Case Study #3: TrueCredit Company Name TrueCredit, subsidiary of TransUnion Number of Employees 4,000 overall 90 in TrueCredit Industry Vertical Financial Interviewee Scott Metzger- Architect, Chief Technology OfficeroverviewTrueCredit, a wholly owned subsidiary of TransUnion, provides credit reports from the three major credit bureaus toconsumers as part of a broad suite of credit management services. To facilitate this process, they began rolling out SOAservices in 2000.the challenge – Business drivers for soATrueCredit turned to SOA several years ago in response to high customer demand. After the Credit Act was passed, thegeneral public gained access to credit reports and the number of requests skyrocketed. TrueCredit needed to find a wayto address this increased demand, which has been as high as 50,000 concurrent users. An additional motivation was thevolatility of their business. Change is a constant factor in the financial services sector, and organizational groups canchange their requirements from month to month. So reuse and refactoring of services was a major driver, as was theability to leverage core capabilities across multiple lines of business.SOA: A View from the Trenches page 0©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  14. 14. Implementation details Scott was the executive sponsor for SOA implementation within the company. They have a very dynamic environment to manage from an operational perspective, which forced them to spend the extra time and thought up front to get it right. TrueCredit has 60 employees in their technical group, with approximately 60% on the engineering side and 40% on the IT support side. They have now spent almost five years on their design model and development processes. The result is that they now have enough detail to get predictable results from their development efforts. For the first 1 1/2 years, they focused on creating simple rules that everybody in the organization understood and incor- porated into their design and development work. Over time, they built on those initial rules. They also spent a lot of time on architecture and process, and outsourced to augment capacity because they knew they would have to grow faster than they could hire. Initially, they used homegrown monitoring tools, but incrementally added monitoring products as their SOA became more critical to the business. TrueCredit packed a lot of experience into these years, and, in Scott’s words, “bled a lot to get there.” They did it on their own with no SOA consultants. A major reason for this was because, since they started so long ago, few SOA consultants were even available. Their goals included: • High throughput for minimal cost. • Ability to provision underlying hardware on the fly: A key requirement was to be able to provision quickly throughout the day, so that they could rebalance production infrastructure as needed. They currently do not use policies, as the applications that consume their services may be 10% or 90% different from one another. They have found, for example, that the interactions with various business partners vary significantly between partners. Instead of using policies, they build these variations into the services themselves. The result is that can make modifications in a forward and backward compatible manner. soA products currently in Use: BEA WebLogic, OpTier, Acsera TrueCredit started out by building its own SOA solutions in-house. In 2000, they built their own homegrown Services Manager, and wrote their own monitoring solutions. They have added products incrementally as the need arose. They are currently using BEA WebLogic, and have enough services that they are starting to provide access to third parties. To provide this connectivity, they are evaluating ESBs for registry/repository functionality. Their implementation evolved with Web Services. In 2002 and 2003 they evaluated products for XML functionality, workflow, standards support and enterprise features, which led to their purchase of BEA. For monitoring, they use OpTier and Acsera. OpTier provides TrueCredit with an end-to-end view of all transaction workloads across all tiers including Web Services and legacy systems. It also simplifies the management of prioritization across tiers. At night, TrueCredit uses batch jobs to exchange information with partners. These batch processes execute during the off-hours, and OpTier provides the flexibility to dynamically change priorities based on time schedule. OpTier’s capability to prioritize across tiers and to “understand” the load profile over 24 hours was critical to TrueCredit, and resulted in a substantial increase in aggregate throughput. Acsera is an additional monitoring system that provides workflow metrics for core services such as payment process details, which include authorizations and refund transactions. Using Acsera, they can “watch” the execution of their ser- vices, drill into the services and see profiles of the transactions. To get this visibility, the application code is automatically instrumented and modeled to provide another level of operational intelligence. TrueCredit also uses OpTier to monitor their core services as they interact with other applications.page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  15. 15. product selection processPrior to purchasing OpTier, TrueCredit evaluated a number of solutions, and were very focused on functionality as theyhad a problem they had to solve “yesterday.” Because of their very clear requirements, they could quickly validate whetherproducts worked or not. One criterion was that a proof of concept took 90 days or less. Included in the 90 days wastime to let the software run in pilot before a second consultation with the vendor. As their normal evaluation cycle is 30days, they are not generally interested in solutions that take a long time to deploy and test. OpTier gave them optimalfunctionality at a reasonable cost while requiring minimal staff resources for implementation and support.ResultsScott definitely believes that SOA was the right direction for TrueCredit, and that it would have been tough for themto have progressed as far as they have without taking this approach. From his perspective, SOA wasn’t easy, but the endresult was worth it.Issues • Translating business requirements into technical implementations. • Early adoption requires a long learning curve and can be painful. • Governance to achieve reuse objectives. • Troubleshooting and debugging loosely coupled SOAs require different tools and a different mindset compared to traditional software architectures.Advice to new Users • Talk to the business. Take the time to understand the business processes that SOA services are going to model. Include the business in that analysis. A big part of the ability to succeed is to dive into the business to get a good understanding of what’s important to stakeholders and what key business processes allow the business to be competitive. • Concentrate on good design rather than specific technology. Technology is not as important as design. TrueCredit cur- rently uses Java, but could have used a .NET solution as well. A good design shouldn’t depend on underlying technology to work. Although articles on SOA indicate that specific products are required to implement it, analyzing services and talking to key business stakeholders is most important. Once that is right, everything else falls into place. • Before embarking on implementation, take the time to determine how the services and applications will be managed. Define key performance indicators for the business as well as required metrics up front. It is also important to walk through root cause analysis scenarios to ensure that you have enough visibility to the operational environment to diagnose and troubleshoot issues. Attaining optimal performance requires enough visibility to the execution environment to be able to see early warning signs leading up to a problem. The ideal is for the issue to be fixed before a failure occurs.Key takeaways • Planning pays off. Scott indicates that, for the first 1 1/2 years, they focused on creating and following simple rules. Over time, they built on those rules. They also spent a lot of time on architecture and process. • Keep it simple at first, and where possible, use home-built products or those that are already in-house. Initially, TrueCredit built its own homegrown Services Manager and monitoring tools. They have added other products as the need arose. • Buy products only to address specific functionality. TrueCredit moved to BEA when they needed to scale and standard- ize. They purchased OpTier because of the requirement to get on-demand provisioning and high throughput for minimal cost. • Make decisions based on the unique needs of the business. While MedicAlert has gained a lot of value from using policies, TrueCredit has made a conscious decision not to use them.SOA: A View from the Trenches page 2©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  16. 16. • Be very clear on product requirements and try before you buy. TrueCredit has a well-developed proof of concept process as well as clear guidelines for completion. Combined with specific requirements, this gives them a laser-like ability to tie functionality to overall value. • Talk to the business. Most articles about SOA focus on the technical side of SOA, not the business side. Organizations that have been most successful with SOA are those that have used it to address specific business challenges. Taking time to clearly understand the problems of the business, and to work with the business to formulate solutions with clear business value, ensures a tight alignment between IT and business goals. Case Study #4: Thomson Learning Company Name Thomson Learning Number of Employees 40,000 Industry Vertical Media, Education Interviewee Christopher Crowhurst, VP and Chief Architect overview The Thomson Corporation is a leading global provider of integrated information solutions to over 20 million users in the fields of law, tax, accounting, higher education, reference information, corporate e-learning and assessment, financial services, scientific research and healthcare. The company had revenues of over $8 billion, 8% over the prior year, in 2005. It is listed on the New York and Toronto stock exchanges. the challenge – Business drivers for soA For Thomson Learning, one of the major drivers for implementing SOA was the classic one – the need to deliver business services more cost effectively. SOA wasn’t just an attempt to gain asset reuse, they also needed to be able to share services with other companies. The unit cost for new development had become so high, and software services so complex, that sharing was a major requirement for cost efficiencies. The cost of the SOA service components they are sharing is enormous, with multi-million dollar software platforms being integrated to business partners and customers. An additional driver was new revenue generation, based on the idea that composite applications could be brought to market faster than traditional legacy software rollouts. Using services to expose core business capabilities enabled reuse of those core services for subsequent rollouts, enabling Thomson Learning to bring services to market faster than their competition. From their perspective, SOA is initially easier to justify in terms of cost reduction; going forward, revenue generation becomes an additional driver. Implementation details Thomson Learning didn’t set out to “create” an SOA project, but instead evolved into SOA by using development oppor- tunities as they became available. As new projects came into the pipeline, they analyzed whether each one would best be implemented using SOA principles or traditional software development methodologies, keeping in mind business drivers and overall vision. They continue to use the same strategy today, adding SOA services where it makes sense to do so. For example, recently they implemented a new identity management system based on best practices for identity manage- ment. As subsequent SOA services are rolled out, they can use the identity management service already in place. Using this strategy, each new design exposes additional functionality which can then be applied to subsequent projects. The SOA effort was driven by Christopher Crowhurst, who presented the initial concept at his CTO’s strategy meeting. After receiving approval at the CTO level, he then created marketing collateral that his group used to market the SOA concept to other “C” level executives, as well as to the production group and others within the organizations.page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  17. 17. From Christopher’s perspective, this was “the only way to be successful,” as he anticipated that SOA would have a bigimpact on the organization. From his perspective, internal organizational groups had to be willing to modify their busi-ness processes where necessary to maximize SOA’s potential benefits. For example, reuse of a service might require thatorganizational business units standardize their processes across the company, a change that typically creates discomfortat many levels.Regarding technology, for example the SOAP versus REST debate that is currently in the news, Christopher believesthat is actually a “non-debate” that shows little true understanding of what SOA actually is. From his perspective, SOAisn’t just Web Services and it isn’t just technology – organizations can choose technology based on what works in theirenvironment. “One of the joys of SOA is that is protocol independent,” Christopher says, and protocol discussionssimply add unnecessary complexity and vendor specificity to SOA discussions.Christopher is also big on the idea of decoupling services from technology and agrees with EMA that loosely coupledservices are one of the key hallmarks of SOA. Thomson Learning didn’t call their system an “SOA” until decoupledservices had been running for between 18 months and 2 years. From their perspective, loose coupling is one of thekeystones of managing change. Likewise, at the beginning they didn’t see the need for a commercial registry, but usedMicrosoft Excel as their registry. Once they grew to 50 services, however, they invested in a commercial registry andrepository to add robust service governance to their SOA.soA products currently in Use:Reactivity, Actional, Microsoft BizTalk, LogicLibrary, Systinet, BEA, .NETThomson Learning has been using BizTalk for over five years and has used each new version as it has become available.BizTalk, Microsoft’s equivalent of an Enterprise Service Bus (ESB), gives them orchestration, business rules and businessactivity monitoring capabilities. They like BizTalk because they don’t see an ESB as a product, but more as a style ofarchitecture that includes reliable messaging, orchestration and transformation. By transformation, they mean protocoltranslation, such as HTTP to MQ, or translation of the body of a message from one XML schema to another. Reactivityand Progress also have this translation capability, and from this perspective both have ESB-like characteristics.Their components are written largely in .NET, COM+ and some J2EE, so BizTalk was a natural choice for them.Because XML is bulky and processing-intensive, they leverage Reactivity to offload XML processing and acceleration. Thisimproves performance while also adding security functionality.product selection processIn terms of products, they initially used what they had in place. They used Microsoft Excel as their registry for several years.When they found they needed an ESB solution, they drew from experience and did a bake-off. They evaluated BizTalk,BEA, IBM, and Sonic, then chose BizTalk for its rich functionality and the fact that it was compatible with their in-housetechnology.ResultsOne thing they quickly proved was that the first project takes much more time and is much more expensive than subse-quent projects. There is a learning curve for SOA, but this time is well spent because subsequent projects become cheaperas the organizational knowledge grows. So the organization needs to be prepared at all levels for the fact that SOA willcost more up front, both in terms of time and money, but that costs per service will decrease as time goes on.Christopher says that SOA was not so much an end state as a development style. By leveraging SOA, the entire library ofcomponents, once built, became reusable, enabling significant cost savings as time went on. Each application deployedadds leverage and overall value to their software assets.Scaling has not proven to be a problem. They have been able to scale up, in other words to add new services and infra-structure to their SOA, as well as horizontally, giving them the capability to federate across multiple groups. In fact, theyhave yet to find an organization they can’t scale to.SOA: A View from the Trenches page ©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  18. 18. Issues • Interface design: While it’s fine to expose Web Services by “wrapping” legacy software, this doesn’t contribute to decoupling. It simply gives visibility to a legacy service. This provides interoperability, but that’s it. It’s important to clearly understand what’s important to the business, and, with that in mind, to design interfaces for reuse. • Identification of critical services: What are the critical services, and how do you expose them? As a matter of fact, EMA is finding that analyzing legacy source code to determine which “pieces” add significant business value, and which can be safely discarded, is becoming a lucrative revenue source for consulting companies. • Creating taxonomies for the enterprise: These are specific to each enterprise, not necessarily to external interactions. ◦ How do you put services in a registry and describe them so they can be reused? To do this requires a taxonomy that describes the services in terms that match the business domains. ◦ Business process taxonomy: There is a need to define a common language across the business and common names for entities within the business such as products, sale, etc. This is a model of the company’s “world” in a language that everybody understands. Once business and IT begin to work closely together, everyone needs to understand what a “customer” or a “product” is. In many organizations, a customer is called one thing in the Customer Relationship Management (CRM) system and another in the Enterprise Resource Planning (ERP) system. Without semantic definitions, a company can end up with an enormous translation challenge. Advice to new Users • Don’t start with infrastructure products. Start with planning and governance: In an effort to get started with SOA quickly, many organizations engage with vendors way too early, thinking that technology will solve their problems. It won’t. SOA has to be carefully planned and executed. Without having a governance model defined and a strategy for policy management in place, one can quickly create a mesh of infrastructure without a coherent strategy to manage the infrastructure itself. • Use care in selecting consultants: Consultants can be of assistance in terms of recommending best practices, however it is important to select consulting companies that do not have ties to particular vendors. Key takeaways • SOA implementations are initially easier to justify in terms of cost reduction. Going forward, revenue generation becomes an additional driver • Don’t adopt a “big bang” approach, and suddenly decide to apply SOA to each and every new project. Instead, evaluate each new project to weigh the value of implementing via SOA versus implementing via traditional methodologies • Each new service can be leveraged by multiple future projects. View services as assets that, once developed, can be reused in combination with future services. This is one of the major sources of cost savings attributable to SOA. • Don’t confuse SOA with a particular technology. It is protocol independent. Endless debate over the benefits of one technology versus another cloud the issue, and add complexity. The fact is that no one technology solves every problem. • Loose coupling provides a foundation for managing change. As SOAs become more complex, modifying and reusing services becomes more of an issue. Loose coupling is one of the key hallmarks of SOA and adds flexibility that can’t be realized without it. • Initially, focus on architecture and governance, not products. Use products in-house until you outgrow them, and don’t purchase products until you have a crystal clear understanding of why you need them.page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  19. 19. • Anticipate that the first project takes much more time and is much more expensive than subsequent projects, and prepare manage- ment expectations that this will be the case. • SOA isn’t as much an end state as it is a development style. Analyze project requirements and use SOA where appropri- ate, not across the board.Case Study #5: Financial Services Organization Company Name Withheld at request of Interviewee company Number of Employees Withheld at request of Interviewee company Industry Vertical Financial Services Interviewee Withheld, Senior Architect/Development ManageroverviewThe subject of this section of the report is a worldwide financial services organization that owns multiple smaller com-panies including banks and insurance organizations. Due to internal policy, neither the organization nor the intervieweecan be identified by name. For the purpose of this paper, we’ll call the interviewee Mark, who is the Senior Architect/Development Manager in the Development organization. The 2005 total revenue for the entire combined organizationwas in the neighborhood of $130 billion.the challenge – Business drivers for soAThere were both internal and external business reasons for SOA adoption. Business drivers included: • The need to simplify service rollouts and modifications. • The need to integrate software assets running on multiple platforms. • The need for unlike systems to exchange information. • The need to simplify system integration.To date, the IT organization has rolled out between 50 and 60 SOA services, with approximately 75% addressing internalfunctions and the remainder addressing external services. The external services support a high percentage of theirrevenue and include business-to-business trading networks, primarily Electronic Data Interchange (EDI) and batch con-nections, and data downloads.The applications environment consists of a mix of SOA and non-SOA applications. Mark sees his company’s SOAdeployments as being a pathway to improved integration, both within the company and to external partners. “Think ofit as what the Internet does for humans.”Implementation detailsMark’s group began piloting SOA in 2004 and rolled out their first production services in late 2004. From their perspec-tive, SOA “is the easiest and simplest way to connect everything.” They found it easy to deploy, approximately on par withother software deployments, and, once the initial services were in place, their SOA ecosystem grew very quickly – “likewildfire.” Growth forced them to add policies for change control using a UDDI-compliant registry. The registry acts astheir checkpoint for new services and releases, with only the Administrator having the ability to publish new services.The consensus is that 50 services is just the tip of the iceberg, a “drop in the bucket.” Although they did find, like otherSOA early adopters, that initial costs were high, subsequent rollouts became easier and they have seen considerable payoffas their SOA ecosystem has proliferated.They see their next evolution as combining fine-grained services into coarse-grained services that more closely resembletheir business environment. For example, a coarse-grained loan approval service might consist of multiple fine-grainedservices such as an account balance check, a credit check and a 401K check. One of their goals is to bring businessSOA: A View from the Trenches page 6©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  20. 20. analysts into the service design process. They would provide a high level business-related design, then turn their designs over to programmers to implement. Modeling SOA services to more closely resemble business services will facilitate this process. Currently, business analysts collect business requirements at a high level and write specifications in tools like Microsoft Word. Developers read these service descriptions, then open up their Integrated Development Environment (IDE) to determine which fine-grained services are available to use in developing the Business Analyst’s specification. Where services aren’t available, they write them. Where they are available, developers do the “plumbing” that connects the services. Next on their agenda is to add monitoring capabilities, which they currently address using homegrown products. soA products currently in Use: webMethods, LogicLibrary Logidex, BEA WebLogic, IBM WebSphere, home grown monitoring solutions Mark’s company is committed to industry standards and is using a mix of products. Their goal is to make sure that all legacy systems or software assets can expose interfaces as Web Services. This ensures interoperability, but to reach this end state requires multiple solutions and niche products. They use webMethods to expose mainframe applications and end-to-end business-to-business transactions with their trading partners. So far, they have primarily used webMethods for their suite of adaptors and connectors, which is “very strong.” Connectors give the capability to connect diverse technologies so that they can communicate with one another. They have standardized on UDDI and on Apache, an open source Web Services stack, as their web server. Mark’s organization appreciates the fact that vendors are turning to standards rather than proprietary solutions to build their products. They are using webMethods’ orchestration capabilities both because they have the product in-house, and because the product is moving toward fully supporting Business Process Execution Language (BPEL) standards. They also feel that webMethods’ integration server and trading network suite are very strong. Their homegrown monitoring solutions utilize SNMP and a commercial ping product to test device availability. If a service is not responding, these tools do automated exception handling and send an SNMP message to Tivoli, which opens up a trouble ticket for the support group. This notification is important, as it identifies which fine-grained service is causing the problem. They are also planning to use LogicLibrary’s Logidex, an enterprise SOA governance platform to automate and improve their SOA governance process. They will integrate the design time governance features of Logidex with their runtime UDDI environment (Apache’s jUDDI) Other solutions in use within the company are standard Web Services interfaces, BEA Weblogic, WebSphere, and Microsoft’s IIS. product selection process Due to the large size of their company and the number of separate entities that comprise it, it is difficult if not impossible to standardize on products. Instead, they standardize on standards. As an organization, they don’t specify what applica- tion server a particular company uses, as long as it is standards compliant. From their perspective, standards are key to reaping the economies that SOA has the potential to deliver. Results They feel that going with SOA was a good choice, as there really was no other option for their integration challenges. They very much view the SOA implementation as ongoing and anticipate continuing to roll out new services as time goes on. Because SOA services are dependent on multiple components, the reuse concept changes the way they have typically approached development. Traditionally, a given group within a company requested that a particular capability be devel- oped, and they paid for that development. SOA makes organizations re-think the way they fund projects and the way they determine who owns what.page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  21. 21. Issues • Culture change: SOA forces cultural changes in terms of component funding and ownership, since components may be reused later as orchestrated steps in long-running composite processes. • Skeptics within the organization required value to be demonstrated quickly: They had to overcome an environment in which skeptical business people viewed SOA as “just another buzzword.” It was very important for them to demon- strate business value, practically from day one. • Immature Standards: Many industry standards are still not well defined. Nevertheless, they chose to steer away from proprietary technologies in favor of standards-based solution. • Upfront initial cost and continuous investments: Unlike “big bang” investments like Enterprise Resource Planning (ERP) systems, the fact that SOA is standards-based made it easy to integrate and to gain incremental value on investments. An initial investment is needed to establish the minimum infrastructure including the web services stack, UDDI, and lightweight governance foundations. Once the platform is in place, incremental development and planned service rollouts become a matter of analyzing and scheduling. • Funding: The organization had to reexamine and adjust its development project funding policies to establish a pool of standardized services that would be available for subsequent reuse.Advice to new Users • Crawl, then walk, then run. The most important advice is to start small and build incrementally. • Standards are more important than products: Especially in very large organizations like Mark’s, it is difficult for the entire enterprise to standardize on a given product. It makes more sense for the enterprise to standardize on a specific standard, then require that any products purchased conform to that standard. From this perspective, an understanding of where the industry is going in terms of current and future standards is key to making good purchasing decisions. • Governance: From the beginning, governance is critical to maintaining discipline in SOA, especially as the orga- nization begins to modify and reuse services. It is best to fit SOA governance within the overall IT governance strategy, but at minimum, governance needs to be in place from the very early phases of SOA deployment and maintained as the SOA infrastructure grows larger.Key takeaways • Once the first SOA services were in place, the SOA grew “like wildfire.” Once an organization starts reaping the benefits of SOA services, the SOA ecosystem tends to grow very rapidly. • Growth quickly drove governance. The need for a standards-based registry and an administrator with final control over the release management of SOA services soon became apparent. • Although initial costs were high, subsequent rollouts became easier and they have seen considerable payoff over time. • They started out using homegrown solutions to monitor, and are just beginning to evaluate commercial monitoring products. Again, make do with what is in place until a specific, clear-cut need for a product exists. • The organization is committed to standards as a route towards interoperability. If a company is too large and/or diverse to standardize on products, consider standardizing on standards • The reuse concept changes the development process in multiple ways. We have already talked about changes to funding paradigms. However, SOA also affects specific development standards and techniques. For example, imple- mentation of policy-based processing introduces the potential to push functionality to policies versus hard- coding. It is important to be aware of such factors and to be willing to adjust development techniques and standards accordingly.SOA: A View from the Trenches page ©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.
  22. 22. Summary Tables: Drivers, Issues, Advice to New Users Drivers Drivers Votes 5 To integrate: with health providers, multiple platforms 2 Reuse and refactoring of services, share them with other organizations 1 To be able to bring new services to market very rapidly in a competitive environment 1 To deliver business services more cost-effectively 1 To generate new revenue from new services 1 To simplify service rollouts and modifications 1 To design global information grid 1 To leverage economies of scale 1 To satisfy the Credit Act: numbers of credit reports dramatically increased 1 To utilize a common services framework and to leverage Web Services 1 To leverage core capabilities across lines of business Table 1: Drivers When asked about the drivers for SOA implementation, all 5 of the interviewees mentioned integration. The specific requirements varied by respondent, with some having very specific integration requirements, such as integration with health providers, and some having a broader perspective, such as “designing a global information grid.” This finding was not surprising, since integration is typically reported as being a key inducement for organizations to evaluate SOA. Two respondents mentioned reuse and/or refactoring of services, which has been widely reported as another key incentive as well as a major source of cost savings. A unique take on this concept was a single respondent that mentioned an orga- nizational imperative to share services with other like organizations, due to the very high cost of service development. The remainder of the responses received one vote each and included several interesting business exigencies. One was to realize the economies of scale made possible by integrating the supply orders of multiple agencies into cost-effective bulk orders. Another was to address the unexpected volume of customer requests generated by new legislation. Only one cited new revenue generation as a goal. This is consistent with other industry studies showing that while companies commonly embark upon SOA because of the need to integrate, new opportunities for revenue generation become apparent as the SOA matures. Once the first SOA services are rolled out, companies see for themselves that subsequent services can be brought to production faster and cheaper than was possible in the past. The agility they gain prompts them to become more creative in identifying gaps in the marketplace that can potentially be addressed with new service offerings. Several of the interviewees mentioned that they felt they had gained ground over their competitors by following just such an approach.page SOA: A View from the Trenches ©2006 Enterprise Management Associates, Inc. All Rights Reserved.
  23. 23. Issues Issues Votes 3 Culture changes regarding component funding and ownership 3 Governance 2 SOA difficulty and learning curve 2 SOA requires different ways of monitoring and managing than legacy systems 1 SOA designs require careful planning and can get complex very quickly 1 Security has to be carefully architected, not necessarily because it’s hard, but to make sure you get it right 1 Interface design 1 Identification of critical services 1 Creating taxonomies for the enterprise 1 Skeptics within the organization required value to be demonstrated quickly 1 Many industry standards are still immature and not well defined 1 Up front initial cost and continuous investments 1 Organizational changes 1 Translating business requirements into technical implementations Table 2: IssuesLearning from the experiences of others is a primary education tool for most of us, and newcomers to SOA are curiousabout the obstacles faced by others as SOA was introduced into the enterprise. Again, there was a lot of agreement aboutthe top three or four issues among those interviewed. The most common issue, mentioned by three respondents, wasrelated to the culture changes regarding component funding and ownership. Service reuse, in particular, tends to bringthis challenge into the open since it is often the case that, once services are funded and brought to production by onebusiness unit, other business units see it working and want to utilize the service for their own transactions. Since reusecan be a source of significant cost savings at the enterprise level, it is important to address this issue up front and to get itright. Virtually all companies operate within the limitations of departmental budgets, and the reuse model is a departurefrom the simplicity of this norm. So, for example, if HR funds a service to track employee personnel information, Payrollwill eventually want to use the same service to print paychecks. Does Payroll get it for free? Or do they pay a royalty toHR, since HR funded it? This is one piece of the overall governance question, but one that has to be addressed soonerrather than later, because it is an issue that will quickly crop up after the initial service rollouts.Governance is a high level strategy issue, and not just in terms of reuse of an “as is” service. Questions around modify-ing or extending services are additional considerations. In a typical example, Payroll finds that the service HR createdaddresses 90% of their employee tracking requirements. However, for it to totally fulfill requirements, the service wouldhave to be added to or modified to add the missing functionality. Who determines how this tweak is made and whomakes it? Who determines how and when the service is rolled out into the SOA infrastructure and, if the organizationuses policies, how policies are modified as well? We all know that SOAs can be complex, and governance of SOAs canbe problematical as well. Over time, it’s likely that best practices for SOA governance will emerge, but SOA is still so earlystate that, compared to ITIL’s IT Service Management library, for example, SOA best practice is still very immature.Two respondents cited SOA’s learning curve as an issue, while one stated that, since their organization was skeptical thatSOA would even work, a quick win was very important. They had to demonstrate value almost from day one, and thiscan be difficult in organizations where learning curve is a big factor.SOA monitoring and management was another key issue, with two respondents citing this as problematical. SOA manage-ment requires unfamiliar techniques and products that are different from those required to manage legacy technologies,and EMA is also seeing this in the marketplace. Although tools and products that monitor and manage SOA transactionsand environments are starting to come to market, they aren’t as well-developed as, for example, traditional applicationand server management products.SOA: A View from the Trenches page 20©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.

×