Capacity Planning is a foundation capability for all architects. Tied closely to the core pillar of Quality Attributes, the architect is responsible for ensuring that the capacity of any process, service or system meets the needs of all key system stakeholders e.g. investors, customers and consumers, not just on day 1 but throughout the full lifetime of the system.
The Wikipedia definition of Capacity Planning, taken from the Supply Chain Resource Co-Operative, while described in language more aligned to manufacturing, can also be applied to IT and IT systems/services. (As in many other areas, it is often good practice for IT architects to leverage approaches developed in other disciplines to advance the maturity of capacity planning and management in IT systems).
Capacity planning is the process of determining the production capacity needed by an organization to meet changing demands for its products. In the context of capacity planning, Design Capacity is the maximum amount of work that an organization is capable of completing in a given period. Effective Capacity is the maximum amount of work that an organization is capable of completing in a given period due to constraints such as quality problems, delays, material handling, etc. The phrase is also used in business computing as a synonym for capacity management.
A discrepancy between the capacity of an organization and the demands of its customers results in inefficiency, either in under-utilized resources or unfulfilled customers. The goal of capacity planning is to minimize this discrepancy. Demand for an organization’s capacity varies based on changes in production output, such as increasing or decreasing the production quantity of an existing product, or producing new products. Better utilization of existing capacity can be accomplished through improvements in overall equipment effectiveness (OEE). Capacity can be increased through introducing new techniques, equipment and materials, increasing the number of workers or machines, increasing the number of shifts, or acquiring additional production facilities.
As already suggested, combining a service oriented framework, such as ITIL, with concepts from other disciplines such as manufacturing will allow architects to design, plan and manage capacity more effectively.
Capacity Planning Methods
A number of standard methods exist for capacity planning. The pros and cons or each are outlined in the following table:
||In trending, component behavior is modelled based on a simple linear model.
||Relatively simple approach to implement.
||May not reflect accurately real world non-linear impact on capacity.
||Simulation involves building a bespoke software based model that accurately mirrors the behavior of the real world system.
||Flexible and potentially very accurate
Allows for significant levels of what-if analysis
|The more complex the system the more expensive it will be to build an accurate model.
Requires specialist skills
||The testing method uses a real-world copy of the system to carry out load analysis.
||High levels of accuracy
Much less complex to build than simulation as should be replica of production environment
|Cost – accuracy based on degree to which test environment replicated production environment.
||Combines statistical analysis of real world data with a model that represents the complex interactions inherent in the system.
||Potentially very accurate and allows for relatively inexpensive what-if analysis.
Uses relatively easily gathered data from real world system and does not require expensive test environments.
3rd party tool support exists e.g. Teamquest, VMWare Capacity Planner etc.
|As with simulation, analytical modelling requires end to end understanding of system – business, application and technology.
Capacity Planning and Views & Viewpoints
While typically led by the infrastructure architect, all architects are responsible for carrying out Capacity Planning at their respective architectural layers e.g. enterprise, business, application, technology. In other words, capacity is an important Viewpoint that should be applied to all architectural Views.
View Specific Capacity Planning
While the definition of standard views may vary by organization, for the purpose of this guide we will use the TOGAF defined views – Business Architecture, Information Systems Architecture and Technology Architecture – as an example of how the Capacity Viewpoint can be applied to each.
||TOGAF 9.0 Definition
||Capacity Planning Viewpoint
||Business Architecture describes the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment. TOGAF 9.0
|While significant automation may exist within a modern business process it is the number and behavior of the humans in the process that ultimately defines the load on the system.
In a non-dynamically managed system, clearly defined business process workflows are a critical input into the capacity planning process. In organizations where business processes are explicitly defined e.g. by a business architect, the maximum and average capacity of the business process should be estimated by the business architect.
Where a service oriented approach is used the business architecture should also identify all service components that play a part in the capacity of a system over an extended period. This viewpoint ensures that the capacity of supporting processes such as business management, monitoring, support and operations are also estimated.
|The business architect of a Sales Order Taking process should provide both estimated maximum and average orders per hour and any longer term load trend factors such as market growth or seasonable fluctuations (based on customer demand estimates and number of resources allocated to process).
This capacity target can then be passed as a requirement to all impacted services/processes.
|Information Systems Architecture
||The Target Information Systems (Data and Application) Architecture, describes how the enterprise’s Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns. TOGAF 9.0.
||Typically the responsibility of the solution, data and/or application architect, business/service capacity requirements must be gathered and translated into specific requirements for logical data and logical application architectures.
The application architect should ensure that the logical application technology architecture can meet these requirements either directly via dedicated application components configured with the required capacity or indirectly via shared infrastructure components – typically agreed with the infrastructure architect/infrastructure solution architects.
|In applications requiring highly scalable capacity logical application design patterns that are based on stateless, message based application servers connecting to a distributed, in-memory database may be appropriate, as this will allow the most flexibility in terms of meeting dynamic capacity requirements.
Systems that have a more fixed capacity requirements may be better served by a simpler application architecture that does not require complex or specialized supporting components.
||The Technology Architecture enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns. TOGAF 9.0
||Solution or infrastructure architects must gather requirements from application/data architects and translate them into the required technology architecture.
Depending on the size, scale and complexity of the system, infrastructure components can be relatively simple e.g. local server CPUs/disks/memory/network links or relatively complex e.g. shared infrastructure services such virtual server farms, storage area networks, load balanced geo-stretched VLANs.
In the lowest architectural layer, physical environment, infrastructure architects must also ensure that adequate aggregate capacity is in place in terms of data center floor space, racking, power, air conditioning and cabling.
Infrastructure architects responsible for cloud type systems must also be able to put in place tools and processes to allow for dynamic capacity management. E.g. Amazon AWS and Microsoft Azure IAAS and PAAS services use service wrappers and automated service provisioning and management tools.
|At this level architects can choose between a range of infrastructure design patterns that can provide different capacity options at different price and performance points including:
- proprietary (Windows, UNIX, VMWare) or open source (LINUX, OpenStack) platforms
- on-premise or cloud based solutions
- fixed or dynamic capacity management tools
Capacity Planning and Managing architectural accountability
Closely related to View and Viewpoints, it is critical that the infrastructure architect manages relationships with all dependent layers, either directly or indirectly, through some form of formally managed agreements. In practice, accountability for Capacity Planning is often split between a number of different but highly interdependent architecture roles e.g. enterprise, business, application, data, solution, service and infrastructure. Ensuring accountability is clearly defined at each level is critical to ensure that long term, end to end system capacity meets business requirements. In practice this can be difficult to achieve for a number of reasons:
- Traditionally architects have not been involved in the day to day running of a system and therefore changes that are a result of increased load are not always tracked against the original capacity design leading to capacity related issues that are perceived as an IT service delivery issue rather than a known capacity constraint that is linked to the original design and associated capital investment.
- In large enterprise systems, tracking change through the different architectural layers is complex and difficult to achieve. Changes at one level may be difficult to communicate clearly at all architectural levels. This can make root cause analysis complex and as a result capacity related issues are not always identified correctly as such.
One approach to tackling this challenge is to ensure that where architectural accountability switches from one architect to another, a formal agreement of some sort is put in place that captures clear capacity related terms and conditions. Examples of such formal operating agreements are Service and Operating Level Agreements as defined in ITIL or standardized service contracts as defined in SOA. The architect’s role is typically to create these contracts and hand over to the service management team to monitor and manage. Architectural involvement is also recommended when and where these contracts need to be renegotiated.
Capacity Planning, Platforms and SDLC Approaches
The nature of the target infrastructure platform is a critical factor when designing the optimum approach to Capacity Planning. In environments with more traditional models of on-premise infrastructure, a waterfall based approach may be most appropriate. In this approach a detailed theoretical design is completed based on a detailed assessment of demand (short, medium and long term) against availability risks i.e. risk that capacity may unpredictably spike beyond available levels, lead time of provisioning additional capacity and analysis of costs associated with provisioning capacity at different times in the lifecycle of the service. This design is then tested using simulated load, where an appropriate test environment is available. While a valid approach the resulting system’s capacity is largely fixed with major capital investment required up front and can only be increased (or decreased) as part of a major and often expensive change project.
Where more agile approaches are adopted, more dynamic approaches to capacity planning and design are required. This puts a much greater emphasis on a system design that supports dynamic capacity management as a key system attribute.
Well-designed cloud systems – public or private – should always support this approach. In these systems the focus of capacity planning moves from design and testing using simulated load to gathering real time data on the performance of the system at different levels of actual load and using this data to:
- Automatically provision additional shared capacity and
Carry out some form of analytical modelling to identify capacity related trends and allow for timely capital investments to add additional capacity.
 Iasa ITABOK: A viewpoint defines the perspective from which a view is taken. More specifically, a viewpoint defines: how to construct and use a view (by means of an appropriate schema or template); the information that should appear in the view; the modeling techniques for expressing and analyzing the information; and a rationale for these choices (e.g., by describing the purpose and intended audience of the view).
 Iasa ITABOK: A view is a representation of one or more structural aspects of an architecture that illustrates how the architecture addresses one or more concerns held by one or more of its stakeholders.