This would be in our COA collaboration center, but I’m still not satisfied with the options available software-wise – they’re either too heavyweight or too confusing for non-technical users. I wanted to address these comments, however, so I’ll use this space for now. Here are two other takes on our Compliance Oriented Architecture concept – we have quite a bit more to share shortly.
From Jonathan Schwartz of Sun’s blog:
And speaking of Reg FD, RedMonk has written an interesting piece about the evolution of what they’re calling “compliance oriented architectures.” A concept to which I totally subscribe – as legislative priorities continue to emerge around privacy, disclosure, accountability and security (SarBox, RegFD, SEC 17a, HIPAA, etc.), the IT industry should rest comfortably knowing their role is secure in the world: going forward, legislative compliance will be impossible without IT. RedMonk focuses mostly on identity – but to me, it’s far, far broader. Someone should write a thank you note to Congress. Minimally, those of us in the storage business. And maybe even the blogosphere…
I’m actually – despite the wording above – in violent agreement with Jonathan here. I’d argue that COA as we’ve articulated it is far broader than identity (COA services we identify in the piece include analytics, archive/backup, auditing, collaboration, conflict resolution, information integration, monitoring, notarization, retention, workflow and more), but in any event we wholeheartedly second the notion that the issue of compliance is very broad, and a true enterprise-wide need. That is in fact one of the primary drivers we see for COAs.
From Michael Curry of Ascential’s blog:
The approach is very interesting, and I agree that compliance is a great candidate for implementation in a SOA. While many business functions become naturally federated to the business function or unit to which they are important (see my earlier post on federation), compliance is something that really needs to be enforced centrally to be effective. This is one of the main points being made by Redmonk. Companies may start their compliance efforts on a unit by unit basis, particularly if they are trying to comply with aggressive regulatory deadlines, but they ultimately need to centralize the control of compliance governance (at least on a per regulation basis).
Michael gets it. I think it’s important to stress however that while a services-based architecture clearly benefits compliance personnel by calling for a streamlined and centralized approach to what is a distributed problem today, it can be just as much of a boon to IT staffs and developers. For them a COA offers less redundant development, simplified management, and application purchasing simplification. But as I mentioned yesterday, it’s important that each audience – business and technical – understands what’s in it for them.
From Michael Mimoso of SearchWebServices.com:
Peter Underwood, vice president of software development for Wall Street Access, a New York brokerage, said compliance can effectively be balanced with an existing service-oriented architecture.
“SOA massively simplifies compliance,” Underwood said. Wall Street Access has to comply with Securities and Exchange Commission regulations at nearly every level of its business. Audits are mandated at each of those levels, and particular services have to be architected with compliance in mind.
“Injecting compliance components into an SOA makes immense sense,” Underwood said. “It saves a tremendous amount of time and expense. You don’t, however, have an SOA of compliance services.”
RedMonk may be trying to signal a change in that thinking. IT shops too often address compliance projects in silos, which lead to redundancy and complexity, RedMonk said. The analysts advise IT shops to merge implementation teams working with the Health Insurance Portability and Accountability Act , the Sarbanes-Oxley Act, BASEL II projects and others and avoid giving in to individual regulatory demands when architecting services.
Seems to be a bit of confusion here. With COA we are recommending that enterprises and governmental institutions consider implementing – incrementally – a services-based architecture that is composed of compliance specific services. But let me be clear, however, in that we’re absolutely NOT advocating that enterprises beginning setting set up multiple SOAs for every horizontal business need they have. You’ll notice that COA omits some fundamental pieces for an SOA – runtime for one, base identity system for another. The reasoning for this is simple: we expect COAs to be one flavor of SOA implemented on a central SOA platform. That same platform may support a variety of other non-compliance specific services. If we were recommending the creation of a separate architecture for COA, we’d be reducing compliance overhead while increasing platform overhead – a net loss for an organization. COA is about leveraging the services and platform you have, not building a whole new infrastructure. KISS, as always.
