[See intro notes to my first post for what’s going on here.]
David Gai (moderator), Scott Metzgar (CTO True Credit), Eric Peebles (Application Architect City of Chicago), Colin Karsten (manager, Pratt & Whitney)
Scott Metzgar, True Credit
Web app for consumer credit problems. SOA based…driven by re-use needs. Partner with Providian, CitiBank, Motley Fool, and Chase. Intel Itanium, Red Hat, BEA JRockit. 25,000 users. 5 week release cycles. We’ve been able to scale out software with BEA.
“It truly was a product vs. a consulting activity.” 3 years into production/project of switching over to BEA platform.
Dev cycle is 2 weeks to 3(?) months.
Eric Peebles, City of Chicago
Delivering services to the citizens. First (early 1999) had large silo’ed systems for each cluster of services — billing, assistance, registrations.
Found that systems needed to exchange information. It was “accidental architecture.” Many options surfaced: “something email, FTP.” But we wanted other ways, like making the info available online to enable self-service for end-users…instead of waiting inline [I bet the story of how Texas did online driver’s license renewal is interesting. I’ll have to look around for that.]
BAAM! Enter SOA. The city’s IT growth is slower than private sector. Needed platform that could support us, not take too much training, and use the small number of people we had to deliver web based services for citizens quickly. And who did they choose? [I’ll give you a few seconds to wonder]…BEA.
Delivering services…now we can look at businesses and deliver more services…generate more revenue for the city, e.g., 20% incremental increase in vehicle registration revenue.
[If you make it easier for people to spend money, they will.]
Colin Karsten, Pratt & Whitney
Grew after-market maintenance business 50-100% annually over past 3 years. 3x customer satisfaction.
With airline company, for example, we’ve got 10’s of points of contact within different silos. We looked at portals way back when. Then we looked at SOA/composite applications. “ESN dot com” [not the real URL]: customers can type in the serial number of any engine made since about 1963, and you see a dashboard/composite app of all information available about that engine. [Pulling from info-silos.]
When engine is getting manufactured, data starts tracking, including customers. E.g., Japanese customer got a view into their engine over-hauls thanks to composite app. This causes the Japanese customer to increase satisfaction score.
Likes Fuego. I pulled back on my internal marketing about Fuego, because I saw such appetite from the execute team for it that I needed time to deliver.
David: how do you get funding for these projects?
Scott: in-depth analysis…what drove it was how we do the reallocation of budget. Off-load responsibility of maintaining [our own] middle-ware and software infrastructure. We moved that money into licensing, and can keep our org small and nimble.
Eric: always competition between departments in the city. Fireman, policemen needing new equipment, and then you’ve got me needing a new server. With SOA, our biz users were able to grab onto the key concepts, and they really understood that you need a biz process to drive your IT. Educating biz folks on what SOA is: there’s a bus there…the team that’s the bus driver…if they get on the bus, they get access to data and systems.
Colin: the model has changed quite a bit. We used to be the old taxing model: we got our funding from the IT bucket for a bunch of [line-item stuff]. President of commercial engines came to me and asked me to grab my 5 best people, and he wanted to fund us. [IT moved out the IT silo into the business silo! BAAM! Boutique programming in the enterprise! …what does that say about the SOA notions?]
Quality budgets are large in manufacturing. “Escape”: something bad that gets through the system. Execs get big dings for escapes. So execs pay a lot of money. Fuego is targeted at quality, so execs will pay for it out of their quality budgets.
Quick Wins
Colin: ability to go out and build these little mini-apps and portlets. Customers wanted to look at the inventory in the shops…so they built a little Java applet/portlet that pulled info from SAP.
Scott: payment engine/service. Once we built that service, we could build out 12 other apps that used it. Biz people liked this, of course. Kept projects focused on small projects that focused on what we knew and our skills, and slowly built forward.
[On the screen composite apps.]
Scott: incremental as well. Proving it, then building on success.
Why BEA?
Scott: we knew the SOA stuff we wanted, and we could validate if vendors did SOA in a way that was useful to our biz. We liked that it was all in the stack from one vendor: O/R mapping, XML transformation, workflow engine…this is back in 2003. Since then with acquisitions and development, BEA strategy is aligned with our company.
Eric: look at what we had. Keep it focused, and do the things we can do well. We didn’t want a lot of different products, but we wanted good enterprise class products.
If our teams have best practice/industry knowledge, they can pick up BEA fast. [Does the “blended approach” feed into this, or was that way before OSS+BEA?]
One beck to choke, and that’s BEA’s, but I’ve never had to choke it, because they’ve come through.
Colin: with BEA, you won the bake-off. Divisions come up with their requirements, and you run it all, and the winner is usually the pick.
“The perfect addition to the portal was Fuego. Last night I recommended to Alfred one more thing, and we’ll see if he does it.” Liked Fuego acquisition because it puts both products under one roof. Better than dealing with two vendors.
[Tension between developers wanting to use lots of stuff, and managers wanting one vendor. “We don’t need a perfect solution, we want as few vendors as possible.” Is that often captured in requirements?]
Eric: …people worried and scared about technology. But with BEA’s success, we’ve built up the trust that technology can be delivered. The biz people then enjoy working with IT, and IT enjoys working with them.
Performance and Scale
David: What performance stuff do you expect from BEA?
Scott: the support organization is “honestly one of the main reasons that we remain a BEA customer.” With one vendor, you have the advantage that everything was designed to work together.
In our scaling out, we’ve been doing some testing with Azul, and BEA has been effective in that partnership.
With credit reports, we have a Federally mandated SLA that is not negotiable. Sense of trust in BEA to help with that.
Future Plans?
Colin: two dudes on Fuego. Sending sensor and video data from remote sites to engineering at HQ so the engineers can check it out and say it’s good. Those are the two 06 focuses.
Eric: “focused on building an environment that allows us to deliver data” more openly. Looking at what we have to (1.) drive revenue to the city, and, (2.) help out businesses with what we have.
Scott: support same rate of growth. Big investment to have scalable website…what we found building partnership network is that there’s still a huge off-line market: mailings, async, human based request/response. So, integrate with the legacy methods for paper-based delivery of credit reports. It’s causing us to evaluate additional BEA products.
[More Franz?]
Disclaimer: BEA is a client, and paid for me to come to this conference.
Recent Comments