BriefingsDirect SOA Insights Analysts on Converged Governance and the New SOA Consortium

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Feb. 16, 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 12, 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 consists of Steve Garone, former IDC group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome to the show, Steve.

Steve Garone: Thank you, Dana. It’s great to be here once again.

Gardner: Also joining us is Joe McKendrick, a research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Welcome back, Joe.

Joe McKendrick: Real pleasure to be here, Dana. Thank you.

Gardner: Also joining us is Neil Macehiter, a research director at Macehiter Ward-Dutton in the U.K. Welcome back, Neil.

Neil Macehiter: Thanks, Dana.

Gardner: And also here is Jim Kobielus. He is a principal analyst at Current Analysis. Welcome back, Jim.

Jim Kobielus: Hi, Dana.

Gardner: This week -- and it is the week of Feb. 12, 2007 -- we’re going to tackle two subjects. The first one is an important issue around governance, and whether governance is going to evolve into more of a converged activity. What we’re seeing is that SOA governance vendors are putting together policy-based approaches for managing the complexity of SOA. They're trying to automate the various resources within that environment and architecture, and to provide control for those managing the IT development deployment life cycle, as we get more toward a mixed environment of services, perhaps a variety of different sources.

So, we've got SOA governance that is evolving, but with its own technology, its own metadata, its own repositories, and even its own standards. Alongside that on a parallel track are Governance, Risk and Compliance (GRC) platforms, and a number of prominent vendors such as SAP, CA, OpenPages, MEGA and others are providing this as a service for regulatory compliance, principally to CFOs in large organizations.

We've also seen over the years on the management side governance platforms, dashboards, approaches, and methodologies along the lines of a Balanced Scorecard approach or process reengineering for the chief executive’s office. Also we have parallel and yet still disparate tracks for governance. I'm wondering, along with Jim Kobielus who raised this issue, where this might be going? Why don’t you tell us, Jim, what you're seeing, and some of your thoughts around this subject?

Kobielus: Thanks, Dana. I started being fairly cynical about a year ago over whether compliance was a market, I kept hearing about the compliance market, the Sarb-Ox market, and so forth. I was thinking it’s a concern in the same way that competitive advantage is a concern or a benefit from the appropriate and effective deployment of technology, but can you really regard compliance as a platform?

One of the things that I've seen over the past year is the growth of this new sector -- GRC: Governance, Risk, and Compliance Management -- not just as a big top under which many diverse product categories are being lumped, although to some degree it is. You see business intelligence, corporate performance and management, business process management, identity management, document management, all these things, all these existing technologies, being lumped under this GRC heading.

What I've also seen is that a growing group of vendors are building products or platforms into which they’re able to plug in, and are plugging in, various tools specifically geared toward GRC. In other words, a legitimate new niche of GRC vendors is growing up, and, Dana, you listed some of the chief ones that I've come across.

SAP about a year ago acquired a company called Versa Systems, which made tools for continuous controls monitoring. Around the Versa Team as a nucleus SAP has begun to roll out a GRC platform that includes a repository of policies and rules, a process modeling tool geared towards building business controls as structured workflows and also testing and monitoring those controls.

They rolled out a performance management dashboard environment under which you can roll up a unified view of your compliance and your corporate risks across all governance categories. The categories include SOA governance, IT governance, and operational business governance, and so forth. SAP is not alone in this regard.

You mentioned Computer Associates. They have their Clarity family of products, and there are some smaller but just as important like OpenPages and MEGA International, BWise, and several others that have similar product architectures and similar modular approaches to plug-ins. For example, you can plug in to most of these environments a module to do IT governance in compliance to say, CobiT, ITIL, and so forth.

One of the things I haven’t seen yet is any clear convergence between all this GRC governance, a lot of business governance and high level IT governance products, and the SOA governance world of UDDI registries and Web services management agents a la AmberPoint. I see two separate camps right now.

To some degree the GRC vendors are all pretty much SOA-enabled in the sense that they have native implementation of Web services, but I'm not yet seeing the vendors in that camp, other than SAP, with a strong SOA story or SOA partnerships. SAP has significantly SOA-enabled their entire suite of products over the last several years. So, that's the open question I wanted to bring out for group discussion: To what extent do you all see a convergence between business governance a la GRC and SOA governance?

Gardner: Let’s go to Neil Macehiter. Neil, is it necessarily a good thing for a compliance-oriented business policy engine to converge with what is running the IT operations, and increasingly in conjunction with what's going on with the business? Maybe we should check our premises and see if this necessarily a good thing before we start figuring out how to do it?

Macehiter: We’ll have to come back and think about what we mean by governance and compliance. Jim commented on it and he was somewhat cynical about that being a compliance market. I'm still quite cynical about it being a compliance market, because I think compliance and, more generally, governance is something that should be systemic. It’s not something that you sell with a particular tool or even a particular platform. It’s something that has to be systemic throughout the IT architecture, so that, for example, high-level business policies and high-level business requirements, in terms of compliance, can then cascade down through the IT solutions that actually automate and support the business processes that need to comply.

So, yes, absolutely. There is a need for this convergence to occur. For example, the services that are actually supporting your business processes are capable of enforcing the policies that allow you to monitor the controls and enforce the controls that you need to demonstrate compliance. That extends across things like identity management solutions, which have also come up with their own compliance solutions focused on their particular bit of the overall IT architectures. In their case it’s around authentication and authorization and things like separation of roles and segregation of duties. It needs to become systemic, and it’s not just SOA governance that needs to be tied into this. It’s also the work that’s going on in the IT service management market around CobiT- and ITIL-based processes.

It’s a broad issue. The challenge is that SOA, if we take SOA governance specifically, has evolved very much from a bottom-up perspective, in terms of initially addressing design time governance, and then gradually extending into the more run-time governance. Meanwhile, we’ve got things like the GRC solutions from the likes of SAP with Versa coming at it very much from the top-down perspective. The problem is they are not meeting in the middle yet.

It’s largely a semantic problem. How do you translate a high-level business policy that says, "We have to adhere to Sarbanes-Oxley," or "We need to address corporate social responsibility on regulations," or "Provide transparency to operations for customers?" How do you translate that into a set of policies that can then be enforced and actioned at the lower levels of the architecture?

