SOA A View from the Trenches

SOA: A View From The Trenches
A Research Report Prepared by EMA
August 2006

Table of Contents
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 ...........................................................................................................................................................5
Overview .................................................................................................................................................................................5
The Challenge: Business Drivers for SOA .......................................................................................................................5
Implementation Details ........................................................................................................................................................5
SOA Products Currently in Use: .......................................................................................................................................6
Product Selection Process ....................................................................................................................................................6
Results ......................................................................................................................................................................................7
Issues ........................................................................................................................................................................................7
Advice to New Users ............................................................................................................................................................7
Key Takeaways .......................................................................................................................................................................8
Case Study #2: Lockheed Martin.................................................................................................................................................8
Overview .................................................................................................................................................................................8
The Challenge – Business Drivers for SOA .....................................................................................................................8
SOA Products Currently in Use..........................................................................................................................................9
Results ......................................................................................................................................................................................9
Issues ........................................................................................................................................................................................9
Key Takeaways .......................................................................................................................................................................10
Case Study #3: TrueCredit ............................................................................................................................................................10
Overview .................................................................................................................................................................................10
Results ......................................................................................................................................................................................12

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

Issues ........................................................................................................................................................................................12
Key Takeaways .......................................................................................................................................................................12
Case Study #4: Thomson Learning.............................................................................................................................................13
Overview .................................................................................................................................................................................13
Results ......................................................................................................................................................................................14
Issues ........................................................................................................................................................................................15
Key Takeaways .......................................................................................................................................................................15
Case Study #5: Financial Services Organization ......................................................................................................................16
Overview .................................................................................................................................................................................16
Results ......................................................................................................................................................................................17
Issues ........................................................................................................................................................................................18
Key Takeaways .......................................................................................................................................................................18
Summary Tables: Drivers, Issues, Advice to New Users ...............................................................................................................19
Drivers ...............................................................................................................................................................................................19
Issues .................................................................................................................................................................................................20
Advice to New Users .....................................................................................................................................................................21
Case Study Summaries..........................................................................................................................................................................22

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

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

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

Executive Summary
Service Oriented Architecture (SOA) is a hot topic at the moment, and for that reason EMA chose to devote a three part
research series to the subject during 2006. The first paper in the series, entitled “Service Oriented Architectures: Coming
of Age in the Enterprise and the Marketplace,” was published in February. It discussed SOA’s evolution in detail, along
with SOA concepts and current direction. The second paper in the series, entitled “SOA Market and Products 2006:
Current State, Future Directions,” was published second quarter, and provided a detailed product landscape of SOA
solutions in the marketplace. Much of the information in that paper will also be included in EMA’s online SOA Solutions
Guide, which will be available late summer of 2006. This paper is the third and final paper in the series. It offers a point-
in-time perspective on how SOA is being used in today’s enterprises to solve today’s business problems.
This paper is being written in part as an answer to the articles appearing in the trade news questioning whether SOA is
“real.” In fact, EMA recently attended an analyst conference sponsored by one of today’s largest vendors at which an
analyst actually asked that same question. Our industry is bombarded with “news” and “technologies du jour,” many of
which come and go with little or no impact on the industry over time. Our industry has been bedeviled by smoke and mir-
rors during its somewhat short history, and it is little wonder that analysts and customers alike have become skeptics.
In the course of producing the landscape paper referenced above, EMA briefed with a wide range of vendors who dis-
cussed their customer success stories in the SOA space. After those discussions, we were prompted to follow up with our
own customer interviews to get a first-hand perspective on what is required to roll out SOA services in 2006. Vendors are
telling us that SOA is real – is it? We are hearing that SOA implementations are going beyond prototypes and conference
room pilots, are being implemented as production deployments, and are scaling to huge transactional numbers – is this
true? The early adopter case studies and analyses presented in this paper help answer these questions.
In navigating through end user stories, we discovered that SOA is in fact real, but that it’s hard. We found that SOA
implementations can yield enormous business benefits, but not without visionary leadership and a healthy dose of orga-
nizational commitment. Especially at the beginning, when SOA is an unknown quantity, it requires an enormous shift in
skill sets, a long learning curve and an investment in organizational change – so it’s not for the faint of heart. Companies
succeeding in deploying SOA services, however, are positioning themselves for competitive leadership in their industries
and significant new revenue opportunities.
SOA offers a glimpse of a very intriguing technology future. Its complexity and its promise will bring the industry full
circle. In recent years, pundits have discounted the value of technologists and the technology they build in favor of busi-
ness vision. SOA drives home the reality that we’ve entered an era when business can’t be successful without technology.
The early adopters profiled in this paper underline the fact that in most industries today, business success is dependent as
never before on the skill, creativity and talent of the IT technologists who are bringing these services to market.

