No Small Software Purchases, Revisited

Here is a post out of the usual Wednesday cycle. I am posting out of cycle because this post is a follow-up to a previous post. That previous post can be found here.

An experienced executive working in a large American corporation had this reaction to that previous post:

Say your point is true: local solutions give corporate IT heartburn. What are they worried about?

1. Data security/access control/access auditability - ad hoc solutions can be given high levels of data access, but the user level access controls within the solution are maybe not so robust.
2. Business continuity planning (disaster recovery) - making sure that the local solutions are covered by the disaster recovery plan. (data and software backup)
3. Training (ISO 9001 audits of training, etc.) - making sure that the local entities have included their customizations in their training efforts in an auditable fashion, and that the global quality documents are written in a way that allows for local solutions (while being usefully specific about the global solution where no local solution exists)
4. Financial controls - making sure that, if there are financial transactions in the local solution, they have adequate controls.
5. Maintainabiity - does it break when you update your global software?
 

Accounting for all of these things ad hoc in a customized solution makes it expensive, unless the central software provides a framework for dealing with them all in a consistent manner.

These are all valid and interesting points. Here is how I answer them:

Data Security & Access Control
Security issues always come down to policy and enforcement, so I would phrase the question this way:

Can local solutions be trusted to implement global data security policy?

I claim that the answer is "yes." Implementing data security policies should be a dimension along which the local solution is designed, coded and tested.

In practice, I find that a local solution is not likely be better than the prevailing adherence to data security policy and, admittedly, is often worse. For example, we recently installed a suite of apps for a client for which we provided support to use their global Active Directory (AD) as the source of credentials and the source of permissions associated with those credentials. But it was an uphill battle to get the local users to communicate with the global AD keepers about whose account was allowed to do what. It was not easy to merely establish what existing permissions the app's functions should map to.

Given how security policy implementation in large organizations usually plays out, I can sympathize with this concern: is this new way to access data consistent with our policies? But there is no reason that the answer shouldn't be "yes" unless your policies are poorly understood or your infrastructure is closed or poorly configured.

Disaster Recovery
DR is activity which, like prayer or the tennis lob, is rarely rehearsed and usually called upon only in times of great distress. Can a local solution be fit into the DR plan? Almost always. Is this a question that is usually asked? No, it is not. The good news is that more and more DR is more-or-less automatic: SANs and clusters and remote data centers have relieved many local entities of this responsibility.

To be clear, I understand DR to protect against three specific kinds of data or service loss:

1. Human error: someone pushed the button and wiped out lots of data.
2. Hardware failure: a key component, such as a disk drive, has failed.
3. Disaster: the building/city/state is flooded/burning/radioactive.

There are good solutions for each of these issues and local IT solutions should be capable of adapting to nearly any such solution.

Training
We have often found that getting onto the training docket is not easy, but we have never had a problem fitting into any existing training and documentation regimen. However, there are many issues:

• Politically, is it safe to expose the local solution to review?
• Practically, can one providing training materials which do not rely on local experience?
• Who will keep the training materials up-to-date?

Again, I see no reason that a local solution, per se, could not comply, but I often see local solutions which did not. Often the reason is simply that the hoops are large and while an expensive, global solution can afford a real budget for the documentation of training, local solutions feel that they cannot.

Financial Controls
In theory, financial transactions are covered by whatever data security policies are in place. In practice, this is often not the case.

Finance is a tricky area: giving local consultants information about how financial transactions are constructed, verified and secured really goes against the financial grain. It is an issue for which we have no good solution because we cannot figure out a way out of the following conundrum: the financial controls are so tight that we cannot see what we are doing, so we are forced to have a backdoor into the data stream, which of course is only present in the development environment.

Maintainability
"Does it break when you update your global software?" All too often, the answer is "yes" because your global staff does not know or does not care about local dependencies. But in my experience, the full answer is "yes, probably, but with decent communication your service outages should be infrequent and brief." I say infrequent, because there is enormous pressure on global infrastructure to remain constant. I say brief because your local solution should be aware of its dependencies and adapting to changing infrastructure should have been built in.

In our experience, the ramifications of global change are so great that we suffer from the inverse: we are constantly informed of far-off global changes which do not affect us at all. But better that that the alternative.