Got some more feedback last week on COA, our Creative Commons licensed publication that describes our vision of the application of a services oriented architecture (SOA) to the specific and horizontal compliance challenge. From Christopher Byrne of the The Business Controls Caddy, the feedback is intriguing in that it argues not that we’ve gone too far, but rather not far enough. That’s one I haven’t heard yet.
You can read the original post here, but here’s the crux of the disconnect:
I am not going off the deep end here, but am looking at it terms of what any architecture should do: ensure that any information systems projects
* satisfy a clear business objective
* gain necessary approvals before beginning
* are designed to ensure reuse of common assets are reused
* ensure that effective controls are built into the systems.This is often easier said than done and Stephen clearly articulates this in the RedMonk study. But if systems were consistently built with the considerations I state above, there would not be a need to push for a COA. I have seen too many organizations have a knee-jerk reaction and run around like chickens with their heads cut off to respond to the latest fire drill or regulatory requirement. This is often what leads to redundant data stores and the acquisition/implementation/deployment of unnecessary resources, as Stephen points out.
Actually, I don’t think we’re too far apart on this. In fact, I’d agree that if systems were constructed according to those parameters, there’d be a decreased need for COAs – I wouldn’t say none, simply b/c COA is about more than controls. But it’s simply been my experience that very few systems, let alone architectures, are built in such a fashion.
For all the current talk of ‘strategic applications’ and ‘next generation architectures’ one hears from CIOs on a regular basis, the fact is that most systems I’ve worked with, on, or around have been light years away from such gleaming, clean room implementations (what’s that say about my experience, I wonder?). In a perfect world, applications are built modularly and with controls and security built in from day one; that’s why so many of today’s applications are hastily thrown together PHP code. And that’s not even getting into most of the heterogeneous architectures that enterprises are faced with today, which have one foot in the past and one struggling into the present.
If my experience has taught me anything (and there are those who’d contend that it hasn’t ;), it’s that philosophical goals such as the ones mentioned here are difficult to maintain in tight, timeline driven production environments. I love them as design goals, I just have trouble seeing them as the current reality of implementations.
We’ve offered up COA as a means of incrementally advancing towards a compliance services architecture, but maybe Christopher is right, and we’re not being aggressive enough in our expectations.
