In the last four blog posts I've described how an architecture initiative can find unexpected allies by looking outside their usual areas of working and identifying groups that have a shared interest in understanding the dependencies within the organization. But so far, all the groups I've considered have been outside the IT department, which remains the usual location of an Enterprise Architecture group. For this last post in the series, I'm going to return to the IT department and look at how Enterprise Architecture can help with capacity management.
At a first glance, the two disciplines might seem independent. Enterprise Architecture deals with the dependencies and relations between items, while capacity managers are concerned with usage levels of a couple of the entities (infrastructure components and application components) that Enterprise Architecture deals with. And in terms of simply tracking usage levels and capability for expansion on a given platform, that is completely true, EA has nothing to add.
However, it's in the mapping of dependencies that it turns out that the Enterprise Architecture model has something to add.
First, it's common within a large organization to rate their applications for criticality, based on the criticality of the business processes that they support. Such information is often not tracked within capacity management systems, so this information can often be hidden from the capacity management team, leaving them to learn such information over time. The EA model can shine light on this information.
Using this information, Capacity Management can work to avoid clumping critical systems together by chance – as well as concentrating them on the most resilient configurations should that be their strategy. The important point is that formal access to this information enables them to take such decisions.
The second area where an EA model could offer value is in mapping specific groups of business actors to the applications that they use. This becomes useful when said groups have differing usage patterns, either as a result of differing activities or their location in differing timezones. Awareness of the usage patterns of the different groups that need to use IT resources provides another tool to help the capacity management function allocate resources efficiently.
As I've observed in the other posts in this series, “there ain't no such thing as a free lunch” – this synergy between the two teams has a couple of points to be aware of. The key issue to be aware of is that, based on the IT organizational structures that I've always seen, Enterprise Architecture and Capacity Management are disciplines that will fall under different reporting lines. This implies two things:
First, it's going to be important to set up clear lines of demarcation as to who owns what data. The EA model can add value to the capacity management discipline, but it needs to remain under the aegis of the architecture department. Second, even when the two teams have no agenda, they should be cognizant of any political issues that might exist before formally engaging.
Despite these two considerations, it becomes clear that a partnership between capacity management and enterprise architecture has the potential to offer clear benefits.