In the previous couple of posts, we’ve talked about how the Enterprise Architecture department can make themselves useful in assisting with regulatory compliance, and in so doing make allies of the risk management unit (when working in the finance industry) or, more generally, of the regulatory affairs unit (when working in some other, heavily regulated industry).
Both of those use cases center around complying with constraints that have been externally imposed by outside agencies; but now it’s time to start considering how Enterprise Architecture can assist with internally driven concerns. The first case of this type that I have seen is the alignment of interests that exists between Enterprise Architecture and Service Quality initiatives.
Numerous organizations establish initiatives around service quality with the goal of improving the value that the organization provides.
The first and most obvious touchpoint between the Enterprise Architecture group and a Service Quality group is, unsurprisingly, services. Improving service quality necessarily involves identifying the services being provided. So immediately, EA has an ally where both groups have an interest in establishing a formal catalog of business services.
There a couple of challenges around this, however. First of all, the question arises as to who is the formal owner of this catalog. Such a question does introduce a certain political aspect to the discussion, even when all parties mean well. In general, I’ve seen it work better where the service quality team has this responsibility, as they are more focused on that one specific aspect of the enterprise.
A second consideration is that service quality teams often come from the business side rather than the technical side. This is sensible, but it does mean that they have less experience in thinking in a structured, precise manner than a more technical person would have. Where this becomes a problem is that they can struggle with the notorious service/function/process division – what is a process versus what is a service. Since the Enterprise Architecture group will generally be more used to such questions, it means that there is an opportunity for them to provide valuable assistance to the service quality initiative.
A third area where the EA team can assist is the actual service quality initiative itself. Much of a service quality initiative focuses on improving the processes that deliver the service, but despite claims in some quarters, the vast majority of business services depend in some way on information technology. This in turn means that requirements around availability and resiliency for a given process can inform requirements for applications that support that process.
Where this provides an opportunity to Enterprise Architecture to support service quality, is in identifying the applications that support each service and from this providing a better understanding of how application performance inputs into service quality. But as with the previous two points, there is a nuance to be aware of. The specific nuance to be aware of there is the division between external service quality targets and internal service quality targets.
It can be tempting to assess the desired recovery times for the various services and use these to establish target recovery times for the supporting applications and infrastructure. However, it’s one thing to establish such targets, committing to them is another. EA will need to carefully manage expectations in deriving such information, so that it does appear to make Operational Level Agreement commitments to the service quality team. The figures they provide can act as input into Operational Level Agreements (OLA) that are agreed between the service quality team and IT, but they must not be taken to provide a commitment.