Part 2 - Components of the Benefit Categories
In my previous post on a possible business case for an architecture model, I outlined 5 top-level benefit areas, 5 top-level cost areas, and talked briefly about a general approach used to estimate each of them. The next step will be to break each of the benefit and cost areas into components, and consider how we could estimate each of them. In this post, I’ll be breaking the benefit areas into components. There are many resources out there that we can leverage to populate a structure, too many to list (just google “Enterprise Architecture Benefits”). I’ll point to the Enterprise Architecture Benefits Framework as one example in the area.
I identified 5 areas of benefits; let’s discuss some components of each one, and how Enterprise Architecture helps each one.
Risk Reduction
Regulatory Compliance. Most industries these days encounter some level of regulation. For some, it is often a key concern. But modeling an architecture enables greater compliance by mapping the regulations to the processes, applications and data that are affected by this regulation.
Security Architecture. Security of data is a critical concern these days; data breaches are headline news stories. At the time of writing, Google is being sued for $100 Million by various celebrities who had their personal photos stolen by hackers. Anything that can reduce the risk of such a breach is going to be beneficial.
Disaster Recovery. Disaster Recovery is a standard aspect of corporate governance. However, in a large organization, being able to design and maintain the disaster recovery plan requires an understanding of which business operations depend on which system. An architecture model supports this and can also identify mitigation efforts for various disaster scenarios.
Operating Cost Reduction
Application Consolidation. This is one of the most common activities for an architecture department at the moment. To state it expressly, this is the activity of assessing which applications can be retired (due to duplication or obsolescence) so as to eliminate the ongoing costs associated with using that application.
Reduced System Downtime. Things break. It’s their nature. However, maintaining a clear picture of how systems fit together and support the business both supports faster incident resolution, and enables problem analysis as defined by ITIL – finding patterns in incidents to remove the root causes of incidents.
Eliminating Inefficiencies. When a modeler working at one level has visibility of the environment at other levels, they can take such details into account. For example, an application architect working for a multinational could design the structure of a new rollout better with a full understanding of the global network architecture. Often, such considerations are taken into account already, but on an ad-hoc basis.
Faster Analysis and Design. A natural part of every implementation is performing analysis of what needs to change, possible touch points and so on. In the absence of an architecture model, this is done ad-hoc and manually. Maintaining an architecture model can speed up such analysis by enabling a level of automated analysis.
Revenue Increase
Reduced Time to Market. A common complaint from the business is that IT takes too long to implement changes. In practice, the primary reason behind this is a lack of communication between IT and the business. While IT departments have adopted various best practices to address this, such as demand managers, service managers and the like, possessing an architecture model makes the lives of the staff filling these positions much easier.
Improved Innovation. A second complaint is that IT comes up with a simple response that something can’t be done. In general, this is not the IT department being obstructive; it is merely that by the time concepts get to them the concept has been solidified into a form that is impracticable. Better communication avoids this. So the improved communication that an architecture model provides does not merely reduce time to market, it can enable new services that would not come about otherwise.
Improved Decision Making
Project Estimation. As described above, maintaining an architecture model is an aid in performing impact analysis, to estimate the effort involved in making changes to processes, applications and infrastructure. The more support there is for this, the more accurate the estimates of effort can be.
Reference Architectures. Having a standardized set of architecture patterns is a recognized best practice. It enables an architect to effectively ‘reuse’ certain standard design decisions and focus on those areas that are specific to that project. It also makes a given deployment more understandable to a new architect who has to change the deployment with no access to the original architect who created it.
Capability Planning. By engaging in a full capability map, IT becomes able to take the high-level strategic plan and better estimate the downstream effects that this will have on requirements for IT.
Cultural Changes
Enabling Transformation. Having a clear picture of the architecture of the organization greatly facilitates any kind of transformational exercise, whether the transformation is a wholesale move to cloud-based computing, or selling off an operating unit.
Culture of Co-operation. Enabling closer working relationships between different groups can have intangible benefits such as a higher level of employee satisfaction.
So at this point, we have examined various components that make up our five categories. Not every component will apply to every organization, and there may be other components that I’ve not considered. But this is a usable framework that we can apply for estimation purposes.
I’ll make one last observation before closing. It may be helpful to represent this breakdown graphically. Busy executives are often more receptive to something that provides a break from charts, tables and expositions. My personal choice for creating such a representation would be to create it as a motivation model. There are several potential frameworks out there; ArchiMate has the Motivation Extension, TOGAF has a motivation extension as well, and the OMG has their Business Motivation Model.
Now we have our components identified, the next step will be to use them to estimate values for these five categories.