Director in LiquidHub’s Management Consulting Practice
SOA-infused development promises to provide a number of long sought-after benefits including reuse, reduced development time, and increased transparency between IT and Business Units. However, who should bear the costs of services that span the enterprise? The initial business adopter? Corporate IT? Or a combination of the two?
SOA technology deployments, by their very nature, are geared for reuse and assembly (Services assembled into Composite Services as well into new Applications). However, in the initial stages of SOA strategy, development, and deployment, such reuse is not yet possible. Both Business Units and IT are struggling with the most effective ways of funding initial Service creation. Based on the maturing of an Enterprise’s Governance capability as well as the Enterprise’s Operating Model, there are three main funding approaches:
1. Utility Model: CIO/CEO Identifies and Funds Keys Services
In the Utility Model, a centralized Governance body collects business requirements, sets priority and sequence of Service Development, and provides funding through a corporate budget. In such cases, the first services to be developed should be those that will most widely used or have the most impact across business units. Alternatively, the centralized Governance body may choose to fund a small number of “incubator” Services for the express purpose of gaining expertise in Service granularity or to gauge the impact of SOA on the Development Lifecycle. Companies with strong centralized development teams should adopt this model.
The Utility Model is also highly effective to show SOA progress and accountability to the Executive team and is useful in educating the Enterprise at large about the benefits of the SOA strategy; this leads to very measured (but slow) adoption of SOA principles.
2. Partnership Model: IT and Business Jointly Fund Service Development
In the Partnership Model, IT and the Business meet in smaller, more nimble sub-teams to set strategy regarding Service granularity and design. After the set of Services is rationalized and agreed-upon, joint development can begin. Based on internal charge-back mechanisms, the cost of Service development is shared between IT and the Business Units. This leads to tighter integration of the teams as well as shared responsibility and more effective resource utilization.
Companies with effective distributed development teams / matrixed organizations should build on their previous successes and adopt the Partnership model. The Partnership Model ensures that IT and the Business are in “lock step” as SOA adoption unfolds, and leads to a reasonable speed of development and deployment. However, it also demands continual, close coordination, trust, and joint ownership from both parties.
3. Entrepreneur Model: Business Develops Services and “Sells” Back to Enterprise-at-Large
Many Some Organizations may prefer to employ an Entrepreneurial model whereby key IT-savvy Business Units (especially early adopters) are encouraged to perform initial Service development. This allows for rapid development and deployment, and ensures that the Services meet the needs of the particular Business Unit. Once the Services are developed and tested they can be “sold” back to the Enterprise to offset the Business Unit’s development costs. This promotes and internal market of Services that could optimally provide wide applicability and rapid evolution. However this approach also carries significantly higher risks, including service duplication, granularity a too-low a level, and Services that might expose an Organization’s weaknesses in its Enterprise Data Strategy.
The Entrepreneur Model works best in Organizations that have deep IT skills embedded within the Business Units as well as an evolved Enterprise Data Strategy and strong Project Management disciplines. It enables the fastest adoption of SOA within an Enterprise.
The LiquidHub Takeaway:
Each of the three funding models plays to the strengths of the Organization in question (Centralized vs. Distributed/Matrixed, Top/Down vs. Bottom-Up, and Conservative Adopter vs. Early Adopter). However, certain themes are common to all models:
1. Visible Governance Body: Such a body must oversee the overall SOA Strategy, and clearly define the Operating Model that an Organization will adopt (before SOA deployment beings). This Governance Body could be only a lightweight clearinghouse, but must be the focal point where SOA activities are at least catalogued.
2. Funding / Charge-back Approach: An internal “Market Approach” regarding the way SOA Services will be funded is essential to provide the Executive Team with clear metrics regarding the total costs of the effort, and to ensure that funds and human resources are being spent wisely.
3. Corporate Data Strategy: Initial design and development of Services needs to highly leverage the Organization’s Data and Information Strategy (or will expose the lack thereof).
As SOA takes hold as both a Business and IT-led phenomenon, forward-thinking companies will take the opportunity to gain new insight into funding their development efforts, and, as a fringe benefit, forever transform the Business / IT relationship.
(Note: Information on LiquidHub can be found at www.liquidhub.com.)