SOA In The Marketplace: Hype Or Reality?
Estimates on SOA spending vary, but a conservative estimate is that spending worldwide on technology and services will
be upwards of $40 billion dollars by 2010. Vendors and consulting firms are getting in line for a slice of this pie and there
will clearly be a lot of room for both, as a majority of organizations indicate that they plan to roll out SOA initiatives
during 2006.
SOA is clearly being billed as the next great opportunity for both vendors and businesses, and this is undoubtedly one
of the reasons why it is continually in the news. However, a bigger reason why we’re hearing so much about SOA is
because it is reported as being capable of delivering startling benefits in terms of business agility and ROI (Return On
Investment).
Organizations interviewed for this paper reiterated this fact over and over: those organizations that have started down the
SOA path, then abandoned it as “too hard” or “too expensive” are the reason why SOA is still viewed as a pipe dream
in some quarters. This is definitely a case where a high initial investment in terms of time and money yields expertise,

page SOA: A View from the Trenches

assets and infrastructure that enable subsequent rollouts
80%
to be implemented much more quickly than would be
possible using traditional legacy architectures. SOA’s 70%
payoff comes with reuse, not during ramp up, which is 70%

one reason why it is so important that SOA rollouts have
executive sponsorship. 60%

SOA isn’t simple to implement. You can’t buy a product
50%
and roll out an SOA. You can’t adopt industry standards
or Web Services and “do” SOA. SOA is just an architec-
40%
ture, and fleshing it out into an organizational strategy
requires technology expertise, organizational gover-
nance, executive sponsorship and a fairly hefty up-front 30%
investment. The touted cost savings don’t start until the
first few implementations are in place. Because of this, 20%
businesses with short-term IT strategies are wary of 10%
SOA because of the risk of investing a lot of money and 10%
potentially ending up with little to show for it.
How pervasive is SOA? We’ve seen published figures 0%
Research Estimate Vendor Estimate
ranging from an astonishing 70-80% to a more realistic
10-25%. We use the word astonishing because the 70- Figure 1: SOA Adoption in 2006: Published
80% figure is obviously way off the mark and probably Estimates versus Vendor estimates
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

SOA: A View from the Trenches page 2

each customer’s policies. The result is that the telco was able to reduce new customer integrations from an average of
3,000 hours per customer to an average of 160 hours per customer. Obviously, the ROI in situations like this one is expo-
nential. Not only can each customer be integrated to the telco base system in a fraction of the time required previously,
but more customers can be provisioned in the same amount of time.
Obviously, telecommunications companies are among the leading edge market leaders in terms of technology capabili-
ties. Getting that first customer on board using SOA required an investment in products, training, services, and a pilot
project. The first few implementations required a learning curve as well. Once that initial investment was made, however,
the ROI was very rapid. This is characteristic of SOAs and this scenario is being played out across the industry as SOA
implementations proliferate.
With these kinds of results, it becomes clear that SOA isn’t vaporware, isn’t a fad, and isn’t going to go away. In fact, many
industry experts predict that this is the direction the entire industry is taking, and when you look closely at the kinds of
returns that SOA is producing, it looks more and more as if they are correct.

Methodology
To gather information for this paper, EMA did in-depth interviews with five organizations with between 2 and 6 years
of experience with Service Oriented Architecture. Currently, EMA sees SOA as cresting the “early adoption” phase, and
this presents difficulty in terms of locating interviewees that both have a good understanding of SOA and have used it
in production. Once interviewees were located and contacted, EMA used a standardized questionnaire for each interview
that followed the format of the interview results detailed in this paper. These interviews provided the raw data for the
Case Study profiles in the “Customer Stories” section of this paper, as well as for the “Drivers,” “Issues,” “Advice to New
Users” and “Key Takeaways” summaries.
The “How Do I Do It? One Approach To SOA Implementation” section is a step-by-step implementation strategy cre-
ated by summarizing EMA’s 2006 SOA research series. It condenses all three of EMA’s 2006 SOA studies, including the
“Advice to New Users” from our five case study interviewees, into a single step-by-step methodology that represents our
current recommendations as to a potential strategy for SOA adoption. This strategy will be updated in years to come as
SOA is more widely adopted and becomes more mature.

