<<Service-oriented architecture (SOA) development is not your father's IT project.
The differences between SOA and yesteryear's application development changed the way departmental stakeholders think about their roles in the process, says Gary Cripps, vice president for finance & information technology at the Delaware Electric Cooperative, which provides power to the state's two more rural counties. Having worked through several SOA projects involving not only IT, but representatives of departments including engineering, customer service and accounting, Cripps said it took time to understand the uncharted territory they had ventured into. "At some point the realization dawns that this isn't just another IT project," he said. "This is more about enterprise efficiency, and this is a strategic direction for what was before a tactical engagement. It's critical to get input from each and every stakeholder. There's a lot of detail in doing SOA." For all the stakeholders to have their voices heard and their participation encouraged requires executive support for SOA, which Delaware Electric had, Cripps said. He got all the departmental representatives to sit together around a table and work through issues such as who owns what data, as well as the realization that SOA was going to require some people to learn new skills. Of the change SOA makes in thinking about data ownership, Cripps said, "Our engineering team is a perfect example. They looked at the integration of their applications into customer relations systems and accounting systems as almost an invasion of their data. It was their data and it wasn't enterprise data." Eventually, all the departmental people came to understand the enterprise nature of SOA and began to view sharing data in a positive light, he said. "You get through a couple of those things and everyone becomes a believer," Cripps said. Another revelation for members of the SOA team at the power company, he said, was that new skills were going to be required for the new approach to application development where it is important to think in terms of business processes. The team had discovered that a change to a process that seemed to be related to only one department, could, in fact, impact as many as 12 cost centers in the organization. "We realized we were babes in the woods in terms of this whole process identification piece," Cripps said. "When we got into SOA, we really learned that we didn't have the expertise from A to Z in any one individual. So it became much more of a business organization effort to do that because we needed to comprehend what all of the processes were. We couldn't leave out any of the details." That revelation led to assigning one team member to take charge of process management and sending a team member to business process modeling training. The importance of focusing on business processes in SOA development became clear to Cripps as he reviewed the metrics on the first projects. To understand the processes that will become part of the new SOA application, the team at Delaware Electric first identified them in what they term a "statement of work," he explained. The statement of work might be that data needs to be pushed from a field engineering application to the customer information system and then on to the accounting system. "Once I have that statement of work and I start breaking that down into all the processes," Cripps explained, "what we found was that, in an SOA engagement of this magnitude, we spent 55 percent of our time defining the processes. Fifty-five percent, I found that pretty amazing. Twenty percent of our time was in coding. The remaining 25 percent was in testing and implementation." This is one of the major lessons learned that he is sharing with other small and medium sized power companies around the country. The difference between the previous generation application development and SOA is that the emphasis needs to be on identifying and modeling the business processes. Coding then becomes secondary. This is good news for small and medium sized businesses contemplating SOA, Cripps said. Business process identification and modeling can be done within the core team that includes the departmental stakeholders, but the 20 percent of the project that is coding can be outsourced. Noting that he cannot hire his own army of SOA developers, Cripps said, "The hard science the coding was really the smallest part of the project. That was really a revelation." Since coding isn't the major effort in SOA, he outsources much of it to IBM and its partners, saving the cost of hiring high-priced coders. In-house, the SOA team members have changed their way of thinking about applications in terms of business processes, Cripps said. "When we went with service orientation, as far as my team members were concerned, it really elevated their knowledge because it took a significant effort to understand the business processes and the business rules through multiple departments that would be involved in a particular transaction," he said.>> You can read this at: http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1307332,00.html?track=NL-110&ad=630798&asrc=EM_NLN_3371091&uid=5532089 Gervas