The semantic issue will be enabled through standards, but until there’s some common agreement around the semantics and the translations between these different layers and different solutions, it’s going to be a challenge that does need to be overcome. So governance and compliance become something that’s systemic and continuous, as opposed to a solution you need to address every time, you've got an audit coming up.

Kobielus: I agree completely. It should be systemic. I'm still cynical about the notion of a compliance product market. Compliance is really much more of a professional-services market in terms of consultancies, large consultancies, sending teams of people out to help organizations, to reengineer their business processes, to audit their processes, and so forth. For the most part, at least two-thirds or more of the so called compliance market is purely services, and the products are the least of it. Most of the products in the market are point products for the squeaky wheel that needs the grease. These all-encompassing, omnibus compliance platforms are the least of the market currently.

Gardner: Correct me if I'm wrong, but isn’t the regulatory compliance these GRC platforms are primarily geared at gathering information in a reporting sense -- audit trails and discovery -- to demonstrate whether compliance is happening or not? On the other hand, from the bottom-up perspective as Neil mentioned, SOA governance is also involved with execution and the enforcement, taking a policy and then making it instantiated in the architecture and behavior of the processes. So, it's yet another reason why they should come together is that they actually need each other. How do you see this, Steve Garone?

Garone: I've been listening to the other guys talking. They're very insightful comments, and I agree with them in substance. I think the over-arching issue here is that GRC platforms are taking more of an enterprise architecture approach. They're still looking at business processes, monitoring business processes, and maybe even getting to some extent into the redesign of those processes to optimize the ability to meet compliance needs. SOA has, in fact, been coming from the ground up, and solving maybe a specific problem or issue within the department or organization. Because we’re in the early days of SOA, we're seeing a lot of that.

One of the interesting nuances here is that both approaches eventually need to focus on the business processes within the company, and optimize them for various reasons. SOA tends more, at least right now, to focus on making business processes work more efficiently. How those services are segmented and designed functionally ideally should reflect that; whereas, for the enterprise architectural approach and the GRC approach, we're looking more at being able to meet compliance needs. The question becomes how do you develop a services-oriented approach that meets both of those needs, optimizes compliance on one end, and optimizes customer satisfaction and performance and business agility on the other hand. Those could ultimately be in conflict, as these two worlds come together, and that’s an interesting new answer that organizations are going to have to look at.

Gardner: So, there seems to be some general consensus that there is value in bringing these so far disparate areas together -- governance risk and compliance with the SOA governance. If we were to move toward this middle ground and make them relate, it strikes me that data becomes important.

Joe McKendrick, you keep your ear to the street on data quite a bit. Do you think that this is simply a matter of yet again finding a meta level or layer that allows the data that’s being derived for one or both of these areas to be viewed, or used together, and wouldn’t that be a first necessary step?

McKendrick: Absolutely, Dana. It’s interesting that when we talk about SOA in relation to another type of corporate initiative -- in this case SOX and GRC and so forth -- we're always wrestling with how SOA fits into the picture. We've been challenged to make the pieces fit together, and I find that’s an interesting conundrum for SOA across a range of things happening in organizations. That being said, I recently conducted a survey for the Oracle application’s users group. We just released the survey last month on the very topic of GRC. These would be the folks who are working with the Oracle e-Business Suite, Oracle application server, and so forth…

Gardner: Of course, we know that anything SAP does, Oracle will be coming along, or vice versa.

McKendrick: Exactly. SAP seems to be pretty far head of the curve in this regard in GRC. What we found in the survey is that for the most part, there’s awareness. About 40 percent of the survey group from the 400 companies we interviewed was fairly aware of GRC, what's happening, and what's required for GRC. That was higher than we expected. So they’re trying to getting their heads around what needs to be done with compliance. At this point, the tools that are being used the most to accomplish the task around GRC compliance are the Excel spreadsheets or the Word-type documents that are flying back and forth. Seven out of 10 companies are moving these processes through or doing the reporting and putting out reports for the audits with these manual tools. Only about 15 percent say they have any measure of automation.

Gardner: They are using Excel spreadsheets?

McKendrick: Exactly. Excel. I think automation is going to be the key to all this, because companies are not in the business to meet SOX requirements. They are in business to make money for their shareholders. They’re in business to sell products. Compliance isn't their main line of business. They're being forced to pay attention to compliance and they are being forced to deliver these reports to auditors. Right now, they're committing staff to it. They're committing a lot of resource time, and resources that they don’t want to, and it’s happening on a quarterly basis. The folks involved in the reporting process have to generate the same reports every quarter, and we need to build in automation and repeatable processes. This is where SOA can play a pretty vital role.

Gardner: And, clearly business intelligence vendors, including SAP, have come into the fore. Reporting is the very core of business intelligence. So, first and foremost, if you want to do compliance, you have to produce reports, and if you have to produce reports on a regular basis from structured data in your operational systems, you need business intelligence (BI). That’s really the core, as it were, of any GRC platform.

One of the interesting things I'm finding in the growth of these GRC über-platforms is that there’s another important user interface, other than just the reporting and dashboarding the BI stuff. There are also structured surveys that can be delivered to stakeholders in a process on a periodic basis, asking, for example, procurement agents how well various business requirements or regulatory requirements are being met, from the procurement side to be in compliance with Sarb-Ox or whatever it might be.

So most of these platforms now have what I call a stakeholder interaction environment, involving not only the surveys, but other human workflows, not just GRC as a mean for pushing big rolled-up risk dashboards to the CFOs and the CEOs, but GRC as a way of regularly serving the troops as to how well processes are performing on various levels.

Steve asked earlier about how do you develop a GRC approach that addresses compliance, but also ensures business agility? One of the things that you can do is survey the troops, the grassroots stakeholders and process participants on a regular basis. "How well are we not only serving the Sarb-Ox requirements, but how well are we serving the customers through this retool process that you instantiate every day?"

Macehiter: As we see more of these compliance solutions emerging around identity management, business intelligence, and the stovepipes of technology, what will happen is that the problem will move away from organization struggling to find the information. We actually have too much information and we have to rationalize it. Our identity management system is telling us we're in compliance with Sarb-Ox because x-y-z, and our purchasing application is telling us, but we can’t actually rationalize the different information to provide visibility into whether we are really compliant. That’s going to be a very real problem.

