SOA A View from the Trenches

SOA: A View From The Trenches

A Research Report Prepared by EMA August 2006

Table of Contents

SOA: A View from the Trenches©2006 Enterprise Management Associates, Inc. All Rights Reserved.

Executive Summary ..............................................................................................................................................................................1

SOA In The Marketplace: Hype Or Reality? ...................................................................................................................................1

Methodology ..........................................................................................................................................................................................3

Analysis ....................................................................................................................................................................................................3

Key Takeaways .......................................................................................................................................................................................4

Summary of Key Takeaways.........................................................................................................................................................4

Case Studies ............................................................................................................................................................................................5

Case Study #1: MedicAlert ...........................................................................................................................................................5Overview .................................................................................................................................................................................5The Challenge: Business Drivers for SOA .......................................................................................................................5Implementation Details ........................................................................................................................................................5SOA Products Currently in Use: .......................................................................................................................................6Product Selection Process ....................................................................................................................................................6Results ......................................................................................................................................................................................7Issues ........................................................................................................................................................................................7Advice to New Users ............................................................................................................................................................7Key Takeaways .......................................................................................................................................................................8

Case Study #2: Lockheed Martin.................................................................................................................................................8Overview .................................................................................................................................................................................8The Challenge – Business Drivers for SOA .....................................................................................................................8Implementation Details ........................................................................................................................................................9SOA Products Currently in Use..........................................................................................................................................9Results ......................................................................................................................................................................................9Issues ........................................................................................................................................................................................9Advice to New Users ............................................................................................................................................................10Key Takeaways .......................................................................................................................................................................10

Case Study #3: TrueCredit ............................................................................................................................................................10Overview .................................................................................................................................................................................10The Challenge – Business Drivers for SOA .....................................................................................................................10Implementation Details ........................................................................................................................................................11SOA Products Currently in Use: .......................................................................................................................................11Product Selection Process ....................................................................................................................................................12Results ......................................................................................................................................................................................12

SOA: A View from the Trenches©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.

Issues ........................................................................................................................................................................................12Advice to New Users ............................................................................................................................................................12Key Takeaways .......................................................................................................................................................................12

Case Study #4: Thomson Learning .............................................................................................................................................13Overview .................................................................................................................................................................................13The Challenge – Business Drivers for SOA .....................................................................................................................13Implementation Details ........................................................................................................................................................13SOA Products Currently in Use: .......................................................................................................................................14Product Selection Process ....................................................................................................................................................14Results ......................................................................................................................................................................................14Issues ........................................................................................................................................................................................15Advice to New Users ............................................................................................................................................................15Key Takeaways .......................................................................................................................................................................15

Case Study #5: Financial Services Organization ......................................................................................................................16Overview .................................................................................................................................................................................16The Challenge – Business Drivers for SOA .....................................................................................................................16Implementation Details ........................................................................................................................................................16SOA Products Currently in Use: .......................................................................................................................................17Product Selection Process ....................................................................................................................................................17Results ......................................................................................................................................................................................17Issues ........................................................................................................................................................................................18Advice to New Users ............................................................................................................................................................18Key Takeaways .......................................................................................................................................................................18

Summary Tables: Drivers, Issues, Advice to New Users ...............................................................................................................19

Drivers ...............................................................................................................................................................................................19Issues .................................................................................................................................................................................................20Advice to New Users .....................................................................................................................................................................21

Case Study Summaries..........................................................................................................................................................................22

How Do I Do It? One Approach To SOA Implementation ........................................................................................................25

Conclusion ..............................................................................................................................................................................................27

page � SOA: A View from the Trenches©2006 Enterprise Management Associates, Inc. All Rights Reserved.

Executive SummaryService 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 2 SOA: A View from the Trenches©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.

assets and infrastructure that enable subsequent rollouts to be implemented much more quickly than would be possible using traditional legacy architectures. SOA’s payoff comes with reuse, not during ramp up, which is one reason why it is so important that SOA rollouts have executive sponsorship.

