Systems Architecture 

Systems Architecture

A System is an integrated composite of people, products and processes that provides a capability to satisfy a stated need or objective. It is a combination or assembly of hardware, software, principles, doctrines, methods, ideas, procedures and personnel, or a combination of these, arranged or ordered towards a common objective.

A System of Systems is a collection of task-oriented or dedicated systems that pool their resources and capabilities to obtain a new, more complex, 'meta-system' which offers more functionality and performance than simply the sum of the constituent systems.

Systems Architecture is concerned with the various systems that are operated to manipulate and exchange information and provide drive to the processes. In the representation of Architecture Segmentation in the Taxonomy, the segment architectures are separate Systems of Systems where one segment may represent, for example distributed computing, another - centralised computing and another - networks.

Traditional siloed classifications (voice/data/video, LAN/WAN/UC/VC/security etc.) tend to treat Systems architectures separately and often in isolation. Common considerations such as sytems management, security and service management can then be treated as an after-thought.

The term 'system' in Enterprise Architecture usage is ambiguous. While it represents a primary classification in the EA Taxonomy, it also applies at each of these primary levels. For example, an enterpise is a 'system', or system-of-systems; Infrastructure Architecture is a system of its own component systems. Enterprise Architecting is all about the assembly of components at increasing levels of detail where an assembly of components forms a system, and a collection of systems forms a system-of-systems at mulitple levels from conceptual to logical to physical. At the Systems Architecture level, it is a proper noun (System) and in other uses is a common noun (system).

Mission Systems

Key characteristics: A System that directly performs an operational function. Examples include platforms, distributed Systems (e.g. a communications network), and discrete systems that integrate into other Mission Systems. Major components of a Support System (such as network monitoring, simulators, automatic test equipment, logistic information management systems) could also be classified as a Mission System where they fulfill a business function. such a Network Management systems in a Service Provider's context.

Mission Systems should be described in terms of the mission(s) that they are required to fulfil. Describing Mission Systems in terms of product portfolios is using the Subject Matter dimension of the Taxonomy. Rather, the purpose of a reference EA is to map design directly to the Business Architecture.

Support Systems

Key characteristics: The organisation of hardware, software, facilities, personnel, data and processes required to enable a Mission System to be effectively operated and supported so that the Mission System can meet its operational requirements. The Support System includes the support required for components of the Support System.

A Support System may be comprised of supporting resources (tools, processes, skills) and the customer's or third-party resources, or likely, a combination of these.

Support Systems can cover a range of capabilities, including but not limited to network monitoring and management, simulators, automatic test equipment, logistic information management and security.

Service Management such as ITIL and the tools deployed for it forms a system (an architecture can apply to processes, as well as physical components). In this Taxonomy,the Systems level applies to the identification of those procecess that are relevant within the overall architecture. The defined processes and specific toolsets are a part of the Infrastructure Architecture.

Cloud Systems

Cloud Systems can be further differentiated as public and private cloud where both are utilised. Cloud systems are

• XaaS.SaaS and IaaS are classified at the Systems Architecture level rather than the Information Architecture level as, despite the naming suggesting otherwise, they are Systems. PaaS could be a classification in Infrastructre Architecture.
• Hosted. Until XaaS definitions become clearer, a separate classification can be applied to Hosted systems - being customer owned systems hosted in 3rd party facilities for cost reduction, security and environmental purposes.
• Virtual. Centrex services can be considered to be Platform-as-a-Service - within the XaaS classification. A separate definition as a Virtual service may be more appropriate where, for example, it is primarily a telephony capability. Virtual Systems include VPNs, where the Infrastructure Architecture contributes components of the total VPN System-of-Systems.

On Premises Systems

On Premises, or on-site systems have particular requirements of, and implications for maintenance and support hence their separate classification from cloud-based systems. On-site systems also tend to be dedicated to a specific customer, while public cloud services are shared.

• Provider Systems. Network terminating devices form a part of the network - the Infrastructure Architecture. Provider Systems located on a customer's premises include Support Systems such as management terminals, routers and switches. The determinant is that the System is provider-owned component, not owned or specifically subscribed to by the customer.
• Customer Premises Equipment. Customer owned or leased equipment subject to service levels agreed with the customer.
• Wireless. While not limited to being 'on-premises', mobile devices can be classified as such as they typically require the nomination of an address for Service Management purposes. For taxonomical purposes it simplifies the secondary classifications. They can be separately classified when it suits the circumstances.
• BYOD. Subject to specific policies for deployment, use and support, BYODs need to be separately addressed. As with mobile Systems (which they generally will be) they can be separately classified at the primary level.

Content

Integration, convergence, multimedia, digital/analogue, wired/wireless, human-to-human, human-to-machine, M2M: regardless, the basic classification for content is voice, data or imagery. At some point in end-to-end communications, the content will be discriminated by one of these 3 fundamental media. Content is discriminated at this level in the Taxonomy as each imposes different requirements at some point or points in the communication exchange. The basic considerations of Quality of Service (QoS), contention, priority, shaping etc. are default criteria for designing networks and their component Systems.

Classifying content at the Systems level provides the point where user needs are reconciled with the Business capabilities. Will ubiquitous BYOD tablet and smartphone variants connecting via the Internet to cloud services as the default standard see the demise of the network architect? It will certainly change the focus, and the concept of a common multi-media collaboration interface forms a Future State that is worth considering. In such a scenario, the discrimination by media classification is being pushed to the network boundary at the user device, and/or at the point of storage, but it still applies; just more so at a Systems level than an Infrastructure level.

• Voice, audio, speech. Not sexy, and taken for granted! Like oxygen. Even call centres are looking for alternative media, however it will never die, despite the pervasive texting of the Gen-Yers.
• Data. Content traversing a network as bits is all data - including voice aand imagery. So, specifically, data as a category is the default for all content except at the point in a network where is is translated into speech or an image, which is occurring more commonly at the user device level. Architecture development tends to diverge at this point - Network Architects' focus is on the Data Exchanged, whereas Data Architects look at the Data At Rest and Data In Use.
• Imagery, video, graphics. Pedantry aside (e.g. "graphics files take up less space than image files, video needs more bandwidth than graphics"), a common classification can apply to all, and in the necessary context, or at another level, the image types can be separately classified.

Connectivity

This level describes the communities involved in a communication at a fundamental level - within the enterprise, within an extended enterpise and with the public. This allows for separate identification of user needs for data access and an enterpise's needs for data protection. Further categorisation such as WAN, LAN, MAN, CAN, SAN etc is undertaken at the Infrastructure Architecture level once the Systems Architecture has set out these boundaries; i.e. the virtual and logical architectures are defined at the Systems level while the Physical architecture is defined at the Infrastructure level.

Intranets and Extranets tend to be partly defined as being based on the Internet Protocol (IP). While obviously true for the Internet, architects could consider other network protocols as being components of an enterprise's Intranet or Extranet - or treat them as an Off-Net classification.

• Intranet. Describes the enterprise in terms of its internal communications - the information to be exchanged, stored, accessed and the points of interactions linked to the business functions being, or to be, performed.
• Extranet. Describes the 'extended enterprise' in architecture terms, where extension of an enterprise's intranet is enabled to entities external to that enterprise in isolation from all other Internet users.
• Internet. Describes the ingress required for anyone - and how that ingress is to be treated in terms of control over data accessibility and protection, presentation and manipulation.
• Offnet. Connectivity to external networks (except the Internet and Extranet instances) typically across shared public infrastructure.