Kobielus: Now, I just want to add a note here too. Hugh Taylor, vice president over at SOA Software wrote a book on this very topic called, "The Joy of SOX." I don’t know where he got that title from. Was there another book with the similar title one time?

McKendrick: "Fox in Sox" is a Dr. Seuss book.

Kobielus: The full title was, "The Joy of SOX: Why Sarbanes-Oxley and Services Oriented Architecture May Be the Best Thing That Ever Happened to You." He actually connects the dots, and it's the first real comprehensive case I've seen of someone actually tying the two together.

For his main point, he talks about the agility that SOA can deliver and the agility that is required to meet various compliance mandates and future mandates that will be coming down the road. The key thing with SOA is that, it enables you to access legacy systems. Most of large companies that are facing SOX audits also have mainframes and many legacy systems that they need to deal with.

Gardner: Well, if he can make regulatory compliance sexy, all the more power to him.

But I think we've come to a point here where hypothetically we recognize that having converged governance makes great sense. It strikes me, however, this is going to be many years before any kind of actualization. In the meantime, the larger message perhaps is that, as you’re doing BI, and as you’re creating more ability to capture data, cleanse it, and provide it in a way that gives you this GRC benefit, then when you decide whether you’re compliant or not, or you come up with an agenda of what needs to be done, that is not by choice but is mandated, how do then face back into the organization and get that into execution?

That’s where SOA can come up to the plate and say, "Well, why don’t we take your mandates and instantiate them into our policy engine that's reflected through the IT systems that has a relation to the legacy systems, as well as to the new systems?" Then SOA becomes the hammer through which something like a GRC platform can mandate and enforce. Even if these two systems remain disparate, it seems that they have a tag team in the near term. Can anyone react to that?

Macehiter: In an ideal world, the way the service-oriented approach works is that it’s much more declarative, much more policy driven. You don’t lock away, for example, the way that you authenticate a request or the way that you log a request into the application logic. You externalize that and control it through policy. That then allows you to drive though these policies from the high-level requirements to the GRC level down into the service infrastructure.

Whatever follows from SOX doesn’t mean building in a bunch of new code that ensures that you comply with SOX-plus, SOX 2.0, but rather that you define the policies that you need to, and then get them enforced through the infrastructure. So, I think you’re right that it’s a hammer, but the hammer needs to be wielded quite carefully. The key is going to be the semantics, and the language that allows you to define what most policies are, so that they can be enforced effectively.

Garone: I agree and just to carry the analogy a little bit further, it’ll be nice to able to design that hammer at the same time you’re assessing your compliance requirements and putting that infrastructure in place as well, so that the wielding of the hammer becomes more closely aligned with your goals as far as compliance is concerned.

Gardner: That would be the ultimate convergence, but even in the meantime it strikes me that there is sufficient short- to medium-term value in generating a SOA governance capability. Compliance and regulatory oversight is perhaps a major rationale for SOA, sooner rather than later.

Anybody else want to comment? Jim?

Kobielus: SOA is about sharing and reusing valuable corporate resources that are networked. The GRC platforms increasingly will differentiate based on their ability to bundle a broader range of best practices accelerator with polices and works flows and roles and metadata, and forth. So, really, GRC platforms are platforms for SIs to customize the policies to meet the needs of particular clients. The accelerators themselves are the sharable, reusable SOA resource that will speed up the implementation of compliance solutions in various markets. The accelerators themselves are the most critical resource that defines a GRC platform or GRC solution.

Macehiter: The point Jim raised about sharing and reusing is absolutely the key here. It's the one of the biggest challenges around compliance. Typically, organizations have multiple instances of processes locked away in different applications. They have 16 different versions of their customer or 14 different versions of a purchase order.

If what you can do by virtue of adopting more of a service-oriented approach is have common services to actually deliver capabilities that need to be audited, logged, and monitored, or if you can have a single shared service that increases consistency and reduces the effort you need to apply for compliance, increasingly what we will see is the rationale for the business case. What underpins an SOA initiative will be either that it improves our ability to comply in a cost-effective way and increases the consistency of what we do to comply.

Gardner: Perhaps what we should expect to see is not only the SOA vendors and service providers talking about compliance and regulation as a rationale for SOA investment and evolution, but perhaps it might be in the best interest also of these GRC platforms to say how well they play in conjunction with SOA and that there is a complimentary nature here.

McKendrick: Right. The only issue is that GRC is typically led by financial folks and, of course, SOA is coming out of the IT department. What happens is that the financial folks are saying, “We need more of this automated. We are not going to give you more budget to do it, but IT folks automate this process little bit more for us."

Gardner: Well, that issue is an excellent segue to our next topic, which is the announcement on Feb., 12 of the SOA Consortium, a group of both vendors and enterprises -- they are calling themselves Global 1000 End-user Organizations -- in order perhaps to bridge some of these gaps and promote the best interests of different constituencies within organizations, as well as within vendors and types of vendors.

The declared goal of this organization is to promote the adoption of SOA, and they’ve given themselves a deadline of 2010. So, in the next three or four years they want to get more people aware of SOA as a key enabler, as an element of any modern 21st century architecture and enterprise. They want to achieve benefits of SOA to change both IT and business, bridging the gaps and silos, both technically as well as culturally. They want to help the perception of SOA by business executives, they say, as an IT integration and productivity story, rather than a business agility story.

That sentence jumped out at me to say, "Aha!" These are some of the things we’ve been discussing for a number of weeks about the positioning of SOA for adoption and appreciation. It seems to me to be saying that the story around business agility is a system’s integrator business and organizational management topic. They want to bring it back into an integration function. Any reaction to that?

Macehiter: I read the press release and I think it’s actually a badly worded release, to be honest. What they’re actually saying is that one of the issues they're trying to address is the fact that SOA is perceived by business executives as an IT and integration productivity story, and they want to turn it into a business agility story. But it’s not clear.

McKendrick: I read it the same way and I agree with that statement, based on my experience with end-users. When I hear them talk about their experiences with SOA, it’s always around cost issues and the integration challenges, and very little about "Look at the business agility we achieved." What they are doing is citing that as a significant issue and potentially a barrier to SOA adoption, and I assume it’s their intent to address that.

Kobielus: I didn’t see a lot of specifics in this announcement. I try to boil down every press release to its absolute core, in terms of substance, and I didn’t see a whole lot here other than they are going to hold a bunch of summits in different cities, present some general mission, seek validation of that mission, and then ultimately produce a detailed report that will validate and direct the charter of the SOA Consortium.