SOA isn’t simple to implement. You can’t buy a product and roll out an SOA. You can’t adopt industry standards or Web Services and “do” SOA. SOA is just an architec-ture, and fleshing it out into an organizational strategy requires technology expertise, organizational gover-nance, executive sponsorship and a fairly hefty up-front investment. The touted cost savings don’t start until the first few implementations are in place. Because of this, businesses with short-term IT strategies are wary of SOA because of the risk of investing a lot of money and potentially ending up with little to show for it.

How pervasive is SOA? We’ve seen published figures ranging from an astonishing 70-80% to a more realistic 10-25%. We use the word astonishing because the 70-80% figure is obviously way off the mark and probably reflects a misunderstanding of the difference between SOA 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 initial rollouts. However, the vendors we surveyed were unanimous in estimating the number of companies that have actually rolled out production grade SOA deployments at this point in time as probably less than 10%. Our estimate is that this is probably closer to the mark.

Who are these companies? The telco, financial and insurance industries, and surprisingly, government, have been early adopters, as have Web-based retail companies. Why have they done so? Primarily because alternative architectures were costing 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 as well 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 excellent illustration of how SOA is being used in today’s business. The example involves a telecommunications company that provides a multitude of services, including trouble ticketing, billing, etc. to very large customers. Customers want to have these services integrated into their own systems. For example, trouble ticketing has to integrate with monitoring and alerting systems already in-house.

Typically, each new customer used the same 90% of the telco application’s base code. Only the remaining 10% varied from one customer to the next. However with traditional integration efforts, the telco invested approximately 3,000 person hours in each new integration effort. This time was required to go through the entire development lifecycle from business 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 executes

0%

10%

20%

30%

40%

50%

60%

70%

80%

Vendor EstimateResearch Estimate

70%

10%

Figure 1: SOA Adoption in 2006: Published Estimates versus Vendor estimates


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.

MethodologyTo 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.

AnalysisEach 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.

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.

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•


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 StudiesCase Study #1: MedicAlert

Company Name MedicAlert

Number of Employees 150

Industry Vertical Healthcare Services

Interviewee Jorge Mercado, Senior Engineer

overviewMedicAlert® 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 soAMedical 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 detailsMedicAlert 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.

•

•

•

•

•

•


Jorge heads the Architecture team, which is composed of a total of 4 technologists. The team is responsible for the overall enterprise architecture, including the SOA. While Jorge or someone on his team is responsible for design work, a separate 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 work internally, without general consulting assistance. However, they did use vendor consultants to assist with training and product implementation. Jorge believes that this vendor presence helped them to understand and deploy products faster and 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 that companies that do this tend to become consulting-dependent instead of developing necessary skills in-house. Their approach was to use technologists already on staff and give them the opportunity to thoroughly understand both SOA and the business. SOA needs to be implemented differently for each business, and from MedicAlert’s perspective, general consultants tend to apply “cookie cutter” solutions to very diverse business problems.

soA products currently in Use: Microsoft BizTalk, Forum Systems, AmberPoint

MedicAlert uses Microsoft BizTalk as their integration platform. They use BizTalk to build their SOA services from start to finish, 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 sensitive medical 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 approximately 50-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 tie the “pieces” together, but when business processing is required, they run the services through BizTalk. Initially, getting everything 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 visibility and 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 and deprovisioning as well. It can also be used as part of a security solution. For example, if an encrypted message is sent into an 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 services execute. 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 “transformation request response management” and enables the service to respond and “act” differently for different consumers. Pushing policies 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 is only 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 its value in the development environment, they decided to purchase AmberPoint SOA Management System for use in their production rollout.


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.

ResultsMedicAlert 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.

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 (IS&S)

Number of Employees 130,000 overall

15,000 in IS&S

Industry Vertical 100% Government

Interviewee Tim Vibbert, Sr. Systems Engineer

overviewLockheed 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 (IS&S) is a Systems Integrator. Much of its practice is SOA-related. Currently, most IS&S 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 IS&S architecture and design group provides business assessments and consults to determine whether SOA is the right option for customer prospects, and to provide an analysis of alternatives. There is a separate implementation group that executes the designs produced during the architecture assessment.

