TSS Java Symposium: F100 Enterprise Mashups

Eugene Ciurana, one of Walmart.com's most influential platform architects, says F100 IT execs want more business value from IT investment. So, lower ROI tasks will go overseas, and those who can integrate open technologies with legacy will benefit. Ciurana discusses high-value "Enterprise Mashups" between old and new at TheServerSide Java Symposium in Las Vegas Mar. 21-23. IDN gets a preview.

Tags: Enterprise, Applications, Enterprise Mashups, Open Source, Cost, Business, Architects,


Eugene Ciurana, one of Walmart.com's most influential platform architects, says that large F100 companies are setting their future enterprise IT strategies using many more open standards and Open Source components. Ciurana will discuss the future of what he calls "Enterprise Mashups," which bridge the old and new, at TheServerSide Java Symposium in Las Vegas Mar. 21-23. IDN gets a preview.

Ciurana recently delivered a presentation on "Enterprise Application Mashups: Architecting the Future" at the TSS Java Symposium.

Cost-conscious Fortune 100 companies demand More, Fast, Cheap and Now. IT vendors see this as a chance to sell their wares and lock the customer in. Programming jobs with low ROI are outsourced overseas. Companies must come up with the new applications that the business demand and balance costs, leverage open-source technologies, and decide between vendors' offerings.
To Ciurara, "enterprise application mashups" are how enterprise IT professinals are working to define how commercial software, in-house software and Open Source options will meet and converge. Mule ESB, Codehaus Xfire, Terracotta DSO, Java 6 and 7, and even AJAX and JSF are changing the landscape. IDN speaks with Ciurana to learn how. (Click here for more on Ciurana's presentation at TheServerSide's Java Symposium, held last month March 21-23.in Las Vegas, Nev.)

Integration Developer News interview with
Eugene Ciurana, Director of Platform Technology
and Enterprise Architect
Walmart.com


TOPIC: Defining 'Enterprise Mashups'
IDN: You say that "enterprise mashups" should be new apps that balance business demands, time-to-deployment, and costs of projects. Could you describe in more detail your definition?

Ciurana: The short answer is yes, I can share a checklist and some guiding principals.

But, first, let's start with the mashup concept first: [A]ny enterprise today is already running a mashup of one form or another. Very few, if any, run every application with a single vendor's wares. Enterprises run a combination of in-house and commercial applications that somehow need to inter-operate.

Enterprise applications were originally designed as islands with bridges: interoperability was the result of building dedicated paths between applications. Databases and data warehouses are some times used as a sort of asynchronous conduit between islands. Message queuing is a dynamic way of bridging applications but it requires establishing queues between each individual subsystem and eventually creates more complexity.

The surge of Open Source applications and infrastructure is a boon for architects because it allows them to mix and match systems at a fraction of the cost and with lower risk of lock-in when compared against commercial offerings. There are few (are there any?) Open Source enterprise software packages because such applications demand intimate knowledge of vertical problem domains. Open Source finds its home in the infrastructural components: operating systems, runtimes, conduits, and perhaps even databases.

TOPIC: 'Enterprise Mashups' Leverage Open Source
IDN: Your tone of "enterprise mashups" appears to take into account the "blending" of open Source and commercial apps/tools throughout the whole enterprise framework, and not simply for client apps? Is that true?

Ciurana: Yes, it's true. If we define a "mashup" as an aggregation of disparate technologies to achieve a goal, then an "enterprise mashup" is a way of combining legacy, in-house, commercial, and open-source software to create new products and services for the enterprise.

Clients are only one part of the mashup. Software as a service, and applications that act as services, consumers, or both, can be integrated together to provide more value than any individual component can by itself. On the commercial side, for example, Oracle acquired a number of companies in the last few years and had to get the products from all of them to inter-operate. They market their products mashup today as Oracle Fusion. Oracle's experience is no different from the challenges and opportunities that enterprise architects face every day.

TOPIC: Checklist to Prep for 'Enterprise Mashups'
IDN: Wow, that all sounds a bit daunting for devs/architect looking to achieve this new balance. Can you offer a checklist (or guiding principals) our readers can use to reach this new balance?

Ciurana: The guiding principles for making all these things work are simple:

1. Define unambiguous, non-subjective selection criteria for each application and component
2. Modern and retooled applications must support access to their results as services
3. Based on 1. and 2. pick the product that best matches the selection criteria and SLA
4. Applications must deliver services through standard (collegiate or de facto) protocols and interoperability mechanisms such as SOAP, message queuing, REST, XML, JSON, BPEL, etc. These protocols and mechanisms should not be language- or runtime-dependent
5. Use an enterprise service bus (ESB) to tie everything together; why reinvent the wheel?

