Home > Articles > Web Services > SOA

Enterprise Mashups Part II: Why SOA Architects Should Care

  • Print
  • + Share This
Gartner recently named Enterprise Mashups a “Top 10 Strategic Technology for 2008”, noting that “by 2010, Web mashups will be the dominant model for the creation of composite enterprise applications.” This should make any SOA architect sit up and wonder: Can I describe the value of mashups? Can I outline the relationship between mashups and existing enterprise technology like SOA? In Part 2, learn why SOA architects should care about enterprise mashups.

This article was originally published in The SOA Magazine (www.soamag.com), a publication officially associated with “The Prentice Hall Service-Oriented Computing Series from Thomas Erl” (www.soabooks.com). Copyright SOA Systems Inc. (www.soasystems.com).

Like this article? We recommend

Like this article? We recommend

Enterprise Mashups Part II: Why SOA Architects Should Care

Abstract: Gartner recently named Enterprise Mashups a #quot;Top 10 Strategic Technology for 2008", noting that #quot;by 2010, Web mashups will be the dominant model (80 percent) for the creation of composite enterprise applications." [REF-1] This should make any SOA architect sit up and wonder: Can I describe the value of mashups? Can I outline the relationship between mashups and existing enterprise technology like SOA?

Knowing the answers to these questions can advance you well down the road to embracing this exciting technology in your organization. In Part 1 of this three-part series, we defined a mashup in the context of the enterprise, contrasted it against other common data integration technologies, and outlined some of the more important architectural elements of an enterprise-grade mashup solution. Now, in Part 2, we’ll discuss why SOA architects should care about enterprise mashups.

To understand the value and relationship between enterprise mashups and SOA, it is helpful to first understand why we need enterprise mashups at all. To recap what we covered in the preceding article:

  • mashups give you faster answers
  • mashups improve your resource use (of both personnel and soft/hard computing resources)
  • mashups help you address new business opportunities by letting users assemble internal and external data in an opportunistic way

In a mashup world, SOA can provide the #quot;service cloud" that supplies the raw materials to a community of mashup users. And therein lies the conundrum: The most successful SOA initiatives will drive the need for mashups, but the bottom-up, ad-hoc nature of mashups can run contrary to the very principles that made your SOA a success in the first place. Avoiding this trap is not impossible. But adding mashups to a service-oriented enterprise architecture does require that the SOA architect pay close attention to the #quot;big 3" principle issues of SOA.

Having spent many years evangelizing, architecting and writing SOA solutions, we now know SOA is an easy sell to IT because it’s an architectural best practice. The service-oriented architectural style has attractive principles like shared services, loose-coupling and service reuse. We’ve also learned that IT is fast to accept SOA but can often get tripped up implementing the fundamental issues of governance, granularity, and scope.

The beauty of loosely-coupled services is in being able to decouple the service contract from the service implementation. Loose-coupling is like giving someone an address to your home and letting them get there anyway they want. But, what if you wanted them to only take a specific route and you wanted to check their ID before they drove up your driveway (doesn’t sound too inviting, but you’ll get the idea)? The same applies to SOA. Inherently, SOA does not force you down a specific route, nor does it check your credentials. Or in other words, there is no governance built into SOA. This is okay behind the firewall; but, when you want to expose services to the outside, IT gets very nervous and all of a sudden loose-coupling looks a bit more dangerous and governance looks a lot more important. Thus, governance becomes paramount but it makes a simple path to SOA a bit more complicated.

After governance, service granularity peeks its head out. To get the SOA right-sized, you must address questions like #quot;how large is a service", #quot;is a service atomic or does it represent a process", #quot;is a service so flexible it can support many variations or is it static and supports only one mega definition of data". Granularity discussions can get heated with epic debates lasting years in some organizations. Ultimately, you’ll probably settle on #quot;business granular", meaning that you should gauge the service granularity by being able to talk about it in business terms. Think ‘Inventory’, ‘Payroll’, and ‘Orders’. If you can talk about both in the service and the data that is being exchanged in business vernacular, you’re on the right path. As you can imagine this is no small feat and, like governance, adds another layer of complexity to the SOA roadmap.

