Then:
http://briefingsdirect.blogspot.com/2007/04/briefingsdirect-soa-insights-analysts.html
Again:
Kobielus [again, now, Aug. 20 2007, for the umpteenth]: “Federation is a governance structure under which autonomous domains agree to honor each other’s decisions and accept each other’s assertions in some sphere of human endeavor, subject to business contracts, trust relationships, interoperability agreements, and local policies.”
With that as context, here’s how, on
“Kobielus: An SOA initiative is a success if it gives you the ability to adapt the SOA governance structure to your actual business governance structure. As you’re saying, your business governance structure will evolve over time. All business models change. So the extent to which your SOA initiative and your SOA governance are totally centralized and totally rigid -- but your business environment and the challenges and threats and so forth are constantly changing -- then your SOA failure will ultimately become a business failure, a failure to adapt….”
”Kobielus: We talk about political governance in terms of the world community. There is no one right governance model within a state or among the various states of the world. But clearly, history has been marked by individual states or groups of states playing and towing with, if you can use the word, various governance models ranging from absolute dictatorships and empires down to sort of laissez-faire, no centralized government.
But governance is an abstract concept, and you don’t necessarily want to dictate one governance model that’s applicable or should be applicable to all organizations and industries. Everybody has their own pressures, market pressures and so forth. In terms of SOA governance, there are radically centralized models in a given organization. It could be a radically centralized governance model within a given industry sector in the sense that basically one monopoly company controls an entire sector of the economy and they then dictate all the SOA policies and practices for all of their tributaries, as it were.
In the world, you have 230-something countries that are sovereign states ostensibly, and they establish various bilateral treaty relationships and also participate in various multi-lateral treaty organizations like the United Nations and NATO and so forth. Any given country is probably, involved in various international governance schemes as it were -- but also internally, from generation to generation, from revolution to revolution it’s going from centralized to decentralized. One size doesn’t fit all generations of governance….”
”Kobielus: Think of this notion of where companies in the most post-modern age are going to get their governance structures from. I think a lot of the governance risk and compliance (GRC) management vendors -- it’s a new market space; companies like SAP and OpenPages and MEGA International and BWise, and others, are building up platforms that have both verticalized and horizontalized governance templates, rules and workflows, and so forth. Increasingly companies or enterprises will standardize on a dominant GRC management vendor for their organizations, and then use whatever templates they choose. And their SIs will modify them to suit their own needs going forward.
Bringing this back to the whole notion of where nations get their governance charters. I just read a book, a really good one, called "Declarations of Independence," and it shows that the first actual declaration of independence ever created to found a nation was our Declaration of Independence in 1776. You wouldn’t believe how many other countries have actually plagiarized or borrowed language and whole concepts from it, including
Notice how, on Feb. 2, I shifted the topic of SOA governance away from its typical focus on best practices, registries, and so forth, toward a discussion of a new SOA product niche: GRC. In my work at Current Analysis, I’ve been speaking with many GRC vendors, have written a fair number of reports on this market, and am developing a GRC reference framework and maturity model. So, having run the GRC topic up this preliminary flagpole, I proposed it outright for the Feb. 16 podcast. Dana and the crew accepted it, and we had a great discussion developing it further on that latter date. Essentially, GRC tools are IT/SOA means for putting “teeth” in business governance policies, practices, mandates, etc.
Here’s how Dana framed that Feb. 16 GRC discussion upfront:
“
“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 Virsa Systems, which made tools for continuous controls monitoring. Around the Virsa 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?”
“Macehiter: ….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…..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. …. 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.”
“Garone: ….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 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.”
Dana (making an observation that goes to the heart of the GRC reference framework—more from me on this at the end of this post):
“
“McKendrick: …. 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.”
Me again (tying GRC back to the notion of needing to be included/integrated in SOA suites):
“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.”
Neil again (offering a comment so perfectly tuned to my argument that I’m wondering if I should him for his services on that occasion):
“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.”
Then Joe again, explaining why it’s likely that the GRC and SOA/IT governance markets will remain on slightly different wavelengths, due to different business drivers, advocates, stakeholders, users:
“McKendrick: …. 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."
Now, me again, jumping to another date (Mar 22, 2007—the following month) and another context (an Advisory Report for Current Analysis, in which I presented the outlines of my GRC reference framework)…that Feb. 16 podcast was the final-validation point in my development of these ideas, which had been germinating in my mind since the previous May:
“Governance, risk, and compliance (GRC) is a catch-all market segment into which a growing range of vendors are positioning solutions. Recent GRC-related product announcements from Oracle, CA, SAP, and other vendors have to some degree validated that this is in fact an important niche. However, much popular confusion reigns regarding the functional scope of GRC suites, their support (or lack thereof) for related concepts such as IT governance and SOA governance, and the value added (if any) for enterprises that invest in GRC-enabling product suites rather than diverse point solutions. Nevertheless, GRC suites are emerging and maturing, and commercial solutions are converging on a common functional architecture that blends elements of business intelligence (BI), corporate performance management (CPM), business process management (BPM), data warehousing (DW), master data management (MDM), identity and access management (I&AM), and collaboration….
For starters, GRC suites revolve around a core feature set: the ability to monitor, verify, and optimize business controls that have been expressed as structured workflows. All GRC suites support automatic aggregation of enterprise business-process risks, provide supporting evidence of compliance, pinpoint control violations, and enable escalation and prioritization of corrective actions. They do so through the following functional components:
• GRC repositories: These repositories support centralized storage, administration, auditing, and control of GRC-relevant entities, including frameworks, mandates, policies, rules, roles, metrics, and workflows. Often, the repositories include libraries of segregation-of-duties (SoD) controls in support of automated detection and prevention of access control violations.
• GRC BPM tools: These tools support modeling, simulation, and development of enterprise controls; execution and enforcement of the associated workflows; monitoring, auditing, and tracking of compliance; and initiation of alerts and corrective actions. Often, such tools support continuous monitoring for changes in SoD and application-configuration controls, including the ability to set up auditing parameters to enforce organizational tolerances across multiple process instances.
• GRC CPM dashboards: These visual dashboards, scorecards, analytics, and reports provide high-level visibility and detailed drilldowns into GRC metrics across one or more mandates, enterprise levels, organizational entities, business processes, and IT infrastructures. They often support real-time continuous updates to displays of key metrics, and also provide visibility into historical trends into ongoing compliance.
• GRC stakeholder interaction services: These services support collaboration, human workflows, role-based personalized views, survey feedback links, action plan management tools, and configurable alerts to support operational enterprise risk management among business process analysts, process participants, and other GRC stakeholders.
• GRC resource connectors: These connectors provide integration to the diverse applications, databases, middleware environments, and other infrastructures across which GRC controls are being monitored, enforced, and audited. Relying both on loosely-coupled service-oriented architecture (SOA) approaches and/or embedded agent technologies, connectors also provide integration with the diverse portal, BI, CPM, BPM, DW, I&AM, and other point solution elements of a heterogeneous, multivendor GRC infrastructure.
One key area of differentiation among GRC vendors is in their ability to facilitate their customers’ GRC projects through prepackaged “project accelerators.” These accelerators consist of bundled regulatory framework libraries, implementation templates, workflows, and other metadata—as well as professional services--to support diverse GRC mandates and best practices, including SOX, HIPAA, Basel II, COSO, COBIT, and ITIL. The best-of-breed GRC platforms will be those that support ongoing compliance with many overlapping mandates.”
Tough balance to maintain. Pulled every which way. Comply continually with contradictory mandates? Is that even possible?
Then again, that’s why “risk” is the fulcrum word in “GRC.”
