Read a full transcript of the discussion.
Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.
Welcome to the latest BriefingsDirect Analyst Insights Edition, Vol. 36, a periodic discussion and dissection of software, services, Service Oriented Architecture (SOA) and compute cloud-related news and events with a panel of IT analysts.
In this episode, recorded Jan. 12, 2009, our guests examine what might keep SOA alive and vibrant -- the ability for the architectural approach to grow inclusive of service types like service-oriented communications (SOC).
We also visit the purported demise of large-scale SOA to calibrate the life span of SOA -- is it dead or alive?
Please join noted IT industry analysts and experts Todd Landry, vice president of NEC Sphere; Jim Kobielus, senior analyst at Forrester Research; Tony Baer, senior analyst at Ovum; Joe McKendrick, independent analyst and prolific blogger; Dave Linthicum, founder of Blue Mountain Labs; JP Morgenthal, senior analyst at Burton Group, and Anne Thomas Manes, vice president and research director at Burton Group.
Our discussion is hosted and moderated by BriefingDirect's Dana Gardner.
Here are some excerpts:
Taking pulse of SOA ...Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Charter Sponsor: Active Endpoints. Additional underwriting by TIBCO Software.
Manes: Certainly, lots of people have refuted my claim [that large-scale SOA is dead]. At the same time, I've had at least as many people, and probably more, I am dead-on right. My goal with the blog post was to at least get the conversation going, and I think I managed to do that effectively.
I still believe that if you go before a funding board this year -- if you are an IT group and you are trying to get funding for some projects -- and you go forward with a proposal that says we need to do SOA, because SOA is good, it’s going to get shot down. Instead, what you have to go forward with is very specific value-add projects that say we need to do this, we need to do that, and we need to do that.
You need to talk about what services you're going to provide. In the example of communications services, there's a really strong value proposition associated with creating communications services. Likewise, going forward with a request to say, "We need to build a billing service which replaces the 27 different billing capabilities that we have in each of our product applications out there."
That’s a very strong, financially rich, good ROI type of proposal that’s going to win. But, it's not going to work, if you go forward and just say, "Oh, we need to go get an ESB. We need to go get some registry and repository technologies. We need to invest in all the SOA infrastructure. We need to do SOA just because SOA is what everybody is telling me we need to do."
Just talk about the services and talk about the practices that are going to help improve the architecture of your systems. Talk about doing application rationalization and talk about reducing the redundancy within your environment.
Talk about dismantling the 47 data warehouses you have that contain customer information and create a set of data services instead that actually gives you a richer, cleaner and more complete information about your customers. Those are things that are going to win.
... One of my favorite comments that came back from the blog post were the number of people who said, "Basically, we just really suck at doing architecture."
One of the primary reasons that a lot of SOA initiatives are failing is because people don’t actually do the architecture. Instead, what they do is service-oriented integration, as opposed to SOA. If you're truly doing architecture, then you're doing an analysis of your applications architecture, figuring out why you have so much extra garbage in your environment, and figuring out what you should actually start to get rid of.
... The folks who have a little more architectural maturity recognize the value of taking this opportunity, when lots and lots of projects are no longer going forward. They can say, "Well, now is a great time for us to start focusing on architecture and figure out how we can position ourselves to take advantage of the economy, when it does finally turn around."
Baer: I think what Anne is saying right now is that organizations that did get ahead of the curve with SOA, that thoughtfully began the architecture process and rationalized it, will go ahead, because there will be real economies at some point compared to traditional application development.
McKendrick: I've always said that the companies that have gravitated toward SOA are the companies that will probably do well anyway. Those are the companies with more visionary management and more tightly integrated approaches to business. Those are the companies that we've seen in all the case studies that over recent years that have gravitated toward SOA. Let’s face it, if they didn’t have SOA, they probably would have been doing okay anyway, because they're well-managed companies.
The companies that really could have used SOA, the companies not likely to be adopting SOA, or not likely be looking at SOA, as Anne and Tony discussed, those are the hunker-down companies, the companies that have fairly unsatisfactory architectures or no architectural approach.
Linthicum: There are companies out there that have some very good IT talent, and they can take SOA, WOA, or cloud computing, look at the business problems, make some very nice systems, and automate the business nicely.
However, the majority of people out there who are wrestling around with architecture are ill-equipped to solve some of the issues. They have a tendency to focus in wrong areas. Anne hit this in her blog as well. It was brilliant.
In the area of, "Let’s do quick tactical things, and look at this as a big systemic issue we are looking to solve," it just becomes too big, too complex. They try to solve it with things that are too tactical and just don’t have enough value. There are no free lunches with SOA or any kind of an architectural approach or any thing we have to improve the business.
You're going to have to break things down to their functional primitive and build them up again. You're going to have to think long and hard about how your architecture relates and links back to the business and how that’s going to work.
I wish there were something you could buy in a box or something you could download or some cloud you can connect to, but at the end of the day it’s the talent of the people who are doing the job. That’s where people have been falling down. Over and over again, in the last three years, we have identified this. I don’t think anybody has taken steps to improve it. In fact, I think it’s gotten worse.
Kobielus: We all know the real-world implementation problems with SOA, the way it’s been developed and presented and discussed in the industry. The core of it is services. As Anne indicated, services are the unit of governance that SOA begot.
We all now focus on services. Now, we’re moving into the world of cloud computing and you know what? A nebulous environment has gotten even more nebulous. The issues with governance, services, and the cloud -- everything is a service in the cloud. So, how do you govern everything? How do you federate public and private clouds? How do you control mashups and so forth? How do you deal with the issues like virtual machine sprawl?
The range of issues now being thrown into the big SOA hopper under the cloud paradigm is just growing, and the fatigue is going to grow, and the disillusionment is going to grow with the very concept of SOA.
Manes: My core recommendation is to think big and take small steps.
You need to do the planning, and your architecture team should be able to do that, without having to go get permission from your funding organization to do planning, because that’s what they’re supposed to be doing. But then, they have to identify quick, short, tactical projects that will actually deliver value.
That’s what they should do and are designed to do to improve the architecture as a whole. It can't be just, "Oh I have to integrate this system with that system." They really should be focusing on identifying projects that will, in fact, improve the architecture. In that way, you’ll be in a better position when things are over.
How service oriented communications has evolved ...
Landry: ... On any given day in a business, do people care about doing the mashup or do they care about having their business be more effective, especially in these times? We believe that people will continue to look for more efficiency in their IT infrastructure. They'll continue to look for how people can be more connected, not only internally but with their customers. At the end of the day, you're right. It’s really about how people get more interconnected with the business process.
... If you look at any implementation and then what happens in the business, the real connective tissue between all of these includes people. The decisions and actions that take place in a business on a day-to-day basis are highly dependent on these people being effective.
Therefore, the manner in which we can help them with their communications and help them collaborate becomes a critical factor in how the workflows can be more effective and more efficient. We've looked at that and said the more you can make communications into business applications, the more you can make communications a more natural part of an SOA.
... [We] had to communicate to the industry the concept of how communications integrates into frameworks in the IT infrastructure. SOA is a one term still used out there to define an approach. When we built our communications platform, we opened up all its services in a manner that we believe fit very naturally into the concept of a SOA. Therefore, our communications platform is really more service oriented than it is a closed and proprietary traditional PBX-oriented system.
... The idea of being able to click-to-call has been around for quite some time. With the more recent technologies mashing up the directory listings, mashing up a call function inside of a business application, is much more achievable and can be done much easier manner than it has in the past.
Baer: The idea of being able to manage and integrate spoken communications may actually be a critical gap in compliance strategy. I could see that as being an incredible justification for trying to integrate voice communications. Another instance would be with any type of real-time supply chain or with trading.
Kobielus: I see SOC as very much an important extension of SOA or an application of SOA, where the service that you're trying to maximize, share, and use is the intelligence that’s in people’s heads -- the people in the organization, in your team. You have various ways in which you can get access to that knowledge and intelligence, one of which is by tapping into a common social networking environment.
In a consumer sphere, the thing is the intelligence you want to gain access to is intelligence sets residing in mobile assets -- human beings on the run. Human beings have various devices and applications through which they can get access to all manner of content and through which they can get access to each other.
So, in a consumer world, a lot of the SOC value proposition is in how it supports social networking. The Facebook environments provide an ever more service-oriented environment within which people can mash up not only their presence and profiles, but all of the content the human beings generate on the fly. Possibly, they can tag on the fly as well, and that might be relevant to other people.
There is a strong potential for SOC and that consumer Facebook-style paradigm of sharing everybody’s user-generated content that’s developed on the fly.
Linthicum: ... The fact of the matter is that people are just getting their arms around exactly what a service is and how you take multiple services and turn them in solutions. ... If you're going to take services like this, expose them as services, and make easier use of them ... then you have to create the integration yourself through very disparate mechanisms and things like that. People are always struggling, trying to figure how to aggregate this [SOC] stuff and its solutions.
Morgenthal: I'd been working with a number of companies who had warehouse issues, and we were basically normalizing those issues by instituting a new services architecture and layering that on top of that legacy system, so they could build their business processes.
One of the biggest issue was they were still communicating exceptions that were happening in the warehouse because device limitations were scanners and text in a very noisy environment. Everyone agreed that the best communications tool in that environment was their cell phone because it vibrated. Well, the Blackberry now has vibration too. So, that’s also a valid form of communication.
If you tie this as a unified communications strategy to the business process, it’s very effective and not only is it very effective ... We expect things in microseconds. So it's enhancing the expectations of people in general because of that. But still, I think overall productivity goes up tremendously, and we move much more effectively toward a real-time event architecture across communications and systems and people. It’s really fascinating to watch and it’s very effective.
Manes: When we're talking about communications services, you want to make sure that those services are very easy to access. With communications services, when you start looking inside PBXs, voice over IP, and those kinds of things, that’s arcane and completely out of the realm of normal development skills that you would get in a Web developer.
Now, we do have some nice capabilities like click to call, and those are set up as drop-in components that people can now use inside their Web applications. Wouldn’t it be nice, if we actually had a much more powerful communications service that a developer can use to communicate with a customer, communicate with a shop manager, or communicate with whatever at this point in the application?
They can call out to a communications service and specify, "Here is who I want to talk to. Here is the information I want to send. And, here is the method through which I want send it." And, and then they can have the communications service completely take care of the whole processes associated with making that work.
I can guarantee that a developer is going to choose that over, "Oh, I have to write all kinds of arcane code in order to figure out how to send an email or how to launch a phone call." So, building these services that simplify a very complex process is extremely valuable from a productivity perspective.
Landry: ... There's is another piece of this that says these platforms are bringing together multiple forms of media, so that you can utilize text messaging, audio, or video communications. You can do screen-sharing data collaboration in a simpler and more consistent fashion and you can utilize one set of services to do that.
Whether they're deployed as a cloud and the enterprise is using those services from within a cloud or whether they've made the decision to do them on premises, both are very viable and, in many cases, both are being done today.
Read a full transcript of the discussion.
Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.
Thanks for sharing all of this stuff. I love it.
ReplyDeleteBusiness Process Management