Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Vol. 20, a weekly discussion and dissection of Services Oriented Architecture (SOA) related news and events with a panel of industry analysts and guests. I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions.
Jim Kobielus: Thanks, Dana. Hi, everybody.
Todd Biske: Thanks Dana.
Brad Shimmin: Thanks for having me, Dana. I focus on application infrastructure and spend most of my time thinking about middleware and SOA.
Dave Linthicum: It’s Dave Linthicum.
As I was saying, we’re just getting into our topics, and we’re going to look at some of the IBM news this week that came out of the Rational Division. There was the intent to buy Telelogic, a Swedish firm that’s got a lot of product across requirements, tests, QA, architecture and modeling, as well as embedded and system development. So, we’ll talk a little bit about that.
We’ll look at some of the announcements out of the Rational Developer Conference, including the Jazz Community, an innovative commercial/open-source community approach to development. Also, one of the more interesting product announcements was Rational Asset Manager, essentially a design-time metadata repository that can be used in conjunction with an operational or run-time registry and repository for a lifecycle approach to services.
What’s more, we’ll go around the table and look at what research folks have been conducting this week. That might include a look at WS02, the IONA Artix announcement, and some announcements also from BEA.
So, let’s start with the Telelogic acquisition. Telelogic is a publicly held company in
Why don’t we start with Jim Kobielus? IBM and embedded -- we haven't seen anything along those lines for a while. They jettisoned the Rational embedded drive before IBM had acquired Rational, but now they seem to have a new-found interest in embedded. That's increasingly focused on end-to-end development, recognizing that the entertainment and media sectors are going to be creating devices different from a personal computer. IBM doesn’t want to miss out on the opportunity to leverage its back-end systems vis-à-vis these new types of devices. Any thoughts, Jim?
Kobielus: Clearly, IBM over the last few years has made stronger moves into the appliance space and really helped to define it. Obviously, with the DataPower acquisition a few years ago and increasingly taking their data warehousing appliances -- I think they’ve already revamped that entire product family -- they can scale from very small, or relatively small, data warehouses to very large ones.
IBM is trying to fuse their chief software products and technologies with their hardware engineering expertise to develop products for various markets. Embedded operating systems, embedded application components, and so forth, are key to all that.
So, when I saw that they were acquiring Telelogic, it made perfect sense. IBM is very much bringing together the hardware and software worlds into appliances, both for the business and potentially for the consumer market.
I think they see a wide-open opportunity in embedded that is still a fairly wide-open, roll-your-own test, roll-your-own tools, even roll-your-own IDE or real-time operating system. So, I wonder if anyone else has some thoughts on the embedded angle on this?
Shimmin: Well, Dana, not so much about the embedded angle, sorry to say, but perhaps something that might transition us into talking about Rational. When I look at what IBM is doing here -- and this is pursuant to what Jim was just saying about their synergies between hardware and software -- I see IBM doing two things.
One is renewing the focus on software development on the design time and development time side of things. Then, I see them taking their expertise in hardware and putting the two together to build what a lot of the software companies or platform companies really wish they had in the space, and that is the ability to do two things: create well-performing software and actually have software that performs well in the production environment. They’re going to be pretty well positioned to take advantage of those two things.
They seem to be involved now more and more with getting very close to the application, almost to the point of being in a position to be dominant in terms of custom application development. Do you have any sense from your perspective, Brad, about the whole notion of the shift in the definition of applications and how to create them?
Shimmin: Absolutely, Dana. It’s funny. Both IBM and Oracle are the two companies leading the chart with what you just said there. They’re taking tentative baby steps, because this is a pretty daunting task they’ve undertaken. That is, as you said, dive deep into a given vertical and a given set of business processes within that vertical to provide literally out-of-the-box functionality. You’ve got your data models. You’ve got your actual BPEL processes. You’ve got everything that surrounds whatever it is you need to actually get some sort of process up and running within their environments.
Maybe five years ago or so, platform vendors really focused on the foundation infrastructure of what these applications run on. They’ve realized in maybe the last six months that the success that they’re going to enjoy is going to come from their ability to save their customers money from the exorbitant consulting and professional engagement fees that usually come hand-in-hand with rolling out software like this.
So, what they're doing is pretty cool, and I applaud them for it. As I was saying a second ago it’s a pretty long row to hoe and it’s going to take a lot of energy on Oracle’s and IBM’s part to actually fulfill this and to say, “Okay, we’re going to give you a set of business processes with all the data you need to set them up and get them running for your vertical.”
Shimmin: I think IBM is actually leaning that way and they have a very strong ecosystem already in place.
Biske: I have not evaluated it myself. Momentum’s CEO, Jeff Schneider, said maybe we’ll see some more activity on that product. It’s interesting, because I’ve yet to run into an organization that’s really leveraging some of the EA-specific products that are out there. They still tend to do 90 percent of what they need to do in Visio, rather than some of the specialized tools in that area, but, as the discipline matures, we’re going to see a lot more of that.
I want to talk a little more about this notion of it bringing IBM closer to the application business that you first commented about in your blog. At least, that was the first time that that was brought to my attention.
I have a friend from college who has worked in the embedded space pretty much since we graduated, and he contacted me recently about applying SOA to some of the work that he was doing. It surprised me a little bit, because it’s not a space that I’ve had to deal with. I’ve typically been in big IT and big enterprises. It opened my eyes that their environment for developing is maturing as well. They are getting to higher levels of abstraction and taking advantage of the same types of programming models a typical enterprise developer is.
I thought they were going to be so focused on performance and real-time behavior of these systems, that they may not have a strong interest in some of the things that Web service standards and XML have to offer, because of the tradeoffs from a performance standpoint. He said, “No, we are looking at all of that.”
Now, with IBM making this acquisition of a company that’s dealt in the embedded space, it really shows that development is still development. IBM is now recognizing that it’s not all just about “build whatever you want.” We are getting more specialized, and maybe the right way to get into the applications market is to create specialized tools for particular vertical domains, rather than providing the applications themselves.
It’s definitely something to pay attention to, as we go along. They did it on the tool side; they did it on the software side with the Webify acquisition last year; and I would guess that we’ll continue to see more in this direction.
Linthicum: What’s missing in the space is a holistic design tool around SOA. I looked at Telelogic at the EA Conference in
Linthicum: I did look at it from the online piece, and I think that it’s going to have value in this space as well. The folks at IBM are not dumb. They’re out in the back, trying to figure out how all this stuff is going to fit together. They want to have not only the mega-stack in terms of deploying technology and development technology, but the mega-stack in terms of the design time stuff, including holistic enterprise architecture, asset management, service management, and SOA governance.
So, it’s going to be very difficult not to see IBM in almost all the larger SOA implementations out there, once they have a critical mass of tools. They’re investing right now. They see this as a long term strategy and a way to gain revenue 10-15 years down the line. I think they’re making some smart moves. I would have acquired Telelogic as well, if I were IBM.
Linthicum: Oh, it’s a bargain. They did very well buying it, and they’re going to reap a lot of benefits from it. This is the right move from IBM and the investors are going to love that three or four years down the line.
Kobielus: That’s exactly what I’ve seen too, Dana. Rational is becoming the crown jewel within IBM. In my area of focus, master data management (MDM), the Rational tool has become the primary master data modeling and domain modeling tool for all of IBM’s MDM products. I agree. It was probably their most important acquisition in the last 10 years.
One last item in the IBM news. They announced this Jazz community, jazz.org, and it’s essentially an open environment, which people can join and help contribute to the development of Rational products. This is somewhat of a trial balloon with IBM saying, “Wow. Look, how successful Eclipse was as a governance environment and a community development force in the market. How can we take what was good about Eclipse, but apply it to commercial product development, not just open-source development?”
It strikes me that if the companies who partner with IBM that have a vested interest in how their products relate to the Rational products contribute and help define the Rational products, then the same model could be applied to other commercial aspects within IBM, and they could then perhaps even take the model to other products. Has anyone had a chance to look at Jazz? Do you think that this is a wacky idea, or do you think it will get traction?
Shimmin: I looked at it a little bit. This is not the first time this has been done, and it certainly won’t be the last. As you said, they saw the success of Eclipse and they saw that it was an environment that fostered innovation. As we all know, it’s very hard for large closed-source vendors to innovate quickly, while maintaining a customer base accustomed to once-a-year big upgrades, punctuated with little patch here and there.
I look at what IBM has done, as well as TIBCO, Sun, BEA, and Red Hat -- even though they’re not closed source -- and I see them using the tools that the open-source community fostered in order to collaborate over a large-scale network of developers, and they’re applying it, just as you said, to closed source. There are many benefits to that.
First and foremost is a quicker turnaround on bug fixes and getting to a GA. When you’re dealing with the traditional closed-source development cycle, you build your software, you send it out to maybe 10 trusted customers. They hammer on it a little, and you have your own internal people hammering on it, and that’s maybe a three month venture.
Using 10 customers, who have their own jobs to do and don’t give this a lot of shrift, sets you up for failure. That’s why we see so many post-release patches going out. What this is going to do, if it succeeds and can be applied to closed source, is let these large vendors get their code out quicker in a much more tip-top, enterprise-ready fashion.
Shimmin: Absolutely. IBM is taking a tiered approach to it, and some of the others have too. As we were saying with these trusted customers and partners, partners in particular are going to play a big role in this, but they would get access to source code at deeper levels. Folks that maybe are smaller customers or just interested parties, who want to make this product go forward, will have more limited access, unlike a traditional open source. They’ll have more limited access to the details of the source code.
Shimmin: Should we be thanking Microsoft, Novell and SUSE for that a little bit?
Biske: It’s an interesting idea. I wonder how different it is from some of the efforts already going on. Clearly, we have commercial efforts built on open-source products. The key question here involves open-source products that are not available for free. If developers are working on it and they can build it and use it, how is that model going to come together if they say, “No, you only have a license to run it in a development mode and nothing more than that?” Is that going to be followed or not? Are they going to bother to enforce it, or do they really know in the long run it’s going to take the same direction that Eclipse did.
IBM has a commercial version of Eclipse, but largely people just go with the free product, because they can still include all the plug-ins that they need to. If they need to buy add-ins to it, they’re okay with that. So, they can focus their attention on Eclipse and create a framework, and can plug-in commercial components as they need to.
The other risk that they take is that the community is just going to look at this and think they’re just looking for free work. trying to take advantage of developers who just love to code and could care less whether they’re getting paid for it or not.
Shimmin: There are no selfless acts. Right, guys? When I scroll some message boards for these development efforts, I see people in enterprises saying, “I need access to this API because I need to extend the product to work with something I’ve built in-house.” I think that’s the kind of work that’s going to drive us forward.
[[[Speaker:]]] It’s the same phenomenon as the developers who are employed by a vendor like IBM. They quite often work excessive unpaid overtime, just because they’re committed to their jobs, their products, etc. In a sense, now you’re roping in the partner ecosystem as well. They’re putting in essentially unpaid overtime to help out the mother-ship vendor get its products debugged and developed.
Okay, let’s move on to some other topics. WS02 announced ESB 1, which is largely based on the Apache Synapse ESB. I want to make a disclosure that WS02 is a client of mine, and we should consider that as I present comments. I wonder if anyone else took a look at this, and had some thoughts on, “Wow. Yet another ESB and yet another open-source support maintenance business model entrant in the SOA ecology?”
Shimmin: Dana, I talked to them briefly about this before they released it. Like you, I saw this as, “Oh, yes, here’s another one, and maybe Red Hat should worry.” But, I don’t think anyone else is going to worry, except maybe the pure play ESB vendors like
They’re focusing on what everybody in this space is trying to focus on, performance. Everyone has realized that ESB is at its level of maturity. You need to really be focusing on availability, reliance, reliability -- the “ilities” -- of deployment. This is the third vendor in the last month -- this would include
Shimmin: I got the same vibe from them too, but I feel as if every vendor with an ESB these days feels the same way. They realize that, as with databases, you’re going into a heterogeneous environment regardless, and most likely inter-departmental, inter-company you’re going to have multiple ESBs and different messaging platforms that need to interoperate.
Biske: It doesn’t bother me. I’d rather see a lot more in the open-source space. They’ve got the freedom to keep it more focused on some of the target areas. In the case of WS02, they really are focused more on what I call the middle capabilities, rather than on service development and execution capabilities. You see a lot of the commercial ESBs going in the direction of giving you an orchestration platform and a composition platform. All of it is about building new services, and not about connecting existing consumers and existing service providers.
Some of these open-source ones are keeping it a little bit more constrained and targeted. Now, with the open-source model, if an enterprise needs to augment that for their particular needs it gives them the ability to do so. I’ve run into a few clients who are looking at some of these products and have a potential need to do that. The openness is a plus for them.
I don’t necessarily see it as too many ESBs out there. The market naturally will shake them out on its own. This is just the way these product spaces work. I don’t view it as an SOA bad thing.
Biske: Absolutely. At Momentum, we’re vendor neutral, and I know Dave talked in a recent podcast about the importance, when dealing with system integrators, of having one that is not closely tied to a particular partner, unless your company has already decided that you’re married to this particular vendor. Then, it makes sense.
If you’re looking for your pure systems integrator, you have got to select solutions that are in the best interests of the client, not the best interests of the consulting company or the partner ecosystem around this. Having open-source products gives us a lot more flexibility in meeting the needs of the clients.
Linthicum: I don’t put as much value as everybody else does into the open-source equation. In fact, my client base -- and it’s Global 2000 and government folks -- are indeed buying ESBs and other things based on the notion of having access to the source code. I just can’t imagine in my lifetime that they would ever want to become a product development vendor and would have the skill set to actually maintain a middleware product, having built a bunch of those in my lifetime. I’m a little skeptical about the ultimate value there. To me, open-source needs to have marketing value. I’m not sure it’s going to have a lot of technical value going forward.
My larger concern with the number of ESBs out there is that, in many instances, these have a tendency to be queuing systems with service interfaces on top of them. Therefore, they’re more information- or data- oriented than transaction-oriented. That has a tendency to limit some of the emerging patterns I’m seeing within SOA. People are looking basically to automate these high-end business transactional systems well beyond just data consumption and production.
Most of the ESBs don’t really address that. They basically become queuing systems with a nice interface on them. To Todd’s point, they do have orchestration layers and other development technology. Some of the higher ESBs out there definitely have that capability. That seems to be nice, but it still seems to be limited by the underlying infrastructure that they’re selling.
I’m concerned about the number of the ESBs in the market, and I’m concerned about the ability of those ESBs to deliver the ultimate value as the SOA we’re building becomes much more sophisticated.
Shimmin: This week I looked at two things primarily. One was the release AmberPoint made regarding their SOA validation system and their SOA management system. They have two products and they just versioned them to 6. I found what they were talking about very interesting, because, as I was just saying a second ago, they too are focusing on performance.
What they’ve gotten at is their desire to be in a run-time environment, because, as you guys know, they are like the Switzerland of SOA run-time governance in our industry. They are focusing on being able to scale their platform, and they have a number of partnerships and potential partnerships with hardware manufacturers, going back to our earlier discussion about IBM and their DataPower acquisition.
They seem to have this idea of, “Well, we’re run-time governance only, and we have the capability to be design-time governance as well, but we’re not going to get into that space.” I found that interesting, because they’ve just announced this as a part of this pre-flight check that they do. This is similar to the type of the service that
In the AmberPoint product, but a little bit more predominantly positioned, they actually go look at that WSDL as it relates to other processes across the entire application and looks for any interdependencies, broken relationships, and anything within the production environment that may cause a problem.
I think about companies like CA, HP, and IBM, who all really are trying to come at the same problem, but from the design and development side, and I think of AmberPoint coming at it from the run-time side. I feel like, “Well, why don’t you guys just get together? Let’s put these two notions together and make it so that we have a more coherent lifecycle management of our codes for SOA implementations that starts in design and ends in run-time.”
Shimmin: It’s a combination. When I talked to AmberPoint about that very question, Dana, we were talking about it with regards to this throttling technology they have, where they can look at PKIs and SOAs that have been defined inside the Registry Repository and tell the process to slow down on Thursday afternoons, for example, because I need these other process to take priority on that date and time.
I said to them, “Well, gosh, I know there are a lot of tools out there at designed/development time – a lot of BPM products for example -- let me establish these and stick them in a registry. You just pick those up automatically and start executing them.” They said, no, because the schema and the amount of data that comes from this is not really enough to do it.
Kobielus: One of the glues, of course, is a common registry and repository infrastructure between the design-time and the run-time environments, but just as important is the wetware, as you indicated, a common governance environment with roles and workflows. People who are doing the design and optimization of the Web services and the people who are administering the services in a run-time can be collaborating on a ongoing basis.
The common rules and policies of this common infrastructure, be it AmberPoint on the run time or tons of other vendors on the design time, they can all share. So, it’s a bit of the registry and it’s a bit of the governance human administrative workflow.
Biske: It’s interesting that you bring that up, Jim, because one of the things that I wanted to come back to was the Rational Asset Manager. It seems to be typical of IBM that in their SOA offerings they’ve got three of everything. If the registry repository is the key, and I agree with you that this is really the unifying component on some of these things that are dealing with policy on the metadata, they’ve got Rational Asset Manager, which is effectively a metadata repository, and then they’ve got WebSphere Registry Repository, which is another metadata repository.
I’ve had conversations with them going back a couple of years on this subject, asking “How are you going bridge those, and what’s
Brad hit on the other point, in his conversation with AmberPoint, that it’s not the fact that you have a metadata repository out there, but it’s the information that’s going into it. Until there’s some standard level of policy domain languages that these tools can leverage, you’re going to still see people just building their own fiefdoms and saying, “Well, you’ve got to have either AmberPoint everywhere or HP everywhere -- or whatever your management system of choice is -- to be able to do some of these things, like throttling across systems, and some of the run-time policy enforcement. It does need to bridge all the way back into the development tools.” So, again, IBM’s in a great position, providing products in all of those spaces, but it’s going to be difficult to pull off.
Linthicum: It’s possible for the newer offering, but they will have some pushback, given the fact that every domain is extremely different. One challenge that people have, when they try to get out in the market with this kind of stuff, is that ultimately what they think they’re implementing is different than what’s actually being implemented. I see a huge chasm between the perceptions.
For example, I was at the Gartner event this week to do a talk on ROI, and I got a chance to wander around and talk to a number of the people who are pushing in the market, both customers and users. There’s a very different perception as to what vendors think the problems are and what the problems are that users are actually experiencing. There’s going to be a bit of a sobering [[[-- come to Jesus --]]] that’s going to happen over the next year or so, when these guys push out there.
Linthicum: In the user community, all the problem domains I’m seeing, definitely in my client base, are unique. There doesn’t seem to be any one set of solution patterns you can apply across the board. You see bits and pieces of a stack and how simplistic those problem domains are. The vendors don’t see that when they design SOA in general. They typically give you the same stack and the same problem description. I’m not seeing a consistent problem description out there to work with the client.
Linthicum: You can’t do that, and that’s the problem people are running into right now. I saw the same thing back in the integration days, back in the AI days. We tried to take one problem domain, all the spaghetti code, and put it through a single hub. While that was applicable to a small percentage of the problem domains, it wasn’t widely applicable. It wasn’t applicable to all problem domains. SOA is even more complex than that. Vendors are going to find that they’re missing the boat in terms of understanding the needs of the people they’re trying to serve.
Linthicum: Dana, it’s all about people. As I’m getting further along in this stuff and learning more about it, I find that the people issues are really the core of all this all. I can solve any problem with technology, and probably everybody in this space can do the same thing. However, getting people aligned with how that’s going to happen and setting them up for success is the ultimate challenge right now, and the vendors need to understand that.
Shimmin: Back to our example of AmberPoint. If I have a nice BPM tool that lets me find my PKIs and SOAs, and if it’s not in my best interest to include that additional data the additional artifacts that AmberPoint is going to need to make that throttling automatic, why am I going to do it? I won’t.
Kobielus: That explains why I’m seeing more emphasis in the SOA space on pre-built domain models, essentially solutions that package up the rules, the best practices templates, the workflows, the policies, and so forth, for a particular problem domain, be it in the MDM space or be it in the ESB space. The customers are demanding these accelerators so they don’t need to hire people who are smart enough to build all that stuff from scratch. If the vendor and their partner ecosystem have already frozen all that expertise into the solution, the customer can be productive from day one. So, the customer could have a little bit longer to go find the appropriate smart people, wherever they happened to be, whether in
Shimmin: That’s why you look at the Rational and Jazz announcements this week and you see the reality that IBM is seeing, which is that, although we want to have this deep knowledge that’s in-house, that’s not likely to happen. You need to go where the talent is. So, the software is hopefully bridging those gaps.
Back to what you were saying earlier, Dana, about even Lotus being able to play in this, I think what’s going to become a much more predominant paradigm is that sort of telepresence for the entire life cycle of software for all involved in that.
Biske: I have a little bit different take on this. I still feel that it’s not that we need better developers, but that the technologists need to become more business aware and more business savvy.
There are a lot of businesses that may be looking offshore for a lot of these efforts, strictly from a cost reduction effort, but that doesn’t necessarily mean they’re going to get any better technical solutions than they would have with resources in-house. It just may mean that they’re going to get it less expensively, and even that is debatable.
So, they haven’t really improved things from that standpoint. In terms of business agility, they’ve reduced their cost, but is the IT solutions actually helping the business any more than it did before when all the work was being done internally? The only thing that’s really going to help push it along is to get people who are both knowledgeable about the business, as well as knowledgeable about the technology, and being able to bring those two worlds together.
Shimmin: I don’t think BPEL is the only way to do that, but that seems like that’s all vendors are focusing on right now.
Maybe we should be thinking about this as small pods or teams, where you’ve got a business person who is savvy, you’ve got a technologist who is savvy. And, then you’ve got a facilitator, a person who is very good at motivating and communicating, and create three-person pods to approach this, rather than think you’re going to get it in just one individual.
Kobielus:[[[???]]] Right, because these are all separate domains of complexity. You can be really astute on business issues, if you focus on that and you continue to refresh your understanding and the nuances of all of that day in and day out. Likewise, all the technology areas are themselves entirely stand-alone spheres of complexity. Imagine one person trying to juggle those different spheres of complexity all day, every day, and do a good job of it. That’s really hard from a wetware perspective.
Shimmin: Do you guys know the notion of extreme programming? The idea is to have these micro teams with two people who are always working on a given aspect of a project. Why not have one of them be the IT technologist and the other one be the business analyst?
Gardner: There’s an opportunity here for someone like a McKinsey to come in and start analyzing the organizational dynamics of approaching SOA, what sort of teams should be put together, and what sort of people should have certain skills. This whole notion of one person doing it seems to me as farfetched. These teams could be much more capable and much more distributed. You could push them into different activities within this problem set and they won’t necessarily have to be physically there.
Biske: Companies that have started to practice user-centered design and some formal usability practices are probably in a much better position. One thing you find in doing that is that you immediately have to get out of this customer-supplier relationship and into a team environment, as you describe, for developing solutions for business users. They’re part of the team. They’re not a customer.
Pointing to other potential groups, someone like Patricia Seybold Group, and their focus on customer innovation, some of those concepts really need to be brought in here to stop viewing IT as a supplier to the business and instead as a partner and working from a team standpoint.
You’re absolutely right that the T can be built by creating a team, rather than looking for one superstar individual that understands it all, because there aren’t too many of them.
Kobielus: My pleasure.
Biske: Thank you.
Shimmin: It’s been a pleasure everyone, thank you.
Listen to the podcast here.
Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production. If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 20. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.