IS&S views itself as the customer’s trusted advisor. As such, their consulting projects focus on developing business and technical assessments, as well as possible implementation options. This gives customers tools to assess and prioritize their requirements 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, IS&S has developed its own assessment tools for use in customer engagements. While other large consulting organizations such as IBM and BEA have similar assessment tools, they tend to be more commercially oriented and, from the IS&S perspective, often don’t fit well into the requirements of the government domain. In many cases, government requirements for life, safety, and security are more critical and real-time, necessitating 100% availability and reliability, and second 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. Although in the past government has typically not been known for “leading-edge” solutions, they have adopted SOA as probably the only way to solve their multiple business challenges. The vision, at least at the federal level, is a global information grid incorporating applications from multiple agencies. The end result would be a massive federated data store and processing 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.

•

•

•

•


Implementation detailsThe IS&S 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 UseLockheed 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 IS&S 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.

ResultsCustomers 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 �0 SOA: A View from the Trenches©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.

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 Officer

overviewTrueCredit, a wholly owned subsidiary of TransUnion, provides credit reports from the three major credit bureaus to consumers as part of a broad suite of credit management services. To facilitate this process, they began rolling out SOA services 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, the general public gained access to credit reports and the number of requests skyrocketed. TrueCredit needed to find a way to address this increased demand, which has been as high as 50,000 concurrent users. An additional motivation was the volatility of their business. Change is a constant factor in the financial services sector, and organizational groups can change their requirements from month to month. So reuse and refactoring of services was a major driver, as was the ability to leverage core capabilities across multiple lines of business.

•

•

•

•

•

•

•

•

page �� SOA: A View from the Trenches©2006 Enterprise Management Associates, Inc. All Rights Reserved.

Implementation detailsScott 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.

•

•


product selection processPrior to purchasing OpTier, TrueCredit evaluated a number of solutions, and were very focused on functionality as they had a problem they had to solve “yesterday.” Because of their very clear requirements, they could quickly validate whether products worked or not. One criterion was that a proof of concept took 90 days or less. Included in the 90 days was time to let the software run in pilot before a second consultation with the vendor. As their normal evaluation cycle is 30 days, they are not generally interested in solutions that take a long time to deploy and test. OpTier gave them optimal functionality 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 them to have progressed as far as they have without taking this approach. From his perspective, SOA wasn’t easy, but the end result was worth it.

IssuesTranslating 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.

•

•

•

•

•

•

•

•

•

•

•


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

overviewThe 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 soAFor 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 detailsThomson 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.

From Christopher’s perspective, this was “the only way to be successful,” as he anticipated that SOA would have a big impact 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 that organizational business units standardize their processes across the company, a change that typically creates discomfort at many levels.

Regarding technology, for example the SOAP versus REST debate that is currently in the news, Christopher believes that is actually a “non-debate” that shows little true understanding of what SOA actually is. From his perspective, SOA isn’t just Web Services and it isn’t just technology – organizations can choose technology based on what works in their environment. “One of the joys of SOA is that is protocol independent,” Christopher says, and protocol discussions simply 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 coupled services are one of the key hallmarks of SOA. Thomson Learning didn’t call their system an “SOA” until decoupled services had been running for between 18 months and 2 years. From their perspective, loose coupling is one of the keystones of managing change. Likewise, at the beginning they didn’t see the need for a commercial registry, but used Microsoft Excel as their registry. Once they grew to 50 services, however, they invested in a commercial registry and repository to add robust service governance to their SOA.

soA products currently in Use: Reactivity, Actional, Microsoft BizTalk, LogicLibrary, Systinet, BEA, .NET

Thomson 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 business activity monitoring capabilities. They like BizTalk because they don’t see an ESB as a product, but more as a style of architecture that includes reliable messaging, orchestration and transformation. By transformation, they mean protocol translation, such as HTTP to MQ, or translation of the body of a message from one XML schema to another. Reactivity and 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. This improves 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-house technology.

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 cheaper as the organizational knowledge grows. So the organization needs to be prepared at all levels for the fact that SOA will cost 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 of components, once built, became reusable, enabling significant cost savings as time went on. Each application deployed adds 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, they have yet to find an organization they can’t scale to.


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.

