Almost everything you once knew about business computing has changed with SOA.
That was the high level summary of insights from CIOs and CTOs collected by the Object Management Group's (OMG) SOA Consortium. The consortium, founded by BEA Systems Inc., Cisco Systems Inc., IBM and SAP AG to focus on SOA as a business strategy, revealed the top five insights gleaned from it recent executive summit for CIOs and CTOs.
While not all of the executive insights are unheard of in SOA architect and developer circles, the views from the executive suite portend a top-down revolution in thinking about business computing and software. The CIOs and CTOs, invited to the consortium summit and promised anonymity for their views, don't expect to buy software in the same way, if they expect to buy it at all. They now get that service-orientation changes how IT will work with the business side of the enterprise and are ready to re-organize departments to get SOA beyond the pilot stage.
The SOA Consortium itself, with its motto "SOA means business," is – unlike most other SOA organizations – not particularly interested in technology, said Richard Mark Soley, executive director of the consortium and Chairman and CEO of OMG.
"There's already a lot of information out about service-oriented architecture and how it impacts your technology infrastructure," he said during a Webcast to present the top five insights in advance of the consortium's inaugural meeting in San Diego this week. "But to us SOA means business. SOA doesn't mean technology. It's a business strategy focused on business agility."
The business focus, showed up in the first of the five insights, which was also the first one CIOs and CTOs wanted to talk about, according to Brenda Michelson, principal at External Links, who gathered and presented the insights.
1. No artificial separation of SOA and BPM.
"CIOs and CTOs do not artificially separate SOA from business process management (BPM)." Michelson said.
She recalled one CTO telling her, "You know, SOA, BPM, Lean, Six Sigma are all basically one thing. It's about business strategy and structure. It's about business transformation. And they must work side-by-side."
The marketers for SOA vendors may promote separation of SOA and BPM into special product categories, Michelson said, but "none of the CIOs or CTOs that we talked to do that."
"When they think about SOA," she explained, "they think about a top down business view. They start looking at their business processes. They start discovering and discussing with their business units what are the business activities within that business process. How does this business activity tie to their balance sheet? What are the services that need to be in place in order to accomplish those activities?"
In defining their terms, she said, the executives start with business services, not Web services.
"When they talk about services, they're not talking yet about discrete services that we might implement in a service-oriented architecture," Michelson said. "They're saying there are services that are accomplished by people and there are services that are accomplished by machines."
Modeling of services starts with the business side in the view of the executives at the SOA summit.
"They want to be able to execute the model of their business rather than systems," Michelson said. "One of the CTOs talked about how important it was in the future to just remove the word 'systems' from the language of their business partners. All they want to talk about is business processes, activities and services. When you start to talk about systems you artificially constrain you're potential because you start to think about the fact that you have system A and system B, and what can they do, rather than what am I trying to accomplish."
2. Success requires business and IT collaboration.
Aligning business and IT is talked about a lot in almost all discussions of SOA, but Michelson pointed out that it is one of the fundamental premises of the consortium and it was a hot topic with the executives at the summit.
"As we discussed this premise, we said that today what happens typically in an enterprise is that a business strategy may or may not influence IT strategy," she said. "Business strategy influences business requirements. But what we've all seen time and time again is that unfortunately the IT solution, whether you buy it yourself, build it yourself, the IT solution actually ends up influencing the business process. Then what happens is the architecture of your business, the structure, the processes, the policies all become a result of the IT solution as opposed to the driver of the IT solution."
Michelson said the executives want to turn the old IT approach to business on its head. SOA makes obsolete the old practice where IT could buy or develop software and then explain to business people how it might help them.
"With SOA we're seeing more collaboration upfront between the business and IT," Michelson said, summarizing the executives' point of view. "You get a business strategy influencing a business architecture that you actually plan. The business strategy and IT strategy are aligned and they serve each other because there's a lot of technology advances that influence what your business strategy might look like and your IT strategy influences your enterprise architecture. Your business architecture and your enterprise architecture need to relate strongly."
3. On the IT side, SOA must permeate the organization.
SOA may start with a skunk works team or, in the politically correct parlance of the executive suite, a "center of excellence," but it can't stop there. While executives may not view the rogue or pilot SOA project with skepticism, since they are seeking to encourage innovation, they do view the center of excellence as a possible bottleneck.
"You start with a center of excellence, a handful of people with architectural roots," Michelson said in explaining the view from the top. "They start your SOA program and your blueprint. They define the initial infrastructure services. They do some early business services. They do some pilot projects."
However, once the pilot is done, the role of the center of excellence needs to change or SOA may die on the vine.
"You can't stay with a center of excellence," Michelson said. "Almost from the beginning, your center of excellence is a bottleneck. You really need to move on and infuse SOA throughout your organization."
Some CIOs told Michelson they have already transitioned the center of excellence from pilot development to education and coordination for the enterprise development teams.
"CIOs tell us that the center of excellence works with the development project teams and teaches them about the SOA standards and practices," she said. "From the development project, you start to get SOA infused into the development organization. Finally, the center of excellence reforms again and its job becomes governance and coordination. The development organization is then responsible for SOA execution."
4. Substantial operational impacts, little industry emphasis.
If the CIOs and CTOs had one major gripe about SOA it was that the software industry is not being candid about, nor providing support for the operational impact of transitioning to SOA.
As an example, Michelson said, "The challenge that the CIOs called out was services versioning and that nobody has a really good handle yet on the way to do services versioning. What they do know is that it's naive to think you're only going to have one version of a service in production. The people we were talking to had between 140 and 250 services that were being used by anywhere from nine to 95 composite applications. Definitely a pretty complicated environment as soon as you start to introduce change."
Marketers for testing and governance vendors may be promising help with this, but in the executive suite seems to be repeating Edward Deming's old saying, "In God we trust, everyone else bring data." Despite the hype they are not sure the technology being marketed is up to the job. They have a lot of questions and they want answers.
"They talked a lot about testing and how you actually test your service consumers and test your service providers," Michelson said. "How do you synchronize that testing? And how do you stress test? How can you possibly test everything at once? It goes back to what's the impact of testing on your versioning practices."
She said the when the discussion turned to change management, especially where they are doing agile development, they did not see technology yet able to handle a scenario where "you're introducing something every couple weeks and you have 95 consumers of that service."
The CIOs told Michelson they wanted to see more industry focus technology to support the operations of a large SOA environment.
5. SOA is game changing for application providers
This insight might give vendors marketing products to support SOA a few sleepless nights.
"A CIO told us that SOA fundamentally changes the marketplace," Michelson recalled. "The way they buy software today is changing."
Some of the executives do not plan to "buy software in the future." Many are looking to either subscribe to a software as a service (SaaS) offering or they except to be able to get free open source software. Michelson found almost no support for the old way of buying monolithic software packages, known in marketing-ese as suites.
Michelson recalled: "When we asked the group: where will the services come from? They told us they are essentially going to come from everywhere. Some are going to be internally built. They're going to be exposing existing functions and data. In fact, one CTO told us 'Ninety-five percent of the functions and data I need to run my business exist. I just can't get at them. They are not orchestrated in a business process that makes sense for me.'"
The only bright spot for vendors seems to be reserved for those selling platforms.
After talking to the CIOs and CTOs, Michelson concluded: "What they assume is that they will buy an application platform and then get the services for free."