I knew this was the right path.
Some research was carried out on the Service Oriented Architecture (SOA) type of software delivery model. Click on the title of this entry to be taken to the research web page. This article suggests the odds are against us with only a 20% success rate in the SOA business model. It also provides a guide as to what we are doing correctly. And I think a clear understanding of where we need to move to in order to achieve the success that we are expecting.
What are we doing right;
Failed SOA projects get too focused on the means rather than the end. The failure to focus on business goals is a problem and focusing on them is the solution. There is sometimes a failure to ask the most basic questions in building the business case for SOA. Why should we be building services? What does it mean at the end of the day?... While one of the business drivers for SOA is reducing costs and achieving return on investment (ROI), ROI for SOA remains an elusive goal and SOA project leaders frequently take a leap of faith where ROI is concerned.People, Ideas & Objects is about identifying and supporting the industry standard Joint Operating Committee (JOC). Aligning of its financial, legal, operational decision making and cultural frameworks with the compliance and governance framework. Compliance and governance being the sole domain of the bureaucracy, the separation of operational decision making and compliance and governance is a recipe for disaster. Nonetheless, the stated objective of this software development project is to enable;
"This community, using this software in their own service business offering, will be the method and means that the oil and gas producer will conduct its most profitable commercial operations."This is not about the technology. It is not about project management. Although this project uses these two disciplines to achieve the stated objective. This is about getting the business of the oil and gas producer in alignment with the rapidly changing earth sciences and engineering disciplines. This alignment facilitates innovation and enables the oil and gas producer to keep pace with the changes in the underlying sciences.
and
Here we have a mixture of opportunities and problems. Item #'s 3, 4, and 6 are in place in my opinion. Item # 1, 2, 5, and 7 are hitting on the one area that has caused this project to struggle, money and trust. This may be a short term problem as the community involved in this software development continues its logarithmic growth in the U.S. I fundamentally mis-trust the companies I highlighted in my review of stock based compensation. These little piggies attempt to steal this project from me during September 2003 and April 2004 has left a bad taste in my mouth. As such I will not miss them. I however am willing to fully participate with the U.S. and British based industries and any other region that wishes to participate. We have much to do, and as you may have guessed, I have a driving passion for this project.
- Business and IT reorganization, usually with a new CIO coming on board
- Sponsorship at the C-level or by the Board of Directors
- Agile/iterative development methodologies put into place
- Projects tied to and measured by business goals, not IT drivers
- Well-defined funding and maintenance models that balance the needs of service providers and consumers
- A simplified architecture, making it easier to access and manage quality data
- A culture of trust between business and IT
With that in mind I am frankly grateful for this next set of recommendations.
I have a fear of the issue that these points intimate. We don't need to follow any blind bunny trails and desperately need to keep the focus and tract of development in-line with the needs of the producers. However, we need the resources to build this project. If as I suggested a few weeks ago the scope of this project might be in the billion dollar range, over probably four years. The smooth application of the financial resources over the life of the project is the obligation of the collective group of project sponsors. This project needs to be managed on a basis that delivers the application with these constraints and difficulties in mind. This I will diligently work toward.
- Define the business cases clearly. If you can’t, don’t do SOA
- Empower those who need to drive the systemic change that SOA requires, typically, with the money and the authority to do something. Else, don’t bother. You need to control the money and be able to fire people if this is to work in a reasonable amount of time. Otherwise, you’re in endless meetings with people who have agendas that don’t include rebuilding the architecture for agility and reuse.
- Think long term and strategic, not short term and tactical. It’s okay; things won’t collapse as you move from a reactive to a proactive mode. Indeed, that’s how companies win their markets.
- Start small, but keep the momentum going. Small battles win the war, and little by little the architecture will get better if you just keep moving the ball forward
Which leads me to reiterate the value proposition of this software development project. The costs of development are allocated to the producers on a "per barrel of oil / day" basis. These costs are incurred plus a percentage of those costs for the project. The costs therefore are a small percentage of what the license costs of SAP or Oracle. Once the project is released in a commercial offering the costs of supporting and further developments will be handled on the same basis.
This article brings out another point that was assumed but never identified or communicated. The SOA model within an oil and gas company doesn't provide the value an industry focused SOA solution does. Does this mean an SOA denotes that it is an industry focused solution? I think it does and it seems this research indicates that conclusion may be valid.
Technorati Tags: People's Architecture Knowledge Learning Research