Analysis
Each case study includes the following sections:
• Overview
• The Challenge – Business Drivers for SOA
• Implementation Details
• SOA Products Currently in Use
• Product Selection Process
• Results
• Issues
• Advice to New Users
• Key Takeaways
Drivers, Issues, Advice to New Users, and Key Takeaways are summarized by interviewee in a series of tables at the
end of the Case Studies section. However, the section immediately following this one provides a high level summary of
findings for those readers interested in summarized versus detailed information.


Key Takeaways
Summary of Key Takeaways
This section represents EMA’s summary of the key messages gathered during the course of this research.
• Once SOA services are in place, expect exponential growth.
• Consider governance from day one. If you don’t, growth quickly forces governance and you’ll have to go back and address what is
already in place anyway.
• Talk to the business, understand it, and make decisions based on its unique needs.
• Don’t use a “big bang” approach to SOA adoption; instead, evaluate each new project to weigh the value of implementing it using
SOA versus more traditional methodologies.
• Consulting can help organizations determine whether SOA is the best option at a given point in time. However, interviewees were
split on the consulting issue, with most recommending vendor consulting over general SOA consulting.
• Planning pays off. Some of the interviewees spent months in the planning and design phases before they ever rolled out a service, and
believe that is a major reason for their success.
• Don’t get sidetracked by “religious discussions” about technology, such as SOAP versus REST. SOA isn’t just technology – in fact,
it is technology-agnostic.
• Where possible, shift functionality from hard-coded services to policy-based execution. One interviewee estimated that his organization
saves up to an estimated 85% of development cost by doing this, while reducing the risk inherent in development projects.
• Taking advantage of automated recovery and other automated capabilities in management solutions can improve performance and
significantly reduce support costs. This typically is a hard sell to support staff, who may feel that they are losing control. However,
choosing policy-based solutions that provide an audit trail can help mitigate this issue, since technicians set the policies and can refer to
the audit trail if necessary.
• Learn about loose coupling and learn how to use it – it is at the heart of SOA and one of the foundations for managing change.
• The debate over fine-grained versus coarse-grained services continues to rage. However, our early-adopters indicate that, although they
tend to start with fine-grained services, they combined them over time to make them more closely resemble “real” business services.
• SOAs are designed for massive scalability. However, they may require performance enhancers such as XML acceleration appliances
and load balancers to be viable performance-wise.
• Keep it simple at first, and where possible, use home-built products or those that are already in-house.
• Don’t invest in products until you see a clear need for them and understand specific requirements. Corollary: Use products already
in-house until you outgrow them.
• Regarding products, try before you buy.
• SOA isn’t as much an end state as it is a development style.
• Be aware that the reuse concept requires changes to development styles and techniques.
• After the initial SOA services are rolled out and technologists have gotten through the learning curve, the benefits of SOA adoption
can be significant.
• The first few projects take much more time and are much more expensive than subsequent projects.
• Although initial costs are high, subsequent rollouts become easier and yield considerable payoff.
• The up-front investment required, aside from staff ramp-up, is to establish the minimum infrastructure including the Web Services
stack, UDDI, and lightweight governance foundations.

SOA: A View from the Trenches page

• Once the initial services are rolled out, the question of how services are paid for will become an issue, as business units across the
organization will want to reuse services developed, and paid for, by other business units. Early on, the organization needs to address
how this works as part of their governance process.
• Keep abreast of standards as they are the route to interoperability.
• If your company is too large and/or diverse to standardize on products, consider standardizing on standards.
• SOA gives organizations the ability to create new services and bring new product offerings to market very quickly.
• Although SOA implementations are initially easier to justify in terms of cost reduction, going forward, revenue generation becomes an
additional driver.
• Each new service becomes an asset that can be leveraged by multiple future projects.

