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.