I’m sorry, I had to put on my cynic hat. It sounds like this is an excuse for many fine lunches and dinners to be had. In terms of building awareness of SOA, it’s like -- duh. Aren't we all hyper-aware of SOA by now? Let’s think of the next step. You can sort of understand the vendor’s perspective in working in an organization like this, getting visibility and perhaps more importantly being able to leverage the successes of some of the companies who have used SOA. I’m not really sure what’s in it for the end-user organizations, and that's where I become skeptical.

Gardner: Well, if you look at the very last line of the release, it says, the SOA Consortium is managed by the Object Management Group, and we know from past history that the OMG's job has been to create a consortium generally around a set of standards, and there is no mention here of standards, because these are invitation-only summits, with both vendors and end-users. I think that the underlying agenda between the lines here is to help create a level of some standardization, perhaps around governance, perhaps around SOA interoperability. But, clearly there’s going to be a set of standards that’s going to evolve from this, not just from the perspective of the vendors, but also the end-users. And, that in itself strikes me as somewhat positive.

Macehiter: I think so. Look at what’s happened, for example, around the Liberty Alliance in a different domain involving large adopters and vendors, and that has delivered some tangible results. So, I think it holds promise because this is not the classic vendor "Let's set standards" to help customers, but without actually involving the customers in the process. So, that’s a positive sign.

My concern around this is whether the Object Management Group is going to embrace the work that’s currently on the go, taking place in OASIS around blueprints reference architectures, because there’s a lot of IT being developed there, that could be effectively exploited. I am just slightly concerned that what we are going to get is a proliferation of best practices and no common best practice. I’m also concerned that this is about global initiative, where the initial summit’s taking place just in the U.S., because the way SOA is being adopted in Europe, is very different from the way it’s being adopted in the U.S., and its relationship to things like enterprise architecture. I know this is only the initial meeting, but it sets the frame of reference for the rest of the work.

Gardner: Hold on a second. There could be some hope for this being global, if the funding sponsors are BEA Systems, Cisco Systems, IBM and SAP.

Macehiter: I think that’s global from a vendor perspective, as opposed to an adopter perspective. If I start to see the likes of HSBC or Tesco and some of the big adopters that we have over on this side of the pond involved in this process. That will stand in good stead.

Gardner: That will be critical for them. I agree.

Garone: The OMG has usually been pretty good about globalizing what they do, so I wouldn’t be too concerned about that. I also think that the point about the vendors being global is an important point, because based on the way the OMG model has evolved; I suspect this is being driven mostly by the vendor community.

Gardner: What we should do then is invite someone from this group onto the show in the next few weeks. I’ll reach out to Richard Soley, who is the chairman and CEO of the Object Management Group, and invite him to come on the show, and we can pose some of these questions to him. Is this a movement toward standards? Will they be global and inclusive? Will they be vendor-focused, or is there going to be a good balance between the end-user organizations as well? So, our listeners can look forward to a further discussion on the SOA consortium announcement with someone involved closely with this effort.

Kobielus: I like the parallel you drew with the Liberty Alliance, which is still actually a very vital organization. It started out as a standards organization or standards developer and still is to a degree, but has really moved deliberately to more of a best-practices forum in the identity management space. This is a critically important in a space such as in identity management, where there’s still a blizzard of standards and specifications, competing for market share and so forth. More than that, there is a huge variety of use cases and possible deployment scenarios, topologies and interoperability issues bedeviling that space.

Think about SOA. That’s even more confused and confusing in terms of best practices in such a global oceanic sense. SOA is literally all over the map. So if OMG, as a best practices forum, can help the industry to converge on a consensus of best practices for SOA, godspeed to them.

Gardner: Well, this has been another insightful 45 minutes. I would like to thank our panel of Steve Garone, Joe McKendrick, Neil Macehiter, and Jim Kobielus. I'm your host and moderator, Dana Gardner.

That’s it for this week's SOA Insights Edition, Volume 12. We appreciate your time and listening in. Please come back next week. Thanks, everyone.

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.

Listen to the podcast here.

Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 12. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.

BriefingsDirect SOA Insights Analysts on SOA Suites Vs. Best-of-Breed SOA, and Master Data Management

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Jan. 26, 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 Dana Gardner at 603-528-2435.

Gardner: Hello, and welcome to the latest BriefingsDirect, SOA Insights Edition, Volume 10. 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 SOA columnist.

Our panel this week consists of show regular Steve Garone. Steve is a former IDC Group vice president, founder of the AlignIT Group, and an independent industry analyst. Welcome again, Steve.

Steve Garone: Hi, Dana, great to be back.

Gardner: Also joining us again Joe McKendrick, research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Thanks for coming, Joe.

Joe McKendrick: Thanks, Dana, glad to be here.

Gardner: Also Tony Baer is making another appearance. He is principal at onStrategies. Thank for coming, Tony.

Tony Baer: Hey, Dana, good to be here.

Gardner: We’re also talking with Neil Macehiter. He is a research director at Macehiter Ward-Dutton in the U.K. Thanks for coming, Neil.

Neil Macehiter: No problem, Dana.

Gardner: And last on our list -- we have a large group today -- Jim Kobielus. Jim is a principal analyst at Current Analysis. Thanks for coming along, Jim.

Jim Kobielus: Thanks a lot, Dana. Hi, everybody.

Gardner: For our first topic this week -- and this is the week of Jan. 22, 2007 -- we’ll begin with the notion of SOA suites, a merging and definable market segment. We’re going to be looking at how mature such suites are. I suppose we should also look at the distinction between the best-of-breed-approach, where one could pick and choose various components within their SOA arsenal, or a more complete suite, a holistic full-feature set with the benefits, trade-offs, and detriments of each of these approaches.

Jim, you’re the one who was interested in this topic. Why don't you give us a little set-up as to what you think the state of the market is?

Kobielus: Thanks a lot. Over time, we’ve all been seeing this notion of a SOA suite take root in the industry’s productization of their various features, functions, and applications. Now, the big guys -- SAP, Oracle, Microsoft, webMethods, for that matter lots of software vendors -- are saying, “Hey, we provide a bigger, 'badder' SOA suite than the next guy.” That raises an alarm bell in my mind, or it’s an anomaly or oxymoron, because when you think of SOA, you think of loose coupling and virtualization of application functionality across a heterogeneous environment. Isn’t this notion of a SOA suite from a single vendor getting us back into the monolithic days of yore?