•

•

•

◦

◦

•

•

•

•

•

•

•

•


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 Manager

overviewThe 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 interviewee can 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 organization was 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 internal functions and the remainder addressing external services. The external services support a high percentage of their revenue 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 SOA deployments as being a pathway to improved integration, both within the company and to external partners. “Think of it 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 with other software deployments, and, once the initial services were in place, their SOA ecosystem grew very quickly – “like wildfire.” Growth forced them to add policies for change control using a UDDI-compliant registry. The registry acts as their 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 other SOA early adopters, that initial costs were high, subsequent rollouts became easier and they have seen considerable payoff as their SOA ecosystem has proliferated.

They see their next evolution as combining fine-grained services into coarse-grained services that more closely resemble their business environment. For example, a coarse-grained loan approval service might consist of multiple fine-grained services such as an account balance check, a credit check and a 401K check. One of their goals is to bring business

•

•

•

•

•

•


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 processDue 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.

ResultsThey 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.

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 UsersCrawl, 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.

•

•

•

•

•

•

•

•

•

•

•

•

•

•


Summary Tables: Drivers, Issues, Advice to New UsersDrivers

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

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.

Table 1: Drivers


IssuesIssues

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

Learning from the experiences of others is a primary education tool for most of us, and newcomers to SOA are curious about the obstacles faced by others as SOA was introduced into the enterprise. Again, there was a lot of agreement about the top three or four issues among those interviewed. The most common issue, mentioned by three respondents, was related to the culture changes regarding component funding and ownership. Service reuse, in particular, tends to bring this challenge into the open since it is often the case that, once services are funded and brought to production by one business unit, other business units see it working and want to utilize the service for their own transactions. Since reuse can be a source of significant cost savings at the enterprise level, it is important to address this issue up front and to get it right. Virtually all companies operate within the limitations of departmental budgets, and the reuse model is a departure from the simplicity of this norm. So, for example, if HR funds a service to track employee personnel information, Payroll will eventually want to use the same service to print paychecks. Does Payroll get it for free? Or do they pay a royalty to HR, since HR funded it? This is one piece of the overall governance question, but one that has to be addressed sooner rather 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 created addresses 90% of their employee tracking requirements. However, for it to totally fulfill requirements, the service would have to be added to or modified to add the missing functionality. Who determines how this tweak is made and who makes it? Who determines how and when the service is rolled out into the SOA infrastructure and, if the organization uses policies, how policies are modified as well? We all know that SOAs can be complex, and governance of SOAs can be problematical as well. Over time, it’s likely that best practices for SOA governance will emerge, but SOA is still so early state 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 that SOA would even work, a quick win was very important. They had to demonstrate value almost from day one, and this can 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 transactions and environments are starting to come to market, they aren’t as well-developed as, for example, traditional application and server management products.

Table 2: Issues

page 2� SOA: A View from the Trenches©2006 Enterprise Management Associates, Inc. All Rights Reserved.

Advice to New UsersRecommendations

Votes

4 Planning: Develop a delivery strategy, management strategy and business alignment as early as possible

3 Crawl, then walk, then run

2 Standards and design are more important than specific products or technology

1 Don’t be afraid to reengineer and simplify business processes

1 Use care in designing policy-based services. They have to be designed differently than legacy systems

1 Don’t start with products; start with planning and governance

Use care in selecting consultants; vendor consultants may be a good source of knowledge to start with

1 Governance is key to maintaining discipline in SOA, especially as the organization begins to modify and reuse services

1 Define a common semantic “language”

1 Talk to the business