The final issue of scope determines how big or how much of a problem IT is willing is to tackle when SOA-tizing the datacenter. From a project management and funding perspective, scope can really impact the likelihood of success or failure. After years of brilliant marketing, CIOs are betting on the lofty ROI, agility and time-to-market promises by making SOA a top 3 corporate initiative. Good for funding and commitment; bad for pragmatic realization. We now know that SOA can be very successful if managed as a series of well-scoped, smallish projects that are tied to business need. In essence, proper scope can lead directly to SOA success…or failure.

Figure 1

Figure 1: How mashups establish a layer between SOA and users.

After navigating the governance, granularity and scope issues of your SOA, you have one (or more) small, successful SOA projects that have resulted in a library of business-driven, micro-services that have can immediate business impact. But there’s the rub in your successful SOA: You either have no direct demand for your services by business users or you have demand for direct access by business with no way of delivering them safely.

That’s where mashups come in. A mashup can help deliver a new, dynamic, and potentially huge group of consumers to your services. And that’s why an SOA architect should care about mashups: Mashups can become that invaluable direct link between an SOA and the business community of an organization.

But how can we push our services out to a mashup community without trampling the principle issues of governance, granularity and scope that made the SOA effort successful in the first place? And furthermore, what are the interaction patterns between your SOA and these mashups? It is this fusion of SOA and enterprise mashups that SOA architects must understand.

Mashups Can Deliver SOAs to the User (Without Breaking Your SOA)

Mashups bring a #quot;user" into the SOA mix. This is an entirely new element and one that is dynamic and unpredictable. But the SOA architect needs to appreciate this as a good thing: The new demand that is being generated for an SOA from a mashup community. By having the business build mashups upon the foundation of you service-oriented architecture, they essentially become SOA champions without knowing it.

To get a better picture, it helps to consider some of the more common #quot;connections and interactions" between the two:

Information Right-Sizing

Three years ago we wrote a blog entitled: SOA Best Practice for Business Unit Alignment [REF-2]. The premise was simple: You had a better chance making your SOA successful if you included the business unit and made SOA more top-down. At the time, ~80% of the readers agreed and ~20% didn’t.

The group that agreed not only believed this to be true, but felt this was the only way SOA would achieve success. They felt that without the business, IT would not be able to correctly define the correct service granularity. That also meant you should be able to talk about services in business (not technical) terms. Interestingly, the 20% that didn’t agree felt that it should actually be done both top-down and bottom up.

But our point went further. IT needed to not only see the value in bringing the business to the table, but should actually let the business take more of a leadership role in defining the data they want and have that drives the service definition and creation. As a result, it is three years later and I have concluded that both groups were right.

The ideas are relevant here because mashups are a great forcing function for the right-sizing interaction between SOA architects and SOA business consumers. In most service-oriented solutions, IT needs to #quot;right size" services. This kind of dynamic virtualization is best defined by the use-cases from the business but needs the guiding hand of IT to make it stick.

Publishing and Syndication

Many view mashups as data displayed on maps. While the majority of early mashups certainly seemed to fit this description, today enterprise mashups can be published to many kinds of destinations that an enterprise user would appreciate. In addition to SOA-friendly formats, such as RSS and Atom plus REST and SOAP, mashup creators can publish mashups to spreadsheets, as WSRP-compliant portlets, wiki- and blog-friendly widgets, or even into a mobile phone as a micro-application. Mashups can become the vehicle through which services become part of the everyday tools of the enterprise business user.

A detailed example can reinforce this idea. Certainly most Web surfers have seen the power of syndicated widgets in popular sites such as iGoogle, Netvibes, Yahoo Maps and YouTube. Widgets let users do one or two narrowly-defined things well. And because both widgets and mashups are micro in scale, the fusion of widgets and mashups can yield explosive results. Today, the newly-combined data in your mashup can be published as a widget for use by others.

One good example of mashup-driven widgets is the system called #quot;The Badge" from Thomson Scientific’s ResearcherID.com community [REF-3]. The Badges let research professionals around the world publish a dynamic set of personal research data (such as number of citations, citations by country, and other professional data) into their own personal blog or Web site. To the Web site visitor, the Badge looks like a graphical button; it is in fact a widget that communicates with a service-oriented solution in the Thomson datacenter.

Mashup-to-SOA Publishing

The whole value proposition of loosely-coupled services gets muddied by the need to version services. The public interface of services, once published to the greater consuming community, must remain static. You're pretty much stuck with them. Yes, you can introduce bug fixes, but fundamental enhancements that affect the public service definition (like changing data types and adding new operations) can be very problematic for services that are widely consumed. Popularity, in a sense, can be an impediment to improving your SOA.