This thought came to me when I was reading a Wall Street Journal article earlier in the week about SAP, “SAP Trails Nimble Start-Ups As Software Market Matures.” There was one paragraph in there that just jumped out at me. They said, “Some argue that SAP's slump highlights a broader shift under way in business software, in which startup companies wield an advantage over established titans. Under this traditional business model companies buy large, costly packages of software from SAP and Oracle to help them run their back-office functions and so forth, but as the business software industry matures, many companies already have the big software pieces they need, and feel little urgency to replace them.”

So, clearly SAP is then sort of a driver in the SOA suite arena for few years with NetWeaver. Is the notion of SOA suite an oxymoron? Are there are best-of-breed-suites? There are also best-of-breed SOA components, and I’m not sure that the notion of a suite, an integrated suite is really what companies are looking for from SOA. They want best-of-breed components with the assurance, of course, that those components are implementing the full range of SOA standards for heterogeneous interoperability. So, I’m taking issue with this notion of a "best-of-breed" suite. Anybody else have any thoughts on that?

Macehiter: I’ll give you a couple of perspectives on this. We have to recognize that organizations increasingly are looking to rationalize their supply strategy. So, they’re increasingly looking to deal with a smaller number of vendors and suppliers, which is, in part, driving the move toward larger vendors attempting to offer a suite or portfolio of product capabilities that can help organizations manage the lifecycle of an SOA initiative.

That’s one factor that’s driving it. The second issue is the use of the term "suite," and what that really entails, versus what the market is currently delivering. Companies are putting together a bunch of products under a common brand, whether it’s Oracle Fusion, SAP NetWeaver, or under the IBM WebSphere brand. That's one thing. Actually making sure the products are well integrated and that they have a common management environment, common configuration environment, and common policy definition environment is the second thing. That’s one element of it.

The second issue is what actually constitutes a suite to support service-oriented initiatives. There is a tendency, certainly among the larger vendors, to focus on SOA from a development and integration proposition, rather than thinking more broadly about the capabilities you need to support service-oriented initiatives throughout the lifecycle. That extends beyond development and integration into things like security and identity, which have to be incorporated into an overall SOA offering.

Management and monitoring, usage management, audit logging are in the broad range of capabilities that you need. There’s a question as to whether it’s feasible for one vendor to offer all of those capabilities that you need to support an SOA initiative versus a set of core capabilities. Then the hooks in the interoperability allow you to exploit existing security and management infrastructure. There are a number of factors that we need to consider, and a lot of the SOA suite propositions are very much focused around development and integration, rather than management and monitoring, and really dealing with the lifecycle of services.

Gardner: I guess that explains and is consistent with the past. If you can have a cohesive approach to the development side, then the deployment tends to follow, and that’s where you monetize. Steve Garone, what do you think of this breakdown between best-of-breed and a suite?

Garone: All of us on this podcast today know that the debate over best-of-breed versus integrated-stack approach has been going for many years in a variety of scenarios and contexts, and it hasn’t stopped. I don’t really like the word "suite." It reeks more of marketing than functionality. I think what you really have to look at in terms of SOA is how people are actually approaching getting into building SOA-based environments.

What we’ve seen so far -- and we’ve talked about this on other podcasts -- is that up to this point people have tended to do pilot projects that are much lower in scale than what they will eventually do if they have success with the immediate projects. One tends to think that what they’re going to do at that point is pick and choose the individual products and functions that they need to make that happen in the short term.

I think that’s what we’re seeing, but I also sense that, despite the fact that everybody wants an open environment where they can pick and choose and not be tied to one vendor, what overrides all this is a desire to get things done quickly, efficiently. They want a way in which they don’t have to be concerned about integrating a lot of products and what that entails, and having potentially an unreliable environment. What that points to is working toward one vendor. End users will do that even in the short term by choosing someone that they know they can grow with in the future.

Gardner: Pragmatically, these vendors are also looking at their future and they’re saying, “We have an installed base. We have certain shops where we’re predominant. We want to be able to give them a clear path as to how to attain SOA values from their investment in our legacy. Therefore, we need to follow through with add-ons that smack of a integrated-stack approach.” So, it is almost incumbent on vendors to try to produce this "whole greater than the sum of the parts" -- if not to build out more SOA business, then just to hold on to their previous business.

Garone: That up brings up another interesting point, which is vendors, especially the platform vendors. The larger vendors, like IBM, Sun, and so on, tend to try to walk the line between being able to offer a fully integrated stack of software to accomplish whatever the goal it is -- in this case SOA implementations -- and also being what might be called “integratable.” This means you can bring in another product, because we adhere to standards, we’ll be able to help you do that.

They try to walk that line; where that really makes a difference is not so much what you are going to do in the future, but rather what you have done in the past. If you've got an existing registry that you used for identity management with your current applications, if you have existing app servers -- which is probably more common -- whomever you choose is going to have to be able to allow you to continue to work with those as part of a legacy environment. It sounds funny calling application servers legacy, but at this point you can do that, and that’s really where the "integratability" aspects of a fully integrated stack come into play.

Gardner: So how about you, Joe McKendrick? Do you see that the drive for simplicity and working from your installed base creates a compelling case for an integrated SOA approach? Or is the trade-off such that this is really not going to happen anymore? Is that the old way -- and is SOA fundamentally different, and therefore one should look for a different strategy?

McKendrick: Perhaps a little of both, Dana. Basically the industry still operates under the traditional mode where a lot of enterprises rely on one vendor -- we'll call it a master vendor -- that supplies most of its solutions. We see that in the IBM and in the Oracle markets. I agree with Jim that the notion of a SOA suite is very much an oxymoron. The idea of a SOA is to have "hot-swappable" software components that you could install and take out as needed in a loosely coupled architecture.

Dana, you hit upon the point that the vendors themselves have to demonstrate that they have some type of path to their installed base. They need some type of path to show that, "Yes, we are on top of the technology." In fact, if you speak with vendors out there about this strategy, even if the products or the path that they're offering are something customers aren’t adopting at the moment, it’s something they want to see with the vendor. If Oracle, hypothetically, wasn’t talking about SOA at all, there would be a lot of consternation, a lot of concern, among their installed base as to where the vendor is going.