Many of these recommendations are related to the issues cited above. For example, while we talked about the importance of governance in the “Issues” section, in the “Advice to New Users” section, 4 out of 5 of our respondents cited early planning as a key consideration. In this case, planning encompasses delivery, management, and governance strategies, as well as business alignment. Since all of these companies have been successful in bringing SOAs to market, in contrast to multiple other companies that have not been successful, this is a telling comment and one that companies contemplating their SOA direction need to pay attention to. Planning was considered to be so critical that one of our interviewee com-panies, who not coincidentally has reaped significant ROI from their SOA rollout, spent months up front going through the planning and governance design processes before ever rolling out their first SOA service.

Three of the five responders recommended that companies start small, perhaps by doing a non-critical project or by wrapping a legacy service in a Web Services wrapper as a first step. This strategy gives the organization a chance to build up skills in a gradual learning curve, and also ensures that production services aren’t adversely impacted by a new techni-cal direction. Two of the five found that standards and design are more important than specific products or technology, and further, recommend that organizations design and implement SOAs using products that are already in-house, home-grown or freely available. The general feeling seems to be that purchasing products prematurely, without a good grasp of SOA principles, is a big mistake. Organizations should progress as far as they can with what they have –for example, one respondent used Microsoft Excel as their registry for several years before purchasing a registry product – confident in the fact that when they need a particular product, that need will become readily apparent.

Table 3: Advice to New Users


Case Study SummariesDrivers

Company #

MedicAlert 1 To integrate with health providers

2 To be able to bring new services to market very rapidly in a competitive environment

Thomson Learning 3 To deliver business services more cost-effectively

4 To reuse services, share them with other organizations

5 To generate new revenue generation from new services

Financial Services Company

6 To simplify service rollouts and modifications

7 To integrate software assets running on multiple platforms

8 To allow unlike systems to exchange information

9 To simplify system integration

Lockheed Martin 10 For government, to design global information grid

11 Need to integrate mission-critical systems, including back-office systems

12 Need to share information with partners and suppliers on diverse technology platforms

13 To leverage economies of scale

True Credit 14 To satisfy the Credit Act: numbers of credit reports dramatically increased

15 The need to utilize a common services framework and to leverage Web Services

16 To promote reuse and refactoring of services

17 To leverage core capabilities across lines of business

Issues

Company #

MedicAlert 1 SOA isn’t easy and it has a learning curve

2 SOA designs require careful planning and can get complex very quickly

3 Security has to be carefully architected, not necessarily because it’s hard, but to make sure you get it right

4 SOA requires different ways of monitoring and managing than legacy systems

Thomson Learning 5 Interface design

6 Identification of critical services

7 Creating taxonomies for the enterprise


8 Culture changes in terms of component funding and ownership

9 Skeptics within the organization required value to be demonstrated quickly

10 Many industry standards are still immature and not well defined

11 Up front initial cost and continuous investments

12 The organization had to reexamine and adjust its development project funding policies

Lockheed Martin 13 Governance is a critical component of any SOA deployment

14 Architecture and technology implications including organizational changes, funding, and change governance and service reuse.

TrueCredit 15 Translating business requirements into technical implementations

16 Early adoption requires a long learning curve and can be painful

17 Governance to achieve reuse objectives

18 Troubleshooting and debugging loosely coupled SOAs require different tools and mindset over traditional development.

Table 4: Drivers by Respondent

Table 5: Issues by Respondent


Recommendations

Company

MedicAlert 1 Crawl, then walk, then run

2 Develop a delivery strategy and business alignment as early as possible

3 Don’t be afraid to reengineer and simplify business processes

4 Use care in designing policy-based services. They have to be designed differently than legacy systems

Thomson Learning 5 Don’t start with products; start with planning and governance

6 Use care in selecting consultants; vendor consultants may be a good source of knowledge to start with


7 Start small and build incrementally

8 Standards are more important than specific products

9 Governance is key to maintaining discipline in SOA, especially as the organization begins to modify and reuse services

Lockheed Martin 10 Plan: develop an SOA roadmap and monitor progress over time

11 Start small

12 Define a common semantic “language”

13 Develop a reference architecture/model and build services on this common foundation

TrueCredit 14 Talk to the business

15 Concentrate on good design rather than specific technology

16 Before embarking on the implementation, take the time to determine how the services and applications will be managed