Let me also share some rules of thumb as you define your architecture:
  • Assume that business logic and domain-specific applications will come from commercial vendors, in-house development teams, or a combination of both
  • Expect that your infrastructure (operating systems, app servers, databases, messaging stacks) will come from open-source products or services
  • Remember that vendors have a vested interest in their wares and may stretch the truth a bit; make them prove that they can inter-operate with third-parties, even with competitors' products, during the selection phase


  • TOPIC: Is Open Source Ready for 'Enterprise Mashups'
    IDN: What do you say to architects/devs who say some Open Source projects may be too early for serious F1000 projects (MuleSource and Tuscany, for example, might be exciting, but they can also be scary if your job depends on them)?

    Ciurana: Do your homework.

    The scary part of using Open Source software isn't really the software itself, but the potential exposures from its use due to licensing. Most issues have nothing to do with the quality or scope of the technology. The problems occur when a company doesn't have a clear open-source policy, or worse, when the policy is archaic or misguided. Part of doing ones homework may consist of understanding licensing issues and educating the legal department and business managers about solving potential misunderstandings.

    Evaluating projects and products is a similar exercise regardless of whether they are commercial or open-source. The key is to identify risk factors and weigh them against the benefits of using the Open Source.

    Here are a few questions that must be answered:
  • What is the definition of maturity for the product in relation to the company's SLA?
  • Is the product mature enough? Does it meet all functional requirements and features?
  • Does it have a rich, thriving community around it? Is the community growing? Is it easy to join and participate in that community?
  • Do the licenses for the product and its sub-components conflict with business goals in any way? Is there an alternate license if this is the case?
  • Are there one or more commercial entities providing support, training, custom development, etc. for the project?
  • Is there a commercial or other entity that provides indemnification for the product's users?
  • Will the company's engineering participate in contributing to the project? Is there a policy for releasing code back to the open-source community?

  • And, for good measure, here is a question to ask yourself from the gut:
  • Assume that the licensing cost for competing commercial and open-source products is zero. Are the open-source product's features compelling enough to overcome the feature set of the commercial offering in relation to your business goals and SLAs?


  • I was recently involved in one of those selection exercises between OpenLaszlo and an industry standard commercial Flash product. My team followed the selection criteria outlined earlier, including "if the cost is zero, would you chose X?". Having an understanding of all the issues, business goals, licensing, support, etc. eased the decision to go with OpenLaszlo because the risks and benefits were known prior to committing to this product.

    TOPIC: Hottest 'Enterprise Mashup' Opps
    IDN: With so many choices - ranging from RIA, Ajax, new 'Open' frameworks for ESB/SOA, and even dashboards and BI apps - what "enterprise mashups" sectors will be hottest in the coming years?

    Ciurana: This will depend on the industry and problem domain where a given company thrives.

    SOA/ESB seems poised to be a good bet across multiple industries because companies have two huge problems: They must remain competitive and they must reign their costs. One of the best ways to remain competitive is by quickly integrating "best of breed" products of services, whether they come from commercial vendors, other in-house divisions, the open-source community, or your own division's engineering team.

    Time to market is key in all industries, and the engineering teams that deliver first are the ones that will contribute the most to the enterprise's business goals. Find the best tool for solving a given problem. Shift your focus from developing everything in-house, or buying everything from vendors, or whatever your company's policy is, and focus on integrating the best discrete components into an application that delivers value to your business.

    This second problem, reigning the costs, is trickier to solve. First, you must shift your organization's focus from developing new software 100% of the time toward developing only strategic portions. The rest of your efforts must shift toward integration. Next, integration is best accomplished when you have a common conduit that all applications can use, especially if they're designed to act as services, consumers, or both. Application integration through SOA helps reduce the costs because new functionality can be added on-demand and faster by bringing it from the marketplace into the system. It's faster to integrate a system into the enterprise than to write a new one or extend existing ones. The per hour cost (i.e. your salary!) will be higher as an integrator, but with a shorter product cycle and fewer engineering hours the enterprise's overall cost will be lower.

    As an enterprise, database, or applications architect, SOA seems to be the best place to be. As a software professional, this is the area where you get to apply hardcore computer engineering or computer science skills in things like designing a caching system, or solving parallelization problems in a massive scale. Complementing this with knowledge about things like Mule, Tuscany, Terracotta, JavaSpaces, etc. helps increase your career prospects.

    Next, come dashboards and business integration apps, because all these software-as-services implementations must be orchestrated, and operations will shift from discrete environments to span the whole organization. Operating and optimizing communications across these services will have a lot of demand.

    And finally, as a developer, [while] I see RIA and AJAX will have tremendous growth, [these areas] will attract a lot of people, eventually saturating the market [because] the barriers to entry are lower, and the number of CASE-like tools for RIA and AJAX grows daily.

    It's a lot more fun to view flashy screens than to deal with infrastructural problems, but as a career choice I believe that becoming dexterous at solving infrastructural problems is a better path. An engineer with the know-how for building a system, or optimizing existing resources, is always in demand. Integration activities are less likely to be outsourced because this know-how involves intimate understanding of the business, the problem domain, and the technology.

    Unlike front-end coding, these skills are harder to develop and require more time, are less vulnerable to automation, and must exist within an organization even in tough economic climates. The outsourcing world provides a good yardstick: Find out the per hour cost of an AJAX/web/front-end engineer vs. a systems/database infrastructure software engineer. The latter will be higher and harder to find.

    Eugene Ciurana is the Chief Architect for Walmart.com. He's contributed to Java and OS X open-source projects and has architected main line of business applications, embedded platforms, and real-time systems for such companies as Bank One, Varco International, Bank of America, Credit Suisse, Nortel Networks, Sun Microsystems, IBM, Univex/Celanese, Nexis/Lexis, etc. He's the author of over 50 feature articles and editorials about technology and computer programming topics for such publications as The Server Side, Software Guru, Informatique!, Computerworld, EE Times, Byte, PC/Tips, and OMNI, and is writing a book about the Mule ESB. Eugene can be found in IRC (##java, #esb, #awk, #security) under the /nick pr3d4t0r.



    back