 | |||
|
|
||
| |||
| |||
| ||||||||
|
|
|||||||
|
|
|
|
| SAP administration / development News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
There has been a great deal of discussion on the need to better align business with IT in order to successfully implement service-oriented architectures (SOAs).
While many developers agree an SOA should ultimately cater to the needs of the business, there are differing opinions on how exactly this should occur. Should a top-down, business-centric approach be employed or a bottom-up approach, in which the Business Unit (BU) is more reactive and sensitive to the realities of IT? In John Crupi's Weblog, the chief technology officer of enterprise Web services practice at Santa Clara, Calif.-based Sun Microsystems Inc., said that SOA is a business-driven architectural style, and for it to be successful, it must employ a "top-down" approach. The BU should own the business drivers, use-cases and processes, according to Crupi. It is then IT's job to implement the BU requirements and own the service definitions. Crupi advised against using a "bottom-up" approach to SOA development, in which existing systems are simply wrapped using Web services to create a service layer. Crupi, who has worked on large projects such as the re-architecting of the eBay 3.0 application, has had many discussions with customers who have failed in their attempts to weave their systems into an SOA by simply wrapping them in Web services. Taking an existing asset or system and making it a Web service creates an immediate mismatch between the new Web service interaction style and the existing system, Crupi said.
Meanwhile, J2EE [Java 2 Enterprise Edition] architect Bill de hóra argued in his Weblog that the probability of failure is higher with a big, top down approach that has the ambition of spanning an enterprise. "The difficulty with a solely top-down approach is that there is no top," de hóra said. "SOA systems in reality tend to be decentralized - there's no one point of architectural leverage or governance." "The goal for any enterprise should be to wean off building big, centralized systems and focus on how to network smaller, more adaptable ones together," de hóra said. Business and IT – crossing the great divide "The reality is that IT and (the) BU typically function as disparate groups and rarely work together to have the business use-cases drive the process and service definition," Crupi said.
Evidence of this disconnect can be seen in efforts to implement Business Process Management (BPM) projects, according to a recent report from Cambridge, Mass.-based Forrester Research Inc. The success of a BPM project depends on how effectively the "top-down" and "bottom-up" cultures in an organization can be made to co-operate, according to the report. It said the "bottom-up" phenomenon occurs when implementers' resistance to change is driven by the fear of potential job losses. On the other hand, the "top-down" approach is the willingness of senior managers to forcefully drive process improvement amongst implementers, driven by the fear of "loss of authority." As BPM tools continue to mature, organizations are leveraging them to enforce business processes in their SOAs. SOA provides a sufficient level of abstraction which BPM systems can leverage to enforce a company's process definitions. According to Forrester, integrated suites for enterprise application integration (EAI) and BPM are empowering business users with the tools to develop composite applications, potentially replacing the need for programmers. SOA's middle way? Meanwhile, in his Weblog, Random Stuff, J2EE architect Stefan Tilkov offered a middle-way to SOA development, one in which a top-down, high-level vision and bottom-up, "quick-win scenarios" gradually converge toward each other. Tilkov suggested an adaptive software development approach that requires the BU and IT to continuously work together to optimize and refine business processes. "When the business people and the architects are thrashing out the documents and processes, you cannot have the programmers sitting on their hands," de hóra said. "They need to build something and show it to the business, so the business can ratify and refine what it's asking for." "A culture of continuous deployment and tending to front line services will help the organization infrastructure become robust to continuous requirements changes," de hóra said. This story originally appeared at SearchWebServices.com, part of the TechTarget network.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
 |  |  | |  | |  | |  | |  | |  | |  | |  | |
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