Case Studies
Case Study #1: MedicAlert
Company Name MedicAlert
Number of Employees 150
Industry Vertical Healthcare Services
Interviewee Jorge Mercado, Senior Engineer

overview
MedicAlert® is a private, non-profit medical informatics organization that provides personal health record services.
Specifically, the company stores computerized medical records for each of its members, including key information such
as medical conditions, medications, allergies and insurance information. In the event of a medical emergency, medical
personnel can access this information and utilize it for proper diagnosis and treatment.
the challenge: Business drivers for soA
Medical information is stored in a variety of data stores including insurance companies, doctor’s offices, hospitals, and
pharmacies. MedicAlert integrates this data, including that of other healthcare information providers, into a unified
information view for each subscriber. MedicAlert requires the ability to integrate with an almost unlimited number of
organizations creating, in effect, a “federated” view of patient medical information. While many of their integration
partners still exchange information via scheduled FTP feeds, MedicAlert made the decision to leverage SOA to position
them for real-time data exchange opportunities and to do this in a flexible, agile manner.
An additional requirement was that they needed a faster way to respond to the dynamic business requirements so char-
acteristic of the healthcare field. Given enough time, the IT group could have addressed evolving business needs using
scalable systems, legacy architectures and traditional development techniques. However, a critical issue for MedicAlert is
that they need to bring new business services to market very rapidly. Legacy software development methodologies and
architectures simply require too much time to deploy.
In the healthcare industry, flexibility and agility are key differentiators for industry leaders. With these requirements driv-
ing them, Jorge Mercado’s group leveraged SOA to contribute to the business bottom line and help the company to gain
marketplace leadership.
Implementation details
MedicAlert started their SOA initiative in April, 2004, and have been evolving their services ever since. They leverage
SOA services for internal company use and to integrate with external customers and business partners. While external
users need to be able to access subscriber medical records in real time, the business also uses the same data internally to
create and submit orders. At present, they have approximately 20 SOA services in place.


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 process
Initially, 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.
Results
MedicAlert has been using SOA as their production architecture for over a year and are finding that the benefits of SOA
are huge – in Jorge’s words, “glaring.” It gives them the flexibility to implement and retire services transparent to consum-
ers and positions their company for future agility to move quickly to create new services and integrations.
From Jorge’s perspective, their SOA implementation has certainly not been without challenges, but they have achieved
excellent results. Policy-based reuse dramatically cuts development time. Rapid service assembly promotes quick time
to market and enables the business to become more nimble in terms of adding new capabilities and new product
offerings.
Jorge is a big proponent of SOA and feels the challenges are worth it, as they can roll out new business processes very
quickly.
Issues
• Not easy to do. There is a learning curve associated with SOA in which the architect has to learn to understand
both SOA and Web Services. Part of the learning curve is getting a good grasp, via trial and error, on what works
and what doesn’t.
• SOA designs require careful planning and can get complex very quickly. There is a huge misconception that simply
putting a Web Service in front of an application is SOA. This isn’t the case, as there are multiple additional
considerations.
• Security is an issue, not because it’s difficult to implement, but because it has to be carefully architected to deploy
it appropriately. What is the best way to secure a SOA service? How do you decide when enough security is
enough?
• Monitoring and management of running services. MedicAlert relies on AmberPoint to provide much of this functional-
ity. For example, SOAP fault exception management can be a big problem. When twenty services are linked
together, it is difficult to track down the source of a problem without specialized tools. AmberPoint helps by
trapping SOAP faults and, via policies, triggering a sequence of recovery events when faults occur. A related
issue is to make sure that SOAP faults are censored, so they aren’t sending out potentially sensitive information
to other systems.
Advice to new Users
• Start small. Crawl, then walk, then run. Start by putting a Web Service in front of an application and go from
there. Some companies have tried to bite off more than they can chew by deploying SOA with little or no under-
standing of the big picture. They are overwhelmed and unsuccessful, then blame SOA for their failures.
• Develop a delivery strategy as early as possible. Weigh a top down (business model to technology) versus bottom up
(technology to business model) design approach. If the business demand is that the service be rolled out quickly,
you may not initially have the luxury of the top down approach. But at some point, you need to analyze from
this perspective to align services to the business model.
• Don’t be afraid to reengineer and simplify business processes. As you analyze business processes, ask the question, “Does it
have to be this way?” View the analysis phase as an opportunity to improve business processes or align them to
better fit technology.
• Use care in designing policy-based services. Designing policy-enabled services requires careful thought. What functional-
ity should be hard-coded and what can be pushed to policies? This is a different design paradigm that requires
careful analysis of message granularity – how coarse or fine does the service need to be? MedicAlert has found
that services that are too fine-grained are often not as reusable as more coarse-grained services, and reuse is key.


