Staffing for SOA Success Janesville WI

provided by: 
Originally published at Internet.com

Just as SOA is changing the way business and IT interrelate, it is also about to transform the types of people who work in IT.

This is because service orientated architectures (SOA) basically transform the IT department from a transaction-oriented cost-center to a change-agent. SOA does this by making business leaner and more agile while, simultaneously, cutting costs and wringing ever more value from existing infrastructure through the reuse of past investments.

But, to make this happen requires looking at IT and the business it serves in more holistic ways. And this, although changing from days past, is not IT's long suit.

"To make SOA really successful it can't be about just building technology, it's got to be about solving business problems," said BEA Systems' Paul Patrick who is vice president and chief architect of its SOA infrastructure product, AquaLogic.

From a technology perspective, SOA is comparatively straight forward. If you have a mature IT department with some depth of skills, then the technological portion of your SOA implementation-wrapping data in XML, setting up SOAP calls for Web services, setting up your registry and repository, etc.-should come pretty natural.

The hard part is seeing things from a big-picture perspective and, unfortunately for those who will have to deal with it, the politics of moving your line-of-business users used to consuming dedicated IT services towards a model that, at its heart, is all about sharing.

"The most important skill, which is going to be new to IT professionals, is they're going to have to shift their thinking and their ability from being very technology and product focused to becoming much more (business) process centric," said Marianne Hedin, a program manager at IDC.

This is where new blood may be needed to get your SOA initiative off the ground and make it successful.

Key to this effort is having a systems' architect on an SOA team set up specifically to tackle the larger, enterprise-wide issues that will inevitably come up:

* Who is going to have priority if shared services get bottlenecked? * Who's budget pays for new hardware and software if the services are going to be rolled out company-wide? * How will SOA affect the business as a whole? * Who's responsible for re-organizing IT into a service-delivery business? Etc.

"It's, in many ways, a micro view of the problems sitting at Homeland Security where you've got 17 distinct agencies all trying to act as if they are one big thing but their culture has been, 'I've got my world, you've got yours. Why should we share?' That's the hidden problem," said BEA's Patrick.

The ideal solution, is to set up a team led by the CIO that includes a business analyst who understand both IT and the business processes it supports (not any easy person to find by all accounts); a system's architect that can turn business concepts into IT-speak and ride herd over the infrastructure in order to minimize unintended consequences; and representatives from each of the company's lines of business.

This last is particularly important to a successful SOA transition, said Chris Warner, Software AG's director of Technical Marketing and a member of SAG's SOA competency center. Without executive buy-in and sponsorship of the changes wrought by SOA, it will most likely, at least in part, fail.

"It's kind of important that you have an executive sponsor for any new initiative," he said. "In the case of SOA, the way that works best is if you can tie that initiative to something the executives already care about. In other words, not SOA for SOA's sake."

Other team members can come and go, such as programmers to explain different concepts, but the core members should be charged with smoothing the feathers sure to ruffled by the wholesale changes SOA can bring and making sure that whatever individual processes that are served up by your SOA do nnot implode the entire system.

"A lot of people think SOA and they just think just technology," said BEA's Patrick. "Our experience has been that if all you do is take a technology approach to this problem Â… you can do a really great job and quick hit a wall."