Edited transcript of BriefingsDirect[tm/sm] podcast with Dana Gardner, recorded July 27, 2007.
Listen to the podcast here. Podcast sponsor: IONA Technologies.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, a sponsored podcast discussion on a top level Apache Software Foundation project, known as Apache Camel.
It’s a way to help developers do better integration and mediation for routing in software-intense environments, and moving lots of objects and component services around, but also relying on rules and patterns to do so.
To help us understand more about Apache Camel, we’re joined today by James Strachan, technical director of engineering at IONA Technologies. Welcome, James.
James Strachan: Hi.
Gardner: Tell us a little bit about Apache Camel. It seems to be a subset of many other integration and infrastructure projects in the open-source community. Tell us a little bit about the history of how Apache Camel came to be.
Strachan: Earlier this year, Apache Camel grew organically from code and ideas from a bunch of other Apache projects, particularly Apache ActiveMQ and Apache ServiceMix. We found that people wanted to create and use patterns from the "Enterprise Integration Patterns" book in many different scenarios.
Some people wanted to use these patterns inside an Enterprise Service Bus (ESB), some people wanted to use these patterns inside a message broker, and other people wanted to use these patterns inside an application itself or to talk between messaging providers. Still other people wanted to use them inside a Web services framework or some other communication platform. So, rather than tie this routing code to a particular message broker or ESB, we tried to extract this code to be a standalone framework that can be used in any project.
Gardner: I assume that this is to simplify it and make it easier for developers? Is that right?
Strachan: Definitely. What we tried to do with Camel was give it the smallest footprint possible, so that it can be reused anywhere, whether in a servlet, in the Web services stack, inside a full ESB, or a messaging application.
Gardner: And, this is a plain old Java object (POJO), I believe, also built in Java. Is that correct?
Strachan: Absolutely.
Gardner: Tell us a bit about the team behind this and perhaps a little background for yourself?
Strachan: I'm an Apache committer. I’ve been in Apache for over five years now, and I am an Apache member for a few years too. I can’t remember how many. The Camel team is comprised mostly of people from the ActiveMQ team and also from ServiceMix and Apache CXF communities. Plus, a bunch of other people have joined since then.
Gardner: Tell us a little bit about your relationship with Apache. You’re involved with a number of activities there. Is that right?
Strachan: I've been around Apache for many years now, and I am involved in all kinds of different projects -- ActiveMQ, ServiceMix are the big ones -- but also on a bunch of others, like Jakarta Commons, Maven, and many others.
Gardner: There are a number of terms we’ve been bandying around. Let’s assume that not everyone listening is that deeply into technology. When we talk about mediation and patterns, let’s flesh some of these out. Mediation and routing, how is that different from what people might understand generally under enterprise integration?
Strachan: I definitely recommend people read Gregor Hohpe's book "Enterprise Integration Patterns." He offers a really good patterns catalog of how people should do mediation and integration. Rather like the original Gang of Four "Design Patterns" book, which describes low-level programming things, Gregor’s book describes very well how enterprise integration patterns (EIPs) can work and gives us a language for describing them.
Aggregate, re-sequencer, message filter, and message translator generally describe patterns people commonly want to do within an integration solution. One of the simplest patterns is "content-based router," where you want to route messages around your network, based on the content. It might be, for example, that for gold-level customers you want to use the big, shiny, fast machines in your data center, but for bronze-level customers you use the crappy, old, worn Linux box in the corner of the basement.
Gardner: You mentioned earlier ESB, enterprise service bus. Explain to me how this works in terms of other ESBs. This is ESB-agnostic. Is it something that people will use to complement ESBs or perhaps replace them in some instances? What’s the relationship between Camel and an ESB?
Strachan: That’s a good question. In some ways the term "ESB" is a little bit like the terms "object" and "component," in that ESB is used for many different things. It has kind of lost a lot of its meaning. We typically don’t tend to think of Camel as being an ESB. We think of it as a rules-based routing and mediation framework that you may deploy inside an ESB.
We work very closely with the ServiceMix community at Apache which has created a complete Java Business Integration (JBI)-compliant container of JBI components. Camel can be deployed within the ServiceMix ESB among JBI components, but some people don’t use JBI and they may just use Java Message Service (JMS) or they may just use Web services or they may just be JAX-WS clients or whatever. So, we try to make Camel agnostic to technologies. You can use it within patterns like Spring, or JBI or OSGi, or you can use it within any application.
Gardner: I’ve also heard you refer to this as a domain-specific language project. What do you mean by that?
Strachan: Programming languages are often very general purpose. They can be used to solve any kind of problem. Domain-specific languages have become popular lately, and they’re basically tied to typically a business domain, such as investment banking, telco, or whatever. In Camel’s case, we’ve made a domain-specific language that focuses purely on the EIPs.
The language itself describes how to do the various things you typically do in the patterns, such as wire tap, aggregator, content-based router. These are first-class concepts within the language itself. We’ve implemented this domain-specific language in both Java and XML, so you can stick to a Java IDE if you prefer, or, if you’d rather, you can use XML to describe this language and deploy it inside your Spring XML.
Gardner: So, we’ve had vertical industry domain-specific languages. This seems to be more of a functionally domain-specific language. Is that a correct statement?
Strachan: Yes. The EIP is the functional domain, or rather the business domain.
Gardner: And, this is all about getting more granularity, more specialization for integration that nonetheless can play across a more general or horizontal capability. Is that fair?
Strachan: Definitely. Across all of IT we’re seeing increased specialization in many different areas, where the specialization helps us solve a problem at a higher level. If you spend your life solving problems, with, say, JavaBeans everywhere, you have a lot of code to comprehend and understand, and things can get quite complicated. The higher level of abstraction helps us solve problems easily.
Gardner: And, because we’re doing it an open-source environment where there’s a community involved, the more likelihood that this will be applied across many other different types of platforms and technology?
Strachan: Exactly. The other benefit of being with Apache is that we have a very liberal license, so this can be embedded in any commercial product very easily. We've seen lots of partners using this technology.
Gardner: Right. A few moments ago, we talked about ESBs. There has been, as you say, some divergence in the term ESB. There are also a number of products and approaches in the field. How about for Camel as a rules-based routing and mediation engine? Are there many others of those? Who else is trying to solve the same problem, or can we safely say that the Camel is unique?
Strachan: It depends on how wide you cast that net. Camel is unique in a number of ways. What we’re doing with Camel is defining a high-level language to describe EIPs, which I don’t think anybody else has done before. The other thing that’s unique is that this language very closely maps to components that work inside Spring 2.
We use a lot Spring 2 features, such as declarative transactions, inversion of control configuration, and various utility classes for working, with such things as JMS and JDBC and Java Persistence API (JPA). What we’re doing is raising the abstraction level to make things very simple, reducing the amount of XML we have to write, but still exposing the wire-level access if you need to do the really hard stuff and roll your sleeves up and get down and dirty.
Gardner: Let’s move this a bit closer to the business side. I wonder what sort of a problem set it is that we’re facing here. Is this a new approach to older problems or a new approach to newer problems? What's the problem solution fit here in the market?
Strachan: The problem we’re trying to address is the routing and mediation problem, which lots of people have. They're taking data from various components and sources -- whether it’s files, databases, message queues, Web services, instant messaging, or other data systems, integrating them together, formatting them, and connecting them to the systems. From a higher level perspective, this could be for legacy integration of systems, for smart routing, performance, monitoring, or testing or monitoring transaction flows.
In general, integration is a very old problem. As soon as we relate to couple of different computer programs, we already have an integration problem and that just grows with time. The thing that’s new is the approach that’s used. We're increasing the abstraction level by making it very easy to work at the EIP layer.
People don’t have to worry about the low-level details of how to use JMS, how to use JBI, or how to wire together the Spring components correctly, and so forth. We're giving people a nice, simple, high-level abstraction, but yet we are exposing all the power of frameworks like Spring and still exposing the low-level details if you need them.
Gardner: Over the last couple of years, because of the popularity and use of Web services, the business side wants to expand the interactions across not only applications, but organizations, and perhaps in a supply chain setting. It sounds like this helps solve the issue of inclusiveness across domains and businesses, and then adds the opportunity to start moving toward event-driven computing. Does that sound fair?
Strachan: Definitely. And, as soon as people start moving toward distributed systems, service oriented architecture (SOA), event-driven architectures, and all these other terms, the one thing that keeps happening is that people need a pervasive technology they can apply anywhere. Camel is lightweight, and can be used anywhere, in a smart end point, in an ESB, or a message broker.
ActiveMQ5 is coming out in [August, 2007]. That's going to have EIPs integrated in the client and the broker by Camel. ServiceMix has integration with Camel and CXF, as a project at Apache, which implements the JAX-WS standard that’s got EIP integration via Camel. We’re seeing a large number of projects that have EIP integration via Camel. It’s already proven in the open-source world that it’s very easy to reuse this routing and mediation technology anywhere. Hopefully, we'll see this just grow and grow.
Gardner: It’s curious to me. It seems like yesterday, but I suppose we're going on 10 years now, that a lot of these functions -- singular, distributed, perhaps even proprietary -- were combined into what became conceptually the application server. Now, it seems like we’re decoupling things. That one large application server approach might not be the best fit, as we get more types of routing and messaging in these integration patterns.
Can you expand on that? What's been the larger trend, in terms of architecture?
Strachan: There’s been a definite move away from J2EE apps, the big application servers, and people are looking for small, lightweight solutions that solve only the problem they have and not problems they don’t have. A lot of software vendors suffered from the kitchen-sink syndrome, where they tried to have one of everything in a big box. That just led to lots of complexity and redundancy.
People really want small and simple-to-use components that solve the problems they have. I've seen that throughout all of our customers. People ask for very specific solutions. They don’t say, "Give me a SOA." They say, "I need a message router," "I need a message bus," "I need an ESB," or "I need a services framework." Often, people have very specific requirements and are very much cherry-picking the best-of-breed components from the open-source tool set.
Gardner: So, it’s the Swiss Army Knife approach.
Strachan: Exactly.
Gardner: That works well for developers. I wonder over time how Camel might find itself being used in terms of operators, specifiers, and architects on the operational side of things. Do you see this moving in that direction? What’s the short-, medium-, and long-term implementation roadmap that you foresee for Camel?
Strachan: Today it's very much developer-focused. The current Camel is aimed at developers who are savvy with Java, XML, or Spring. What we want then is to gradually raise the abstraction level, so the architects and operational people can monitor services, monitor business processes, perform operational behavior, plus be able to design and deploy EIPs in a simple way.
For example, building tools and making it easier to design EIPs, as well as to choose a monitoring tool, are important.
Gardner: How would the specifying roadmap shake out? Do you think this is something that would get bundled in or integrated? How would this be something easily rationalized in production environments for those people that are going to be looking at large data center implementations?
Is this something that would be part of another grouping of products, other Apache kind of projects? How would this combine to make a whole larger than the sum of the parts?
Strachan: What we’ve seen over the last few years is a huge diversity in how people actually deploy products. Maybe five years ago, people assumed the world was J2EE app servers and everything would deploy in a J2EE deployment unit. These days, we see people make their own deployment units. We're seeing a lot of people move towards OSGi bundles. So we see a huge difference in the ways in which people deploy software now.
One of the reasons we’ve taken extreme steps to split Camel up and make it a very simple and easy to use bundle is that we know that there is a huge range of deployment platforms. Some people want to use Camel within their own smart end points. Some people want to host it inside the message broker, in the ESB and so forth. So, we see it going into production in many guises and many different forms.
Gardner: In IONA’s case, how would this be used in the context of its offering? I'm assuming that, as with other IONA offerings, it will be the commercial open-source support approach.
Strachan: Yes. Camel’s pretty much the core foundation for smart routing and mediation within an entire product suite. We have a product called FUSE, an open-source SOA backplane that provides a services framework, a message broker, an ESB, and a mediation and routing engine. The mediation and routing engine is based very heavily on Apache Camel, and we're using Apache Camel throughout other projects as well.
Gardner: Are there forums or community sites? How are some of the dialog and collaboration around this taking place?
Strachan: If you go to http://open.iona.com, there is a whole raft of documentation online forums, a wiki, and so forth.
Gardner: I know this is fairly early, but maybe this will be a good time to lay out some of the milestones. Are we expecting some significant developments and/or visions within the overall Camel project? Can you give us a bit of a timeline?
Strachan: It’s still fairly early for the timeline, but the next version of Camel 1.2 should be out fairly soon, and it's going to offer improved monitoring and management tools and particularly improved visualization and tooling.
Toward the end of the year, we’re hoping to improve various other capabilities we’ve added recently for extract, transform and load (ETL). It’s a way of loading data into systems and load testing systems with data. Plus, another area we’ve been developing what we call business activity monitoring (BAM), which helps monitor transaction flows across different systems.
For example, you might want to track that a purchase order in a system maps through to an invoice that comes out of another system. You might be processing a 100,000 of those a day, but there is one that goes along every few hours, and you want to find out which one that is within a small time window. That’s another area where we are extending the reach of Camel to do very complex and powerful monitoring.
Gardner: That's interesting, because this provides the actual routing mechanisms that provide a window into what's good, and also what's not good about how those processes are being built and used.
Strachan: Definitely. We’ve found that as soon as you have this very flexible and reusable integration patterns, it’s very easy to build on that, to build higher level abstractions, whether this is powerful testing frameworks, stimulation frameworks, ETL or BAM. We’re seeing the levels of abstraction increase to remove layers and layers of complexity.
Gardner: Is this something that could be applied to the ongoing -- and I imagine increasingly arduous -- task of dealing with semantic issues in terms of data across applications? That is to say, helping to define a mediation and a rules-based approach, such as this help in how companies can deal with that diversity and then come up with more common approaches to data and content that can then be injected into a business process.
Strachan: Definitely. This is a very large and complex topic. There are just a few bullet points on the top, and we’ve already got a range of transformation and validation capabilities in Camel, but we’re looking to improve this in various ways.
IONA recently acquired a company, called C24, which has a whole range of technologies for doing semantic mapping and transformation of different data formats. For example, they've got models for pretty much all the standard financial formats, like SWIFT, FpML, FIX, and all these other things. And, they've got other models for telcos. We’re looking to open source some of that and integrate that into Camel for doing lots of data service type integration.
Another area that’s kind of similar, but slightly different, is in the business activity monitoring ground, where you sometimes want to just check the effect of systems. So, it’s a little bit like I am doing real time reconciliation systems, and you’re doing all this transformation between systems, but you want to make sure of the end results, like that final purchase order or that final settlement instruction does contain the values that you expect. For example, we might want to check that the purchase order amount matches the invoice amount, or whatever.
Gardner: As you say, it’s early in the evaluation of Camel, but are there instances where we can see how it's being used or how developers have identified this as a productivity benefit, or are there metrics of productivity? How is it helping in terms of getting a better job done?
Strachan: We’ve got a bunch of different customers using Camel in different ways. We seem to have a few different kinds of customers finding Camel for the first time. Some come from an ActiveMQ background. They're doing lots of messaging, and they want something a bit more powerful to do more complex routing within the message broker itself.
Some come from the ServiceMix background. They are very ESB focused. They love JBI. They like the idea of standards-based ESB. They’ve got a bunch of standards-based integration components, but they’re working together, and they just want a slightly more powerful routing engine to work with.
Some of our customers have been using Mule. They found Camel a little bit easier, and they’ve migrated across. Finally, there are people who’ve just found Camel, that's all they know, and they just dive straight into it.
One of the things we’re seeing from customers is that using APIs, like JMS and JBI in particular, and to a lesser extent JAX-WS, could often become complicated, but people find that wiring things together with Camel is almost trivial. People get things going really quickly without having to read pages and pages of specifications for things like JMS or JBI, or dealing with the lower-level details of Spring.
We see quite a rapid productivity gain, and it means that people can then use lots of different technologies, whether it’s JMS or JBI without having to spend a long time figuring out things in the Spring manuals.
Gardner: Among these early users are there any vertical industries popping out, where it seems to be making sense first, perhaps financial services?
Strachan: Yes, finance and telcos definitely are big markets, but we’re also fairly strong in the e-tailers. Those areas will be our big three markets right now.
Gardner: Can you explain the business problems that they're using it for?
Strachan: Pretty much all of our customers have similar kinds of problems. They have lots of silos in applications. There are lots of messages being exchanged between systems, whether those are messages via flat files, email, JMS, legacy message brokers, or web services. They generally want to do one or more of the patterns, whether counter-based routing, or message transformations. We see more people starting to investigate a business activity monitoring feature of Camel, and that’s something I'm quite excited about.
Lots of companies, once they realize they can tie together messages to business processes, start running rules off the back of that. That has been extremely useful for people. One thing about SOA that’s quite difficult is knowing what’s really happening in your system.
Today, people have often done such things as monitor message queues or use a JMX-based management console to look at numbers and statistics. Being able to tie together all the different things flowing through your SOA to actual business processes is extremely useful and valuable for customers.
Gardner: There seems to be some murkiness in how feedback will occur, when you have events-driven architectures, and how to create common approaches to runtime and design time with this BAM emphasis that we are seeing associated with Camel. Do you expect that Camel could fill some of that role in terms of a balancing act between what takes place in operations and what needs to be brought into a service level agreement of some kind?
Strachan: Definitely. I have worked with quite a few customers on various BAM-related problems, and it does seem that BAM solves those problems. It’s quite hard to have an off-the-shelf tool to do everything people need. Almost as soon as people start doing any kind of BAM, they find that they want to put their own code in there. You might be in financing, and maybe there is a trade in U.S. dollars. You want to take that trade to the settlement instruction, but you want to do a foreign exchange conversion in there.
Almost as soon as you start doing the “hello world,” BAM-type scenarios, you tend to want to roll your sleeves up and actually do some coding of some kind, to do custom reconciliation, custom calculations, custom visualizations. BAM is very much a framework-driven thing, rather then a black-box tool. Certainly, we see people take on the Camel framework itself and then expand and extend it to do more powerful things.
Gardner: I suppose that’s part and parcel of open source, community-driven projects. They tend to be pushed out in a variety of directions. Do you have any sense of what other functional parts or functional capabilities we might see brought into Camel?
Strachan: A big area is visualization. It’s incredibly hard for people to follow what’s happening in general. Once you can create a wire tap into any system, it’s very easy to glean information from it and find out what’s happening, what its throughput is, what it is actually doing. You can then do things like trace messages around the system, correlate messages to business processes, reverse engineer whole business flows from legacy systems.
That whole area is a visualization and tooling problem. I see that as a very large area of research with the Camel project. We hope to be to be rolling out in Q4 the first batch of visualization tools. It's very much a work in progress in the next few years to get even better, more powerful operational controls and visualization engines.
Gardner: By getting more visual, it seems like we can bring more people into the process, and that maybe elevates us beyond BAM into business intelligence. Is that fair?
Strachan: Definitely. Absolutely.
Gardner: I think a lot of business people would like to get more of a real-time sense of what’s going on among these processes to provide more confidence, as they move processes from manual and older message into this new SOA approach.
Strachan: Definitely. Plus people want early warning notice of any kind of failure. One of the nice things is that you can be alerted that maybe something's going on that hasn't been found yet. Maybe it's running a bit slow today, or maybe it’s just a heavy trading day. But, it might not be, and maybe something is really wrong. So, rather than waiting for some extreme failure that results in a fine or extra interest being paid, you can respond more rapidly than that.
Gardner: Let’s just circle back quickly. Developers seem to be the core short- to medium-term audience for this. What sort of developers specifically should be more aware of what Camel’s capable of?
Strachan: I’d say anyone who’s doing any kind of SOA or distributed programming. They should at least take a good look. Definitely, anybody who ever read the EIP book. If you read that book, you’d probably just see Camel and you’ll immediately just figure out exactly what it’s doing. It’s very simple.
If you're doing Web services, you might need mediation. If you're doing any kind of messaging using multiple databases, if you have any kind of integration problems, and certainly if you’re using any kind of ESB, then definitely take Camel for a ride.
Gardner: Now, when we look toward getting more information on this, we have the resources at Apache Foundation, and also, as you mentioned, http://open.iona.com?
Strachan: Yes.
Gardner: Any other resources? You mentioned the book. Are there any other resources on this that people should be aware of?
Strachan: Those are the big three. There’s also my blog: http://macstrac.blogspot.com/.
Gardner: Very good. Well, we’ve been discussing a budding Apache Foundation project known as Apache Camel. It’s a rules-based routing and mediation engine for POJO-based implementation of EIPs.
Discussing this with us today, we had James Strachan, technical director of engineering at IONA Technologies.
I'm your host and moderator Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening and learning more about Apache Camel.
Listen to the podcast here. Podcast sponsor: IONA Technologies.
Transcript of Dana Gardner’s BriefingsDirect podcast on Apache Camel. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Showing posts with label development. Show all posts
Showing posts with label development. Show all posts
Thursday, August 16, 2007
Thursday, June 28, 2007
BriefingsDirect SOA Insights Analysts on Software AG's Acquisition of webMethods, Web 2.0 and SOA, and SOA Hype Curves
Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded April 6, 2007.
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, Volume 16, 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, ZDNet blogger and Redmond Development News Magazine columnist.
Our panel this week, and it is the week of April 2, 2007, consists of Steve Garone, a former IDC group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome, Steve.
Steve Garone: Hi Dana. Great to be here.
Gardner: Also joining us is Joe McKendrick. He is a research consultant, columnist at Database Trends and a blogger at ZDNet and ebizQ. Welcome back, Joe.
Joe McKendrick: Good morning, Dana.
Gardner: Also joining us is Jim Kobielus. Jim is a principal analyst at Current Analysis. Welcome back Jim.
Jim Kobielus: Hey, Dana. Hey, everybody.
Gardner: And, Tony Baer, Tony is a principal at OnStrategies. Hey, Tony!
Tony Baer: Hey, Dana, how are you doing?
Gardner: Great, and joining us as a first-time guest is Todd Biske. Todd is enterprise architect with MomentumSI, an Austin, Texas-based consultancy. Welcome to the show, Todd.
Todd Biske: Thanks, Dana, thanks for letting me join.
Gardner: My pleasure. Because of the big news this week with mergers and acquisitions in the SOA space, we’re going to take that as our top topic. We’re going to look at the announced acquisition of webMethods by Germany’s Software AG. We’re also going to talk about the role of Web 2.0 and SOA and perhaps delve into the notion of using wikis for governance, control, and management of assets and process.
If we have time, we’re going to jump into a discussion about SOA hype. Is SOA over-hyped or under-hyped, and that might take an hour in itself just to get started.
The news this week came as a surprise to me, and I think to many. Germany’s Software AG, a company with database and tools assets, best known for legacy implementations, legacy support -- and perhaps moving more toward modernization and, therefore, SOA -- for about $550 million in cash has announced an agreement to purchase webMethods based in the U.S., in Virginia.
WebMethods itself has recently gone through a series of acquisitions, including, most recently, Infravio. Our regular listeners may recall that we had a vice president from webMethods, Miko Matsumura, on the show just recently. So, let’s go around the table a little bit and get the take. I suppose the big questions are: Is this a big deal or a little deal, and is it a good deal or a bad deal? Let’s start with you, Steve Garone?
Garone: Well, that’s interesting question you just asked. I think it’s a good deal. I'm sure it’s a good deal for webMethods from a financial standpoint and for the folks who are going to profit individually from the acquisition. It’s also a good deal from Software AG's standpoint, given its direction to move more strongly into SOA, which I don’t think -- based on what I’ve seen -- it’s been extremely successful at doing over the last three or four years.
Software AG, if we go back maybe three, four, or five years, went through a series of fairly significant announcements with integration products and database enhancements focused on XML, leading it more toward modernizing into the web services, and eventually SOA, world. My perception is that from a business standpoint it has not been extremely successful at that, particularly in the United States.
So, this move really amounts to an effort to get a lot of customers onboard, customers who are using the webMethods products and suites. As you mentioned, we’ve talked about it on this show before. The governance aspects that resulted from the Infravio acquisition are particularly important for Software AG in terms of acquiring a customer base in the United States.
Gardner: You mentioned the price paid. We should point out the 25 percent premium that is apparently going to be paid by Software AG for webMethods that would be over its publicly traded price before the announcement.
Tony Baer, you had an interesting point in your blog. You’ve mentioned that this price, of roughly $550 million is a third, or significantly less, than the $1.3 billion that webMethods had paid back in 1999 for Active. What’s your take on this? Was this something that was of economic expediency? It seems like it happened fairly quickly after the Infravio acquisition?
Baer: Well, I think that webMethods has been looking for an exit strategy for some time, because basically they're trying to build up their SOA platform story. The fact is that large corporate customers are going to be nervous with a $200 million company. They’re probably a lot more comfortable with a company that’s closer to one billion, if they're looking for a platform play.
In terms of the pricing discrepancies, that just reflects the absurd valuations we had during the dot-com period. That was a very interesting irony. I actually liked the point you raised in your blog, Dana, which is the challenge of integrating German companies with companies of some other regions, especially the U.S. German companies tend to be very deliberate. Take a look at Shai Agassi’s recent departure from SAP. He just didn’t want to wait another couple of years to become CEO or whatever the title is over there.
Gardner: "If" he was going to become CEO.
Baer: Very good point. German companies are very deliberate. I don’t think he had the patience for that. One thing I want to point out is more of a key performance indicator. Software AG had, up until now, a very heavily promoted alliance with Fujitsu. In the area of BPM, Fujitsu would resell Software AG’s service bus and Software AG would resell Fujitsu’s BPM. BPM also happens to be one of the highlights of the webMethods acquisition.
One of the challenges that will be before Software AG, and I think an indicator as to whether they are successfully getting the message out to their customers, is how they handle this transition with BPM. Obviously, having an internal product is going to be a lot more attractive than having to partner for it. In fact, Software AG’s CEO told me that in a quote. So, it will be interesting to see how they handle that.
Gardner: How about you, Jim Kobielus? Do you think that this is a sales and channel opportunity to reach the Asia-Pacific region through the Fujitsu alliance and take what was a complementary fit in terms of North America and European Union presence for these two companies? Is this a technology play for all of the above?
Kobielus: I am not really up on the Fujitsu alliance with Software AG. So, I won’t comment on that. It’s very much a geographic jigsaw puzzle coming together here. Clearly, Software AG is very big in Europe, and not so much in the U.S., in terms of integration in BPM.
It’s pretty clear that from a geographic standpoint it’s very complementary. Actually, it’s more complementary from a product standpoint than many have been there willing to give it credit for. Software AG, as you’ve indicated, Dana, is very strong on legacy modernization of the whole mainframe-based setup products for development, databases, and so forth.
WebMethods is very strong on integration, BPM, and the whole SOA stack registries. There is some redundancy with Software AG’s products, such as the whole Crossvision Suite, but I think that from a technological standpoint webMethods is stronger on BPM, the repository, and all of those SOA components than the company that’s acquiring it.
There definitely are a lot of synergies there. Also, webMethods is a bit more visionary than Software AG on the SOA front and has been for quite a while. In fact, webMethods almost coined the term "Web services" back in the late 1990s, and they had a pre-SOAP implementation or a protocol that presaged or foreshadowed SOAP and the whole WS suite that came along. I think webMethods is still a more dynamic company than Software AG in a variety of ways.
Gardner: Let me just pause you there for a second. So, you’re saying that webMethods is ahead of its time, and Software AG might be behind the times, and so together they are going to be on time?
Kobielus: That's right. Software AG is a little bit stodgy and maybe that has to do with its national background. The whole German-versus-American alliance thing is kind of interesting. So, it’s ironic that a big German and a smaller American company are hooking up right now and trying to make a real go of it on SOA.
Another big German and another American company are divorcing -- DaimlerChrysler, of course. They want to get rid of the German stockholders of DaimlerChrysler, who want to jettison the Chrysler side of it and send it packing its bags back to Detroit. They cited the cultural difference, the Germans did. It didn’t work out.
Gardner: Just as a quick aside, it seems that you can pick up Chrysler for $4.5 billion. That seems like a small change for such a big company. If I had a few more bucks, I might consider it.
Garone: Based on the last Chrysler car I owned, I don’t think it’s a cultural issue.
Gardner: You could sell the bricks in the factory and Chrysler would make that money back.
Kobielus: I was reading in one of the articles in the press that Software AG and webMethods cited a cultural match, and that's why it’s a good synergistic deal for those guys. We’ll wait and see.
Gardner: Just the fact that you bring it up means it’s probably somewhat different, right? Let’s go to Todd Biske. Todd, I really enjoy your blog. I think you have a view of SOA that’s much more pragmatic and practical than some of us tea-leaf readers. You tend to eschew the products and look more to the process and the issue of changing the way people behave. Does this merger and acquisition mean anything to you?
Biske: I always like to follow what's going on. The interesting thing that only time will tell is what you’ve got filling the technology gap. We’ve seen a lot of the recent mergers, even just webMethod acquiring and Infravio for the registry/repository and governance solutions, fill the gap.
Clearly, this isn’t a case of filling a technology gap. It's more about geographic issues. But the question from an end user point of view is, when you combine two medium-sized companies, will you get a new big player or will you just get another medium-sized company, maybe like DaimlerChrysler, and the message just gets kind of watered down for both?
I don’t know whether this acquisition will really make a lot of large enterprises see them in a different light or not, when they’re comparing them against the likes of IBM or Oracle. It certainly creates a potential to do so, and that increased customer base can go a long, long way. We’ll see where we windup with it.
Gardner: Your point is well taken. I see this as kind of a risky activity and I agree that this is one-plus-one-equals-two, or one-plus-one-equals-three. And hopefully now, one plus one plus equals 1.3 or 1.5.
In a sense, the whole SOA notion might be affected by this, because if these companies don’t succeed, and they can’t make a multiplier effect, they can’t show that the whole is greater than sum of the parts. You'd have to ask yourself why two companies that are focusing more and more of their products and processes and approaches on SOA couldn’t pull their companies together.
A failure could happen for a number of reasons. It could be culture, but gee ... SOA has to do with culture. Or it could be geography, and gee ... SOA is supposed to be appealing to multinational companies. And, it could be technology, but gosh ... I hope not, because the SOA technology is suppose to allow for mixing, matching, and elevating to a services level of assets, and data resources, and then to bring the people and process together around that.
Does anyone else share my view that this has a somewhat high level of risk, in that, if doesn’t succeed, it could besmirch SOA in general?
McKendrick: I don’t think it’s going to have a huge impact, at least initially, on either besmirching SOA or advancing SOA. It’s a great metaphor. Have you folks seen the movie, "The Pursuit of Happyness," with Will Smith? I’ve spoken with Software AG on a number of occasions over the past three years. When I look at them, I think of the young Chris Gardner out there trying to sell these bone density scanners to hospitals and doctors. He said in the movie that these scanners are slightly better than X-Rays, but cost three times as much.
That kind of reminds me of Software AG. Software AG has been working very hard over the years to try to sell their products. They had Adabas, EntireX, Tamino, and Bolero. They've been really working hard trying to push these products, which maybe are slightly better than other products in the market out there. I’m not sure if they’re priced three times as high, but they have to work hard, and they just haven't quite risen to that level.
Maybe buying webMethods will give them that final break -- the internship at Dean Witter that Chris Gardner had in the movie. This is their breakthrough into the market.
Also Software AG's focus has always been the legacy market. That's what they have been good at. They bought Sabratec a couple of years ago, which provided very good legacy integration tools for iSeries, AS400 mainframes and that’s always been their focus.
webMethods has played in this integration and legacy market as well. This is a huge, untapped frontier -- the legacy integration side of SOA. There are hundreds of thousands of legacy systems that have yet to be leveraged and exposed. In the long run, there is a lot of potential for Software AG to be well positioned.
Gardner: Well, there are a number of companies that are focusing on legacy. IBM is trying to cover its flank in terms of, "If anybody is going to put the mainframe out of business, it’s going to be us." So, there is certainly a lot of business, and perhaps even more so in Europe and in the type of customers that Software AG has.
I want to throw the question out again. Does anyone want to share my perception that this is a risky merger, given the geography, the culture, and the fact that the SOA is in a sense on trial?
Baer: One thing struck me about both companies, which I think also sort of ups the level of risk. Both companies have been going to their own form of legacy migration. Software AG is obvious, but webMethods is another clear case in point. WebMethods initially was a B2B company, and then it bought Active Software for $1.3 billion, and that was suppose to be webMethods’ future. Unfortunately, they bought an EAI company, just as the EAI market peaked. So, in that post-2000 era, or post-Y2K, where SOA started to emerge, they start to seem a bit of a legacy player.
Over the last five years, they’ve been essentially reinventing themselves from EAI to SOA. If there's any risk here, it’s that maybe webMethods is a company that's a lot more open to change, because it had no choice. It doesn't have the cash cushion of Software AG, but you’re talking about two companies that are trying to undergo transition. That ups the risk factor. On the other hand, it might also up the motivation, as long as Software AG’s cash cushion doesn’t make them both too complacent and, as you say, Dana, the cultural differences don’t get in the way. Those are some very big "ifs."
Garone: I tend to agree with Tony, although I think it has to be put into context of what webMethods has gone through and continues to go through. I don’t think it’s unusual amongst vendors in the EAI space. If you look at the collection of those vendors, webMethods has done a really good job, relatively speaking, and they have a ways to go as they all do.
The platform vendors have had that issue, too. IBM had to move each product toward a more SOA-centric model and has also done a very good job. The point is, I don’t think that’s particularly unusual. There is risk here, culturally and technologically, but I really don’t see this risk as being major enough to influence the adoption of SOA or the SOA space in general.
Gardner: Okay, fair enough.
Kobielus: I find it risky from Software AG’s standpoint. They’re acquiring another vendor whose own customers are not avidly acquiring their new product. What I mean by that is, back in 2002, webMethods had license revenues of about $120 million, and it’s dropped. Last year, it was $84 or $85 million in software license revenues. This doesn’t sound like a healthy software vendor, and, to some degree, it sounds like webMethods' own customers regard them as being a legacy vendor, away from which they’re trying to migrate. That’s just the surface impression I get.
Biske: I don’t think it’s going to impact adoption of SOA or cast that all in a negative light. Interestingly, looking at the other risk to webMethods and to Software AG, how would we’d be perceiving this, if it was in the reverse direction with webMethods acquiring Software AG or even if it was presented as a merger of equals, rather than an acquisition? The fact that you’ve got the German company acquiring the U.S. company, what does that mean for the existing U.S. customers of webMethods, and how are they going to perceive this, because there are some cultural issues that have made it difficult for Software AG to gain ground in the U.S. market.
Garone: That’s an interesting point. I really can’t address the issue of whether this is financially feasible or not, but my first reaction was, "Why isn't this in the other direction?" I perceive webMethods as being better positioned and in a better business position generally than Software AG is.
Gardner: Well, they have certainly shown their interest in expansion, but I don’t think their cash position would have allowed this.
Garone: Right, that’s probably true.
Gardner: So, the desire might have been there, but not the means, right? Now, what about the point about Infravio and the registry/repository? We heard quite a bit from Miko about governance and policy, running an IT organization, and perhaps even a larger take on the whole management of business in general. It was a very visionary discussion we had, and yet Software AG has its own repository.
I frankly don’t know enough about them to put them side by side and pick a winner, but it seems that if Infravio and governance was going to be the tail that wagged the webMethods’ dog, and that this acquisition may show you a little different future for the role of registry and repository. Any thoughts on that issue?
Baer: It depends on who is going to be driving the agenda there. An early indicator is that Software AG has said that they want to keep webMethods’ management in place. That’s kind of interesting, because usually a CEO of an acquired company exits fairly tactfully, if it’s a friendly takeover. We’ll approach the interesting inflection point about 8 to 12 months down the pike, when we see who's really driving the SOA strategy at the combined company. That’s basically going to be the telling point.
Gardner: Okay, thanks, Tony.
Garone: I think that’s correct. The real pessimists out there -- I’m not sure I’m one of them -- would look at this and say there’s no doubt that webMethods is going to drive the SOA strategy. Software AG, in terms of revenue, is highly reliant on Adabas maintenance at this point and it's going to continue that way until it figures out how to leverage what it got via the acquisition of webMethods in the SOA space. I’m not quite sure I’m there, but there are some elements to that that may ring true.
Gardner: Yeah, this smacks of a good sales and channel match-up, and they might run webMethods as a subsidiary for some time. Then there's also this balance-sheet issue, where Software AG has recurring revenue. It’s got an old cash cow to continue to milk, and that gives webMethods an opportunity to be funded and financed -- without the vagaries of a quarterly report to Wall Street -- to pursue the larger brass ring here, which is SOA.
Kobielus: Dana, I’ll make a one last point there. I agree with that with what you just said. Software AG is a cash cow in the same way, for example, SAP is living off the substantial legacy of a very well-entrenched set of products. My first reaction to the webMethods acquisition was how they finally put webMethods out of its misery. When I say misery, how long has it been? WebMethods is about 11 or 12 years old now, and it seems that for most of their history they have been in some financial trouble or shakiness. It’s just been one thing after another, and it’s like they don’t get a break.
Now, they seem to have a corporate parent that has a comfort pillow for them, some money to fund ongoing development, diversification, and so forth. Software AG pulled webMethods out of their misery and has given them a new lease on life.
Gardner: Thanks, Jim. Yeah, maybe then make them the R&D department in a sense, right? Okay, a final word on this issue to Joe McKendrick. Joe, this relates somewhat to our discussions from the past about best-of-breed versus integrated-stack-and-suite. Clearly, these companies think that bigger is better and more is better. Does this change your thinking on the best-of-breed versus integrated-suite issue at all?
McKendrick: Well, as we discussed in a previous podcast, the whole notion of an SOA suite runs counter to the SOA philosophy. SOA is especially about loosely coupling, and it doesn’t matter where the applications or the system resides. SOA should be independent of all that, and the idea of an SOA suite runs counter to that thinking. Nevertheless, we see lot of companies glomming onto each other, a lot of gelling taking place. This Software AG-webMethods merger is an example. Progress Software has been very astute in assembling a collection of companies that deal with different aspects of SOA. They want to compete with Oracles, and we saw that just recently with JBoss.
Gardner: SOA Software?
McKendrick: Yeah, right. SOA Software and JBoss. Their goal, their intention is to compete against these bigger guys, while servicing the smaller business market, of course.
Gardner: More of an ecology approach to how to bulk up.
McKendrick: Yeah, we’re going to see more of these alliances, more of these acquisitions and mergers.
On Web 2.0 and SOA ...
Gardner: Let’s move on to our second topic, which is this notion of Web 2.0 and SOA. Now, Web 2.0, of course, can be defined many ways in the market. Some people look at it as simply a rich Internet application interface approach. Others focus on the collaborative social networking aspects of it. Yet others look at Web 2.0 as simply going from an HTML and text page-driven Web to more of a process and semantic Web.
So, let’s just leave the Web 2.0 definition off the table and look at the issue of any of these new activities, whether it’s social networking or rich Internet application interfaces or whether it’s taking advantage of more semantics and BPEL as a process relating to Web activities instead of just as a publishing medium.
Let’s just say, "All of the above" for defining Web 2.0 and how this relates to SOA. I want to go first to Jim Kobielus, because in some emails this week you had some interesting thoughts. We’ve seen a few companies say, "Let’s leverage Web 2.0." We’ve seen Intel come out and say, "We’re going to corral a number of 'open-source' Web 2.0 functions." We’ve seen Cisco get involved with Web 2.0. We’ve seen BEA just announce an embrace of Web 2.0. Even IBM is tinkering with this, I’m sure.
So, there is something there, but let’s focus on this collaborative aspect and particularly in terms of governance. Annrai O’Toole at Cape Clear mentioned this to me probably about nine months ago that he looked at governance and at Web 2.0 and thought, "Gee, maybe wikis would be a good concept for how people manage their services." They could say, "I think the policy should be this, and I’m going to use it in this way, and you can pick and choose."
It's sort of an open source, open collaboration approach to policy and use of services and their agreements. I suppose provisioning rules would come about. You said, Jim, this is kind of a scary concept, that wikis seem to be anti-governance and that it could be a collaboration with no structure. Tell us a little bit about why you’re concerned?
Kobielus: Well, when I think of governance, like everybody I think of the capital "G," like Government, but governance has a broader concern. You often think about crack-the-whip, controls, and setting controls on how people interact and how policies are created? When I think about wikis, I think of the exact opposite. There are no controls. It’s basically a shared space to which everybody can post, everybody can overwrite, and everybody can erase everybody else’s comments.
Gardner: The wisdom of the crowd, right?
Kobielus: Well, okay, that’s a religious faith. Wiki seems like the wild, wild West. It’s a free-for-all as collaboration. That’s great. It’s definitely got a very valid role in many environments, like open-source initiatives where they are very peer oriented. Everybody is an equal, even-steven, participant. There is a high emphasis on collaboration, design, reciprocity, and all of that. So, when I think about the whole SOA governance space, both design-time governance and run-time governance, I think of wiki as in the design-time governance side, where you have teams of designers or business analysts and IT people sitting around the virtual table, trying to hash out policies.
Gardner: Requirements?
Kobielus: Requirements, policies, data designs, data hierarchies like with their master data management environment. Quite often these are creative processes involving teams of smart people who sit around a virtual table and hash out the overall design approach. Wikis and the whole Web 2.0 repertoire of collaborative tools can be very valuable in this upfront design, modeling, simulation, and shoot-the-breeze aspects that are critically necessary for design time. But runtime SOA governance really depends on clear-cut policies, designs, data definitions, and so forth that have been handed down by the policy gurus, and now are governing ongoing operations without ambiguity.
In that case, you don’t necessarily want any Joe Blow to be able to overwrite the policies and the business rules that are guiding the ongoing monitoring, management control, or security of your SOA.
Gardner: Yes. You said that they needed adult supervision, but I didn’t think that this would be open to anybody. I thought this would be open to the people who have impact, the architects and the line-of-business people perhaps. You're not going to open this up to anybody. There would be a directory and an provisioning, so that only those most close would have access.
Let’s go to the real world. Todd Biske, does it make sense to you? Should we be collaborating among the right people with the right access and privileges in how SOA governance is improved over time?
Biske: I don’t know that you really want a wiki-style collaboration for governance. I tend to agree with Jim that you can’t just open it up to the masses, and even if you look at collaborative environments, whether it’s the large open-source projects, or something like Wikipedia, there's some hierarchy that eventually was put in place, where certain people were allowed to do commits or were designated as senior editors.
So, you always wind up with some form of governance structure around that. The area where I think wikis are going to be important in the SOA space is in the service management lifecycle or service development lifecycle. You got companies that have to move to a service-provider model, whether it’s internally to internal consumers or externally. I have talked a lot about this in my blog.
If we compare that to traditional product management, for a long time it was really just one-way communication. The product marketers went out and said, "Here’s our product. Here are its features. Go and use it." They pushed it out to the market place, and the only response they got back was did people buy the product or not.
Over time, they recognized the need for much more collaboration with their end consumers on how to evolve that product, whether it was the formation of customer advisory boards or even leveraging the Internet and some of the technologies to establish a community around those products. The same thing can apply when adopting SOA.
If I am providing a service out to the rest of the enterprise, I am going to be interested in what the consumers of that have to say. If I am not listening to them, not establishing that bi-directional communication, eventually they are going to go somewhere else or they are going to build it on their own and put that redundancy back into the organization, which is the opposite of what we are trying to achieve.
Gardner: Okay. So social networking has a value here, but you wouldn’t want it necessarily hardwired into the way in which the technology actually operates?
Biske: Exactly.
Gardner: Okay, I can buy that. Does anyone else have any thoughts on this notion of wikis and collaboration as applied to SOA governance?
Garone: I don’t really have a lot to add. The two guys who just talked gave a great view of this particular question, and I agree with virtually all of it. After a while, it becomes something that a few key contributors, people who actually have the power, control, and knowledge, would be part of. I waxed philosophical in my head and asked, "Well, is it then still a wiki or is it in fact a collaborative tool among a set of decision-makers who, through policies themselves, are able to make changes or not?"
Gardner: I think you're right. The key word here is collaboration. I believe that IBM is going to be coming out soon with something called Jazz, which is a collaborative application lifecycle management approach. We are seeing more collaboration across different aspects of the whole development-to-deployment environment and we are looking for the tools to do that. Web 2.0 is perhaps stepping up and saying, "We have some tools that can be used in that way." Perhaps, it's not just a matter of dropping a wiki into the process, but something a bit more tailored to an aspect, but somehow availing all the participants of each others' wisdom in the process.
Kobielus: It’s like an open source project. You have a broad range of contributors, but only a handful of committers who can actually commit changes to the underlying code base. So, you might have a wiki that has potentially 3,000 different contributors, but ultimately there might be a moderator or two whose job it is to periodically weed out the nonsense, and crack the wiki whip to make sure that what’s actually been posted reflects the wisdom of the crowd of 3,000 people and not necessarily the vandalism of the few who decide to just disrupt the process.
Garone: And that’s a governance model in itself.
Gardner: Yeah, that’s right. It’s governance, and it relates back to what we’ve discussed in trying to find analogies in geo-politics for technology governance. You want the best of both. You want a federated approach, where they get grassroots input, but you also need command and control. So, it’s Jefferson and it’s Hamilton, right?
Kobielus: It’s Aaron Burr occasionally too. You’re going to follow the pistols.
Gardner: I heard an interesting analogy the other day. We talked about the chicken and the egg, and somebody said, "What about the rooster?"
Alright, let’s move on. Before we leave with Web 2.0, does anyone else have any inputs about the role of Web 2.0? As I said, it’s a very large subject, and then it evolves into Enterprise 2.0 issues, which have lot to do with software as a service and delivery of service. There is the mash-up notion of creating services and then compositing them, even if not with an application purpose or a process, which is letting people change their interfaces and drag and drop things.
We have seen some information from Google Maps this week that have lent more credence to this. I’ll just throw it out to the crowd, any other beauty tips or predictions for the future about where Web 2.0 and SOA come together or not?
Kobielus: Web 2.0 is really HOA, Human Oriented Architecture. It is pretty much giving human beings the tools to share what’s in their minds, to share their creativity with the big wide world. SOA, Service Oriented Architecture, is about sharing and reusing all matter of resources in a standardized way. HOA, the Web 2.0, is the most critical resource, and the most inexhaustible energy supply is human ingenuity and creativity.
Gardner: That’s like Cosmic 2.0. Woah!
Kobielus: Yeah, I have been known to get cosmic. People who have read my blog realize that I am a total space cadet.
Baer: Jim, I'll give you the award this morning for coining the best buzz words, like "Cracking the wiki whip" and "Human Oriented Architecture."
Gardner: Now, any other thoughts before we leave the Web 2.0 subject area?
McKendrick: This may be just a rumor, but I once heard that there was a company, an enterprise with several architectural teams, and these teams actually met face to face once a year to discuss things. That's just a rumor. I am not sure if it’s true.
Gardner: They had to leave their guns and knives at the door.
McKendrick: Exactly. So, Web 2.0 can only help the situation, help break down some of these walls.
On SOA and the Hype Curve ...
Gardner: Okay, let’s move on to our last subject of the day -- we only have a few more minutes -- but it’s the notion of hype. I just noticed, looking around some of the SOA information that was floating around the Web, we seem to be now in the, past-the-peak of the hype curve on SOA and are apparently, from what they say, approaching the "trough of disillusionment."
I took exception with that. I am not sure we’ve even hyped SOA sufficiently and that we are still ramping up on this one. Does anybody else agree with me that SOA is so large, so long-term, and crosses not into just technology but business in organizing behaviors and even redefining the corporation itself? My point is that we are not hyping SOA enough. Anybody agree or disagree?
Biske: I tend to agree with you that the communication isn’t hitting home and it’s not sinking in. I had a blog I know Joe picked up on at one point that talked about companies that are claiming success with SOA. I pointed out that a lot of these companies are the same ones that claim success with virtually every new technology adoption or business adoption, because their culture is well suited to that. There is still a lot of of companies that just don’t know how to do cultural change. It’s not an easy thing to do.
We hyped SOA a lot from the IT perspective, and a lot of the IT managers certainly may be growing tried of hearing about it, but haven't done anything to actually start that process of cultural change. Is it really adopted by the business side and do they understand what it means and how it can impact our business? If they aren't having those communications, we haven’t really changed anything, and that means they’re still open for that message to continue, and to increase.
Gardner: You are saying that managing change well is a core competency, will be an important aspect of any SOA activity, and perhaps SOA adoption could help companies improve the way that they manage change?
Biske: Absolutely. Back when I was working at an enterprise, I had somebody ask me, "How do I build this service so that it meets the enterprise needs?" And I said, "You don’t. You build it to what you know now, and you understand what your processes are going to need to be to change it in the future? Because it is going to change. Think from a change-first perspective, and how you want to manage that process, rather than stick it out there, not want to have it touch it for 10 years, and have it last forever."
Gardner: Well, not to change this subject, but who else agrees with Todd and me?
Garone: You used an expression earlier, "trough of disillusionment." Those words come easily, because they have been used before. That’s because we go through this cycle every time some disruptive technology comes along. The hype gets really high, and the adoption and the use of the technology lags behind, depending on a variety of factors.
I think the SOA hype is pretty high, but I think that it's difficult to sell to decision-makers due to two factors: 1) the degree to which cultural change needs to take place, and 2) as time has progressed through this decade so far we’ve seen greater caution in IT departments because of shrinking budgets. So, the hype is high, but it needs to be sustained longer with messaging that’s going to be more aligned with business goals, rather than technology.
Gardner: We seem to be in a cheap era when it comes to IT, and ironically it’s coming at a time when the Dow is flirting with a record high, even though it has been a bumpy road in the market for the past couple of months. We are still within a Curt Shilling breaking ball of the record, and companies are enjoying record levels of profit, record growth.
Many of them are sitting on record piles of cash. Capital around the world is still at very cheap level, taxes are at a record low in real terms and are dropping in many countries. If there’s any time to invest in IT for the future, this should be it? And yet we’re not seeing it.
Kobielus: Oh, it’s not inconsistent, Dana, with SOA not succeeding. In fact SOA, the model of SOA practically could be: Do more with less.
Gardner: Yeah, but you've got to spend something to allow for your older systems to be freed up and excise the services. That doesn’t come free.
Biske: One thing you have to be cautious with ... Just as we talked about that things change quickly, a number of businesses got burned in the dot-com boom when stock markets were also very high and revenues were increasing. They increased their IT spending, and then the bottom dropped out of it.
Gardner: But, here it’s 2007. It’s been seven years since this crash.
Baer: But, Dana, probably the major reasons -- and the big difference this time -- is that on the IT side there isn't the same sense of urgency. We don't have this Y2K thing staring us at the face, telling us that we must renovate all those legacy systems that are out there -- either renovate or replace. You don’t have the same drama in the headlines all the time. That’s dropped the sense of urgency.
Combine that with the fact that a lot of organizations felt that they got burned the last time they opened up the purse strings.
That’s probably a large part of the reason why you’re seeing much more deliberate spending. To that extent, it can be a positive force in terms of enforcing some discipline. On the other hand, if you want to do SOA right, do you need to invest upfront to do that planning and architecture? I'm not sure that IT organizations have gotten that message.
Gardner: Perhaps there’s more. We keep going back to the crash, but after the crash, we had a series of corporate scandals and meltdowns that really couldn’t be blamed on hyping IT. They had to do a lot more with malfeasance and neglect. We also had a period where we saw new laws and a different compliance atmosphere.
So it could be that companies are being run more by the accountants -- of, for, and by the accountants -- and therefore the vision around IT is not getting through to them, and the purse strings are not opening up. Is that possible?
Koblielus: You’re pretty much on the mark there. I was talking with one CIO about a year or so ago, after about the first year of Sarbanes-Oxley, and she said that the impact of SOX translates to shutting down IT for about 90 days out of the year, just so that they could just account for their tracks over the previous three quarters.
Gardner: Does anyone else concur that the accountants have run amok, and that the IT guys have very good rationales for spending, but they just can’t get the money?
McKendrick: One effect of the whole compliance scenario was that it gave vendors another hype factor. I'm going to try another buzz word. How about Hype-Oriented Architecture? HOA. Using Jim’s HOA for another purpose.
Kobielus: It’s better to have hype-oriented accounting.
McKendrick: Hype-oriented accounting? I think the whole compliance thing gave a boost to the IT industry in the early 2000s. What do we call this decade anyway, the 2000s?
Gardner: The oughts.
McKendrick: It gave the whole industry a boost at a time when things were kind of down with the IT recession. The whole compliance scenario helped business intelligence and the data-environment vendors who directly addressed the flow of financial information.
Gardner: I’d like to conduct an experiment. I think we should take an accountant out to lunch. Anyone who knows an accountant, take them out to lunch and tell them how great IT is and what SOA can do in terms of long-term efficiency and lower total costs. Bring in some of the other mega trends, such as software as a service, virtualization, and data master management. It behooves us all to educate the accounts on why IT is important, because I think they are suffering from a lack of understanding.
Better yet, take a chief financial officer out to lunch and then take the accountants out to lunch. This is the crowd we need to work on. We keep talking about trying to convince the CEO and the CIO, and I think we need to get right down into the bean counters' frontal lobes on SOA.
Biske: Not to move away from the accountants, but one group I hope will keep the hype going is this newly formed SOA Consortium that OMG is sponsoring. It's an advocacy group, not another standards body coming, into the mix. It would be great to start to see a message come from a collection of end-users that are seeing some success with this, rather than being pushed so strongly by the vendor community.
I think it’s a different type of hype. It is one that will be a bit more pragmatic. Hopefully it will continue the pace, and they’ll achieve the goals that they have set out for themselves. I don’t know if they have any accountants in the consortium, but maybe this will help them bring some in.
Gardner: Well, we'll invite them and try to give them a free membership. They should cotton to that, right?
McKendrick: Often, it’s the stuff going on in the consumer space that begins to leach into the enterprise. Any excitement going on in the consumer space, eventually translates into excitement within the walls of the corporation about a certain technology. We saw that with the PCs and we saw that with the Internet. If anything is going on out there in the consumer space right now, it is Web 2.0, going back to the Web 2.0 discussion.
Gardner: Oh, we know how profitable that is.
McKendrick: It's where the excitement is in the corporation that begins to drive the investment. To paraphrase Wall Street's Gordon Gecko, hype is good.
Gardner: Greed was good in the 1980s -- hype is good in "the oughts."
McKendrick: Because it raises that level of excitement, and that’s why you need to get the attention of the bean counters, the CIOs, and the CEOs, most importantly.
Gardner: Well, here’s the message. Take your hype to your accountants and your CFOs and then make them join the SOA Consortium. I am always tempted at the signoff period of our discussion to take a cue from the Car Talk guys and say, "You’ve wasted another completely good hour," but I am not going to do it
Koblielus: And don't drive like my brother
Gardner: And don’t implement your IT like my brother. We have been joined here once again on our SOA Insights Edition by Steve Garone. Thanks, Steve.
Garone: Thank you Dana. It has been a pleasure.
Gardner: Joe McKendrick.
McKendrick: Thanks, Dana. It is good to be here.
Gardner: Jim Kobielus.
Kobielus: Another pleasurable morning.
Gardner: Tony Baer.
Baer: Another hour not wasted.
Gardner: Our guest -- please come back again Todd; we enjoyed having you -- Todd Biske.
Biske: Thanks, this is a lot of fun. I hope to be back.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to Volume 16 of BriefingsDirect, SOA Insights Edition. Thanks, and come back again next time.
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. 16. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
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, Volume 16, 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, ZDNet blogger and Redmond Development News Magazine columnist.
Our panel this week, and it is the week of April 2, 2007, consists of Steve Garone, a former IDC group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome, Steve.
Steve Garone: Hi Dana. Great to be here.
Gardner: Also joining us is Joe McKendrick. He is a research consultant, columnist at Database Trends and a blogger at ZDNet and ebizQ. Welcome back, Joe.
Joe McKendrick: Good morning, Dana.
Gardner: Also joining us is Jim Kobielus. Jim is a principal analyst at Current Analysis. Welcome back Jim.
Jim Kobielus: Hey, Dana. Hey, everybody.
Gardner: And, Tony Baer, Tony is a principal at OnStrategies. Hey, Tony!
Tony Baer: Hey, Dana, how are you doing?
Gardner: Great, and joining us as a first-time guest is Todd Biske. Todd is enterprise architect with MomentumSI, an Austin, Texas-based consultancy. Welcome to the show, Todd.
Todd Biske: Thanks, Dana, thanks for letting me join.
Gardner: My pleasure. Because of the big news this week with mergers and acquisitions in the SOA space, we’re going to take that as our top topic. We’re going to look at the announced acquisition of webMethods by Germany’s Software AG. We’re also going to talk about the role of Web 2.0 and SOA and perhaps delve into the notion of using wikis for governance, control, and management of assets and process.
If we have time, we’re going to jump into a discussion about SOA hype. Is SOA over-hyped or under-hyped, and that might take an hour in itself just to get started.
The news this week came as a surprise to me, and I think to many. Germany’s Software AG, a company with database and tools assets, best known for legacy implementations, legacy support -- and perhaps moving more toward modernization and, therefore, SOA -- for about $550 million in cash has announced an agreement to purchase webMethods based in the U.S., in Virginia.
WebMethods itself has recently gone through a series of acquisitions, including, most recently, Infravio. Our regular listeners may recall that we had a vice president from webMethods, Miko Matsumura, on the show just recently. So, let’s go around the table a little bit and get the take. I suppose the big questions are: Is this a big deal or a little deal, and is it a good deal or a bad deal? Let’s start with you, Steve Garone?
Garone: Well, that’s interesting question you just asked. I think it’s a good deal. I'm sure it’s a good deal for webMethods from a financial standpoint and for the folks who are going to profit individually from the acquisition. It’s also a good deal from Software AG's standpoint, given its direction to move more strongly into SOA, which I don’t think -- based on what I’ve seen -- it’s been extremely successful at doing over the last three or four years.
Software AG, if we go back maybe three, four, or five years, went through a series of fairly significant announcements with integration products and database enhancements focused on XML, leading it more toward modernizing into the web services, and eventually SOA, world. My perception is that from a business standpoint it has not been extremely successful at that, particularly in the United States.
So, this move really amounts to an effort to get a lot of customers onboard, customers who are using the webMethods products and suites. As you mentioned, we’ve talked about it on this show before. The governance aspects that resulted from the Infravio acquisition are particularly important for Software AG in terms of acquiring a customer base in the United States.
Gardner: You mentioned the price paid. We should point out the 25 percent premium that is apparently going to be paid by Software AG for webMethods that would be over its publicly traded price before the announcement.
Tony Baer, you had an interesting point in your blog. You’ve mentioned that this price, of roughly $550 million is a third, or significantly less, than the $1.3 billion that webMethods had paid back in 1999 for Active. What’s your take on this? Was this something that was of economic expediency? It seems like it happened fairly quickly after the Infravio acquisition?
Baer: Well, I think that webMethods has been looking for an exit strategy for some time, because basically they're trying to build up their SOA platform story. The fact is that large corporate customers are going to be nervous with a $200 million company. They’re probably a lot more comfortable with a company that’s closer to one billion, if they're looking for a platform play.
In terms of the pricing discrepancies, that just reflects the absurd valuations we had during the dot-com period. That was a very interesting irony. I actually liked the point you raised in your blog, Dana, which is the challenge of integrating German companies with companies of some other regions, especially the U.S. German companies tend to be very deliberate. Take a look at Shai Agassi’s recent departure from SAP. He just didn’t want to wait another couple of years to become CEO or whatever the title is over there.
Gardner: "If" he was going to become CEO.
Baer: Very good point. German companies are very deliberate. I don’t think he had the patience for that. One thing I want to point out is more of a key performance indicator. Software AG had, up until now, a very heavily promoted alliance with Fujitsu. In the area of BPM, Fujitsu would resell Software AG’s service bus and Software AG would resell Fujitsu’s BPM. BPM also happens to be one of the highlights of the webMethods acquisition.
One of the challenges that will be before Software AG, and I think an indicator as to whether they are successfully getting the message out to their customers, is how they handle this transition with BPM. Obviously, having an internal product is going to be a lot more attractive than having to partner for it. In fact, Software AG’s CEO told me that in a quote. So, it will be interesting to see how they handle that.
Gardner: How about you, Jim Kobielus? Do you think that this is a sales and channel opportunity to reach the Asia-Pacific region through the Fujitsu alliance and take what was a complementary fit in terms of North America and European Union presence for these two companies? Is this a technology play for all of the above?
Kobielus: I am not really up on the Fujitsu alliance with Software AG. So, I won’t comment on that. It’s very much a geographic jigsaw puzzle coming together here. Clearly, Software AG is very big in Europe, and not so much in the U.S., in terms of integration in BPM.
It’s pretty clear that from a geographic standpoint it’s very complementary. Actually, it’s more complementary from a product standpoint than many have been there willing to give it credit for. Software AG, as you’ve indicated, Dana, is very strong on legacy modernization of the whole mainframe-based setup products for development, databases, and so forth.
WebMethods is very strong on integration, BPM, and the whole SOA stack registries. There is some redundancy with Software AG’s products, such as the whole Crossvision Suite, but I think that from a technological standpoint webMethods is stronger on BPM, the repository, and all of those SOA components than the company that’s acquiring it.
There definitely are a lot of synergies there. Also, webMethods is a bit more visionary than Software AG on the SOA front and has been for quite a while. In fact, webMethods almost coined the term "Web services" back in the late 1990s, and they had a pre-SOAP implementation or a protocol that presaged or foreshadowed SOAP and the whole WS suite that came along. I think webMethods is still a more dynamic company than Software AG in a variety of ways.
Gardner: Let me just pause you there for a second. So, you’re saying that webMethods is ahead of its time, and Software AG might be behind the times, and so together they are going to be on time?
Kobielus: That's right. Software AG is a little bit stodgy and maybe that has to do with its national background. The whole German-versus-American alliance thing is kind of interesting. So, it’s ironic that a big German and a smaller American company are hooking up right now and trying to make a real go of it on SOA.
Another big German and another American company are divorcing -- DaimlerChrysler, of course. They want to get rid of the German stockholders of DaimlerChrysler, who want to jettison the Chrysler side of it and send it packing its bags back to Detroit. They cited the cultural difference, the Germans did. It didn’t work out.
Gardner: Just as a quick aside, it seems that you can pick up Chrysler for $4.5 billion. That seems like a small change for such a big company. If I had a few more bucks, I might consider it.
Garone: Based on the last Chrysler car I owned, I don’t think it’s a cultural issue.
Gardner: You could sell the bricks in the factory and Chrysler would make that money back.
Kobielus: I was reading in one of the articles in the press that Software AG and webMethods cited a cultural match, and that's why it’s a good synergistic deal for those guys. We’ll wait and see.
Gardner: Just the fact that you bring it up means it’s probably somewhat different, right? Let’s go to Todd Biske. Todd, I really enjoy your blog. I think you have a view of SOA that’s much more pragmatic and practical than some of us tea-leaf readers. You tend to eschew the products and look more to the process and the issue of changing the way people behave. Does this merger and acquisition mean anything to you?
Biske: I always like to follow what's going on. The interesting thing that only time will tell is what you’ve got filling the technology gap. We’ve seen a lot of the recent mergers, even just webMethod acquiring and Infravio for the registry/repository and governance solutions, fill the gap.
Clearly, this isn’t a case of filling a technology gap. It's more about geographic issues. But the question from an end user point of view is, when you combine two medium-sized companies, will you get a new big player or will you just get another medium-sized company, maybe like DaimlerChrysler, and the message just gets kind of watered down for both?
I don’t know whether this acquisition will really make a lot of large enterprises see them in a different light or not, when they’re comparing them against the likes of IBM or Oracle. It certainly creates a potential to do so, and that increased customer base can go a long, long way. We’ll see where we windup with it.
Gardner: Your point is well taken. I see this as kind of a risky activity and I agree that this is one-plus-one-equals-two, or one-plus-one-equals-three. And hopefully now, one plus one plus equals 1.3 or 1.5.
In a sense, the whole SOA notion might be affected by this, because if these companies don’t succeed, and they can’t make a multiplier effect, they can’t show that the whole is greater than sum of the parts. You'd have to ask yourself why two companies that are focusing more and more of their products and processes and approaches on SOA couldn’t pull their companies together.
A failure could happen for a number of reasons. It could be culture, but gee ... SOA has to do with culture. Or it could be geography, and gee ... SOA is supposed to be appealing to multinational companies. And, it could be technology, but gosh ... I hope not, because the SOA technology is suppose to allow for mixing, matching, and elevating to a services level of assets, and data resources, and then to bring the people and process together around that.
Does anyone else share my view that this has a somewhat high level of risk, in that, if doesn’t succeed, it could besmirch SOA in general?
McKendrick: I don’t think it’s going to have a huge impact, at least initially, on either besmirching SOA or advancing SOA. It’s a great metaphor. Have you folks seen the movie, "The Pursuit of Happyness," with Will Smith? I’ve spoken with Software AG on a number of occasions over the past three years. When I look at them, I think of the young Chris Gardner out there trying to sell these bone density scanners to hospitals and doctors. He said in the movie that these scanners are slightly better than X-Rays, but cost three times as much.
That kind of reminds me of Software AG. Software AG has been working very hard over the years to try to sell their products. They had Adabas, EntireX, Tamino, and Bolero. They've been really working hard trying to push these products, which maybe are slightly better than other products in the market out there. I’m not sure if they’re priced three times as high, but they have to work hard, and they just haven't quite risen to that level.
Maybe buying webMethods will give them that final break -- the internship at Dean Witter that Chris Gardner had in the movie. This is their breakthrough into the market.
Also Software AG's focus has always been the legacy market. That's what they have been good at. They bought Sabratec a couple of years ago, which provided very good legacy integration tools for iSeries, AS400 mainframes and that’s always been their focus.
webMethods has played in this integration and legacy market as well. This is a huge, untapped frontier -- the legacy integration side of SOA. There are hundreds of thousands of legacy systems that have yet to be leveraged and exposed. In the long run, there is a lot of potential for Software AG to be well positioned.
Gardner: Well, there are a number of companies that are focusing on legacy. IBM is trying to cover its flank in terms of, "If anybody is going to put the mainframe out of business, it’s going to be us." So, there is certainly a lot of business, and perhaps even more so in Europe and in the type of customers that Software AG has.
I want to throw the question out again. Does anyone want to share my perception that this is a risky merger, given the geography, the culture, and the fact that the SOA is in a sense on trial?
Baer: One thing struck me about both companies, which I think also sort of ups the level of risk. Both companies have been going to their own form of legacy migration. Software AG is obvious, but webMethods is another clear case in point. WebMethods initially was a B2B company, and then it bought Active Software for $1.3 billion, and that was suppose to be webMethods’ future. Unfortunately, they bought an EAI company, just as the EAI market peaked. So, in that post-2000 era, or post-Y2K, where SOA started to emerge, they start to seem a bit of a legacy player.
Over the last five years, they’ve been essentially reinventing themselves from EAI to SOA. If there's any risk here, it’s that maybe webMethods is a company that's a lot more open to change, because it had no choice. It doesn't have the cash cushion of Software AG, but you’re talking about two companies that are trying to undergo transition. That ups the risk factor. On the other hand, it might also up the motivation, as long as Software AG’s cash cushion doesn’t make them both too complacent and, as you say, Dana, the cultural differences don’t get in the way. Those are some very big "ifs."
Garone: I tend to agree with Tony, although I think it has to be put into context of what webMethods has gone through and continues to go through. I don’t think it’s unusual amongst vendors in the EAI space. If you look at the collection of those vendors, webMethods has done a really good job, relatively speaking, and they have a ways to go as they all do.
The platform vendors have had that issue, too. IBM had to move each product toward a more SOA-centric model and has also done a very good job. The point is, I don’t think that’s particularly unusual. There is risk here, culturally and technologically, but I really don’t see this risk as being major enough to influence the adoption of SOA or the SOA space in general.
Gardner: Okay, fair enough.
Kobielus: I find it risky from Software AG’s standpoint. They’re acquiring another vendor whose own customers are not avidly acquiring their new product. What I mean by that is, back in 2002, webMethods had license revenues of about $120 million, and it’s dropped. Last year, it was $84 or $85 million in software license revenues. This doesn’t sound like a healthy software vendor, and, to some degree, it sounds like webMethods' own customers regard them as being a legacy vendor, away from which they’re trying to migrate. That’s just the surface impression I get.
Biske: I don’t think it’s going to impact adoption of SOA or cast that all in a negative light. Interestingly, looking at the other risk to webMethods and to Software AG, how would we’d be perceiving this, if it was in the reverse direction with webMethods acquiring Software AG or even if it was presented as a merger of equals, rather than an acquisition? The fact that you’ve got the German company acquiring the U.S. company, what does that mean for the existing U.S. customers of webMethods, and how are they going to perceive this, because there are some cultural issues that have made it difficult for Software AG to gain ground in the U.S. market.
Garone: That’s an interesting point. I really can’t address the issue of whether this is financially feasible or not, but my first reaction was, "Why isn't this in the other direction?" I perceive webMethods as being better positioned and in a better business position generally than Software AG is.
Gardner: Well, they have certainly shown their interest in expansion, but I don’t think their cash position would have allowed this.
Garone: Right, that’s probably true.
Gardner: So, the desire might have been there, but not the means, right? Now, what about the point about Infravio and the registry/repository? We heard quite a bit from Miko about governance and policy, running an IT organization, and perhaps even a larger take on the whole management of business in general. It was a very visionary discussion we had, and yet Software AG has its own repository.
I frankly don’t know enough about them to put them side by side and pick a winner, but it seems that if Infravio and governance was going to be the tail that wagged the webMethods’ dog, and that this acquisition may show you a little different future for the role of registry and repository. Any thoughts on that issue?
Baer: It depends on who is going to be driving the agenda there. An early indicator is that Software AG has said that they want to keep webMethods’ management in place. That’s kind of interesting, because usually a CEO of an acquired company exits fairly tactfully, if it’s a friendly takeover. We’ll approach the interesting inflection point about 8 to 12 months down the pike, when we see who's really driving the SOA strategy at the combined company. That’s basically going to be the telling point.
Gardner: Okay, thanks, Tony.
Garone: I think that’s correct. The real pessimists out there -- I’m not sure I’m one of them -- would look at this and say there’s no doubt that webMethods is going to drive the SOA strategy. Software AG, in terms of revenue, is highly reliant on Adabas maintenance at this point and it's going to continue that way until it figures out how to leverage what it got via the acquisition of webMethods in the SOA space. I’m not quite sure I’m there, but there are some elements to that that may ring true.
Gardner: Yeah, this smacks of a good sales and channel match-up, and they might run webMethods as a subsidiary for some time. Then there's also this balance-sheet issue, where Software AG has recurring revenue. It’s got an old cash cow to continue to milk, and that gives webMethods an opportunity to be funded and financed -- without the vagaries of a quarterly report to Wall Street -- to pursue the larger brass ring here, which is SOA.
Kobielus: Dana, I’ll make a one last point there. I agree with that with what you just said. Software AG is a cash cow in the same way, for example, SAP is living off the substantial legacy of a very well-entrenched set of products. My first reaction to the webMethods acquisition was how they finally put webMethods out of its misery. When I say misery, how long has it been? WebMethods is about 11 or 12 years old now, and it seems that for most of their history they have been in some financial trouble or shakiness. It’s just been one thing after another, and it’s like they don’t get a break.
Now, they seem to have a corporate parent that has a comfort pillow for them, some money to fund ongoing development, diversification, and so forth. Software AG pulled webMethods out of their misery and has given them a new lease on life.
Gardner: Thanks, Jim. Yeah, maybe then make them the R&D department in a sense, right? Okay, a final word on this issue to Joe McKendrick. Joe, this relates somewhat to our discussions from the past about best-of-breed versus integrated-stack-and-suite. Clearly, these companies think that bigger is better and more is better. Does this change your thinking on the best-of-breed versus integrated-suite issue at all?
McKendrick: Well, as we discussed in a previous podcast, the whole notion of an SOA suite runs counter to the SOA philosophy. SOA is especially about loosely coupling, and it doesn’t matter where the applications or the system resides. SOA should be independent of all that, and the idea of an SOA suite runs counter to that thinking. Nevertheless, we see lot of companies glomming onto each other, a lot of gelling taking place. This Software AG-webMethods merger is an example. Progress Software has been very astute in assembling a collection of companies that deal with different aspects of SOA. They want to compete with Oracles, and we saw that just recently with JBoss.
Gardner: SOA Software?
McKendrick: Yeah, right. SOA Software and JBoss. Their goal, their intention is to compete against these bigger guys, while servicing the smaller business market, of course.
Gardner: More of an ecology approach to how to bulk up.
McKendrick: Yeah, we’re going to see more of these alliances, more of these acquisitions and mergers.
On Web 2.0 and SOA ...
Gardner: Let’s move on to our second topic, which is this notion of Web 2.0 and SOA. Now, Web 2.0, of course, can be defined many ways in the market. Some people look at it as simply a rich Internet application interface approach. Others focus on the collaborative social networking aspects of it. Yet others look at Web 2.0 as simply going from an HTML and text page-driven Web to more of a process and semantic Web.
So, let’s just leave the Web 2.0 definition off the table and look at the issue of any of these new activities, whether it’s social networking or rich Internet application interfaces or whether it’s taking advantage of more semantics and BPEL as a process relating to Web activities instead of just as a publishing medium.
Let’s just say, "All of the above" for defining Web 2.0 and how this relates to SOA. I want to go first to Jim Kobielus, because in some emails this week you had some interesting thoughts. We’ve seen a few companies say, "Let’s leverage Web 2.0." We’ve seen Intel come out and say, "We’re going to corral a number of 'open-source' Web 2.0 functions." We’ve seen Cisco get involved with Web 2.0. We’ve seen BEA just announce an embrace of Web 2.0. Even IBM is tinkering with this, I’m sure.
So, there is something there, but let’s focus on this collaborative aspect and particularly in terms of governance. Annrai O’Toole at Cape Clear mentioned this to me probably about nine months ago that he looked at governance and at Web 2.0 and thought, "Gee, maybe wikis would be a good concept for how people manage their services." They could say, "I think the policy should be this, and I’m going to use it in this way, and you can pick and choose."
It's sort of an open source, open collaboration approach to policy and use of services and their agreements. I suppose provisioning rules would come about. You said, Jim, this is kind of a scary concept, that wikis seem to be anti-governance and that it could be a collaboration with no structure. Tell us a little bit about why you’re concerned?
Kobielus: Well, when I think of governance, like everybody I think of the capital "G," like Government, but governance has a broader concern. You often think about crack-the-whip, controls, and setting controls on how people interact and how policies are created? When I think about wikis, I think of the exact opposite. There are no controls. It’s basically a shared space to which everybody can post, everybody can overwrite, and everybody can erase everybody else’s comments.
Gardner: The wisdom of the crowd, right?
Kobielus: Well, okay, that’s a religious faith. Wiki seems like the wild, wild West. It’s a free-for-all as collaboration. That’s great. It’s definitely got a very valid role in many environments, like open-source initiatives where they are very peer oriented. Everybody is an equal, even-steven, participant. There is a high emphasis on collaboration, design, reciprocity, and all of that. So, when I think about the whole SOA governance space, both design-time governance and run-time governance, I think of wiki as in the design-time governance side, where you have teams of designers or business analysts and IT people sitting around the virtual table, trying to hash out policies.
Gardner: Requirements?
Kobielus: Requirements, policies, data designs, data hierarchies like with their master data management environment. Quite often these are creative processes involving teams of smart people who sit around a virtual table and hash out the overall design approach. Wikis and the whole Web 2.0 repertoire of collaborative tools can be very valuable in this upfront design, modeling, simulation, and shoot-the-breeze aspects that are critically necessary for design time. But runtime SOA governance really depends on clear-cut policies, designs, data definitions, and so forth that have been handed down by the policy gurus, and now are governing ongoing operations without ambiguity.
In that case, you don’t necessarily want any Joe Blow to be able to overwrite the policies and the business rules that are guiding the ongoing monitoring, management control, or security of your SOA.
Gardner: Yes. You said that they needed adult supervision, but I didn’t think that this would be open to anybody. I thought this would be open to the people who have impact, the architects and the line-of-business people perhaps. You're not going to open this up to anybody. There would be a directory and an provisioning, so that only those most close would have access.
Let’s go to the real world. Todd Biske, does it make sense to you? Should we be collaborating among the right people with the right access and privileges in how SOA governance is improved over time?
Biske: I don’t know that you really want a wiki-style collaboration for governance. I tend to agree with Jim that you can’t just open it up to the masses, and even if you look at collaborative environments, whether it’s the large open-source projects, or something like Wikipedia, there's some hierarchy that eventually was put in place, where certain people were allowed to do commits or were designated as senior editors.
So, you always wind up with some form of governance structure around that. The area where I think wikis are going to be important in the SOA space is in the service management lifecycle or service development lifecycle. You got companies that have to move to a service-provider model, whether it’s internally to internal consumers or externally. I have talked a lot about this in my blog.
If we compare that to traditional product management, for a long time it was really just one-way communication. The product marketers went out and said, "Here’s our product. Here are its features. Go and use it." They pushed it out to the market place, and the only response they got back was did people buy the product or not.
Over time, they recognized the need for much more collaboration with their end consumers on how to evolve that product, whether it was the formation of customer advisory boards or even leveraging the Internet and some of the technologies to establish a community around those products. The same thing can apply when adopting SOA.
If I am providing a service out to the rest of the enterprise, I am going to be interested in what the consumers of that have to say. If I am not listening to them, not establishing that bi-directional communication, eventually they are going to go somewhere else or they are going to build it on their own and put that redundancy back into the organization, which is the opposite of what we are trying to achieve.
Gardner: Okay. So social networking has a value here, but you wouldn’t want it necessarily hardwired into the way in which the technology actually operates?
Biske: Exactly.
Gardner: Okay, I can buy that. Does anyone else have any thoughts on this notion of wikis and collaboration as applied to SOA governance?
Garone: I don’t really have a lot to add. The two guys who just talked gave a great view of this particular question, and I agree with virtually all of it. After a while, it becomes something that a few key contributors, people who actually have the power, control, and knowledge, would be part of. I waxed philosophical in my head and asked, "Well, is it then still a wiki or is it in fact a collaborative tool among a set of decision-makers who, through policies themselves, are able to make changes or not?"
Gardner: I think you're right. The key word here is collaboration. I believe that IBM is going to be coming out soon with something called Jazz, which is a collaborative application lifecycle management approach. We are seeing more collaboration across different aspects of the whole development-to-deployment environment and we are looking for the tools to do that. Web 2.0 is perhaps stepping up and saying, "We have some tools that can be used in that way." Perhaps, it's not just a matter of dropping a wiki into the process, but something a bit more tailored to an aspect, but somehow availing all the participants of each others' wisdom in the process.
Kobielus: It’s like an open source project. You have a broad range of contributors, but only a handful of committers who can actually commit changes to the underlying code base. So, you might have a wiki that has potentially 3,000 different contributors, but ultimately there might be a moderator or two whose job it is to periodically weed out the nonsense, and crack the wiki whip to make sure that what’s actually been posted reflects the wisdom of the crowd of 3,000 people and not necessarily the vandalism of the few who decide to just disrupt the process.
Garone: And that’s a governance model in itself.
Gardner: Yeah, that’s right. It’s governance, and it relates back to what we’ve discussed in trying to find analogies in geo-politics for technology governance. You want the best of both. You want a federated approach, where they get grassroots input, but you also need command and control. So, it’s Jefferson and it’s Hamilton, right?
Kobielus: It’s Aaron Burr occasionally too. You’re going to follow the pistols.
Gardner: I heard an interesting analogy the other day. We talked about the chicken and the egg, and somebody said, "What about the rooster?"
Alright, let’s move on. Before we leave with Web 2.0, does anyone else have any inputs about the role of Web 2.0? As I said, it’s a very large subject, and then it evolves into Enterprise 2.0 issues, which have lot to do with software as a service and delivery of service. There is the mash-up notion of creating services and then compositing them, even if not with an application purpose or a process, which is letting people change their interfaces and drag and drop things.
We have seen some information from Google Maps this week that have lent more credence to this. I’ll just throw it out to the crowd, any other beauty tips or predictions for the future about where Web 2.0 and SOA come together or not?
Kobielus: Web 2.0 is really HOA, Human Oriented Architecture. It is pretty much giving human beings the tools to share what’s in their minds, to share their creativity with the big wide world. SOA, Service Oriented Architecture, is about sharing and reusing all matter of resources in a standardized way. HOA, the Web 2.0, is the most critical resource, and the most inexhaustible energy supply is human ingenuity and creativity.
Gardner: That’s like Cosmic 2.0. Woah!
Kobielus: Yeah, I have been known to get cosmic. People who have read my blog realize that I am a total space cadet.
Baer: Jim, I'll give you the award this morning for coining the best buzz words, like "Cracking the wiki whip" and "Human Oriented Architecture."
Gardner: Now, any other thoughts before we leave the Web 2.0 subject area?
McKendrick: This may be just a rumor, but I once heard that there was a company, an enterprise with several architectural teams, and these teams actually met face to face once a year to discuss things. That's just a rumor. I am not sure if it’s true.
Gardner: They had to leave their guns and knives at the door.
McKendrick: Exactly. So, Web 2.0 can only help the situation, help break down some of these walls.
On SOA and the Hype Curve ...
Gardner: Okay, let’s move on to our last subject of the day -- we only have a few more minutes -- but it’s the notion of hype. I just noticed, looking around some of the SOA information that was floating around the Web, we seem to be now in the, past-the-peak of the hype curve on SOA and are apparently, from what they say, approaching the "trough of disillusionment."
I took exception with that. I am not sure we’ve even hyped SOA sufficiently and that we are still ramping up on this one. Does anybody else agree with me that SOA is so large, so long-term, and crosses not into just technology but business in organizing behaviors and even redefining the corporation itself? My point is that we are not hyping SOA enough. Anybody agree or disagree?
Biske: I tend to agree with you that the communication isn’t hitting home and it’s not sinking in. I had a blog I know Joe picked up on at one point that talked about companies that are claiming success with SOA. I pointed out that a lot of these companies are the same ones that claim success with virtually every new technology adoption or business adoption, because their culture is well suited to that. There is still a lot of of companies that just don’t know how to do cultural change. It’s not an easy thing to do.
We hyped SOA a lot from the IT perspective, and a lot of the IT managers certainly may be growing tried of hearing about it, but haven't done anything to actually start that process of cultural change. Is it really adopted by the business side and do they understand what it means and how it can impact our business? If they aren't having those communications, we haven’t really changed anything, and that means they’re still open for that message to continue, and to increase.
Gardner: You are saying that managing change well is a core competency, will be an important aspect of any SOA activity, and perhaps SOA adoption could help companies improve the way that they manage change?
Biske: Absolutely. Back when I was working at an enterprise, I had somebody ask me, "How do I build this service so that it meets the enterprise needs?" And I said, "You don’t. You build it to what you know now, and you understand what your processes are going to need to be to change it in the future? Because it is going to change. Think from a change-first perspective, and how you want to manage that process, rather than stick it out there, not want to have it touch it for 10 years, and have it last forever."
Gardner: Well, not to change this subject, but who else agrees with Todd and me?
Garone: You used an expression earlier, "trough of disillusionment." Those words come easily, because they have been used before. That’s because we go through this cycle every time some disruptive technology comes along. The hype gets really high, and the adoption and the use of the technology lags behind, depending on a variety of factors.
I think the SOA hype is pretty high, but I think that it's difficult to sell to decision-makers due to two factors: 1) the degree to which cultural change needs to take place, and 2) as time has progressed through this decade so far we’ve seen greater caution in IT departments because of shrinking budgets. So, the hype is high, but it needs to be sustained longer with messaging that’s going to be more aligned with business goals, rather than technology.
Gardner: We seem to be in a cheap era when it comes to IT, and ironically it’s coming at a time when the Dow is flirting with a record high, even though it has been a bumpy road in the market for the past couple of months. We are still within a Curt Shilling breaking ball of the record, and companies are enjoying record levels of profit, record growth.
Many of them are sitting on record piles of cash. Capital around the world is still at very cheap level, taxes are at a record low in real terms and are dropping in many countries. If there’s any time to invest in IT for the future, this should be it? And yet we’re not seeing it.
Kobielus: Oh, it’s not inconsistent, Dana, with SOA not succeeding. In fact SOA, the model of SOA practically could be: Do more with less.
Gardner: Yeah, but you've got to spend something to allow for your older systems to be freed up and excise the services. That doesn’t come free.
Biske: One thing you have to be cautious with ... Just as we talked about that things change quickly, a number of businesses got burned in the dot-com boom when stock markets were also very high and revenues were increasing. They increased their IT spending, and then the bottom dropped out of it.
Gardner: But, here it’s 2007. It’s been seven years since this crash.
Baer: But, Dana, probably the major reasons -- and the big difference this time -- is that on the IT side there isn't the same sense of urgency. We don't have this Y2K thing staring us at the face, telling us that we must renovate all those legacy systems that are out there -- either renovate or replace. You don’t have the same drama in the headlines all the time. That’s dropped the sense of urgency.
Combine that with the fact that a lot of organizations felt that they got burned the last time they opened up the purse strings.
That’s probably a large part of the reason why you’re seeing much more deliberate spending. To that extent, it can be a positive force in terms of enforcing some discipline. On the other hand, if you want to do SOA right, do you need to invest upfront to do that planning and architecture? I'm not sure that IT organizations have gotten that message.
Gardner: Perhaps there’s more. We keep going back to the crash, but after the crash, we had a series of corporate scandals and meltdowns that really couldn’t be blamed on hyping IT. They had to do a lot more with malfeasance and neglect. We also had a period where we saw new laws and a different compliance atmosphere.
So it could be that companies are being run more by the accountants -- of, for, and by the accountants -- and therefore the vision around IT is not getting through to them, and the purse strings are not opening up. Is that possible?
Koblielus: You’re pretty much on the mark there. I was talking with one CIO about a year or so ago, after about the first year of Sarbanes-Oxley, and she said that the impact of SOX translates to shutting down IT for about 90 days out of the year, just so that they could just account for their tracks over the previous three quarters.
Gardner: Does anyone else concur that the accountants have run amok, and that the IT guys have very good rationales for spending, but they just can’t get the money?
McKendrick: One effect of the whole compliance scenario was that it gave vendors another hype factor. I'm going to try another buzz word. How about Hype-Oriented Architecture? HOA. Using Jim’s HOA for another purpose.
Kobielus: It’s better to have hype-oriented accounting.
McKendrick: Hype-oriented accounting? I think the whole compliance thing gave a boost to the IT industry in the early 2000s. What do we call this decade anyway, the 2000s?
Gardner: The oughts.
McKendrick: It gave the whole industry a boost at a time when things were kind of down with the IT recession. The whole compliance scenario helped business intelligence and the data-environment vendors who directly addressed the flow of financial information.
Gardner: I’d like to conduct an experiment. I think we should take an accountant out to lunch. Anyone who knows an accountant, take them out to lunch and tell them how great IT is and what SOA can do in terms of long-term efficiency and lower total costs. Bring in some of the other mega trends, such as software as a service, virtualization, and data master management. It behooves us all to educate the accounts on why IT is important, because I think they are suffering from a lack of understanding.
Better yet, take a chief financial officer out to lunch and then take the accountants out to lunch. This is the crowd we need to work on. We keep talking about trying to convince the CEO and the CIO, and I think we need to get right down into the bean counters' frontal lobes on SOA.
Biske: Not to move away from the accountants, but one group I hope will keep the hype going is this newly formed SOA Consortium that OMG is sponsoring. It's an advocacy group, not another standards body coming, into the mix. It would be great to start to see a message come from a collection of end-users that are seeing some success with this, rather than being pushed so strongly by the vendor community.
I think it’s a different type of hype. It is one that will be a bit more pragmatic. Hopefully it will continue the pace, and they’ll achieve the goals that they have set out for themselves. I don’t know if they have any accountants in the consortium, but maybe this will help them bring some in.
Gardner: Well, we'll invite them and try to give them a free membership. They should cotton to that, right?
McKendrick: Often, it’s the stuff going on in the consumer space that begins to leach into the enterprise. Any excitement going on in the consumer space, eventually translates into excitement within the walls of the corporation about a certain technology. We saw that with the PCs and we saw that with the Internet. If anything is going on out there in the consumer space right now, it is Web 2.0, going back to the Web 2.0 discussion.
Gardner: Oh, we know how profitable that is.
McKendrick: It's where the excitement is in the corporation that begins to drive the investment. To paraphrase Wall Street's Gordon Gecko, hype is good.
Gardner: Greed was good in the 1980s -- hype is good in "the oughts."
McKendrick: Because it raises that level of excitement, and that’s why you need to get the attention of the bean counters, the CIOs, and the CEOs, most importantly.
Gardner: Well, here’s the message. Take your hype to your accountants and your CFOs and then make them join the SOA Consortium. I am always tempted at the signoff period of our discussion to take a cue from the Car Talk guys and say, "You’ve wasted another completely good hour," but I am not going to do it
Koblielus: And don't drive like my brother
Gardner: And don’t implement your IT like my brother. We have been joined here once again on our SOA Insights Edition by Steve Garone. Thanks, Steve.
Garone: Thank you Dana. It has been a pleasure.
Gardner: Joe McKendrick.
McKendrick: Thanks, Dana. It is good to be here.
Gardner: Jim Kobielus.
Kobielus: Another pleasurable morning.
Gardner: Tony Baer.
Baer: Another hour not wasted.
Gardner: Our guest -- please come back again Todd; we enjoyed having you -- Todd Biske.
Biske: Thanks, this is a lot of fun. I hope to be back.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to Volume 16 of BriefingsDirect, SOA Insights Edition. Thanks, and come back again next time.
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. 16. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Friday, June 08, 2007
BriefingsDirect SOA Insights Analysts on Defining the New Role of 'SOA Architect'
Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded March 23, 2007.
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. 15. This is a weekly discussion and dissection of service-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, ZDNet software strategies blogger and Redmond Developer News Magazine columnist.
Our panel this week consists of Jim Kobielus. He’s a principal analyst at Current Analysis. Welcome to the show, Jim.
Jim Kobielus: Hi, Dana. Hi, everybody.
Gardner: Also joining us from the U.K., Neil Macehiter. He's a research director at Macehiter Ward-Dutton. Welcome, Neil.
Neil Macehiter: Hi, Dana. Hi, everyone.
Gardner: Also joining us today we have Steve Nunn. He's the vice president and COO of The Open Group. Welcome to the show, Steve.
Steve Nunn: Thanks very much, Dana, and good morning, everyone.
Gardner: Also joining us is John Bell, an enterprise architect at Marriott International. Hello, John.
John Bell: Hello.
Gardner: We're going to be discussing the role and concept of what’s becoming defined as the "SOA Architect." This is a different role, as we’re finding out, than the enterprise architect, but certainly seems to be part of an evolution of the role of architect within the enterprise and within IT in general.
We’ve invited a representative from The Open Group, in this case Steve Nunn, to join us, because The Open Group has taken some steps to try to define the role of the SOA architect, has created some certification around that role, and is trying to get in front of this role in terms of what will be required in the marketplace. That is, to try to encourage more people to step up and understand this role and to certify themselves, so that the progress and maturity of SOA practices can continue and not face a human resources crunch.
So, with that, why don’t we hand it off to you, Steve? Why don’t you tell us a little bit more about what The Open Group is doing and why?
Nunn: Thanks, Dana. The Open Group and its members have been working in the architecture space for over a decade now, primarily developing something called The Open Group Architecture Framework (TOGAF), but, as you’ve mentioned, we're running certification programs in two specific areas. One is in relation to TOGAF, but perhaps more relevant to this discussion is our IT Architect Certification (ITAC) program.
I guess that sets a caveat at the outset. The terminology around what type of architect it might be -- IT architect, enterprise architect, SOA architect -- is still very much settling down as a topic of debate in its own right, but our program that I can talk about is the IT Architect Certification Program, which is a broad skills- and experience-based program. It's aimed at creating a vendor-neutral program by which individuals can be certified. It provides them with a transferable qualification in the industry, and it enables employers to know that if they prefer recruiting certified individuals, they would be getting somebody who has been through an accreditation process.
Briefly, the process would be that a resume is compiled, which can be quite extensive, up to 52 pages in some cases.
Gardner: Wow!
Nunn: Yeah and then there’s a peer review by a panel of three certified architects themselves who would probe a little on the resume, ask questions of the candidate, and conclude whether or not that individual meets the conformance requirements.
Gardner: Is this process already up and running, or is it something you're still pulling together in terms of how you want to approach it?
Nunn: No, this is up and running. We launched this in July 2005, and as of today, we have just a shade under 2,000 individuals from all sorts of companies and all over the world who are certified under this program.
Gardner: This is the SOA Architect Certification?
Nunn: This is actually what we call ITAC, the IT Architect Certification.
Gardner: I see.
Nunn: It has several levels and covers various disciplines. The SOA-specific part of it is one that we are still working on. We have various horizontal levels under this program. The conformance requirements for meeting those levels have been agreed upon. There’s an entry level and a higher level. We are working on the highest level right now, but what’s also going on is work on the individual aspects of that certification, of which SOA is one. What we’re quite proud of in this program is the conformance requirements for the overall program, and what we're now focusing on are the conformance requirements for the individual disciplines.
Gardner: Perhaps this is a good time to go around the room, so to speak, and see if we’re in some agreement that an SOA architect is fundamentally different from an enterprise architect and why? Why don’t we start with you Jim Kobielus. Do you see these as significantly different roles?
Kobielus: Not really. You have to be an IT architect to be an SOA architect. It seems to me that an SOA architect, or that discipline, is a subset of the overall enterprise architect. I would like to know precisely what other disciplines or practices that one needs to be certified in to be a SOA architect, versus just an overall enterprise architect, I’m still unclear on that.
Gardner: When we hand it back to you, Steve, one of the helpful concepts for me in understanding this was the notion of the "city planner" or "town planner" role. The analogy is that an SOA architect needs to like a city planner, looking at all the resources and infrastructure and how the entire community comes together, managing constituencies and political relationships, whereas an IT architect might have a smaller role. Can you expand on that a little bit?
Bell: Actually, an enterprise architect from my perspective would have the view of the town planner. When they’re looking at the entire city, they're looking at how the various neighborhoods, how the various business zones, etc., fit into that city. The SOA architect, from my point of view, is really more interested in, "Hey, how does that underlying infrastructure allow different neighborhoods to communicate with each other and exchange messages? How are health services delivered across neighborhoods?"
So, it’s more interested in, "Okay, I’ve got a firehouse. Can the fire truck get to the house before it burns down?" The vision of the SOA architect is more associated with the communications pieces within the community.
Gardner: So, the hierarchy might be that the enterprise architect is in the town planner role, the more holistic, oversight uber-architect role, and then a subset of that is making sure that the communication channels between and among these different facets of resources and functionality are behaving well and conforming to what needs to happen.
Bell: Conforming to the standards so that they’ve got a consistent set of standards for exchanging information, those kinds of things.
Gardner: Okay. Neil Macehiter, what you make of this?
Macehiter: In that that classification of the difference between enterprise architecture and the SOA architect, it sounds to me that the premise is that the SOA architect is focused primarily on the plumbing. From a bottom-up perspective, the challenge that many SOA architects face is more around understanding what the services are that need to be delivered in a business-meaningful way, not just about communication and plumbing. It’s also about understanding the high-level, business-meaningful services.
There is a business strategy, there are business processes and priorities, and there are the services we need at a business level. Then, there's a handoff to what’s currently defined as the SOA architect, who will actually define how those services are deployed in technology terms. So, the distinction is quite blurred. A service-oriented approach is one of the methodologies and the approaches that you can utilize to deliver or to support an enterprise architecture initiative. So, I still find a distinction difficult.
Kobielus: I second what Neil’s saying. I’m uncomfortable with just reducing SOA to the plumbing. In the three-layer stack that I carry in my head, the plumbing level is the enterprise service bus, and then SOA refers to development and reuse practices within the development organization to enable maximum sharing and reuse. Then, there’s the layer above that, which is the applications, services and data -- the business processes.
I’ll put enterprise architecture at that very top layer, concerned with the end-to-end set of resources: app services, data, etc. The SOA architect would be the middle layer of the development and reusing. The layer below that, the enterprise service bus (ESB) or whatever, I call that "IT architect" in the sense that it's the infrastructure architect.
Bell: And to be fair, I didn’t mean to imply that the SOA was limited to the plumbing. My intent was saying that the enterprise architect has a much broader spectrum and scope that they have to deal with than your SOA architect has to deal with. Putting it into that city paradigm, you kind of limit it as to how to describe some of the roles. I try to clarify that by saying it’s not just how they communicate, it’s things like, "Hey, where’s the fire station? Do you have a fire station? Where’s your police station? Where are your schools? Where are all those pieces that are providing services to that community and are they adequate for providing the services to their community?" That’s a subset of what a city planner has to do but it’s still an important city-planning kind of function.
Gardner: John, you’re in the trenches, you’re an enterprise architect in a large global concern. How do you see this hierarchy and is this really the right discussion that we’re having?
Bell: My view is that the enterprise architect is at the top of the hierarchy, and at some place, working with the enterprise architect is an SOA architect, and their focus is on, "What are the services that are being delivered, how am I delivering them? What’s the infrastructure I am using to deliver it? Do I need – using that town model -- a police station? Do I need a fire station? Do I need a school? Do I need a museum? And, if I do, how do I get that service out to the community or to the entire city, not just an individual neighborhood?"
So, from my perspective, using a city planner paradigm, the role of the SOA architect, is identifying what are the services that need to be available to the city and how to deliver those services out to the city.
Gardner: Back to you, Steve Nunn. It seems to me that there needs to be a fair amount of flexibility, enterprise by enterprise, and circumstance by circumstance, as to how this SOA architect role pans out. How much standardization and methodological consistency can we bring to something that, in fact, will probably be dealing with huge variability from organization to organization?
Nunn: Something that we’ve had to address in putting the program together is that there are huge differences. Even taking the frameworks that might be used in implementing an enterprise architecture, there are huge differences among organizations. Some organizations are required to use a certain framework. Our approach is not to specify exactly how enterprise architecture or SOA architecture is done in the certification program, but more about the experience of the individual who's implementing it.
It doesn’t seek to define a particular way of implementing the architecture, but is more about the skills and experience of the individuals who are playing that role inside an organization. They could be part of a team in larger organizations, or could be one person in a much smaller organization who is playing this role. The whole idea of raising the value of the architects of various titles in the organization is what we are seeking to achieve with our efforts in the certification program. It’s about raising the standards of that role, and getting people to understand that it’s a valuable role and, apart from anything else, it should be compensated as such.
Macehiter: Dana, could I chip in with a quick question there?
Gardner: Certainly.
Macehiter: It’s about the approach and the experience, rather than framework, and I agree completely with that. Given that the SOA discipline is currently within the IT architect certification, to what extent do you look at the approach and experience in terms of the interface to the business, business understanding, or collaboration with the business? I think that key elements of the SOA architect role are skill and capability, as well as the more IT-oriented skills and capabilities.
Nunn: Well, that's not so different between SOA and enterprise architecture. I’d say exactly the same about the enterprise architect -- that ability to translate the business need into the systems underlying or delivering the needs of the business. It’s something the enterprise architect absolutely needs to have, and that’s why we think there’s a special set of individuals who play this role. So, there isn’t really a difference in that respect between the SOA architect and the enterprise architect.
Kobielus: I like what you do. Thinking about the whole notion of certification, there are two ways to go about it. One approach that you can easily take -- and this is the way it’s usually perceived -- is when you are certifying a CPA, you’re certifying somebody as a skilled in an established and knowledgeful body of practice, be it law, medicine, whatever. But when there’s no consensus body of practice that everybody agrees upon -- for example SOA, which is still evolving -- a certification in that regard is more like when somebody is applying to college. You’ve got to send in your transcripts, write essays, and you also might have to go and do an interview in the admissions office. They look you over and say, "Oh, this is a smart person. Yeah."
So, they consider the sum total of everything you’ve done and who you are in certifying that. They say, "Yes, you’re good enough to be admitted into this college," and then proceed from there. That’s sounds like what you’re doing. You’re certifying the competency of a particular individual in this general field called a enterprise architect (EA) or a SOA architecture.
Nunn: That’s right, Jim, and it’s not a bad analogy at all. It's about assessing the individual. It’s a relatively young discipline in its own right. One of the things that we look at in a conformance requirement is the role that those individuals have played in the projects that they have been involved in, and whether they had been in a lead role or support role, or a combination of the two, but it certainly is about the individual, rather than the specific approach that they take or any particular body of knowledge.
Macehiter: Just one other quick comment on this, if I may. The other dimension for this, I think, is rather than thinking about the role, thinking about SOA as an approach. Then, thinking about how that approach applies to different types of architect. What I mean by this is that a lot of the emphasis and focus on SOA today has been around application development and integration, when, in fact, there’s a broader perspective that really extends across more traditional IT architecture and other disciplines, for example, a service-oriented approach to infrastructure architecture and the service-oriented approach to the operations and operational management of IT.
So, there are two dimensions that a body such as The Open Group might want to think about. One is the role of a service-oriented architect, and the second is how service orientation impacts other architecture disciplines and other IT functions or operation capabilities. If we don’t do that, we risk driving SOA into a particular stovepipe focused on application development and integration, and aren't thinking about it more broadly as an approach that it is an enabler of whatever the enterprise architects are driving out.
Gardner: Thanks, Neil. I suppose, too, that the role of the SOA architect will shift, as the maturity of SOA principles and methods evolves inside of an organization. They might have to start out a bit more focused on application development and deployment issues, move up toward being mindful of the business issues, and then move up more toward being the communications conduit between the fire house and the police station, for example. Does that make sense?
Macehiter: Absolutely. It’s about gradually extending through the life cycle.
Gardner: One of the reasons we are discussing this is that we’ve seen some warnings from analysts and others saying that we are moving toward SOA, but we really might find ourselves without the people with the background and abilities to move this. So, we’re worried a little bit about a dearth of qualified people, which might, in fact, stifle the progress here for SOA.
Do you see that is the case, Steve Nunn? Do you have any sense of numbers and what the demand is going to be? The second part of the question is, if there aren’t enough people, aren’t these roles going to fall upon the enterprise architect anyway?
Nunn: Dana, what we’re hearing is there aren’t enough enterprise architects to start with. So, I think it’s a given, therefore, that the SOA specialists are in short supply too. We’re hearing from our members that if they spot a good enterprise architect or somebody they think has potential for that, then they try and grab them. They’re pretty few and far between right now in terms of folks with experience.
Obviously, there are other folks that we just talked about with the college analogy who might well be groomed into that role in the future. So, certainly there is a shortage right now. That's what we are hearing from our membership. I don’t have specifics on numbers, but the message we hear is that demand is out-stripping supply right now.
Macehiter: This is not new. We’ve been through this with every major technology advance or discipline advance. You used the word "potential" there. I think there are individuals within organizations that have the potential to fulfill that role. Part of the benefit of this certification approach, providing conformance and definitions of what constitutes the role, is that it will help organizations identify the individuals within that company that have that potential, even if they don’t have the 50-page resume that demonstrates that they have been there and done it, because the key element in a service-oriented approach, and an enterprise architect more broadly, is an understanding of the business.
If you’ve got individuals within the organization that understand how the business works, have been around, and know the right individuals to talk to, that that can be of much benefit in terms of enabling effective EA and SOA, as can be going outside, finding someone from a different vertical market or different industry, and bringing them in because they’ve done six SOA projects elsewhere.
Gardner: Thanks Neil. Let’s take that point back to John Bell. Now, as an enterprise architect with Marriott International, I assume that you’re going to be in the position of having to hire or find SOA architects in this climate of scarcity. Where do you think these people will come from and what kind of backgrounds would you look for?
Bell: I think what we are going to have to do -- fortunately or unfortunately, however you look at it -- is end up training our own people. A lot of it goes back to what was just said about having to have an understanding of the business. You have to know the people in the business. You have to understand what the business of the business is. You have to have a lot of domain knowledge in order to create an effective SOA environment.
Because of that, when you pull somebody from outside, they may understand the technology, but they have to come up and learn the business, which is harder to train than somebody who has a general technology background, but knows the business pretty well, because he has been working in the business. Marriott happens to be a company that retains employees for years and years on end. So, in our IT department we have people who may already have 5, 10, 15 years of experience working directly in the business. And we can’t afford to lose that.
Gardner: Do you find that a developer is a fast-track path to SOA architect or a business analyst, even though it makes great sense to have someone with longevity in your organization? Is there particular type of role that they would have played that seems to conform to this need for SOA process management and evangelism?
Bell: In our experience, we are finding developers, as they move through their technology career path, since they have been developing within the context of the business, if they take that broader view, they understand the basis for the SOA architecture that’s installed in this particular company. They tend to make a good SOA architects with the proper training, and sometimes that training isn’t the technology training; it’s the people training -- teaching them how to conduct interviews, how to talk to people, how to get information from people, particularly in a company like Marriott where the business is not technically oriented.
Kobielus: This is all very good, but it doesn’t address the need that many companies have which is, "Hey, we need to hire people straight out of college who have some background in architecture, and where are we going to find these people and how are they going to get certified?"
Everything I'm hearing says that, an EA or a SOA architect is somebody who has experience and, by definition, somebody right out of college doesn’t have experience. So, is this the kind of thing that we can actually train in school or does somebody have to be in their career for 5, 10, 15 years before they’ve been steeped enough in all of this architectural infrastructural development and integration stuff to the point where they can be certified?
Bell: I’m also an adjunct faculty member at Towson State University, and this is an issue that we’re dealing with at the university level so that the university can provide the skills that the local businesses in the Baltimore area need. So, at the graduate school level, we are looking at what we offer in the way of architecture courses that take architecture from an enterprise or SOA perspective, so that we can enable our students who are finishing graduate school to be more and better prepared as they enter their new job market.
Gardner: These are excellent points. Steve, you and I discussed, when we spoke about some of these issues a month or so ago, that you were also trying to encourage universities to create the curriculum and the definition of these jobs. Can you fill in our listeners a little bit on what you’ve seen?
Nunn: That’s right, Dana. Something The Open Group launched at the end of January this year was the Association of Open Group Enterprise Architects (AOGEA), which really is -- the analogy here is the one somebody used earlier with attorneys or CPAs -- to do for enterprise architects what the Bar Association, for example, would do for attorneys, all joking aside. I think one of the things that we’re trying to do is partner with various types of organization in creating this community and this professional association.
One of those groups is the academic community, so we are putting out feelers to various universities to explore the possibility of getting enterprise architecture on the curriculum. There is one university that we are aware of where there is actually a TOGAF module in some of their courses. Obviously, changing a curriculum is a multi-year project, or multi-year plan. It’s not going to happen overnight, but in the interim, one of the categories of membership for the association is students.
So, those who are on a course of some description inside the university or even working in a job and doing part-time study, can join the association, be part of the community, get the information that’s available there, be on the news groups, maybe take part in the local chapter, or whatever they want to do to start building up some experience.
I had somebody come up to me a couple of weeks ago, after a talk I gave, and said, "This is exactly what I’ve been looking for, because in my organization I’m quite junior and the people above me really aren’t that interested in enterprise architecture, and certainly not SOA, but they won’t listen to me because I’m too junior. So, I need to get some experience or immerse myself in this field. Some kind of virtual community that allows people to do that is going to be a great help to me."
So, that’s one of the thing we’re trying to do. There are various membership categories, and student is just one of those.
Gardner: Now, it does seem that we have a climate of opportunity here. There’s the track for developer to move above that role and embrace more business understanding in domain expertise, and that would be a track. We’re looking at more universities preparing people for these types of roles. We’re probably going to find, again, variety within organizations in terms of business analysts or non-tech people coming into this role, because it requires influencing and consensus building, and so forth.
Usually, in markets, when there’s opportunity and there’s scarcity -- and these are probably well-paying jobs -- we would expect for the supply and demand to even out at some point. For those in the field like yourself, John Bell, am I overly optimistic that this supply and demand is going to mesh, or are we looking at something a bit more serious in terms of the next three to five years where there’s going to be a serious deficit of talent?
Bell: I think that the supply and demand will eventually mesh, but there may be a gap in the next year or two. I don’t know if it will carry out for three to five years.
Gardner: Well, thank you very much. Let’s move on to our next subject of the day.
In March an announcement came from the consortium of large IT vendors including SAP, IBM, Oracle, BEA, and Cisco. They have formed a series of proposed standards, the Service Component Architecture (SCA) specification and the Service Data Objects (SDO) spec. We are not quite at the standards level, but that seems to be the goal, to take this approach through OASIS, which is the organization that’s overseeing the Web services specifications and standards, WSDL, UDDI and SOAP and so forth and all the WS-* specifications.
It seems that the vendors have stepped up and said, "Listen, we need a level of standardization. We are going to do some heavy lifting, create some specifications, and then we are going to hand them off to the standard organization." This strikes me as an important juncture in the maturity and real-world applicability of SOA, and I wanted to test that hypothesis on Jim Kobielus.
Kobielus: Yeah, it’s very important. It’s clear that the SOA paradigm requires ever more high-level abstractions to enable easy development of very complex, orchestrated, end-to-end services. The SCA and SDO specifications – the initiative has been being going on for a couple of years – have come a long way and they’ve got pretty significant support throughout the industry. Microsoft is one of the few important holdouts. It's not only the high-level abstraction for developing competence services, but also, especially, in my area, the SDO, the high-level abstraction for working with heterogeneous data. I see the SDO, in itself, becoming potentially the standard industry framework for what’s called the semantic layer for any data integration.
So, I’m very keen on the potential for SDO, for example, within the business intelligence space, the data warehousing, and the enterprise, information, integration space. The fact that now OASIS will be taking over ongoing development of SDO, puts it on a very important fast track. Hopefully, we’ll get some of the business intelligence (BI) vendors like Business Objects and Cognos behind it. That’s one of my fond hopes.
Gardner: Jim, you’re tracking the data management side on this quite deeply. Do you think that SDO has the potential to become the ODBC/JDBC of SOA in terms of what those things enabled and empowered for distributed architecture?
Kobielus: It’s quite likely, because it’s leveraging the whole WS-* stack and the whole notion of semantic web that’s been kicking around for long time. Tim Berners-Lee keeps this going. It’s really a utopia of interoperability, where the semantic layer is the resource description layer for describing metadata. If you look at the so called semantic web’s specifications like OWL, RDF and a few others, they have not achieved takeoff velocity in the data management world. I can count on one hand the number of the BI or data warehousing vendors that are implementing OWL, for example. The semantic web has not really gotten any traction with standards or specifications where it counts.
With SDO, I still don’t see significant traction yet in the whole BI space, but the fact is that every BI vendor is SOA-focused and enabled and getting ever more so. That’s one of the clear gaps I’ve been seeing in the whole enterprise information integration (EII) side of it all in terms of distributed master data management (MDM). Every vendor, including Business Objects and the others, have their own semantic layer. That’s what Business Objects calls it.
As yet, there is no federated semantic layer specifications, but customers are asking for federation of say, Business Objects, Teradata, Microsoft, Oracle, and I believe that at some point BI and EII will converge around a common set of standards. I’m getting further and deeper into SDO, and it really looks like this is a strong potential framework for them all to work together going forward.
Gardner: A framework for a common and federated metadata approach, is it not?
Kobielus: Yeah, exactly.
Gardner: Now, the politics here struck me as a little bit interesting. Ed Cobb of BEA, who was on the call describing the movement of these specifications to OASIS, said that he hopes that this does for SOA what J2EE did for n-tier in distributed computing, which is to create a climate of growth with application server vendors coming together and ISVs building applications that take advantage of these. That sort of exploded during the mid- and late-1990s into what is now a predominant architecture for enterprise applications, as well as large Web commerce and online commerce types of applications.
Neil Macehiter, what do you make of the politics here? If J2EE did for distributed computing what they hope this does for SOA, why aren't SDO and SCA going into the Java process?
Macehiter: You've hit the nail on the head there. I think there are a couple of issues here. First is, if it went into the Java Community Process (JCP), you’re talking about SOA based on purely Java. As my colleague put it at the time, it’s like a three-legged dog running in a race. If you’ve only got Java, then you’re not really addressing one of the core propositions of SOA -- that it is about heterogeneous interoperability, with services based on multiple languages.
Gardner: What happened to "write once, run anywhere?" Wasn’t that heterogeneity and interoperability?
Macehiter: One programming language, and that’s the distinction. The SCA and the SDO are multi-program, multi-language.
Gardner: So, an abstraction above Java their pointers will make sense?
Macehiter: Yeah. Actually, the second point is that, in part, the creation of SCA and SDO was motivated by the frustration with the J2EE process. Enterprise JavaBeans (EJBs) and things like that never really took off. Some of the lightweight programming frameworks, Spring and Hibernate, were just taking great chunks out of J2EE in terms of deployment.
Then there was a significant amount of discontent among the Java community around the support for Web services, which is clearly one of the key enablers of SOA. Those three things, plus what Microsoft was doing with the Windows Communication Foundation (WCF), and the work they’ve been doing around it, caused the big J2EE players to think, "Well, actually we need to do something different." That was the motivation.
Gardner: I suppose it’s water over the dam at this point, but perhaps if the J2EE and a variety of Java framework specifications had moved into a standards organization like OASIS five years ago or so, the SOA specifications and the Java specifications could find themselves in the same organization. That seems now not to be the case.
On the other hand, if Microsoft has been the holdout in terms of embracing SDO and SCA, and is focusing more on .NET Framework -- but OASIS was a place where Microsoft felt comfortable going when it came to working with folks like IBM on the Web services standards -- do you think that this might move the hearts and minds of Redmond, Washington toward a bit more SOA compatibility and the programmatic approach to SOA, rather than just the interoperability approach?
Macehiter: My gut feeling is "no." And the reason is that Microsoft has collaborated with the likes of IBM, BEA and others, its historical competitors, up to a certain level up the stack. But the level at which SCA and SDO are operating is at the level where Microsoft has a massive investment, and a significant proportion of its business has been driven out of this at the programming model level.
So, I think it would take a lot for Microsoft to move to support SCA and SDO within the composition framework that they have, which is fundamentally around Visual Studio. Whether we are talking about BizTalk or Sharepoint or Office, it’s all around that programming model, which is tied into WCF and Windows Workflow Foundation. So, I just think the battle line is drawn at that level.
Gardner: What we are facing is perhaps an important decision within enterprises and service providers, software-as-a-service (SaaS) providers, and ISVs as to which role you perceive for .NET playing in Microsoft’s tools and process runtimes. Are they a subset of SOA, or are they in fact the master -- and the rest of the SOA componentry is the slave?
That would be one way of looking at it. The other would be that .NET should be just another spoke in the hub of all SOAs. Jim Kobielus, do you think we are going to be facing this sort of a face-off between the role of Microsoft as the hub or the spoke?
Kobielus: I think Microsoft has gotten much more open to being just one spoke. But I wouldn't use the hub vs. spoke analogy here. They’ve become more comfortable with the notion that they’re just one node in a vast mesh on the Internet in terms of Web services and SOA. So I don’t see Microsoft in face-off mode in the SOA world, or where SCA or SDO are concerned. A couple of years ago it might have been different, but it has changed.
Gardner: How about in terms of the role of their communications, their ESB, WCF (the former Indigo) and the role of BizTalk? It seems as if they are happy to be a spoke on one level, but they’d also like to be where business process is coded and logic is instantiated, and therefore become "the place" where SOA is driven, the dashboard from which SOA is driven.
Kobielus: Well, pretty much every BPM vendor wants to be that hub, that business-process hub, and Microsoft is not alone. Companies like TIBCO with ActiveMatrix, are interesting, because basically what it is doing is it is virtualizing the app server or the integration server, so you can run your .NET logic and your J2EE logic, and so forth in different containers on the same platform. That kind of architecture is more where the industry is going. In that case, TIBCO necessarily isn’t trying to be the one and only integration and logic hub out there. It is simply trying to be the hub of all hubs, but one of the hub of many hubs federated to each other.
Gardner: Is it that you don’t agree with Neil then, that if Microsoft is a bit more ecumenical on this, would we expect them to embrace SCA and SDO? Is that what you expect?
Kobielus: It’s a relative thing -- getting ecumenical. They get ecumenical when they are good and ready, like they’re doing right now in the identity space, with this whole notion of user-centric identities. It’s taken them a couple of years of sitting back, watching things like OpenID and Higgins develop. And then finally they make a token offering that says, “Okay, we’ll implement OpenID in the next generation of the Vista Card Space."
And, once again, my sense is they’re going to wait quite a period of time, at least a year, before they make any public pronouncements on the extent to which they are going to work with OASIS on SCA and SDO. It’s just their nature, and they are going to pursue their proprietary approach, as long as it holds out, and as long anybody will implement it.
Macehiter: I’m not suggesting that this a face-off. What I am suggesting really is that it comes down to the point of control that an organization or vendor has. Microsoft does not want to be denigrated to the plumbing, even if that’s interoperable plumbing. The point you raised about TIBCO with ActiveMatrix is that it’s actually using the SCA programming model in order to provide this abstraction.
So, ultimately in that environment who’s controlling it? TIBCO is becoming the master, and it will be the same in an IBM environment. SCA may be under the hood, but ultimately there will be a point of control that IBM wants to wrest for its process server for its development tools, and that’s what Microsoft wants to do. The challenge is that SCA and SDO are trying to do the same thing as Windows Communication Foundation and Microsoft tooling around .NET and SOA.
Gardner: To wrap up, it seems that it's not a face-off, but perhaps there are, as Jim points out, a lot of vendors who would like to be that over uber-dashboard, point of control. Some are BPEL-focused and others are taking different tacks. SCA seems to be playing a role for many of them, and Microsoft would like to play that role as well -- but perhaps thinks that it has an advantage through the way it’s architected up to this point. The market will, I suppose, determine who the ultimate winner is.
Macehiter: I think a lot will depend how quickly the tooling comes out around SCA and SDO, as an alternative to Visual Studio.
Bell: The other piece too is, as Microsoft tends to build those kinds of capabilities in as part of the operating system, other vendors tend to create them as standalone products and infrastructure pieces. If you are a small company, having it built into the operating system is a value to you, but in large, heterogeneous environments that can be costly to you. So, that’s always been used by Microsoft. If you look at CORBA versus COM and DCOM, it’s the same story.
Macehiter: Absolutely.
Gardner: You’ve been listening to yet another BriefingsDirect SOA Insights Edition, Vol. 15, for the week of March 19, 2007. We’ve been joined by Jim Kobielus, principal analyst at Current Analysis. Neil Macehiter, a research director at Macehiter Ward-Dutton. Steve Nunn, the vice president and COO of The Open Group, and John Bell, enterprise architect at Marriott International.
I'm your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions. Thanks everyone, and thanks for listening.
Listen to the podcast here. 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. 15. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
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. 15. This is a weekly discussion and dissection of service-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, ZDNet software strategies blogger and Redmond Developer News Magazine columnist.
Our panel this week consists of Jim Kobielus. He’s a principal analyst at Current Analysis. Welcome to the show, Jim.
Jim Kobielus: Hi, Dana. Hi, everybody.
Gardner: Also joining us from the U.K., Neil Macehiter. He's a research director at Macehiter Ward-Dutton. Welcome, Neil.
Neil Macehiter: Hi, Dana. Hi, everyone.
Gardner: Also joining us today we have Steve Nunn. He's the vice president and COO of The Open Group. Welcome to the show, Steve.
Steve Nunn: Thanks very much, Dana, and good morning, everyone.
Gardner: Also joining us is John Bell, an enterprise architect at Marriott International. Hello, John.
John Bell: Hello.
Gardner: We're going to be discussing the role and concept of what’s becoming defined as the "SOA Architect." This is a different role, as we’re finding out, than the enterprise architect, but certainly seems to be part of an evolution of the role of architect within the enterprise and within IT in general.
We’ve invited a representative from The Open Group, in this case Steve Nunn, to join us, because The Open Group has taken some steps to try to define the role of the SOA architect, has created some certification around that role, and is trying to get in front of this role in terms of what will be required in the marketplace. That is, to try to encourage more people to step up and understand this role and to certify themselves, so that the progress and maturity of SOA practices can continue and not face a human resources crunch.
So, with that, why don’t we hand it off to you, Steve? Why don’t you tell us a little bit more about what The Open Group is doing and why?
Nunn: Thanks, Dana. The Open Group and its members have been working in the architecture space for over a decade now, primarily developing something called The Open Group Architecture Framework (TOGAF), but, as you’ve mentioned, we're running certification programs in two specific areas. One is in relation to TOGAF, but perhaps more relevant to this discussion is our IT Architect Certification (ITAC) program.
I guess that sets a caveat at the outset. The terminology around what type of architect it might be -- IT architect, enterprise architect, SOA architect -- is still very much settling down as a topic of debate in its own right, but our program that I can talk about is the IT Architect Certification Program, which is a broad skills- and experience-based program. It's aimed at creating a vendor-neutral program by which individuals can be certified. It provides them with a transferable qualification in the industry, and it enables employers to know that if they prefer recruiting certified individuals, they would be getting somebody who has been through an accreditation process.
Briefly, the process would be that a resume is compiled, which can be quite extensive, up to 52 pages in some cases.
Gardner: Wow!
Nunn: Yeah and then there’s a peer review by a panel of three certified architects themselves who would probe a little on the resume, ask questions of the candidate, and conclude whether or not that individual meets the conformance requirements.
Gardner: Is this process already up and running, or is it something you're still pulling together in terms of how you want to approach it?
Nunn: No, this is up and running. We launched this in July 2005, and as of today, we have just a shade under 2,000 individuals from all sorts of companies and all over the world who are certified under this program.
Gardner: This is the SOA Architect Certification?
Nunn: This is actually what we call ITAC, the IT Architect Certification.
Gardner: I see.
Nunn: It has several levels and covers various disciplines. The SOA-specific part of it is one that we are still working on. We have various horizontal levels under this program. The conformance requirements for meeting those levels have been agreed upon. There’s an entry level and a higher level. We are working on the highest level right now, but what’s also going on is work on the individual aspects of that certification, of which SOA is one. What we’re quite proud of in this program is the conformance requirements for the overall program, and what we're now focusing on are the conformance requirements for the individual disciplines.
Gardner: Perhaps this is a good time to go around the room, so to speak, and see if we’re in some agreement that an SOA architect is fundamentally different from an enterprise architect and why? Why don’t we start with you Jim Kobielus. Do you see these as significantly different roles?
Kobielus: Not really. You have to be an IT architect to be an SOA architect. It seems to me that an SOA architect, or that discipline, is a subset of the overall enterprise architect. I would like to know precisely what other disciplines or practices that one needs to be certified in to be a SOA architect, versus just an overall enterprise architect, I’m still unclear on that.
Gardner: When we hand it back to you, Steve, one of the helpful concepts for me in understanding this was the notion of the "city planner" or "town planner" role. The analogy is that an SOA architect needs to like a city planner, looking at all the resources and infrastructure and how the entire community comes together, managing constituencies and political relationships, whereas an IT architect might have a smaller role. Can you expand on that a little bit?
Bell: Actually, an enterprise architect from my perspective would have the view of the town planner. When they’re looking at the entire city, they're looking at how the various neighborhoods, how the various business zones, etc., fit into that city. The SOA architect, from my point of view, is really more interested in, "Hey, how does that underlying infrastructure allow different neighborhoods to communicate with each other and exchange messages? How are health services delivered across neighborhoods?"
So, it’s more interested in, "Okay, I’ve got a firehouse. Can the fire truck get to the house before it burns down?" The vision of the SOA architect is more associated with the communications pieces within the community.
Gardner: So, the hierarchy might be that the enterprise architect is in the town planner role, the more holistic, oversight uber-architect role, and then a subset of that is making sure that the communication channels between and among these different facets of resources and functionality are behaving well and conforming to what needs to happen.
Bell: Conforming to the standards so that they’ve got a consistent set of standards for exchanging information, those kinds of things.
Gardner: Okay. Neil Macehiter, what you make of this?
Macehiter: In that that classification of the difference between enterprise architecture and the SOA architect, it sounds to me that the premise is that the SOA architect is focused primarily on the plumbing. From a bottom-up perspective, the challenge that many SOA architects face is more around understanding what the services are that need to be delivered in a business-meaningful way, not just about communication and plumbing. It’s also about understanding the high-level, business-meaningful services.
There is a business strategy, there are business processes and priorities, and there are the services we need at a business level. Then, there's a handoff to what’s currently defined as the SOA architect, who will actually define how those services are deployed in technology terms. So, the distinction is quite blurred. A service-oriented approach is one of the methodologies and the approaches that you can utilize to deliver or to support an enterprise architecture initiative. So, I still find a distinction difficult.
Kobielus: I second what Neil’s saying. I’m uncomfortable with just reducing SOA to the plumbing. In the three-layer stack that I carry in my head, the plumbing level is the enterprise service bus, and then SOA refers to development and reuse practices within the development organization to enable maximum sharing and reuse. Then, there’s the layer above that, which is the applications, services and data -- the business processes.
I’ll put enterprise architecture at that very top layer, concerned with the end-to-end set of resources: app services, data, etc. The SOA architect would be the middle layer of the development and reusing. The layer below that, the enterprise service bus (ESB) or whatever, I call that "IT architect" in the sense that it's the infrastructure architect.
Bell: And to be fair, I didn’t mean to imply that the SOA was limited to the plumbing. My intent was saying that the enterprise architect has a much broader spectrum and scope that they have to deal with than your SOA architect has to deal with. Putting it into that city paradigm, you kind of limit it as to how to describe some of the roles. I try to clarify that by saying it’s not just how they communicate, it’s things like, "Hey, where’s the fire station? Do you have a fire station? Where’s your police station? Where are your schools? Where are all those pieces that are providing services to that community and are they adequate for providing the services to their community?" That’s a subset of what a city planner has to do but it’s still an important city-planning kind of function.
Gardner: John, you’re in the trenches, you’re an enterprise architect in a large global concern. How do you see this hierarchy and is this really the right discussion that we’re having?
Bell: My view is that the enterprise architect is at the top of the hierarchy, and at some place, working with the enterprise architect is an SOA architect, and their focus is on, "What are the services that are being delivered, how am I delivering them? What’s the infrastructure I am using to deliver it? Do I need – using that town model -- a police station? Do I need a fire station? Do I need a school? Do I need a museum? And, if I do, how do I get that service out to the community or to the entire city, not just an individual neighborhood?"
So, from my perspective, using a city planner paradigm, the role of the SOA architect, is identifying what are the services that need to be available to the city and how to deliver those services out to the city.
Gardner: Back to you, Steve Nunn. It seems to me that there needs to be a fair amount of flexibility, enterprise by enterprise, and circumstance by circumstance, as to how this SOA architect role pans out. How much standardization and methodological consistency can we bring to something that, in fact, will probably be dealing with huge variability from organization to organization?
Nunn: Something that we’ve had to address in putting the program together is that there are huge differences. Even taking the frameworks that might be used in implementing an enterprise architecture, there are huge differences among organizations. Some organizations are required to use a certain framework. Our approach is not to specify exactly how enterprise architecture or SOA architecture is done in the certification program, but more about the experience of the individual who's implementing it.
It doesn’t seek to define a particular way of implementing the architecture, but is more about the skills and experience of the individuals who are playing that role inside an organization. They could be part of a team in larger organizations, or could be one person in a much smaller organization who is playing this role. The whole idea of raising the value of the architects of various titles in the organization is what we are seeking to achieve with our efforts in the certification program. It’s about raising the standards of that role, and getting people to understand that it’s a valuable role and, apart from anything else, it should be compensated as such.
Macehiter: Dana, could I chip in with a quick question there?
Gardner: Certainly.
Macehiter: It’s about the approach and the experience, rather than framework, and I agree completely with that. Given that the SOA discipline is currently within the IT architect certification, to what extent do you look at the approach and experience in terms of the interface to the business, business understanding, or collaboration with the business? I think that key elements of the SOA architect role are skill and capability, as well as the more IT-oriented skills and capabilities.
Nunn: Well, that's not so different between SOA and enterprise architecture. I’d say exactly the same about the enterprise architect -- that ability to translate the business need into the systems underlying or delivering the needs of the business. It’s something the enterprise architect absolutely needs to have, and that’s why we think there’s a special set of individuals who play this role. So, there isn’t really a difference in that respect between the SOA architect and the enterprise architect.
Kobielus: I like what you do. Thinking about the whole notion of certification, there are two ways to go about it. One approach that you can easily take -- and this is the way it’s usually perceived -- is when you are certifying a CPA, you’re certifying somebody as a skilled in an established and knowledgeful body of practice, be it law, medicine, whatever. But when there’s no consensus body of practice that everybody agrees upon -- for example SOA, which is still evolving -- a certification in that regard is more like when somebody is applying to college. You’ve got to send in your transcripts, write essays, and you also might have to go and do an interview in the admissions office. They look you over and say, "Oh, this is a smart person. Yeah."
So, they consider the sum total of everything you’ve done and who you are in certifying that. They say, "Yes, you’re good enough to be admitted into this college," and then proceed from there. That’s sounds like what you’re doing. You’re certifying the competency of a particular individual in this general field called a enterprise architect (EA) or a SOA architecture.
Nunn: That’s right, Jim, and it’s not a bad analogy at all. It's about assessing the individual. It’s a relatively young discipline in its own right. One of the things that we look at in a conformance requirement is the role that those individuals have played in the projects that they have been involved in, and whether they had been in a lead role or support role, or a combination of the two, but it certainly is about the individual, rather than the specific approach that they take or any particular body of knowledge.
Macehiter: Just one other quick comment on this, if I may. The other dimension for this, I think, is rather than thinking about the role, thinking about SOA as an approach. Then, thinking about how that approach applies to different types of architect. What I mean by this is that a lot of the emphasis and focus on SOA today has been around application development and integration, when, in fact, there’s a broader perspective that really extends across more traditional IT architecture and other disciplines, for example, a service-oriented approach to infrastructure architecture and the service-oriented approach to the operations and operational management of IT.
So, there are two dimensions that a body such as The Open Group might want to think about. One is the role of a service-oriented architect, and the second is how service orientation impacts other architecture disciplines and other IT functions or operation capabilities. If we don’t do that, we risk driving SOA into a particular stovepipe focused on application development and integration, and aren't thinking about it more broadly as an approach that it is an enabler of whatever the enterprise architects are driving out.
Gardner: Thanks, Neil. I suppose, too, that the role of the SOA architect will shift, as the maturity of SOA principles and methods evolves inside of an organization. They might have to start out a bit more focused on application development and deployment issues, move up toward being mindful of the business issues, and then move up more toward being the communications conduit between the fire house and the police station, for example. Does that make sense?
Macehiter: Absolutely. It’s about gradually extending through the life cycle.
Gardner: One of the reasons we are discussing this is that we’ve seen some warnings from analysts and others saying that we are moving toward SOA, but we really might find ourselves without the people with the background and abilities to move this. So, we’re worried a little bit about a dearth of qualified people, which might, in fact, stifle the progress here for SOA.
Do you see that is the case, Steve Nunn? Do you have any sense of numbers and what the demand is going to be? The second part of the question is, if there aren’t enough people, aren’t these roles going to fall upon the enterprise architect anyway?
Nunn: Dana, what we’re hearing is there aren’t enough enterprise architects to start with. So, I think it’s a given, therefore, that the SOA specialists are in short supply too. We’re hearing from our members that if they spot a good enterprise architect or somebody they think has potential for that, then they try and grab them. They’re pretty few and far between right now in terms of folks with experience.
Obviously, there are other folks that we just talked about with the college analogy who might well be groomed into that role in the future. So, certainly there is a shortage right now. That's what we are hearing from our membership. I don’t have specifics on numbers, but the message we hear is that demand is out-stripping supply right now.
Macehiter: This is not new. We’ve been through this with every major technology advance or discipline advance. You used the word "potential" there. I think there are individuals within organizations that have the potential to fulfill that role. Part of the benefit of this certification approach, providing conformance and definitions of what constitutes the role, is that it will help organizations identify the individuals within that company that have that potential, even if they don’t have the 50-page resume that demonstrates that they have been there and done it, because the key element in a service-oriented approach, and an enterprise architect more broadly, is an understanding of the business.
If you’ve got individuals within the organization that understand how the business works, have been around, and know the right individuals to talk to, that that can be of much benefit in terms of enabling effective EA and SOA, as can be going outside, finding someone from a different vertical market or different industry, and bringing them in because they’ve done six SOA projects elsewhere.
Gardner: Thanks Neil. Let’s take that point back to John Bell. Now, as an enterprise architect with Marriott International, I assume that you’re going to be in the position of having to hire or find SOA architects in this climate of scarcity. Where do you think these people will come from and what kind of backgrounds would you look for?
Bell: I think what we are going to have to do -- fortunately or unfortunately, however you look at it -- is end up training our own people. A lot of it goes back to what was just said about having to have an understanding of the business. You have to know the people in the business. You have to understand what the business of the business is. You have to have a lot of domain knowledge in order to create an effective SOA environment.
Because of that, when you pull somebody from outside, they may understand the technology, but they have to come up and learn the business, which is harder to train than somebody who has a general technology background, but knows the business pretty well, because he has been working in the business. Marriott happens to be a company that retains employees for years and years on end. So, in our IT department we have people who may already have 5, 10, 15 years of experience working directly in the business. And we can’t afford to lose that.
Gardner: Do you find that a developer is a fast-track path to SOA architect or a business analyst, even though it makes great sense to have someone with longevity in your organization? Is there particular type of role that they would have played that seems to conform to this need for SOA process management and evangelism?
Bell: In our experience, we are finding developers, as they move through their technology career path, since they have been developing within the context of the business, if they take that broader view, they understand the basis for the SOA architecture that’s installed in this particular company. They tend to make a good SOA architects with the proper training, and sometimes that training isn’t the technology training; it’s the people training -- teaching them how to conduct interviews, how to talk to people, how to get information from people, particularly in a company like Marriott where the business is not technically oriented.
Kobielus: This is all very good, but it doesn’t address the need that many companies have which is, "Hey, we need to hire people straight out of college who have some background in architecture, and where are we going to find these people and how are they going to get certified?"
Everything I'm hearing says that, an EA or a SOA architect is somebody who has experience and, by definition, somebody right out of college doesn’t have experience. So, is this the kind of thing that we can actually train in school or does somebody have to be in their career for 5, 10, 15 years before they’ve been steeped enough in all of this architectural infrastructural development and integration stuff to the point where they can be certified?
Bell: I’m also an adjunct faculty member at Towson State University, and this is an issue that we’re dealing with at the university level so that the university can provide the skills that the local businesses in the Baltimore area need. So, at the graduate school level, we are looking at what we offer in the way of architecture courses that take architecture from an enterprise or SOA perspective, so that we can enable our students who are finishing graduate school to be more and better prepared as they enter their new job market.
Gardner: These are excellent points. Steve, you and I discussed, when we spoke about some of these issues a month or so ago, that you were also trying to encourage universities to create the curriculum and the definition of these jobs. Can you fill in our listeners a little bit on what you’ve seen?
Nunn: That’s right, Dana. Something The Open Group launched at the end of January this year was the Association of Open Group Enterprise Architects (AOGEA), which really is -- the analogy here is the one somebody used earlier with attorneys or CPAs -- to do for enterprise architects what the Bar Association, for example, would do for attorneys, all joking aside. I think one of the things that we’re trying to do is partner with various types of organization in creating this community and this professional association.
One of those groups is the academic community, so we are putting out feelers to various universities to explore the possibility of getting enterprise architecture on the curriculum. There is one university that we are aware of where there is actually a TOGAF module in some of their courses. Obviously, changing a curriculum is a multi-year project, or multi-year plan. It’s not going to happen overnight, but in the interim, one of the categories of membership for the association is students.
So, those who are on a course of some description inside the university or even working in a job and doing part-time study, can join the association, be part of the community, get the information that’s available there, be on the news groups, maybe take part in the local chapter, or whatever they want to do to start building up some experience.
I had somebody come up to me a couple of weeks ago, after a talk I gave, and said, "This is exactly what I’ve been looking for, because in my organization I’m quite junior and the people above me really aren’t that interested in enterprise architecture, and certainly not SOA, but they won’t listen to me because I’m too junior. So, I need to get some experience or immerse myself in this field. Some kind of virtual community that allows people to do that is going to be a great help to me."
So, that’s one of the thing we’re trying to do. There are various membership categories, and student is just one of those.
Gardner: Now, it does seem that we have a climate of opportunity here. There’s the track for developer to move above that role and embrace more business understanding in domain expertise, and that would be a track. We’re looking at more universities preparing people for these types of roles. We’re probably going to find, again, variety within organizations in terms of business analysts or non-tech people coming into this role, because it requires influencing and consensus building, and so forth.
Usually, in markets, when there’s opportunity and there’s scarcity -- and these are probably well-paying jobs -- we would expect for the supply and demand to even out at some point. For those in the field like yourself, John Bell, am I overly optimistic that this supply and demand is going to mesh, or are we looking at something a bit more serious in terms of the next three to five years where there’s going to be a serious deficit of talent?
Bell: I think that the supply and demand will eventually mesh, but there may be a gap in the next year or two. I don’t know if it will carry out for three to five years.
Gardner: Well, thank you very much. Let’s move on to our next subject of the day.
In March an announcement came from the consortium of large IT vendors including SAP, IBM, Oracle, BEA, and Cisco. They have formed a series of proposed standards, the Service Component Architecture (SCA) specification and the Service Data Objects (SDO) spec. We are not quite at the standards level, but that seems to be the goal, to take this approach through OASIS, which is the organization that’s overseeing the Web services specifications and standards, WSDL, UDDI and SOAP and so forth and all the WS-* specifications.
It seems that the vendors have stepped up and said, "Listen, we need a level of standardization. We are going to do some heavy lifting, create some specifications, and then we are going to hand them off to the standard organization." This strikes me as an important juncture in the maturity and real-world applicability of SOA, and I wanted to test that hypothesis on Jim Kobielus.
Kobielus: Yeah, it’s very important. It’s clear that the SOA paradigm requires ever more high-level abstractions to enable easy development of very complex, orchestrated, end-to-end services. The SCA and SDO specifications – the initiative has been being going on for a couple of years – have come a long way and they’ve got pretty significant support throughout the industry. Microsoft is one of the few important holdouts. It's not only the high-level abstraction for developing competence services, but also, especially, in my area, the SDO, the high-level abstraction for working with heterogeneous data. I see the SDO, in itself, becoming potentially the standard industry framework for what’s called the semantic layer for any data integration.
So, I’m very keen on the potential for SDO, for example, within the business intelligence space, the data warehousing, and the enterprise, information, integration space. The fact that now OASIS will be taking over ongoing development of SDO, puts it on a very important fast track. Hopefully, we’ll get some of the business intelligence (BI) vendors like Business Objects and Cognos behind it. That’s one of my fond hopes.
Gardner: Jim, you’re tracking the data management side on this quite deeply. Do you think that SDO has the potential to become the ODBC/JDBC of SOA in terms of what those things enabled and empowered for distributed architecture?
Kobielus: It’s quite likely, because it’s leveraging the whole WS-* stack and the whole notion of semantic web that’s been kicking around for long time. Tim Berners-Lee keeps this going. It’s really a utopia of interoperability, where the semantic layer is the resource description layer for describing metadata. If you look at the so called semantic web’s specifications like OWL, RDF and a few others, they have not achieved takeoff velocity in the data management world. I can count on one hand the number of the BI or data warehousing vendors that are implementing OWL, for example. The semantic web has not really gotten any traction with standards or specifications where it counts.
With SDO, I still don’t see significant traction yet in the whole BI space, but the fact is that every BI vendor is SOA-focused and enabled and getting ever more so. That’s one of the clear gaps I’ve been seeing in the whole enterprise information integration (EII) side of it all in terms of distributed master data management (MDM). Every vendor, including Business Objects and the others, have their own semantic layer. That’s what Business Objects calls it.
As yet, there is no federated semantic layer specifications, but customers are asking for federation of say, Business Objects, Teradata, Microsoft, Oracle, and I believe that at some point BI and EII will converge around a common set of standards. I’m getting further and deeper into SDO, and it really looks like this is a strong potential framework for them all to work together going forward.
Gardner: A framework for a common and federated metadata approach, is it not?
Kobielus: Yeah, exactly.
Gardner: Now, the politics here struck me as a little bit interesting. Ed Cobb of BEA, who was on the call describing the movement of these specifications to OASIS, said that he hopes that this does for SOA what J2EE did for n-tier in distributed computing, which is to create a climate of growth with application server vendors coming together and ISVs building applications that take advantage of these. That sort of exploded during the mid- and late-1990s into what is now a predominant architecture for enterprise applications, as well as large Web commerce and online commerce types of applications.
Neil Macehiter, what do you make of the politics here? If J2EE did for distributed computing what they hope this does for SOA, why aren't SDO and SCA going into the Java process?
Macehiter: You've hit the nail on the head there. I think there are a couple of issues here. First is, if it went into the Java Community Process (JCP), you’re talking about SOA based on purely Java. As my colleague put it at the time, it’s like a three-legged dog running in a race. If you’ve only got Java, then you’re not really addressing one of the core propositions of SOA -- that it is about heterogeneous interoperability, with services based on multiple languages.
Gardner: What happened to "write once, run anywhere?" Wasn’t that heterogeneity and interoperability?
Macehiter: One programming language, and that’s the distinction. The SCA and the SDO are multi-program, multi-language.
Gardner: So, an abstraction above Java their pointers will make sense?
Macehiter: Yeah. Actually, the second point is that, in part, the creation of SCA and SDO was motivated by the frustration with the J2EE process. Enterprise JavaBeans (EJBs) and things like that never really took off. Some of the lightweight programming frameworks, Spring and Hibernate, were just taking great chunks out of J2EE in terms of deployment.
Then there was a significant amount of discontent among the Java community around the support for Web services, which is clearly one of the key enablers of SOA. Those three things, plus what Microsoft was doing with the Windows Communication Foundation (WCF), and the work they’ve been doing around it, caused the big J2EE players to think, "Well, actually we need to do something different." That was the motivation.
Gardner: I suppose it’s water over the dam at this point, but perhaps if the J2EE and a variety of Java framework specifications had moved into a standards organization like OASIS five years ago or so, the SOA specifications and the Java specifications could find themselves in the same organization. That seems now not to be the case.
On the other hand, if Microsoft has been the holdout in terms of embracing SDO and SCA, and is focusing more on .NET Framework -- but OASIS was a place where Microsoft felt comfortable going when it came to working with folks like IBM on the Web services standards -- do you think that this might move the hearts and minds of Redmond, Washington toward a bit more SOA compatibility and the programmatic approach to SOA, rather than just the interoperability approach?
Macehiter: My gut feeling is "no." And the reason is that Microsoft has collaborated with the likes of IBM, BEA and others, its historical competitors, up to a certain level up the stack. But the level at which SCA and SDO are operating is at the level where Microsoft has a massive investment, and a significant proportion of its business has been driven out of this at the programming model level.
So, I think it would take a lot for Microsoft to move to support SCA and SDO within the composition framework that they have, which is fundamentally around Visual Studio. Whether we are talking about BizTalk or Sharepoint or Office, it’s all around that programming model, which is tied into WCF and Windows Workflow Foundation. So, I just think the battle line is drawn at that level.
Gardner: What we are facing is perhaps an important decision within enterprises and service providers, software-as-a-service (SaaS) providers, and ISVs as to which role you perceive for .NET playing in Microsoft’s tools and process runtimes. Are they a subset of SOA, or are they in fact the master -- and the rest of the SOA componentry is the slave?
That would be one way of looking at it. The other would be that .NET should be just another spoke in the hub of all SOAs. Jim Kobielus, do you think we are going to be facing this sort of a face-off between the role of Microsoft as the hub or the spoke?
Kobielus: I think Microsoft has gotten much more open to being just one spoke. But I wouldn't use the hub vs. spoke analogy here. They’ve become more comfortable with the notion that they’re just one node in a vast mesh on the Internet in terms of Web services and SOA. So I don’t see Microsoft in face-off mode in the SOA world, or where SCA or SDO are concerned. A couple of years ago it might have been different, but it has changed.
Gardner: How about in terms of the role of their communications, their ESB, WCF (the former Indigo) and the role of BizTalk? It seems as if they are happy to be a spoke on one level, but they’d also like to be where business process is coded and logic is instantiated, and therefore become "the place" where SOA is driven, the dashboard from which SOA is driven.
Kobielus: Well, pretty much every BPM vendor wants to be that hub, that business-process hub, and Microsoft is not alone. Companies like TIBCO with ActiveMatrix, are interesting, because basically what it is doing is it is virtualizing the app server or the integration server, so you can run your .NET logic and your J2EE logic, and so forth in different containers on the same platform. That kind of architecture is more where the industry is going. In that case, TIBCO necessarily isn’t trying to be the one and only integration and logic hub out there. It is simply trying to be the hub of all hubs, but one of the hub of many hubs federated to each other.
Gardner: Is it that you don’t agree with Neil then, that if Microsoft is a bit more ecumenical on this, would we expect them to embrace SCA and SDO? Is that what you expect?
Kobielus: It’s a relative thing -- getting ecumenical. They get ecumenical when they are good and ready, like they’re doing right now in the identity space, with this whole notion of user-centric identities. It’s taken them a couple of years of sitting back, watching things like OpenID and Higgins develop. And then finally they make a token offering that says, “Okay, we’ll implement OpenID in the next generation of the Vista Card Space."
And, once again, my sense is they’re going to wait quite a period of time, at least a year, before they make any public pronouncements on the extent to which they are going to work with OASIS on SCA and SDO. It’s just their nature, and they are going to pursue their proprietary approach, as long as it holds out, and as long anybody will implement it.
Macehiter: I’m not suggesting that this a face-off. What I am suggesting really is that it comes down to the point of control that an organization or vendor has. Microsoft does not want to be denigrated to the plumbing, even if that’s interoperable plumbing. The point you raised about TIBCO with ActiveMatrix is that it’s actually using the SCA programming model in order to provide this abstraction.
So, ultimately in that environment who’s controlling it? TIBCO is becoming the master, and it will be the same in an IBM environment. SCA may be under the hood, but ultimately there will be a point of control that IBM wants to wrest for its process server for its development tools, and that’s what Microsoft wants to do. The challenge is that SCA and SDO are trying to do the same thing as Windows Communication Foundation and Microsoft tooling around .NET and SOA.
Gardner: To wrap up, it seems that it's not a face-off, but perhaps there are, as Jim points out, a lot of vendors who would like to be that over uber-dashboard, point of control. Some are BPEL-focused and others are taking different tacks. SCA seems to be playing a role for many of them, and Microsoft would like to play that role as well -- but perhaps thinks that it has an advantage through the way it’s architected up to this point. The market will, I suppose, determine who the ultimate winner is.
Macehiter: I think a lot will depend how quickly the tooling comes out around SCA and SDO, as an alternative to Visual Studio.
Bell: The other piece too is, as Microsoft tends to build those kinds of capabilities in as part of the operating system, other vendors tend to create them as standalone products and infrastructure pieces. If you are a small company, having it built into the operating system is a value to you, but in large, heterogeneous environments that can be costly to you. So, that’s always been used by Microsoft. If you look at CORBA versus COM and DCOM, it’s the same story.
Macehiter: Absolutely.
Gardner: You’ve been listening to yet another BriefingsDirect SOA Insights Edition, Vol. 15, for the week of March 19, 2007. We’ve been joined by Jim Kobielus, principal analyst at Current Analysis. Neil Macehiter, a research director at Macehiter Ward-Dutton. Steve Nunn, the vice president and COO of The Open Group, and John Bell, enterprise architect at Marriott International.
I'm your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions. Thanks everyone, and thanks for listening.
Listen to the podcast here. 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. 15. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Subscribe to:
Posts (Atom)