Key takeaways
• Use policies to tailor the way services run and save on coding. This can be a significant source of ROI, as well as
a way to reduce risk.
• SOA benefits are “glaring.”
• SOA gave them the ability to quickly assemble new services and bring new product offerings
to market very quickly.
• If your management solutions offer automated recovery and other automated capabilities,
take advantage of them.

Case Study #2: Lockheed Martin
Company Name Lockheed Martin Integrated Systems and Solutions (ISS)
Number of Employees 130,000 overall
15,000 in ISS
Industry Vertical 100% Government
Interviewee Tim Vibbert, Sr. Systems Engineer

overview
Lockheed Martin provides us with a look at SOA from the “big consulting” perspective. Lockheed Martin is, of course,
a multinational company and its Integrated Systems and Solutions organization (ISS) is a Systems Integrator. Much of
its practice is SOA-related. Currently, most ISS clients are in the government sector, with representation at the federal,
state and local levels.
Lockheed Martin has committed multiple millions of dollars to SOA research, and customer response to its SOA initia-
tives, including their Center for Innovation in Suffolk, Virginia, has been “phenomenal.” The ISS architecture 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.
ISS 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, ISS 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 ISS 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 soA
Government 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.


The ISS strategy for SOA implementation, and one of the reasons why an up-front assessment is critical, is because
their approach is vendor agnostic. Actual implementation is designed based on the specific requirements of the agency
they are working with. They make every effort to leverage existing products and use solutions already in place to build
out SOA designs.
As a partner with government, Lockheed Martin faces a major challenge – one of connecting systems designed and
implemented as stand-alone entities. At this point in time, there are few or no viable alternatives to SOA for addressing
these massive integration requirements.
soA products currently in Use
Lockheed Martin is very focused on standards-based solutions and, in fact, the federal government’s direction requires
a standards-based approach. Traditional Enterprise Application Integration (EAI) solutions, which are often based on
proprietary technology, don’t meet this criterion. Lockheed Martin is very much engaged with standards development
bodies and, not only do they specify the specific standards to be employed when they specify architecture for a given
project, they also proactively plan for the standards they will support in the future.
Typically, architecture projects provide high-level product specifications which are then left up to implementers to select.
Most customers prefer or require that ISS not divulge exact implementation details. Deployments utilize technology
from well-known vendors across multiple platforms and architectures. Projects include a combination of open and pro-
prietary systems, many of which are utilized because they are already in-house. As government organizations transform
themselves into service based entities, Lockheed Martin concentrates on leveraging products in place, where possible, to
maximize business value.
Results
Customers have realized the benefits of becoming more agile with their information sharing and more responsive to
business needs. In addition, they are seeing reductions in subsequent development and operational costs.
Issues
• Governance: SOA Governance is a critical component of any SOA deployment, probably more so in the govern-
ment space than any other. As customers transform to service-based entities, visibility of information and
sensitivity issues surrounding data usage are key governance challenges. Other governance issues are security
requirements, runtime SLAs (Service Level Agreements) and QoS (Quality of Service).
• Architecture and technology implications:
◦ Business process and organizational changes are required to support SOA.
◦ Service change governance quickly becomes an issue: One key factor is governance related to changing services in step
with changes to internal business processes. This is especially an issue once services have
been reused.
◦ Funding questions: One of SOA’s key differentiators, and a major source of cost savings, is service reuse. When
service components are reused, 90% of the service functionality can often be leveraged towards a
new service. However, most organizations don’t have models in place to specify how the remaining 10% will
be funded.
In the federal sector, an example is where multiple agencies want to use a single service. One agency creates the
service and puts it into production. A second agency wants to use it. If they do so, should the agency creating
the service be reimbursed by the second agency?
◦ Service reuse also introduces additional dependencies and therefore risk.


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