Table 6: Advice to New Users by Respondent

page 2� SOA: A View from the Trenches©2006 EntERpRIsE MAnAgEMEnt AssocIAtEs, Inc. All RIghts REsERvEd.

Key Takeaways

Company #

MedicAlert 1 Shifting functionality to policies versus hard-coding can save up to an estimated 85% of development costs

2 After the initial SOA services are rolled out and technologists have gotten through the learning curve, benefits of adopting SOA are significant

3 SOA gives organizations the ability to create new services and bring new product offerings to market very quickly

4 Taking advantage of automated recovery and other automated capabilities in management solutions can improve performance and reduce support costs

Thomson Learning

5 SOA implementations are initially easier to justify in terms of cost reduction; going forward, revenue generation becomes an additional driver

6 Don’t use a “big bang” approach: instead, evaluate each new project to weigh the value of implementing via SOA versus implementing via traditional methodologies

7 Each new service becomes an asset that can be leveraged by multiple future projects

8 Don’t get sidetracked by “religious discussions” about technology. SOA isn’t just technology- in fact, it is technologically nonpartisan

9 Learn about loose coupling and how to use it – it is one of the foundations for managing change

10 Don’t invest in products until you see the need for them. Corollary: Use products already in-house until you outgrow them

11 The first project takes much more time and is much more expensive than subsequent projects

12 SOA isn’t as much an end state as it is a development style

Financial Company

13 Once SOA services are in place, expect exponential growth

14 Consider governance from day one. Growth quickly forces governance and you’ll have to go back and address what is already in place anyway

15 Although initial costs are high, subsequent rollouts become easier and yield considerable payoff

16 Started out using homegrown solutions to monitor

17 Keep abreast of standards as they are the route to interoperability

18 If your company is too large and/or diverse to standardize on products, consider standardizing on standards

19 Reuse concept changes the approach to development

20 The debate over fine-grained versus coarse-grained services continues to rage in the industry. However, 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

21 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

Lockheed Martin

22 Consulting can help organizations determine whether SOA is their best option

23 Standards are important

24 SOAs are being designed for massive scalability

TrueCredit 25 Planning pays off

26 Keep it simple at first, and, where possible, use home-built products or those that are already in-house

27 Buy products only to address specific functionality

28 Make decisions based on the unique needs of the business

29 Be very clear on product requirements and try before you buy

30 Talk to the business

Table 7: Key Takeaways by Respondent


How Do I Do It? One Approach To SOA ImplementationOne of the big questions we hear from our end-user consulting clients is, “How do we do this?” This question is being addressed on a grand scale by a multitude of consulting firms with groups specializing in answering this very question. However, based on the findings summarized in this report, we can formulate a broad set of recommendations that lever-age the experiences of early adopters.

Step 1: Build a foundation by creating a mature and stable organizational platform built over industry best practicesThis is, in fact, something that many organizations have been doing for the past several years. EMA’s recent research indicates that more than 70% of the companies surveyed have implemented at least some portion of ITIL. While ITIL isn’t the be-all and end-all of IT efficiency, it does take advantage of the experience of thousands of IT managers and helps organizations gain perspective on ways to improve or optimize their service deliverables.

What ITIL does really well is simplify communication and development of cross-functional processes between support groups. This is absolutely critical to supporting SOA implementations, as they are, by their very nature, business services abstracted across multiple technologies and platforms. To support SOA services efficiently and cost-effectively, an orga-nization needs first-rate infrastructure skills, which usually means multiple technologists with deep skill sets in specific technology verticals. But infrastructure skills alone aren’t enough: the groups must also be able to routinely collaborate as multi-disciplinary teams to solve complex problems that cross technologies. Although consulting companies have made millions of dollars by facilitating these kinds of efforts, detailed information on ITIL, Six Sigma, CMMI, and COBIT are widely available at no or minimal cost, and can be used by organizations of any size to beef up their support processes and cross-organization communication.

