We are at a very important juncture in the evolution of service-oriented architecture. An incredibly important issue right now is whether we are going to win broad acceptance and deep penetration, or whether SOA remains somewhat marginal.
There are a number of things going on in the market that deserve examination. Trends and developments in information technology such as market acceptance and tipping points — and a sort of social-animal instinct influencing how people behave — become very important. It is no longer just about the technology; it’s about what motivates people, particularly in their businesses.
So, let’s take a level-set in changing times. These are very dynamic times. There are so many things going on in addition to SOA that we can’t look at SOA alone; we have to look at it in the context of what’s going on in general with IT and business.
Over the last two to four years, we have seen SOA develop as a vision, spawned off the work done with Web services, progeny of object orientation and components, bringing it into a standard environment and, hopefully, into much broader usage across IT — not just in development but in how people conceive of IT; a transformative type of activity.
Listen to the discussion (54:35 minutes).
We have gone through SOA standards. We have seen companies come up with methodologies and have had examples of successful, and not so successful, implementations of SOA in the marketplace. Most, if not all, of the large vendors are solidly behind SOA.
We’ve seen them use the terminology. Some are talking more about the business results than the SOA nomenclature itself. It is clear fromIBM to SAP, to Oracle and Sun, that their products and services are based on SOA principles. We expect that will then follow through into the marketplace. We are also seeing quite a bit of development from the large global systems integrators around SOA practices.
Question for SOA Is When, Not If
It has been my analysis for several years that this is an extremely big deal, but what has been missing is the agreement generally in the marketplace as to not if, but when, to do this. We have also had a lot of activity in the marketplace around startups merging and rearranging their businesses. If they did not start focused on SOA, they seem to be heading in that direction. That has led to a period of consolidation. We have seen mergers and acquisitions, partnerships and ecology developments.
We’ve seen the notion of SOA, and it includes governance, bleed over into how IT actually functions — and not just how development and deployment strategies are defined. We are really up against the tipping point here. The crucial issue for SOA is how that tipping point manifests itself.
The real force behind SOA is a transformative activity, which affects both the technologists in the IT department and the way IT is conceived, perceived and used by the businesses. This has been an ongoing issue for many years, if not decades. At this point, we have quite a bit of buy-in around SOA from the technologists. What we see mainly, however, is SOA use behind firewalls and within fairly vertical applications, within a defined business process activity.
What’s more, many services today are data-centric. My studies show about two-thirds of current in-production SOA services have been data-service layer or data-centric services, and so perhaps as few as one third are being devoted to business logic and transactional activities.
This, of course, will vary from company to company, and from vertical industry to vertical industry, but the trend is showing a predominance of interest in making data available as a service. That service is then consumed and used in non-SOA activities and in more traditional integration portal Web applications, and Web or thin-client presentation applications.
How Will SaaS and SOA Emerge Together?
So, SOA remains somewhat tactical even at most mainstream enterprises. There is also an important trend line around Software as a Service (SaaS) providers as they build their applications to be consumed and used as services. They might have a deep impact on how SOA is consumed — almost on an outsourced basis rather than a homegrown basis — and we are going to be tracking that carefully.
An inhibitor to the business side of the house in enterprises adopting SOA broadly is a lack of discretionary spending in IT for SOA types of investments. There is a lot of confusion around SOA and its values, and what business terms and issues are the motivators. Therefore SOA remains difficult to define and rationalize in purely economic terms. There are a lot of reasons for that.
The market is going to work toward a better understanding of the rationale behind businesses as they seek investments in this disruptive technology. We will move from monolithic silos of development and deployment infrastructure and sort of break that apart. Then after the decomposition process we can extend and reuse and redeploy — hopefully with a great deal more efficiency — these resources as granular components or services.
Follow the Money
Though the concept is quite strong, the benefits in terms of numbers and metrics can be rather soft. We could tell people they are going to be more agile, be able to change in the marketplace more quickly, and be able to consolidate and use more singular architectures.
Yet these are not numbers you can bring in on a quarterly basis and say, “Here’s what SOA has done for us this quarter in terms of dollars and cents.” Financial rewards are part of a long-term transformative process as well; something we expect will take years, if not decades, to fully play out.
SOA is really a journey without a destination and, as such, it is harder to quantify and qualify in terms of payback. If there is no destination, when does one know one has succeeded? This also affects cross-organizational use and deployment. There is a traditional chicken-and-egg relationship on whether developers move first, or the SaaS operators, or the people who deploy them on-premises, and that’s currently being played out.
For the true payback of SOA to come about, be it in soft terms or hard terms, it does require a horizontal, holistic and general usage. Politics are also involved here. We have people who have been quite content to remain within a small, isolated arena with their own budget to control, working for several well-known and established taskmasters.
SOA, in a sense, disrupts that. There is no central taskmaster with SOA — and that’s why governance is so important. The idea is for more and more folks to have a handle on these services, and then use them in new and innovative ways — closer to the line of business, closer to the business processes, and extending beyond the confines of the enterprise into a supply chain, for example. So there is naturally some control politics.
Also, budgeting issues play a role, which often means control from the top down rather than the bottom up because it is the central command-and-control folks that effectively change budget structure and allocate funds. So that is in process now as well.
There is also the need for collaboration across these groups. Not only do we want to change how budgets might be formed, we want to encourage people to work in a simultaneous fashion rather than in a linear fashion.
So the hand-off of an application project really can’t happen over a period of six months to 12 months anymore; it needs to happen simultaneously with development. The whole idea here is to go to the business side of the house and tell them we can work quickly and change the process for you, as you have to adapt to a rapidly changing marketplace.
For more insights on SOA, listen to the discussion.
Dana Gardner is president and principal analyst at Interarbor Solutions, which tracks trends, delivers forecasts, and interprets the competitive landscape of enterprise applications and software infrastructure markets for clients. He also producesBriefingsDirect sponsored podcasts. Disclosure: Iona Technologies is a sponsor of BriefingsDirect business productivity podcasts.