overview
TrueCredit, 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.
TrueCredit 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.


Scott was the executive sponsor for SOA implementation within the company. They have a very dynamic environment
to manage from an operational perspective, which forced them to spend the extra time and thought up front to get it
right.
TrueCredit has 60 employees in their technical group, with approximately 60% on the engineering side and 40% on the
IT support side. They have now spent almost five years on their design model and development processes. The result is
that they now have enough detail to get predictable results from their development efforts.
For the first 1 1/2 years, they focused on creating simple rules that everybody in the organization understood and incor-
porated into their design and development work. Over time, they built on those initial rules. They also spent a lot of time
on architecture and process, and outsourced to augment capacity because they knew they would have to grow faster than
they could hire. Initially, they used homegrown monitoring tools, but incrementally added monitoring products as their
SOA became more critical to the business.
TrueCredit packed a lot of experience into these years, and, in Scott’s words, “bled a lot to get there.” They did it on their
own with no SOA consultants. A major reason for this was because, since they started so long ago, few SOA consultants
were even available.
Their goals included:
• High throughput for minimal cost.
• Ability to provision underlying hardware on the fly: A key requirement was to be able to provision quickly throughout
the day, so that they could rebalance production infrastructure as needed.
They currently do not use policies, as the applications that consume their services may be 10% or 90% different from
one another. They have found, for example, that the interactions with various business partners vary significantly between
partners. Instead of using policies, they build these variations into the services themselves. The result is that can make
modifications in a forward and backward compatible manner.
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.


Prior 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.
Results
Scott 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.
Issues
• Translating business requirements into technical implementations.
• Early adoption requires a long learning curve and can be painful.
• Governance to achieve reuse objectives.
• Troubleshooting and debugging loosely coupled SOAs require different tools and a different mindset compared to traditional software
architectures.
Advice to new Users
• Talk to the business. Take the time to understand the business processes that SOA services are going to model.
Include the business in that analysis. A big part of the ability to succeed is to dive into the business to get a
good understanding of what’s important to stakeholders and what key business processes allow the business to
be competitive.
• Concentrate on good design rather than specific technology. Technology is not as important as design. TrueCredit cur-
rently uses Java, but could have used a .NET solution as well. A good design shouldn’t depend on underlying
technology to work. Although articles on SOA indicate that specific products are required to implement it,
analyzing services and talking to key business stakeholders is most important. Once that is right, everything else
falls into place.
• Before embarking on implementation, take the time to determine how the services and applications will be managed. Define
key performance indicators for the business as well as required metrics up front. It is also important to walk
through root cause analysis scenarios to ensure that you have enough visibility to the operational environment
to diagnose and troubleshoot issues. Attaining optimal performance requires enough visibility to the execution
environment to be able to see early warning signs leading up to a problem. The ideal is for the issue to be fixed
before a failure occurs.
Key takeaways
• Planning pays off. Scott indicates that, for the first 1 1/2 years, they focused on creating and following simple rules.
Over time, they built on those rules. They also spent a lot of time on architecture and process.
• Keep it simple at first, and where possible, use home-built products or those that are already in-house. Initially, TrueCredit built
its own homegrown Services Manager and monitoring tools. They have added other products as the need arose.
• Buy products only to address specific functionality. TrueCredit moved to BEA when they needed to scale and standard-
ize. They purchased OpTier because of the requirement to get on-demand provisioning and high throughput for
minimal cost.
• Make decisions based on the unique needs of the business. While MedicAlert has gained a lot of value from using policies,
TrueCredit has made a conscious decision not to use them.


• Be very clear on product requirements and try before you buy. TrueCredit has a well-developed proof of concept process
as well as clear guidelines for completion. Combined with specific requirements, this gives them a laser-like ability
to tie functionality to overall value.
• Talk to the business. Most articles about SOA focus on the technical side of SOA, not the business side.
Organizations that have been most successful with SOA are those that have used it to address specific business
challenges. Taking time to clearly understand the problems of the business, and to work with the business to
formulate solutions with clear business value, ensures a tight alignment between IT and business goals.

Case Study #4: Thomson Learning
Company Name Thomson Learning
Number of Employees 40,000
Industry Vertical Media, Education
Interviewee Christopher Crowhurst, VP and Chief Architect

