Mike Kavis commented my posting on how NOT to justify SOA and ESB:
SOA can not be justified by a single project (unless the project is a huge reengineering effort). Implementing SOA should be a strategic, not a tactical decision. Nobody would recommend establishing an enterprise architecture to solve one project's requirements. The same should be true for SOA. SOA pays off in the long haul. That's why you have to go to the business with a portfolio of projects and a SOA roadmap. This is also why I keep screaming that you need to have BPM as part of your SOA stack. The business understands business processes, they don't understand ESBs.
I agree with him. Though, our problem is that the individual project leaders got ALL the power, even over the enterprise architects. And worse, they are supported in that by the steering committees (involving management). The enterprise architects are neither supported by a strong governance nor by an own chair in the management team. Do you feel the pain?
There is a lack of focus on long term pay offs, even - or especially - in the business. "Long term" doesn't exist anymore in our world. I possibly could get the hands together for "rapid change", but only if I can spell out these changes as I illustrated in my posting mentioned above.
To cope with this situation I recommend an innovation budget - or should I say a survival budget - assigned to an innovation project, where a dedicated and highly authorized project leader has the responsibility to implement an enterprise architecture, including SOA, and the organization of its life cycle.
Any other suggestions?
Posts
7 comments:
In my opinion the client (the project leader) should not be interested in how things are solved. He (or she) should only care that requested requirements matches the outcome and if the outcome is based on a SOA or based on a paper based system that should not matter, as long as it is conform requirements.
Since SOA is indeed a strategic decision it should be supported by the ones who has made this decision by financing the initial investment for SOA so the project leader does not have to pay extra for a strategic solution. The extra costs are most likely the issue of any project leader and if that can be solved, there is no problem anymore.
How would you get such a situation realized, Rick?
-Jack
Every culture is different. I can only speak for what I have seen in my company. But for years I have been pushing EA and SOA with little success. Nobody wanted to invest the time, money, and rigor that it takes to pull it off. Then we went to the business and gave them an ROI for reengineering one of their major pain points. They became interested. Then we told them that we thought there was a bigger opportunity if they reengineered their business processes. They agreed to do an assessment. The rest is history.
The business process assessment uncovered huge opportunities for cost reduction, improved customer satisfaction, incremental revenue opportunities, and more. Then we told them that a BPMS tool was the answer to their prayers. Next we told them that SOA would allow us to implement their BPMS solutions faster by leveraging our legacy applications as opposed to reengineering all of our legacy systems. We told them they could have projects delivered within the first year if they invested in BPM & SOA. They did and we did.
It's been quite a ride and it never would have happened without the business backing. The big take away is that we sold SOA to them without having to talk about ESBs, master data management, repositories, governance, and all of the technical stuff. All they needed to know is SOA allows us to hook up their new work flow enabled UIs to the years worth of legacy.
That's my story. I can't say that it will work everywhere but it worked for us. We have a 3 year roadmap of projects with a multi million dollar ROI.
Hi Mike, thanks for your contribution. You are right, every culture is different. We lack market competition, which stagnates the drive for innovation.
It is very interesting to hear how it works for you. Got any vacancies? ;-)
-Jack
I will second Mike's take on this. The only real ground I've managed to gain has come through a "BPM-first" approach.
The organization I worked in had several products with shared customers but separate-but-equal project/product management. The biggest wall was the one Jack identified: You want to blow my budget and timeline for some "for the good of all" architecture? No way.
The business stakeholders had to see the problems with how the time and cost of business process mgmt and change where multiplying before the "enterprise" budget got started. We started making progress.
Unfortunately, my story didn't end quite like Mike's. The enterprise budget got whacked later on in a tactical vs strategic round of decisions.
My two cents on the subject,
Bubba
Sorry Jack, I just saw your reply.
How the situation could be realized could (should?) be rather simple. The one who decides to use SOA as a strategic option should pay.
e.g. if an it department decides to go SOA, the it department should create (or get) a budget from a sponsor. The budget could be made available based on the planned developments for the other departments (these would expected to be lower due to the reuse of components in the SOA).
Perhaps we could talk about it next week, while having some lunch?
Let's do that, Rick. I am looking forward to it...
-Jack
Post a Comment