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.