overview
The Thomson Corporation is a leading global provider of integrated information solutions to over 20 million users in
the fields of law, tax, accounting, higher education, reference information, corporate e-learning and assessment, financial
services, scientific research and healthcare. The company had revenues of over $8 billion, 8% over the prior year, in 2005.
It is listed on the New York and Toronto stock exchanges.
For Thomson Learning, one of the major drivers for implementing SOA was the classic one – the need to deliver
business services more cost effectively. SOA wasn’t just an attempt to gain asset reuse, they also needed to be able to
share services with other companies. The unit cost for new development had become so high, and software services so
complex, that sharing was a major requirement for cost efficiencies. The cost of the SOA service components they are
sharing is enormous, with multi-million dollar software platforms being integrated to business partners and customers.
An additional driver was new revenue generation, based on the idea that composite applications could be brought to
market faster than traditional legacy software rollouts. Using services to expose core business capabilities enabled reuse
of those core services for subsequent rollouts, enabling Thomson Learning to bring services to market faster than
their competition.
From their perspective, SOA is initially easier to justify in terms of cost reduction; going forward, revenue generation
becomes an additional driver.
Thomson Learning didn’t set out to “create” an SOA project, but instead evolved into SOA by using development oppor-
tunities as they became available. As new projects came into the pipeline, they analyzed whether each one would best be
implemented using SOA principles or traditional software development methodologies, keeping in mind business drivers
and overall vision. They continue to use the same strategy today, adding SOA services where it makes sense to do so.
For example, recently they implemented a new identity management system based on best practices for identity manage-
ment. As subsequent SOA services are rolled out, they can use the identity management service already in place. Using
this strategy, each new design exposes additional functionality which can then be applied to subsequent projects.
The SOA effort was driven by Christopher Crowhurst, who presented the initial concept at his CTO’s strategy meeting.
After receiving approval at the CTO level, he then created marketing collateral that his group used to market the SOA
concept to other “C” level executives, as well as to the production group and others within the organizations.


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.
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.
In 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.
Results
One 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

overview
The 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.
There 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.”
Mark’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.
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.
Due to the large size of their company and the number of separate entities that comprise it, it is difficult if not impossible
to standardize on products. Instead, they standardize on standards. As an organization, they don’t specify what applica-
tion server a particular company uses, as long as it is standards compliant. From their perspective, standards are key to
reaping the economies that SOA has the potential to deliver.
Results
They feel that going with SOA was a good choice, as there really was no other option for their integration challenges.
They very much view the SOA implementation as ongoing and anticipate continuing to roll out new services as time
goes on.
Because SOA services are dependent on multiple components, the reuse concept changes the way they have typically
approached development. Traditionally, a given group within a company requested that a particular capability be devel-
oped, and they paid for that development. SOA makes organizations re-think the way they fund projects and the way they
determine who owns what.


