Today, Todd Biske posted a summary of a session of the Gartner Application Architecture Development & Integration Summit that discussed the funding of SOA.
The footprint of a Service Oriented Architecture in terms of infrastructure, skills and organizational changes can be daunting. It is worth noting that the REST community is trying to solve this problem by minimizing the costs and maximizing the value leveraging the composition capabilities at the presentation layer.
A quick search on the web actually shows that there are few data points on the topic. The question seems to be almost taboo.
Todd reports that the preliminary results of the SOA Consortium funding survey have indicated:
there’s no uniform initial approach to SOA. Some leverage an SOA program, some expect service development out of existing projects, etc.
In [his] experience, [he has] never encountered a funded program whose sole goal was to produce SOA. [He has] always worked with business projects/programs that wanted to leverage services as part of their efforts.
Todd comments that while it is possible to solve the initial funding problem, the ongoing funding problem of SOA remains often a question.
The panel then went on discussing the Metrics:
Without [metrics], how can we say that we’ve accomplished anything? To show that we’re more agile [and productive developing solutions], we need metrics of how things have been and how things are in the future.
There’s also metrics associated with service consumption: number of consumers, usage by consumers, min/avg/max response time, etc. In my own experience, merely making these metrics available, and now at a finer level of granularity than the entry points into a web application were very beneficial.
The third topic of the panel was Service Ownership. Todd comments:
It was great to hear someone else say that the project-based culture of IT can be in impediment to SOA success.
If you don’t have a service owner independent of the consumers, then each consumer is going to try to push things in the direction that has the most benefit for their project, but yet no one will own the service. This in-fighting can be very detrimental to SOA.
The last topic was Service Portfolio Management (SPM). Todd compares SPM to Application Portfolio Management and recommends to focus on SPM early to avoid the mess created by the lack of APM. In his views:
Anyone saying that they don’t need a registry/repository yet because they haven’t reached “critical mass” is potentially making a big mistake.
Overall, this discussion illustrates that, whichever technology you choose, the "form factor" of a service, in a Service Oriented Architecture changes in at least three dimensions when compared to a traditional solution implementation (packaged or custom):
- project management: a service implementation project is smaller than a typical solution, yet requires a rigorous project management capacity which can increase the overhead on top of the service implementation
- degree of coherence: the degree of coherence of the service at the enterprise level, is much higher than a typical solution. A successful service implementation requires that many constituents of the enterprise align their needs and road maps.
- funding and ownership: can often be outside the realm of a project, possibly creating cross-business unit friction in terms of schedule, roadmaps and funding.
Understanding how to best deal with this new form factor in IT might be well worth it since some people such as Dave Frankel, Lead Standards Architect at SAP Labs, argue that SOA paradigm is well aligned to support the emerging business leaders of the new century.