This is where mashups can directly help the SOA architect and developer. Mashups can go well beyond leveraging an SOA by becoming part of that SOA, allowing developers to create customized #quot;service skins" from core services. These skins provide a thin, easy-to-manage buffer against frequent or dramatic changes to the core services within your SOA.

Because mashups can be exposed as REST-, WSDL- and JSON-based services, they look and feel like a real SOA-based service to developers who want to consume them. In this use case, the service(s) from which the mashup is derived remain unchanged and become more of a #quot;behind the scenes" core service. The mashup, created by the developer, becomes the tailored service which is directly aligned with their particular need. Major enhancements to core services can be accommodated with a reformulated or updated mashup by the mashup creators themselves.

Service Virtualization

At a recent conference we asked the audience how many have put SOA into production. Many waggled their hand too-and-fro, not indicating a definitive yes or no but a #quot;sort of". As most SOA architects know by now, implementing a service-oriented solution can become quite complex. That means good SOA doesn’t happen overnight and most SOA teams are diligently working their way through a very long list of services that need to be constructed. Mashups can help create quick-and-dirty #quot;virtual" services from sources that haven't yet been service-oriented. Until the formal SOA magic has been applied across your enterprise, a good mashup tool can provide a light-weight, normalized virtual service for mashup users.

More inquiry with my conference audience revealed that most were not completely comfortable saying their SOA was #quot;in production" for services that just did one or two things. They were under the impression that SOA meant #quot;big in size" and #quot;big in functionality". Or, said another way, functionally-limited services didn’t jive with their view of a properly-architected SOA. But many admitted that there were many services that were essentially simple and data-centric and were being highly utilized by the business.

This is a great opportunity for SOA architects and developers to add mashups to their bag of tricks. Since mashups provide data services that work best by exposing discreet sets of data, it makes sense to employ mashups as a data service provider within your SOA when the service is small and specialized. Sure, you could still have the big services underneath, but mashups make a great light-weight solution that can reduce the services’ complexity and help expose right-sized virtual services in manageable, easily-consumable parts.

Inside-Outside Combinations

The trend towards standardized data formats makes it possible for mashups to combine your SOA with public or external sources that have adopted a standard data exchange format. Imagine you have customer data in your internal Siebel database and more customer data in a hosted Salesforce system. To get a list of opportunities from both systems and view it as a single data source creates a data migration problem. Instead of selecting one of the systems as the master data provider and moving the other data into it, a simple mashup that takes advantage of the standardized service interface of both systems allows you to create a mashup from them. (This assumes you’ve added that nice set of SOA-based services to your internal Siebel system, of course!). In other words, mashups let you create dynamic formats aligned with the users needs without having to migrate large chucks of data.


A mashup can be a first-class service consumer. But a recent Forrester report emphasized that a proper approach to enterprise mashups must #quot;provide a safety net for business users" [REF-4]. In other words, your mashup efforts must address governance, granularity and scope issues as proactively as your SOA efforts did. Assuming you agree and desire this new consumer base for your SOA, the natural inclination might be to rework your original SOA governance, granularity and scope to make it more #quot;user" centric.

At this point any SOA architect worth his WSDL should see that mashups can greatly enhance an SOA and don’t necessarily ignore or break the principles that made your SOA great. But governance, granularity and scope for mashups do require subtle tweaks and adjustments to your enterprise toolset. Because the business has different needs. They want small, not big. They want micro-slices of data, not all of it. They want combined data from a small number of services so that they can further combine it with external systems.

Fear not. Mashup governance, granularity and scope is not as difficult as it might sound and it need not be as difficult as it was during your SOA. If properly architected, your enterprise mashup solution can leverage many SOA technologies, acting as a peer to your SOA. In Part 3 of this series we’ll do just that: discuss an enterprise architecture that incorporates mashups as part of SOA-enabled ERP/CRM/SFA/BI and homegrown applications.


[REF-1] Gartner Identifies the Top 10 Strategic Technologies for 2008, Gartner

[REF-2] SOA Best Practice for Business Unit Alignment by John Crupi, JackBe

[REF-3] Mashups in Action: Fusing Enterprise Mashups to Enterprise Widgets (The Rest of the Story) >by John Crupi, JackBe

[REF-4] Enterprise Mashups: Lead, Don't Follow by Mike Gualtieri, Forrester

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020