Step 2: Make sure management is on boardAt the beginning, SOA is expensive. Organizations that have SOA architects in-house are few and far between and most successful SOA rollouts seem to be the result of homegrown talent taking the initiative to “find a better way.” Breaking a new trail requires experimentation and trial and error, both of which translate into time, and therefore expense.

Christopher’s approach – presenting his ideas to the CTO, then propagating it to other C level management before embracing SOA on a large scale – is a good one. Change hurts, but the pain is minimized when everybody knows what to expect and understands that short-term costs can translate into long-term revenues.

SOA efforts are similar to ITIL efforts in that they need to have an executive-level champion to be successful. There are several reasons why this is true. We have already talked at length about the fact that SOA’s payoff comes over the long- versus the short-term. Management teams with short-term versus strategic business strategies will likely have difficulty with SOA’s deferred gratification. In addition, reuse of SOA services is one major source of cost savings, and effective reuse requires enterprise level agreement on semantics, business process changes and funding of development projects. Changes at this level impact employees across the organization and they can be painful. Executive endorsement helps, as does a level of vision that sees the forest rather than the trees. Visionary executives are better positioned for these tasks than are line staff, and since executives are, in the end, responsible for organizational performance, they need to be able to steer the course for the rest of the organization.

Step 3: Plan and governDiscussions with vendors and end users alike have driven home the importance of governance in SOA environments. Having visibility to and control over the SOA ecosystem adds discipline and makes it easier to scale SOAs over time.

Interviewees have told us that although their SOAs started small, once multiple departments across the business began to see the value of the business’ SOA services, reuse became an issue. The order fulfillment department rolls out an order tracking service so that they can plan for temporary warehouse staffing. Once the sales department sees the service, they want to reuse it to predict revenue pipeline. Service reuse is one of the primary goals of SOA development projects, but reuse brings with it a whole series of questions that have to be addressed.

Who pays for the development of the new service?•


Since order fulfillment invested in building the service out of their own budget, should sales pay order fulfillment a royalty for using their software asset?

If so, how does this process work?

Later, if order fulfillment needs to modify their service, who determines how the change will affect the sales service and, potentially, other areas of the business that are using that service as well?

For that matter, how does the organization track how the service is being utilized and by whom?

Once a WSDL exposes a service interface, that service is available to anybody with access to the SOA implementation. Without governance, organizations find that “rogue” services and users – unauthorized departments or groups that “find” a particular SOA service via WSDL discovery, then latch on to it and use it – very quickly become a problem.

The whole governance question is a very good example of why organizational processes, executive leadership, and cross-department sponsorship are so important. As the SOA begins to take on a life of its own and to proliferate, the questions that arise cross departmental lines and soon become organizational issues. Governance helps establish the “rules of engagement” and prevents a lot of misunderstanding as the SOA grows.

Step 4: Pick a project and do a pilotMany of the articles written about SOA are vendor-funded and make it sound like products are all-important for making SOA work. However, almost across the board, our interviewees disagreed. From their perspective, standards and know-how are more important than any single product. Thomson Learning used Microsoft Excel as its registry for almost five years before investing in a commercial registry product. True Credit started out with its own in-house written services manager, and the Financial Services Company interviewed has been working with SOA for over two years and still uses its own homegrown monitoring solution. Many SOA vendors offer free product downloads for use by developers, providing an excellent way to “try before you buy” and to experiment with SOA in the early stages.

IBM offers free versions of its DB2 9 hybrid data server (relational and XML data base functionality) and also offers a free download of WebSphere in a Community Edition. AmberPoint offers a free download of its policy-based man-agement and security software for SOA governance. Systinet offers multiple downloads, including a 30 day trial of its Registry solution, Systinet Registry 6.5.1. Other vendors offer free downloads as well, and these free versions can give both developers and IT architects hands-on experience with robust SOA products.

Pilot projects provide the kinds of hands-on experience that are invaluable in making organizational architecture deci-sions. The availability of product demo versions, such as those described above, make pilot projects very cost-effective. However, in addition to providing hands-on practice, projects of this nature can also help an organization determine whether SOA is really the best direction for them to take at a given point in time. SOA isn’t a be-all and end-all and, for some organizations, may not be the appropriate choice at a given point in time. Pilot projects can help companies make this determination.