Gardner: SAP would walk in, and their sales people would beat them up in these accounts, right?

McKendrick: Exactly. Now, Oracle is an interesting case. When I think of suites, I think Oracle demonstrates the best tendency in this area. In fact, they called their offering "The SOA Suite," and they include a number of components. I have spoken with some companies that have Oracle installations. Now, it should be noted that typically the customers for these suites are the installed base. The people who will be buying into the components of the Oracle SOA suite are companies that either have the Oracle applications, the E-Business suite or the Oracle database underneath. And, in most cases, they are buying into components of the suite.

I've heard a lot of positive things said about the BPEL Process Manager, for example. And, they are buying into pieces of the solutions, and as Steve pointed out -- it’s still in the pilot-project stage. We’re not seeing widespread enterprise implementations, but they are beginning to buy into pieces of these solutions such as the BPEL Process Manager.

Gardner: Hey, Tony Baer, how about you? Do you think that we are mature enough in SOA that we should be looking for homogeneity when it comes to tools and even deployment side? Or, is heterogeneity the issue that we are trying to manage?

Baer: As Steve was saying before, we can’t decompose it down to the age-old argument of best-of-breed versus integrated-stack. There is always going to be a tension between homogeneity and heterogeneity. For the customer, it’s going to be dictated obviously by what is already in place, basically as Joe pointed out. If 60 percent of my functionality, or even say 30 or 40 percent of my functionality, is SAP, I’m likely to listen when SAP tells me about a NetWeaver Solution.

On the other hand, if I’m in a sector that does not lend itself to package solutions, I will more than likely tend to take a best-of-breed approach -- especially if I do a lot of homegrown development, because my business is so unique. There will always be that creative tension there. That being said, the fact is that at the infrastructural level, there is a desire to have consistency. I don’t want to have five security engines. I don’t want to have three different authentications, if possible. Obviously, we’re never going to get that one, centralized identity repository in the sky, but I want to at least have my management framework be as consistent as possible and to manage what will inevitably be, in most large organizations, a federation of different installed bases of different technologies.

The other side of this is that for vendors -- and Oracle is probably the best poster child for this -- the reality in the enterprise software industry has been one of merger, acquisition, and consolidation. This means that vendors who started as organic developers now have four or five different product lines and each has had a separate lineage. The only way to put some rationality there is something like an Oracle Fusion SOA framework. Oracle has to develop this, if only out of the necessity to keep its own product offerings consistent.

Gardner: Now, back to Jim Kobielus’s point about this integrated approach being an oxymoron for SOA. Shouldn’t the vision of SOA allow us to have it both ways? If you have a culture and mindset in an organization, maybe it’s because of your legacy. Maybe it’s because of how you operate and the value you’ve perceived in past IT investments. Thus, you might want to remain with more of a single-vendor or an integrated-stack approach, but there might be other vendors without a legacy to drag along. The enterprise may want to take advantage of any innovation they can to be functionally heterogeneous and to explore and test open-source componentry as that becomes available. Shouldn’t SOA allow both of these approaches -- and pretty much equally?

Macehiter: In principle it should. We have to be careful to distinguish between the infrastructure that you require to enable SOA initiatives and what you’re trying to enable with that service-oriented initiative. Just because you want to have a loosely coupled component that you can combine in multiple ways to deliver business outcomes, doesn’t mean that the infrastructure that underpins that has to be similarly loosely coupled and based on the heterogeneous offerings from different vendors. So, there is a separation there.

We also we have to bear in mind the challenges around going for best-of-breed approach, which are well understood. It’s not so much whether the individual components can actually talk to one another but more about things like the management environment and how you manage the configuration and how do you deal with policy definition?

We’ve done some detailed assessments of service infrastructure offerings from SAP, BEA, IBM, Oracle, Sun, and webMethods. If you actually dig under the covers, you will see that each of the components has its own policy definition approach. So, the way you configure policy within the orchestration engine is inconsistent with the way you do it within the security and identity management capabilities, and that challenge occurs within suites. That’s going to be compounded as you look across different components. That introduces risk into the deployment. It reduces the visibility of the end-to-end deployment. It's those factors that are going to be important, as well as whether a communication and brokerage capability can integrate with the registry and repository. There are a number of factors that you have to bear in mind there.

Kobielus: I agree -- I think that the notion of a best-of-breed SOA suite makes more sense from an enterprise customer’s point of view. Most enterprises want to standardize on a single vendor and a single stack for the SOA plumbing -- the registries and repositories and also the development tools. They want the flexibility to plug in the different application layer components from Oracle and SAP and others, that are SOA-enabled and that can work with that single-core-plumbing-stack from a single vendor.

Gardner: Perhaps the tension here is between what aspects of SOA should be centralized, repeatable, simplified, and consolidated, and which ones should not. It’s not really a matter of SOA homogeneous or SOA heterogeneous. In moving toward SOA, should you say, "Listen, this is going to be common throughout. Let’s reuse this. Let’s manage our policy as centrally as possible.

"We might say the same for other federated and directory services. We might say the same for our tooling, so that we don’t have myriad tools and approaches from our developers. On the other hand, we want to have great flexibility and loosely coupled benefits, when it comes to which services, be they internal or external, be they traditional nature or more of a ‘software as a service’ nature that we can easily incorporate and then manage those as process."

So, is the dividing line here, Steve Garone, between what architecturally makes sense as centralized and not?

Garone: Actually I’ve just sort of been chomping on the bit here a little, because I’ve been listening to the conversation. This a really important point, mostly because there is a lot of stuff -- a lot of analyst opinion, a lot of blogging -- floating around that I’ve read, and I know you guys have probably read, on this very subject, the sort of philosophical dichotomy between what SOA is supposed to be and the notion of an SOA suite or a SOA integrated stack.

Frankly, from the end-user perspective, the message ought to be that the whole notion of SOA, as it relates to loose coupling, is really focused on the services and the applications that you’re going to deliver. That doesn't imply or even suggest that your infrastructure cannot be based on an integrated stack or software that’s designed to work well together. It allows you to work with a single vendor, and to be very efficient about how you both develop, deploy, and maintain and manage your environment.

