We’ve already talked about how it is important to consider the specific concerns of different groups of stakeholders in how you share your enterprise architecture repository, so that they feel the contents of the repository are relevant to their responsibilities. So far we’ve considered the concerns of two of the key groups of stakeholders – executives, and those involved in the governance and review of proposed architectures – and what their concerns imply for how you share the contents of your repository with these groups.
The third group that we’re going to consider contains those stakeholders that are concerned with management of IT services. In practice, this group will generally involve two distinct subgroups –
1) Those IT employees who are concerned with liaising with the business at large for existing and new service initiatives. Often they have a title such as ‘business manager’ or ‘demand manager’ and work exclusively with a specific division. For example, a bank might have business managers for the consumer, business and treasury divisions
2) Those with an overall remit for service management – often with an ITIL background, and focused more on ensuring that the organization has the service level agreements (SLA) and operational level agreements (OLA) that are appropriate for its needs. For the purpose of this post, I’ll be referring to them as service managers
So what are the concerns of these two groups, and what do these concerns imply for sharing your enterprise architecture repository?
Now, business managers are generally concerned with the management of applications that support their specific area.
So this leads to the following specific questions: what are the applications that support each IT service, what are their portfolio ratings (i.e. business fit, application fit, risk, and criticality), what IT services do they support, what are their actual performance against business needs?
This leads to the following requirements for the access to the repository for IT business managers:
1) The ability to interrogate attributes
2) The ability to report and filter by attributes
3) The ability to trace from attributes to IT services
4) The ability to view or link to performance statistics
Service managers, in contrast, are more concerned with monitoring service level agreements and operational level agreements. This means that they will care about what SLAs and OLAs exist for IT services – and whether they are appropriate for the business services that they support.
This means that they are going to be most interested in the ability to trace between business services and IT services – and also to be able to quickly reference the actual SLAs and OLAs for those IT services. Now, it’s unlikely that the enterprise architecture repository is going to be the repository of record for the actual SLAs and OLAs themselves.
This leads to the following service manager’s wish list for their access to an architecture repository:
1) The ability to trace from business services to IT services and vice versa
2) The ability to trace from IT services to OLAs and SLAs. Now, given the point above, that the EA repository is unlikely to be the repository of record for such documents, an important functionality is going to be the ability to link to external sources of information.
As can be seen, while both groups need the ability to trace relations to IT services, their different concerns lead to substantially different ancillary requirements.