Step 5: CrawlThe “Big Bang” approach to software development and implementation is risky and expensive, as demonstrated by the graveyard of abandoned ERP implementations where countless billions of dollars are buried. Start with small projects to incrementally increase skill levels across the board and to remove application performance from the equation as much as possible. Many of our interviewees also recommended that the first step be a Web Services implementation versus an SOA deployment. Projects involving legacy code “wrapped” in Web Services to expose an interface give hands-on experi-ence with Web Services and composite transactions without a lot of risk exposure. It’s also wise to start with a service that isn’t critical to the business, particularly since we are hearing that Web Services rollouts can encounter significant performance issues. Also, as mentioned already, these initial efforts will take considerable time to complete.

Step 6: Walk, then runTwo of our respondents used the words “crawl, walk, run” in their “advice” responses. After completing all five of the previous steps, you are ready to begin to use SOA to solve your real-world business problems.

•

•

•

•


Thomson Learning indicates that they view each new service as an asset that is available for reuse in subsequent projects. With governance in place, organizational reuse can have a significant positive impact on the time required for future service roll outs. Christopher Crowhurst indicated that, even after five years, they still don’t assume that all new projects will be developed using SOA. For some projects, it just makes sense that they be developed using other methodologies. A focused analysis process can help an organization make this determination.

ConclusionThis is the third and final paper in EMA’s 2006 SOA series, and is a response to wildly different stories about SOA that are appearing in the industry press. While there is a lot of speculation that SOA isn’t really happening and is another instance of hype created by vendors looking to cash in on the SOA boom, at the other end of the spectrum are reports that upwards of 70% of enterprises are already using it. Clearly, both can’t be true. EMA’s perspective, which this paper has hopefully verified, is that neither of these statements accurately reflects SOA’s current state in the marketplace.

Our conclusion is that SOA has demonstrated its value and is already delivering benefits today. However, these benefits are still largely limited to those few organizations that, either by visionary leadership or by practical necessity, have used it to solve specific business problems.

As SOA continues to mature, the industry will undoubtedly face a much larger set of challenges as we begin to address the same issues enterprises are addressing – governance, security, development and release lifecycles, and funding – on the much larger stage of external integration. This very natural evolution will leverage the standards and cross-industry cooperation we are already seeing in such efforts as industry-based XML schemas and EDI projects. It will evolve along with industry standards and best practices and, more than likely, unanticipated new industry efforts to standardize elec-tronic interactions between unrelated entities.

Since we still see SOA as being at the early-adopter stage, there will be a lot more to write about as time goes on. We are already finding products that we would have liked to include in the landscape paper, and are seeing gaps, such as security, that weren’t covered in this year’s series. We will be adding new SOA research and analysis every year and, as a matter of fact, are currently in the process of planning our research calendar for 2007. During Quarter 3, 2006, the research calendar for 2007 will be posted at www.emausa.com. Stay tuned for future developments.

About Enterprise Management Associates, Inc.Enterprise Management Associates is an advisory and research firm providing market insight to solution providers and technology guidance to Fortune 1000 companies. The EMA team is composed of industry respected analysts who deliver strategic awareness about computing and communications infrastructure. Coupling this team of experts with an ever-expanding knowledge repository gives EMA clients an unparalleled advantage against their competition. The firm has published hundreds of articles and books on technology management topics and is frequently requested to share their observations at management forums worldwide.

This report in whole or in part may not be duplicated, reproduced, stored in a retrieval system or retransmitted without prior written permission of Enterprise Management Associates, Inc. All opinions and estimates herein constitute our judgement as of this date and are subject to change without notice. Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies.©2006 Enterprise Management Associates, Inc. All Rights Reserved.

Corporate Headquarters: 2585 Central Avenue, Suite 100 Boulder, CO 80301

Phone: +1 303.543.9500 Fax: +1 303.543.7687

www.enterprisemanagement.com1174.080906

http://www.enterprisemanagement.com

Documents

SOA A View from the Trenches