Why do we Care About System Architecture?
Having just spent an entire chapter discussing what system architecture is and how it affects the system, this may sound like a pretty stupid question. However, it is surprising (and worrying) just how many projects don't really care about system architecture. A number of projects we have seen have architecture documents (and architects) that seem to belong only in an ivory tower. This type of architecture is particularly concerned with being abstract (although they are more often vague – definitely not the same thing) and general. These architectures are produced in isolation and presented as a blueprint for development to the people who have to implement the system. Often these types of document rarely change as the system is developed, not because they are being closely adhered to but because they are so disconnected from what is actually going on as to not be affected.
In other projects, we have seen concerted efforts to define either the software or hardware architectures (or both) with little co-ordination or balance between the two. Whilst this is better than the ivory tower situation, it is still ignoring the overall system. And, let's face it, building a system rather than an application or some infrastructure is what we're interested in here.
We think there are two reasons why we really need to focus on system architecture. Firstly, the creation of an architecture for a large-scale system is not a trivial task – it is definitely a hard problem. Secondly, the system architect is concerned with the delivery of a ‘complete’ system, however far that may reach. This combination of difficulty and responsibility arises from the scale and scope of the systems we are creating.
As the size of the system increases, it becomes more difficult to create an architecture for it that balances all of the requirements placed on the system. The number of elements in the system increase and hence the number of possible interactions in the system increase, potentially in a exponential way. A large system can consist of hundreds of ‘moving parts’, each of which has its own configuration and comes from one of a variety of different vendors. It is easy for the system to become mired in complexity without an overall vision of (relative) simplicity and form. Additionally, as the system increases in size, so too do the size of the individual problems within the system. For example, the data flowing back and forth in a system that must support hundreds of thousands of users is like a primeval force compared to the smaller flows in a departmental system. Any system element not prepared for the scale of such flows will bend or break under the onslaught, which will inevitably lead to problems achieving the required non-functional characteristics. The system architect must predict such intense forces and put in place strategies to cope with them.
The level of difficulty for the system architect also increases as the scope of the system increases. A public Internet system, or a large-scale intranet system, will stretch out across the world, relying on intermediate network connections and browsers on client systems for its delivery. Whether inside or outside of an organization, these links and the client systems are largely outside the system architect's control. However, and this is the difficult part, the system architect must still worry about them. This additional responsibility comes as the scope of the system increases. The creators of individual software elements will be concerned that the elements perform to their specifications, but they bear little or no responsibility beyond that for the overall performance of the system in which they are used. Similarly, a team that writes a packaged product for installation on a PC specifies some basic hardware requirements on the side of the box and their duty is largely discharged. A project team that must develop a traditional client–server application with a thick client, for consumption within an organization, will be responsible for the end-to-end performance of the system but potentially nothing is outside of their control as they may be able to change client processing power, network bandwidth, client software and so on. Once you move into a large-scale system, the amount of control over anything outside of your immediate, server-focused data centre diminishes rapidly. Despite this lessening of control, the team building the system (and hence the system architect) still remains responsible for the overall performance of the system, regardless of who controls which parts. The system architect must identify bottlenecks, or limitations on performance, and issues with the delivery of functionality to potentially differing client platforms.
These concerns should come as no surprise as it is the size and scope of a system that generally governs its need for stringent non-functional requirements. As a system widens its reach, the functional model will probably stay pretty much the same. However, with reach comes concerns about privacy of data, responsiveness across a widely-distributed network and the number of customers who may come to use the system. Someone needs to be concerned that the system as a whole meets the non-functional requirements necessary for it to succeed. It is the job of the system architect to close the gap between characteristics and requirements. Ultimately, as system architect, you ‘own’ the overall system and the way in which it meets customer needs. When it comes to meeting non-functional requirements, user perception is everything (whether those users are customers, developers or the operations team). High-capability, high usage Internet technology systems carry with them a high profile and a high price of failure. These systems rely on having a system architecture that delivers their key non-functional characteristics consistently and the responsibility for this lies squarely with the system architect.
We need to get this right.
No comments:
Post a Comment