SOA represents a brave new world of system design. The business benefits - increased reuse, reduced time to market, and lower total costs of ownership - are often touted by vendors and analysts alike. A major challenge remains that the technical aspects of SOA - WSDLs, schemas, and the like - are often much easier to articulate and implement than the organizational and process methodologies associated with how you actually achieve SOA.

Structure and governance help to guide the people, processes and applications that make SOA successful. As with any emerging society, the participants within an SOA environment need a common governance framework that provides the rules of engagement, in order for everyone to reap the associated benefits.

As we talk with IT organizations, too often we see them making the same mistakes, pushing forward with the technical aspects of SOA without considering the governance implications. Here are the most common mistakes we run into, and some tips on how you might avoid them:

Mistake 1: Decentralizing common artifacts

When common artifacts such as WSDLs, schemas or configs are scattered in various locations, organizations waste time searching for interfaces and schemas. This is because they lack a central authority for the published service interface, which discourages discovery and reuse across an enterprise.

Solution: A centralized authority

Creating a centralized repository or registry allows others to more easily reuse artifacts and utilize an authority for what services, schemas, and applications are available. It also enables an organization to track not just what is available during design-time, but also what services are running in production. More often, an organization must mandate the use of a registry or repository otherwise it will be ignored and no SOA benefits will be realized.

Mistake 2: Reinventing the wheel

In the typical decentralized IT organization, services and applications are often written again and again to perform the same function. As a result, many different versions of the same artifact are built and integrated, increasing development times and creating a huge maintenance cost burden.

Solution: Collaborate and recycle

The way to avoid falling into this trap is simple. Share requirements and collaborate on building artifacts. Reuse applications, services, and artifacts whenever possible and use a centralized repository or registry to store information, discover existing services, and collaborate on new ones.

-1-

Explore Our Topics

• BPM & Enterprise Architecture
• BPM Standards
• BPM Implementation
• BPM Best Practices
• Cloud BPM
• Continuous Process Improvement
• BPM Governance
• Service Governance

• Business to Business (B2B)
• BPM for Supply Chain
• BPM for Customer Management
• BPM for Financial Services
• BPM for Healthcare & Insurance
• BPM for Government

• Business Activity Monitoring
• Event Processing
• Process Intelligence
• Business Rules Management
• Decision Management
• Operational Intelligence

• Workflow Automation
• BPM & Enterprise 2.0
• BPM & Web 2.0
• BPM & ECM
• Case Management
• Collaboration
• Enterprise Portals
• Social BPM

• BPM & Cloud Integration
• BPM Analysis & Optimization
• Business Process Simulation
• Process Visibility & Monitoring
• Process Orchestration
• Process Discovery
• Process Modeling

Home
Webinars
Blogs
ebizQ Forum
All Topics
Subscriptions
White Papers
Analyst Corner
Follow us on Twitter
Fan us on Facebook

Explore Our Topics

BPM Strategy
BPM Solutions
Event Processing Strategy
Content-Centric & Collaborative BPM
Process-Centric BPM

About Us
Editorial Submissions
Feedback
FAQ
Advertise With Us
Site Map
Privacy Policy
Unsubscribe