Gardner: We also have to remember that this evolution of SOA is not happening in a vacuum. There are other major IT trends and business trends of worth. Many of them are focused on trying to reduce the cost of ongoing maintenance and support somewhere between 60 and 80 percent of total IT costs, and maybe more, to free up discretionary spending and to reduce the total spending for IT in many organizations. The trends often involved include data center consolidation, moving toward a more standardized approach for underlying hardware, embracing virtualization/grid/utility principles, and so on. Perhaps we have to recognize that even as SOA moves on its own sort of trajectory, organizations are going to be consolidating and looking for commonality of services, and improved support and maintenance types of features throughout their infrastructure.

Garone: Just to make one more small point. The one area that may diverge from the philosophy that we’ve been talking about is in the area of open source. I think that people who go out and try to implement SOA-based solutions on a variety of levels using open source technology may tend to take a more best-of-breed, individual-component approach than those who would run to their local IBM sales rep and say, “What do I do with SOA?” Even that’s going to change over time, and we’re starting to see SOA suites develop around open-source technology as well. So, that’s going to move in that direction as time goes on.

Gardner: That's another trend that is in tandem with SOA and needs to be woven together with it. It’s obviously a large undertaking. I‘m also reminded, after an interesting briefing I took this week with Informatica, and Ash Kulkarni. We had a really long, interesting discussion about the role of data, master data, and metadata when it comes to moving toward SOA. We really shouldn’t lose track of the fact that as you move to applications as services, and you go loosely coupled, and you adopt more reuse across development with common frameworks, and use rich internet application interfaces -- what about the data?

The data has to be managed as well. Increasingly, companies that have had mergers and acquisitions, or have just gotten myriad applications with varying views of something as specific as a customer identity -- there might be 10 or 15 different views of a customer, as defined by a variety of different applications. How do you manage that? And when you think about the progression of the data, it seems to me that if not in actuality, in a virtual sense, you want to become centralized with your data so that data can be used in a clean and impactful or productive way across all of your services.

Does anyone out there have some thoughts about what considerations to have when it comes to data in this decision about best-of-breed or integrated approach?

Macehiter: I was just going to say, the issue is that data has always been treated as a second-class citizen, and that it has been the product of applications which have then been subsequently analyzed. More organizations are recognizing this need to treat data as a peer, and deliver access to information, whether it’s structured or unstructured, as a service, which can be incorporated as needed into business process.

IBM was quick to identify this when they sold the information as a service strategy. And Oracle, surprisingly, given where they have come from, has actually not really enunciated data services, vision and platform. Although I did notice something on the Oracle Technology Network a couple of weeks ago, where they are just starting to talk about Oracle Data Integrator, based on an acquisition they made of a company called Sunopsis.

So, increasingly that's going to become part of the broader suite proposition. And, this is not just in the area of data but -- more broadly as customer adoption matures -- what constitutes an SOA suite. We’ve seen this around registry and repository, which historically was a best-of-breed proposition from the likes of Systinet and Infravio. Where are they now? They're part of a broader suite proposition from HP and webMethods, respectively. We’ll see this again.

Through acquisition what constitutes a suite will broaden as organizations become more mature in their approach to SOA. "Information as a service" is exactly one of those areas. Initially, that will probably be served by best-of-breed components, and then through a combination of acquisitions or very close partnership relationships will gradually be subsumed into what organizations believe is a SOA suite.

Gardner: Any other thoughts on the data services level and how that relates to this discussion?

Kobielus: I cover SOA for Current Analysis, primarily with reference to data management; and SOA in the data management realm is really consistent with master data management (MDM) as a discipline. Basically, master data management revolves around how you share, reuse, and enable maximum interoperability of your core master reference data, your single version-of-truth information, which is maintained in data warehouses and various operational data stores, and so forth.

Informatica is one of many vendors -- you mentioned Informatica earlier -- that has a strong MDM strategy. But there are are a lot of enterprise information integration (EII) vendors out there. EII revolves around really federated MDM, where you keep the data in its source repository, and then provide a virtualized access layer. This allows your business intelligence and other applications to access that data through a common object or model and a common set of access schemas -- wherever that data might reside -- but facilitated through a virtualized access layer. That’s very much EII as implemented by Business Objects, BEA, and many other vendors, and is very much the approach for federated MDM.

Gardner: Let me pause you there for a minute, Jim. If a virtualized centralization works for information, why wouldn’t it work for other aspects of SOA?

Kobielus: Oh, it does. Virtualization, of course, is one of the big themes in SOA.

Gardner: You can enjoy the benefits of a homogeneous approach, but, in fact, have great heterogeneity beneath the covers. Isn't that the whole idea of SOA -- to provide homogeneity in terms of productivity control management, and yet with flexibility and agility?

Kobielus: SOA, first and foremost, is a virtualization approach -- virtualization defined as an approach for abstracting the external call interface from the internal implementation of a resource, be it data or application functionality.

Gardner: So SOA is best-of-breed -- and it’s integrated. And you can pick and choose how to proceed, based perhaps on your legacy and your skill sets.

Macehiter: We just have to be clear to distinguish between the assets or resources that you’re virtualizing through SOA, which is typically going to be functional assets versus whether you need to virtualize the infrastructure and apply SOA to the underlying infrastructure. That’s the key distinguishing point. And that gets the point that was being raised earlier about virtualized access to information.

The infrastructure could be common, but the information assets that you’re accessing will be in heterogeneous repositories accessed in a number of different ways. This is exactly what IBM is doing with its offerings around information-as-a-service, and BEA as well. It's having the equivalent of application adapters by applying them to information assets and then exposing those through a service interface, so it’s virtualized and transparent: where the information is, how it’s stored and what format it’s in.

Kobielus: You mentioned Oracle’s acquisition of Sunopsis, which is interesting, because Sunopsis is an ETL vendor and the transform side of it is critically important. When you are extracting data from source repositories, you’re transforming it in various ways. Traditionally, Sunopsis’s tools have been used primarily to support transformation of data, which will then be loaded into centralized data warehouses.

But transformation functionality is important, whether you’re doing it in an ETL data warehousing environment -- in other words, the traditional bus for MDM -- or whether you’re doing the transformation in an EII environment. There, in fact, you are not ultimately loading the transform data into a central store, but rather simply transforming the data, keeping it in it’s original schema, but transforming it so it can be rationalized, harmonized, or aligned with a virtualized data access model provided by that EII environment.

