 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > IBM's internal SOA governance implementation |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The experience from his first service-oriented architecture (SOA) implementation in 2002 still informs the thinking of John Falka, chief architect for SOA governance in IBM's internal software group.
That first SOA project now provides best practices for other IBM customers, he explained while presenting an early adopter case study during a recent Webcast titled The Keys to Business-Critical SOA. "I'm pretty familiar with this case study and the customer involved," Falka deadpanned as he began explain how SOA was first implemented at IBM The case study has value because the way IBM started out with SOA five years ago is not unlike how a company would begin by dipping its toe into service-orientation today. Falka and his colleagues didn't start out doing big SOA, they began with little SOA, as most consultants and analysts currently recommend for neophytes. "We started in 2002 with exploratory services doing things like proof of concept and technology focused projects, which were basically just testing the waters of how we can enable SOA and SOA governance," Falka said. In 2003, SOA still was not a mission critical project at IBM, but Falka's team began looking at what production services might mean for their company. And the next two years, SOA started to catch on at IBM, but it was still a tactical pursuit. "Moving into 2004 and 2005, we started to identify some opportunity projects that were good-fit projects with willing participants," he said. "But we were still in a bottoms-up approach to the enablement of SOA technologies and Web services." By 2005, the SOA team within IBM began using service-oriented modeling and architecture (SOMA) to identify Web services that could be reused in new applications. SOMA helped deal with a problem familiar to all large organizations working with Web services. Divisions within IBM were developing their own Web services that performed the same functions as Web services developed by other divisions. In other words, there was a whole lot of redundant programming going on. "One of the problems we were focused on, because it's always good to have something that you're focusing on, we wanted to eliminate redundancy of services and promote reuse within the IBM divisions," Falka said. Enter SOA governance. Governance started with identifying services as enterprise components so the same service could be used in multiple applications in multiple divisions. "We provided funding for the single build-out of a service as opposed to the multiple build outs of a service and raised the operational cost benefits of not having redundant services that were generating additional costs," Falka explained.
Governance at IBM became holistic covering everything from the creation of a Web services to how and when they could be used. "We ensure that we know who owned the service, who can use it and when it will be available, which is really important when you have so many service consumers," Falka said. Since most IBM customers do not have five years to develop an extensive governance model, Falka has developed a template for them. "We've incorporated best practices learned here into consulting methods and into SOMA, as well as into IBM's SOA Governance and Management Method (SGMM)," he said. "It is a full process for the SOA governance lifecycle."
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
