Skip navigation

 

The JBoss SOA early adopter Swedish Railroad has been blogged about here earlier. Matt Asay picks up on this deployment more recently here.

 

 

 

Additionally, I presented Open Source SOA Value and Strategy at Red Hat Summit and SOA World in late June. CIO e-magazine picked up on the Swedish RR example and other current status of open source SOA and future projections here. In particular, we see the convergence of EAI, SOA, BPM, EDA and CEP into a set of integration styles that may be implemented using a common platform - the 2nd generation ESB or SOA Platform. A flexible platform like this is a more cost effective and simpler (reduced to no need for separate architectural bases for EAI, SOA, EDA, BPM, etc...) way to implement an agile IT and enterprise in the future.

 

 

 

I met Bruno when he was a customer of JBoss, Inc. back in 2005 at JBossWorld Barcelona (Spain). As a customer, he was a leader in adopting open source for high value SOA projects. As a colleague at Red Hat, I continue to enjoy working with him. Presented below is an interview with his perspective as a user/customer of open source for SOA.

 

Bruno Georges was Enterprise Architect and Head Of Development for a privately held, major global company in the Oil & Energy industry, of over 10,000 employees with over 140 billion dollars in yearly revenue. Today, as a senior technical manager at JBoss, a Division of Red Hat, Bruno Georges offers some insight into real-life business factors that cause CIO's to choose JBoss.

 

Q: Bruno, what was the business need for the project. Why change at all?

 

The majority of our IT budget was spent in maintenance, rather than investing in added value. The primary challenge was raised during a global meeting we held on SOA adoption. Growing complexity resulting from integrations meant budget spent in re-wiring and maintaining multiple source of “business knowledge / business rules” and corporate processes. We were suffering from duplication of these processes, and running the risk of accidentally not updating one of them. It was getting too dangerous: we urgently needed to reduce time to market, decrease risk through exposure, and protect ourselves from wrong financial reports and statements.

 

Q: What kind of new services were needed?

 

Integration Services really, ensuring that services were decoupled from each others, with well-defined boundaries. The integration service needed to take responsibility for validation, routing, transformation, and enrichment,etc.. before forwarding this to our core business services, for example, accounting, treasury, trades, etc.

 

The company's core applications and systems relies partly on Enterprise Java. These applications rely on a Service Oriented Architecture (SOA) , where coarse grain interfaces to Accounting, Treasury and Commodity Trading systems can be invoked over the network.

 

The business challenge revolved around migrating these Core Business Services from one Enterprise Java platform to another without any noticeable downtime, loss of performance, assuring data integrity and more importantly, without affecting financial transactions like trading activities, currency hedging, etc. Other business challenges included planning, where it was crucial to run the migration project without disrupting any existing deliverables.

 

Technical challenges were encountered during the planning of the migration, such as managing the dependencies of the services to migrate, based on whether or not they were using vendor-specific features. The aim of the migration was that it should bring equivalent - if not better - performance, quality and stability.

 

Q: Was there a particular desire to employ open source technology? If so, why?

 

We initially identified that we needed to implement our S.O.A. plan at the lowest cost, and with minimum risk. Then the question was raised of whether to use alternatives to commercial products to follow our SOA initiatives with minimum risk and expenditure. It was from identifying these specific requirements that we decided to seriously assess open sources alternatives such as JBoss.

 

Total Cost of Ownership was a main concern. Moving to a company-wide SOA implementation based on proprietary solutions (i.e WebLogic) would have reached 7 digits, especially considering that we were in the middle of a hardware refresh cycle, moving away from 1-2 CPU machines to 8 core Sun boxes.

 

Q: How did the project happen in terms of actually getting it underway?

 

First I arranged a meeting with (JBoss CTO) Sacha Labourey to discuss how we could approach this. We then decided to go ahead with JBoss's 3-Day Assessment offer. From this point we decided to further extend the assessment to come up with a more accurate picture of the resource and planning involved. In the meantime we also assessed local providers and partners like HP and Syseca to identify who could lead the migration and support us afterwards.

 

We hired JBoss professionals and Red Hat Partner Syseca to support us during the migration. Careful planning and regular reviews were conducted to prevent any issues and conflicts with existing projects or deliverables. Few internal resources were involved to reduce impact on daily activities and existing projects.

 

The Services forming our SOA have been migrated in 2 steps, the first one being a small and fairly low risk application, so we could give our engineering and operations some production experience and start building a new support and monitoring infrastructure using JBoss ON.

 

Technical issues were addressed directly with JBoss using the Customer Support Portal. We were really impressed to see JBoss's leading developer and guru Scott Stark getting involved when things got difficult.

 

Q: Why was JBoss technology considered?

 

The maturity of the product was important. and of course, the low price! But other things were especially important, too - like the local and global availability of JBoss expertise (Partner: Syseca), Because I was working for such a huge company, Red Hat's global presence was critical.

 

Q: What solution was finally decided on? Did this result in any savings? Any efficiency advantages?

 

The vendor selected was JBoss, due to its impressive market share, product quality and support offering, of which there is no equivalent in the open source application server landscape.

 

JBoss Enterprise Middleware provided a consistent open source platform and choice of tools to build our new infrastructure and applications. Also it offers a comprehensive set of products and a clear roadmap to support our SOA and ESB (Enterprise Service Bus) initiatives.

 

Q: How long did the project take to deploy?

 

There were two phases: the first one took three months, and the second and final phase was completed six months later.

 

Q: What was the most interesting aspect of the project, from a business point of view?

 

There were many examples, but one thing I especially noticed was time-to-market in an M&A situation. For example, we could now - and did - integrate very quickly with a company which had totally different accounting systems and technical / developer resources. The time-to-market to integrate two totally different platforms (.Net and Java) was dramatically reduced by the use of simple industry standards. What's more, we were able to confirm and validate the in-built functionalities and logic as we progressed. Validation of these milestones was even built into our migration contract, in order to contain, measure and insure against any business risk. This could then be prototyped with minimal effort and in less than one day. Unbelievable! No change was needed in our application/ implementation, or within the infrastructure, and the protection of the existing investment allowed full re-usability of existing infrastructure and resources. To be specific, we did not alter existing IT landscapes, hardware, or business processes, which was great. Another example is where jBPM helped us to reduce the development life-cycle, and allow business analysts to interact with the developers at the “right level”. i.e, the process definition.

 

Q: How did the JBoss solution improve the business bottom-line?

 

The great thing about an SOA project is that it brings business stake-holders together to agree on common corporate business policies, processes and rules. Long term business benefits will include removal of license costs on commercial products [through Portal and Integration solutions], and significantly reduce our capital expenditure. In addition, rollout of new business processes became a much simpler exercise, including analysis, implementation and validation.

 

Q: How was business improved as a result of the new deployment?

 

The first benefit was financial. We moved away from WebLogic products to JBoss Enterprise Middleware, saving up to six digits yearly. As a result, I was then able to invest more into staff training and development, technology, intellectual IT assets, and other high-value areas.

 

Executive management can now add more requests for the next Financial Year, and will see that resources are allocated more efficiently. IT department gained credit with the companies business folk. Perception is better, business sponsors become confident that IT is investing in the right direction, and subsequently become more ready to sponsor such changes.

 

Q: Any advice to other companies considering JBoss Enterprise Middleware?

 

Go ahead, don't wait. The longer you wait, the harder it will get.

 

 

Filter Blog

By date:
By tag: