| By Thaddeus Marcelli | Article Rating: |
|
| August 18, 2008 11:00 PM EDT | Reads: |
2,538 |
Over the past several years, there has been much fanfare regarding the promise of SOA. However, as with any IT-related solution, it is not a magic bullet or cure-all for IT integration. In fact, SOA does not solve business process problems, but rather identifies both the good and bad organizational processes. In most instances, SOA will require additional front-loaded costs until a critical mass of services are developed for reuse. It will require organizational and even process
changes that will demand high levels of training, funding, and organizational governance. Even with these challenges, adopting an SOA methodology is recommended.
Building a successful SOA Governance organization requires the attention to assets and capabilities across all service domains or high-level categories of services. Domains typically can focus on a major entity, e.g., customer or employee, the intersection of two entities, or smaller partitions like product pricing. SOAG is an extension of IT Governance, which focuses on the decision rights and accountability framework to encourage desirable IT behavior.
SOAG also balances enterprise needs and departmental goals to create a framework for delivering service-oriented business solutions. It defines individual and group responsibility, accountability, and a structure for identifying, amending, and enforcing governance policies. Conversely, developing SOA without a defined governance model could lead to less-than-desired outcomes. There are the obvious sunk costs associated with the resources, hardware, and software used during the trial and implementation phases, but it goes beyond financial loss.
One of the most efficient means to execute against an SOA Governance plan is to institute an SOA Shared Service Center (SSSC). Generally speaking, a Shared Service Center provides a centralized way to coordinate all SOA-related activities among team members efficiently. It also provides a way to enforce governance processes very similar to the way police enforce state and city laws.
SOA Shared Service Center Rationale
The argument could be made that creating a separate organization to support the SOA Governance program is too much. Those making this argument believe that resources spread across existing organizations could be as effective. While this can sometimes be true, it greatly depends on the scope and goals of the SOA program. The approach still requires a strong central coordination point with managerial power over a variety of resources with differing levels of responsibilities, priorities, and time. It has been found that in most organizations there are many good reasons to establish an SSSC.
Fulfill Customer Needs
A customer can be defined as any individual, group, or organization with SOA environment dependencies as either a consumer or provider. It is significantly easier for customers to contact one entity or unit that can consult, develop, guide, and support their SOA needs rather than having to communicate with a variety of individuals with no set guidelines or centralized, consistent communication back to the constituent. A single point of contact simplifies communications as the SOA Program matures.
A simple analogy is a call center where there is usually one phone number and a set of options to choose from once connected. This model is significantly easier than having to dial a different phone number for each individual problem.
One thing to always remember is that success sells. Success for SOA comes from being overly attentive to constituents and ensuring that their concerns are addressed, deadlines are met, and expectations are exceeded. It is also important to document the successes, issues that were overcome, and the expected returns in order to communicate results back to the enterprise. This communication with customers and prospects fosters adoption and raises awareness of the importance the organization is placing on SOA.
A decentralized team will not be able to do this as easily because they are not concentrated on the same set of goals and values. As a result, customer service will suffer, hindering SOA adoption.
Published August 18, 2008 Reads 2,538
Copyright © 2008 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Thaddeus Marcelli
Thaddeus Marcelli is a principal SOA srchitect at MomentumSI. He has many years of practical knowledge in the SOA framework space and has faced many SOA implementation challenges.
- Cloud CEOs, CTOs & SVPs to Speak at 4th International Cloud Computing Expo
- Kindle 2 vs Nook
- Why IBM’s Server Chief Got Busted
- The Difference Between Web Hosting and Cloud Computing
- Cloud Computing Journal Opens "Readers' Choice Awards" Nominations
- Cloud Computing Expo: Exclusive Q&A with Yahoo! SVP Cloud Computing
- Industry Experts Discuss the State of Cloud Computing
- Ajax in RichFaces 3.3, JSF 2 and RichFaces 4
- It's the Java vs. C++ Shootout Revisited!
- The End of IT 1.0 As We Know It Has Begun
- An Introduction to Abbot
- Java Kicks Ruby on Rails in the Butt
- Interviewing Java Developers With Tears in My Eyes
- Cloud CEOs, CTOs & SVPs to Speak at 4th International Cloud Computing Expo
- 1st Annual Government IT Expo: Call for Papers Deadline July 15
- How to Diagnose Java Resource Starvation
- REA Is Where RIA Becomes the Norm
- Kindle 2 vs Nook
- Anatomy of a Java Finalizer
- Why IBM’s Server Chief Got Busted
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- The i-Technology Right Stuff
- JavaServer Faces (JSF) vs Struts
- Rich Internet Applications with Adobe Flex 2 and Java
- Java vs C++ "Shootout" Revisited
- Bean-Managed Persistence Using a Proxy List
- Reporting Made Easy with JasperReports and Hibernate
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate
- What's New in Eclipse?





























