For the past several years, I have been involved in many healthy discussions centered around the benefits of adopting technology and its supporting tools and infrastructure. Never once had I ever thought of measuring the benefits in terms of tonnage of hardware or in kilowatts per hour (kW/h).
In David Linthicum’s recent blog on “Is SOA Green” , he makes the point that “the more efficient a business is, the fewer resources, natural and otherwise it will consume. Thus, the better the business is automated, and business processes optimized, the more efficient it will be. The primary of objective of an SOA is both efficiency and agility through architectural rejuvenation”
In light of all these things coming together, and in the spirit of “going green”, I would like to tell you about a concrete example in an exciting account of one of Oracle’s customers, Verizon Wireless, who is in the process of going green by rewriting their fraud detection application using SOA, EDA, and Web 2.0, and as a result plan to eliminate 6 tons of hardware from their datacenter, and reduce power consumption by 99.5% from 200 kW/h down to 1100 W/h.
From a software and architecture perspective, this is an exciting story about how Verizon Wireless is building a new Fraud Detection application which uses Event-Driven Architecture (EDA), BPEL process management, a business rules engine together with a Web 2.0 style Flash/Flex UI to build what would be referred to in financial services as a straight-through processing application.
In the process of doing this, they are dramatically reducing the amount of code that has been written, and the amount of data that needs to be stored locally. As such, they plan to eliminate 6 E-class Sun boxes using ~192 processors and replace them with a single 8 core processor on a Sun UltraSPARC T1 using the Niagara chip architecture.
The old application is based on J2EE using what was available in the mid to late 90’s. It happened to replicate the entire data warehouse of call detail records for use by the fraud detection application. It also had a lot of procedural custom code that was hand written by 5 FTE over 2 years, some stuff that was ported from Forte to J2EE, and 100s of JSPs feeding (circa 1995) html 3.0 pages with data.
I plan to provide more detail about their service architecture in the future, but here is the basic outline of the new application structure:
The BPEL process invokes a number of services, which includes going out directly to the source of the call detail records to get the information necessary to enrich the event data. It is then fed into a rules engine to check for violations, make decisions based on policy, and then on to generate more detailed reports. (This is the SOA part of it)
So, back to the “going green” part - They are working with a third party energy consultant to produce the final number on energy reduction once they go into production (they are in UAT stage now), but here is their best estimate given what is known today.
I’m no expert at cooling system requirements, but I have heard the rough calculation for power consumption of cooling systems range from 1.3 to 2 X the amount of power consumption of the hardware, so the numbers should really be 200 kW/h reduced to 1080 W/h. Its still a 99.5% reduction in power usage.
Of course I can’t attribute 100% of the impressive results to adopting SOA. There are lots of things that contribute to the reduction in footprint, such as the massive rewrite and the introduction of more powerful hardware and chip technology (I’ll leave that writeup for SUN to have their own day in the…sun). However, I can point out some things that are obvious and significant -
It is often said that the best line of code is one that you never have to write. The new implementation is 0.5% of its original size. This is directly attributable to using BPEL and the rules engine instead of their custom code. They also went from 5 FTE down to 1 consultant who built 40 - 50 BPEL processes over the course of a year. The result is more flexible and resilient to change as it is declarative and UI driven rather than being hard wired into custom code. Their presentation tier code also went down to 0.5% of its original size by moving to 1 JSP and 1 SWF for rich UI.
The other significant contributor to the reduction in footprint is due to the nature of modern SOA standards and supporting infrastructure such as BPEL and ESB, which allows Verizon to extend the reach of their systems so that they don’t have to store their “golden record” call detail data locally. They can get the data remotely and on the fly, and use enrichment services along the way to get the data in the proper form to be make decisions about fraud and overage, and generate detailed reports about the business exceptions that are identified. This is huge for them in that they no longer have to replicate the data warehouse, but are able to pull call records and other information directly from external heterogeneous systems.
BTW, in David’s blog he also points out - “Thus, with gas approaching four bucks a gallon, I made the shift from an SUV that get’s 11 MPG to a crossover that gets 30 MPG“. I’m still in the process of shopping around to make that shift…but I have some time since summer is here and my Harley gets 44mpg!