Macehiter: Exactly. The transformation should occur behind the service interface, and this is why you need the idea of common information models and common schema models.

Gardner: Before we get down too much in the weeds on EII -- we can address that perhaps in a whole show in the future with a guest who is very much involved with that industry. Let’s move on to our second topic today, given the amount of time we have.

There are a burgeoning number of critical skill sets that need to be applied to SOA. We’ve talked about data, whether it’s cleansing, transforming, virtualizing and approaching some sort of a MDM capability. We have talked about development and process, BPEL. We talked about infrastructure. There is the management, the architectural overview, and what’s our philosophy.

It seems like we’re going to need a lot of very skilled people who are both generalists, as well as highly specific and technical. Because for SOA to work, a bunch of people who are highly specific -- but don’t share the same vision or have a general sense of the strategy -- probably won’t fare too well. This issue comes to us from Joe McKendrick. Joe, give us a little setup and overview of where you think things are headed in terms of the necessary skill sets companies are going to need in order to accomplish the promise of SOA.

McKendrick: Thanks, Dana. It’s interesting. Actually, the impetus for my thinking on this came from a report Ron Schmelzer posted and I reported on my blog this week.

Gardner: Ron being with ZapThink.

McKendrick: That’s correct. He is sounding the alarm bells that the folks that we need to drive SOA forward in the enterprise is this class of enterprise architects and enlightened architects, if you will. There are a lot of SOA projects everybody is interested in. Everybody’s kind of ginned up about SOA now, and we’ve been hearing about it. Enterprises really want to begin to either pilot or move SOA past the pilot stage, and 2007 should be a big year.

Ron Schmelzer feels there may not be enough architects who can take this high-level view and drive this process forward. Now, it’s interesting, but when I posted this on my blog, I got lot of feedback that perhaps architects are not the only ones who can really lead this effort. There are plenty of developers out there, high-level developers, who can also contribute to the process and interact with the business. The key behind this argument is that you need folks who know what’s going on technically, but can interact with the business. It can be a rare skill to have both.

Gardner: Yeah, this is going to be demanding. You can get Oracle-certified, you can get Microsoft-certified, IBM-certified. Where do you go to become SOA architect-certified?

McKendrick: Where do you go in terms of higher education institutes to get trained on architectural planning and network design? I’ve talked to lots of people who say, “Yeah, we look at the computer science graduates coming up, but how many of these people really, fully have had any training or courses whatsoever on broad architectural subjects like SOA?" Very few.

Kobielus: That’s true. Not to get reminiscent or anything, but 10 years ago, when we started seeing Java ramp up, we saw a lag there as well. A lot of organizations were really hungry for Java developers, and the universities came through with more focus on it, but later than probably most organizations wanted. What will happen here is that while this ramp-up goes on, we might see a lot of new business and new interest in service organizations that can provide the professional services required to get people through it.

Macehiter: Yeah, that’s true. That’s going to be an important -- absolutely an important source. Also, there’s some work under way. I don’t know whether any of you are familiar with the the International Association of Software Architects (IASA), which is really trying to foster a community that does try and share best practice around software architecture, including SOA.

You hit the nail on the head in terms of the key skills that are required around being able to interface with the business. One of the skills and attributes that you also need as a SOA architect is really this ability to balance supporting short-term business outcomes but keeping an eye on the longer-term objectives in terms of gaining high quality and maximizing IT value. That’s an equally difficult skill because too often architecture historically has been focused on quite discrete initiatives or infrastructure. I’m thinking about server architecture or network architecture rather than this broader perspective. There are skills occurring from such things as Oasis and what they are trying to do around things like SOA blueprints. It will be useful to get someone from Oasis in a future podcast to discuss this, because this is where the education is coming from.

Gardner: I think that if everyone goes about SOA methodically on his or her own track, and based on their own experience, and we are going to come up with a real mish-mash, then it’s going to be a problem. There needs to be some standardization around methodology.

Coincidentally, in April we’re expecting to see version 3 of the Information Technology Infrastructure Library (ITIL). This is focused on the lifecycle of services. It’s really more at the IT service-management level than pure technology, but it does offer blueprints and books and standardized approaches on how to setup an IT department and manage some of these organizational things. It strikes me that that might be another influence on bringing some kind of a cohesive approach to SOA, rather than be totally scatter-shot.

Macehiter: ITIL came out of the U.K. government. What was interesting about it is that it was driven very much from the experience of people who were grappling with these very challenges. That’s where it’s going to come from in SOA. It’s going to come from things like the IASA and others practitioners defining the best practice, rather than a more theoretical, academic approach to defining the ideal methodology.

Gardner: It's my understanding that the global systems integrators are very interested in this coming version of ITIL, and some of these other standardization-for-methodological-benefit approaches. As I’ve said before, SOA is the gift that keeps giving, if you’re a systems integrator in a professional services organization. It will be really interesting to see how successful they are at bringing a standardized set of approaches to the SOA architect role and whether that’s actually in their best interests over time.

McKendrick: And when it washes up on these shores, we’ll call it American ITIL.

Gardner: Actually the number of ITIL users is highest in the private sector and in North America, as I understand it, although it’s hard to see to what degree people actually use it. I think people use it in dribs and drabs and not in entirety.

McKendrick: It’s going to be interesting. There’s a lot of emphasis on compliance now, and data management is a big part of it as well. ITIL is really going to come into play, and should be coming into play, because processes are outsourced. Because processes are being managed by third-party firms, you need to have across-the-board standards to ensure that the data is being managed properly and in accordance with some type of universal standard. And, the regulators are going to want to see that as well.

Gardner: Well, I think we’ve come up with two separate shows we'll need to do -- one on enterprise information integration (EII) and dig in to that topic specifically; and then, perhaps, we should do an ITIL show, get someone who is familiar with some of the authoring there, and dig into its implications for SOA.

Well I think that wraps it up for today. We’ve covered quite a bit of ground in a short amount of time. I want to thank all of our guests. We’ve had Steve Garone, Joe McKendrick, Neil Macehiter, Tony Baer and Jim Kobielus. This is Dana Gardner, your host and moderator for this week’s BriefingsDirect SOA Insights Edition. Please come back and join us next week. Thank you.

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 me, Dana Gardner at 603-528-2435.

Listen to the podcast here.

Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 10. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.