Issues
• Culture change: SOA forces cultural changes in terms of component funding and ownership, since components
may be reused later as orchestrated steps in long-running composite processes.
• Skeptics within the organization required value to be demonstrated quickly: They had to overcome an environment in which
skeptical business people viewed SOA as “just another buzzword.” It was very important for them to demon-
strate business value, practically from day one.
• Immature Standards: Many industry standards are still not well defined. Nevertheless, they chose to steer away from
proprietary technologies in favor of standards-based solution.
• Upfront initial cost and continuous investments: Unlike “big bang” investments like Enterprise Resource Planning
(ERP) systems, the fact that SOA is standards-based made it easy to integrate and to gain incremental value on
investments. An initial investment is needed to establish the minimum infrastructure including the web services
stack, UDDI, and lightweight governance foundations. Once the platform is in place, incremental development
and planned service rollouts become a matter of analyzing and scheduling.
• Funding: The organization had to reexamine and adjust its development project funding policies to establish a
pool of standardized services that would be available for subsequent reuse.
Advice to new Users
• Crawl, then walk, then run. The most important advice is to start small and build incrementally.
• Standards are more important than products: Especially in very large organizations like Mark’s, it is difficult for the
entire enterprise to standardize on a given product. It makes more sense for the enterprise to standardize on a
specific standard, then require that any products purchased conform to that standard. From this perspective, an
understanding of where the industry is going in terms of current and future standards is key to making good
purchasing decisions.
• Governance: From the beginning, governance is critical to maintaining discipline in SOA, especially as the orga-
nization begins to modify and reuse services. It is best to fit SOA governance within the overall IT governance
strategy, but at minimum, governance needs to be in place from the very early phases of SOA deployment and
maintained as the SOA infrastructure grows larger.
Key takeaways
• Once the first SOA services were in place, the SOA grew “like wildfire.” Once an organization starts reaping the benefits
of SOA services, the SOA ecosystem tends to grow very rapidly.
• Growth quickly drove governance. The need for a standards-based registry and an administrator with final control over
the release management of SOA services soon became apparent.
• Although initial costs were high, subsequent rollouts became easier and they have seen considerable payoff over time.
• They started out using homegrown solutions to monitor, and are just beginning to evaluate commercial monitoring products. Again,
make do with what is in place until a specific, clear-cut need for a product exists.
• The organization is committed to standards as a route towards interoperability. If a company is too large and/or diverse to
standardize on products, consider standardizing on standards
• The reuse concept changes the development process in multiple ways. We have already talked about changes to funding
paradigms. However, SOA also affects specific development standards and techniques. For example, imple-
mentation of policy-based processing introduces the potential to push functionality to policies versus hard-
coding. It is important to be aware of such factors and to be willing to adjust development techniques and
standards accordingly.


Summary Tables: Drivers, Issues, Advice to New Users
Drivers
Drivers
Votes
5 To integrate: with health providers, multiple platforms
2 Reuse and refactoring of services, share them with other organizations
1 To be able to bring new services to market very rapidly in a competitive environment
1 To deliver business services more cost-effectively
1 To generate new revenue from new services
1 To simplify service rollouts and modifications
1 To design global information grid
1 To leverage economies of scale
1 To satisfy the Credit Act: numbers of credit reports dramatically increased
1 To utilize a common services framework and to leverage Web Services
1 To leverage core capabilities across lines of business

Table 1: Drivers

When asked about the drivers for SOA implementation, all 5 of the interviewees mentioned integration. The specific
requirements varied by respondent, with some having very specific integration requirements, such as integration with
health providers, and some having a broader perspective, such as “designing a global information grid.” This finding was
not surprising, since integration is typically reported as being a key inducement for organizations to evaluate SOA.
Two respondents mentioned reuse and/or refactoring of services, which has been widely reported as another key incentive
as well as a major source of cost savings. A unique take on this concept was a single respondent that mentioned an orga-
nizational imperative to share services with other like organizations, due to the very high cost of service development.
The remainder of the responses received one vote each and included several interesting business exigencies. One was to
realize the economies of scale made possible by integrating the supply orders of multiple agencies into cost-effective bulk
orders. Another was to address the unexpected volume of customer requests generated by new legislation.
Only one cited new revenue generation as a goal. This is consistent with other industry studies showing that while
companies commonly embark upon SOA because of the need to integrate, new opportunities for revenue generation
become apparent as the SOA matures. Once the first SOA services are rolled out, companies see for themselves that
subsequent services can be brought to production faster and cheaper than was possible in the past. The agility they gain
prompts them to become more creative in identifying gaps in the marketplace that can potentially be addressed with new
service offerings. Several of the interviewees mentioned that they felt they had gained ground over their competitors by
following just such an approach.


Issues
Issues
Votes
3 Culture changes regarding component funding and ownership
3 Governance
2 SOA difficulty and learning curve
2 SOA requires different ways of monitoring and managing than legacy systems
1 SOA designs require careful planning and can get complex very quickly
1 Security has to be carefully architected, not necessarily because it’s hard, but to make sure you get it right
1 Interface design
1 Identification of critical services
1 Creating taxonomies for the enterprise
1 Skeptics within the organization required value to be demonstrated quickly
1 Many industry standards are still immature and not well defined
1 Up front initial cost and continuous investments
1 Organizational changes
1 Translating business requirements into technical implementations

Table 2: Issues

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.


SOA A View from the Trenches

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie SOA A View from the Trenches

Ähnlich wie SOA A View from the Trenches (20)

SOA A View from the Trenches