Different stakeholders in an enterprise architecture effort will naturally have different concerns, as outlined in good old IEEE 1471 (now ISO 42010), and referenced in plenty of other places, e.g. in the TOGAF specification. So far, we’ve considered three of the most common groups of stakeholders – the executive suite, governance and review, and service management – and what their concerns can mean for the information and functionality offered when you share your repository with these stakeholders.
In this last post in the series, we’re going to talk about a group that might be less obvious - regulatory compliance. Now, obviously, this is really a function, but it’s an inescapable fact that most, if not all organizations assign responsibility for regulatory compliance to specific members of their staff - and in many cases, the regulations themselves require that specific, identified personnel are charged with responsibility for ensuring compliance with those regulations. So we can refer to the function as a shorthand for the staff members responsible for ensuring its execution.
All well and good, but why would this group care about the enterprise architecture effort? There are four reasons. First of all, some industries specifically require the establishment of an enterprise architecture and so the regulatory compliance staff will want to see evidence that this has taken place. Second, mapping regulations to processes, data and applications makes it easier to assess compliance. Third, if the mapping just described takes place this can be shown to auditors as a means to demonstrate efforts to ensure compliance. Last of all, depending on the industry there may be generalized principles that are required to apply to IT systems and these become natural candidates for inclusion into the catalog of architecture principles. All these factors taken together mean that regulatory compliance personnel are going to be stakeholders for the enterprise architecture initiative.
With our group of stakeholders established, what are their concerns going to be and what does this imply for their access to the enterprise architecture repository?
As mentioned, the first concern is going to be simply to show that an enterprise architecture exists. However, this separates out into two requirements – the ability to check the enterprise architecture online, and the ability to provide materials showing its existence to outside auditors. I’ve encountered cases where auditors have wanted hard copies of materials, and so online access needs to be supplemented with the ability to print comprehensible hard copies.
The next concern is going to be the ability to check that regulations are being applied accurately. This implies online access to both the architecture principles and to where requirements arising from regulations map to processes, applications and data. However, in both cases, regulatory compliance personnel will need to know which regulation to check against. This in turn means that if a principle derives from regulation, or if a requirement derived from regulations is mapped to an architecture entity, then that principle or requirement needs to be tagged with the precise regulation that has given rise to it – and tagged in such a way that this information is available by whatever mechanism is used to share the enterprise architecture repository with the regulatory compliance staff.
Sometimes the variety of stakeholders involved in our enterprise architecture can seem overwhelming, and it's never an easy task to please everyone. But as long as you take time to really consider what each group looking for, you can work to showcase your repository in the best light. Still want a bit more guidance? Why not download our handy poster below and learn how to transform your stakeholder needs into actions!