As we move from just thinking about SOA to just doing it, now is the time when the real work gets done. Thus we are working through the issues as well. In some cases, the projects are on schedule and on budget. In other cases, they are in "SOA project hell." Let me see if I can help.

First of all, you need to understand that, in many instances, a SOA project breaks new ground within your enterprise architecture. Therefore, a few issues will arise as you go through the initial learning curve. Second, while there are many consultants out there who sell themselves as "SOA Experts," most of those guys, even the big consulting names, don't yet understand what they are doing. Thus, you can find that they take you down the wrong roads while you pay them $5K a day. Finally, the fundamentals around project management still apply. Those who forget that fact soon discover the failures apply as well, but it does not have to be that way.

While the project problem patterns are far reaching, I've identified a few key issues. They are:

• Not enough budget
• Not enough influence
• Wrong people
• Bad schedule
• No plan, approach, or method
  

Not Enough Budget
While all who run an IT project will complain about a lack of money, there is a huge difference between running project too lean and not having the resources you need to be successful. SOA is strategic, it's expensive, and those who think they can drive systemic change with the existing architecture on the cheap are in for a rude awakening.

Most Global 2000 companies will find that their initial SOA project or projects will run into the millions. However, when considering the ROI of having a truly agile architecture, that's the bargain of the century. The trick is to determine the value of your SOA first (the return), and then the real dollars required to do it right (the investment). From there you can make the appropriate business case, and thus the required budget.

Not Enough Influence
One of the major mistakes that those who drive SOA within their company make is to accept the responsibility to do a SOA, but then they do not ask enough questions about authority. Truth-be-told, if you don't have the political juice, you won't get it by declaring that you're the SOA people, and you're here to help. Indeed, the opposite will likely occur. You'll be asking to change a systemic architecture, but have no power to influence anybody. You'll be easily ignored, and thus ineffective.
To counter this, you should insist on having enough authority to get things done. This typically means budget authority, and the C-levels are reluctant to grant you that power. I would not do a SOA project without it, and I would give you the same advice.

-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 Customer Management
• BPM for Financial Services
• BPM for Government
• BPM for Healthcare & Insurance
• BPM for Supply Chain

• 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