Some introductory remarks
One of the challenges that all Enterprise Architecture programs face is getting and keeping the support of the business. This is so much a part of Enterprise Architecture that the TOGAF specification devotes an entire chapter to it.
When we think of stakeholders and stakeholder management, it's natural to focus on the executives in IT and in the wider organization. After all, IT leadership are the people whose budgets are being reduced, and whose staff will be asked to support an Enterprise Architecture initiative through provision of information and compliance to review mechanisms. Meanwhile, the executives in the wider business will be the ones who will (hopefully) benefit from the outputs of the EA effort.
However, this can sometimes be short-sighted, as certain organizations can have groups that wield power that is out of all proportion to their size (or even position in the hierarchy). This fact makes such organizations potential stakeholders, in that their support can make a surprising difference to how willing other groups are willing to then lend their support.
Over the next few posts, and the remainder of this one, I'm going to point to five examples of when this might be true.
Allying with the Risk Management Unit
Every large organization looks to manage risk to some extent, but for financial institutions it is a regulatory requirement. Regulations such as Basel 2 and Solvency 2, Sarbanes-Oxley and Dodd-Frank, all impose a requirement to manage risk and so the Risk Management Unit is a commonly occurring function in financial institutions.
One aspect of their responsibilities is to manage and monitor operational risk. Operational risk is defined by Basel as “The risk of loss resulting from inadequate or failed internal processes, people and systems or from external events.” Basel actually goes further than this and defines 7 categories of operation risk to monitor, one of which is 'Business Disruption and Systems Failures'.
What this all comes to mean is, that a bank needs a way to manage the risk to its business operations from failures that occur in its IT systems. In other words, it’s a question of understanding the dependencies – does this sound familiar?
So, we need to accomplish a mapping between the business activities of the bank and the applications that support them – a classic Enterprise Architecture activity of mapping from the business to the IT. The difference being that performing this mapping is now a way to meet a significant regulatory requirement.
Now, this seems like it’s too good to be true and the obvious question that most people will be asking is, “what’s the catch?” The catch that I’ve experienced is that you can’t simply email a bunch of business units in the bank and say “please list the business services you provide and the applications that support them”.
The first problem with doing so is, what is an application? And what is a business service? Without a decent definition, the level of granularity that you might get, and the type of operation that gets identified, will be all over the map. You need to engage with each group to define concepts, so that you ensure some level of consistency.
The last challenge is the old bugbear of naming conventions. It’s entirely possible that the consumer banking and the high net worth banking group both have a service called credit checking, but they might do them in different ways using different applications – making them different services. So a standard way of naming items, to keep such cases separate, will be useful.
The same problem exists with applications. Ask 5 different groups what they call a given bit of software and you are guaranteed to get more than one name for it. So it’s worth establishing a canonical catalog of applications, with official names but also with official aliases if at all possible.
So in summary, the risk management group of a financial institution can be an invaluable ally in that modeling the dependencies between business services and applications meets a specific regulatory requirement. However, the main challenge in aligning them with an EA effort is to establish clear understanding of modeling concepts; to establish naming conventions; and to establish a business glossary of the applications that exist within the organization.