Software is at the core of most CBSs. Figure 1 shows each CBS has software four elements: (i) one or more interfaces to people or systems in the environment (ii) a controlling architecture (iii) data processing functionality (iii) a dataset (iv). Often these elements are distributed on different machines and devices and sometimes across national and international boundaries (hence the term distributed systems). Increases in scale (number of components), scope (interconnectedness), geographical distribution (over country boundaries and laws) and system ownership (issues of governance, control and legal liability) of all the software, computers and other devices that are allocated to run the CBS add significant layers of complexity to its development.

Each CBS also has a set of quality characteristics that must be satisfied that affect the construction of the elements e.g. performance criteria, security, reliability. These characteristics are often cross-cutting system properties. The challenge for the software design team is to interpret the impact of each characteristic for each functional behavioural scenario that the system must execute.

In considering architectural design it can be helpful to characterise different types of problem and hence their system solution. Different systems can be arbitrarily categorised in accordance with what they do, how they do it or the criticality of a particular quality attributes. Table 1 shows one way of categorising the range of CBS.

Table 1: Computer-Based System Types

System Type	Example	Characteristics
Enterprise Information System 2	Usually concerned with the management of a given resource e.g. money (banks), airlines (seats), libraries (books and digital media), household goods food (supermarkets).	Different transactions are carried out and large sets of persistent data are accessed concurrently often through web browsers. Most systems are distributed across many machines in different geographical locations
Event-based systems	mobile phones, washing machines, home entertainment systems, weather stations	Event-based systems respond to external events in the system’s environment. The type of event and its timing are unpredictable. Some systems take information from a keyboard or mouse. Some systems just receive data from other systems. Often they drive a range of actuators attached to mechanical and electrical engine parts.
Batch Processing	Multi-million account bank cheque ledger system that requires updates to all savings accounts when say bank interest rates change.	An enterprise information system but which requires regular multi-change updates to very large datasets (millions of records) that updates take many hours and are conducted in “batches” offline to minimise the entire system being offline.
Safety-Critical System	Car engine management, on-board spacecraft control system; nuclear reactor monitoring system; Heart pacemakers, flexible manufacturing system	An event-based system in which the safety of lives and/or a lot of money is at risk if there is a significant failure and hence the rigour, precision, fail safety design and consequently the cost is an order of magnitude different to most other systems.
Autonomous Systems	Driverless Cars1, In-Flight Aircraft Engine Management systems, robots	An autonomous system can perform tasks in unstructured environments without human intervention or pre-programmed guidance. There are normally some AI components that can learn new patterns about the changing status of the environmental context and cause the system to adapt its behaviour accordingly. A Semi-autonomous system requires some human intervention.

Over the last 50+ years many different software development processes, design methods, data structures, programming languages and software tools have emerged that can be used to support the development of these types of system. The appropriate choice of processes, design methods, data structures, programming languages and software tools is normally informed by the type of computer-based system being developed but is also often an organisational socio-political decision informed by the specific requirements of a customer and the skillsets of the available staff in the supplier, particularly pertinent when an existing system is being evolved.

1The Society of Automotive Engineers(https://www.sae.org/) have devised a 6-level driving autonomy taxonomy ranging from no driving automation (level 0) to full driving automation (level 5)

There will continue to be a demand for a range of software design and software architect roles. The architect is often the principal technical conduit between a business sponsor and/or a project manager and the software design team. It requires a complex and often rare blend of capabilities. It is worth noting that great designers or great programmers do not necessarily make great architects. Whilst many people are able to intellectually grasp the breadth of business and/or breadth of technical knowledge that underpins a successful system, far fewer people are able to master it, communicate it freely and at the right level to the various business and technical stakeholders involved developing and using that knowledge.

In large complex computer-based systems with several different structural hardware and software components there may be hardware and software architects who report to a global systems architect. For example a national aviation radar (radio direction and ranging) processing system may have a radio detection hardware and software system to process radio signals from aircraft, a distributed radar information management system that interprets these signals and converts them into meaningful messages for different radar operators, and a graphical display hardware and software system to provide meaningful visualisations to help manage the speed and complexity of the information. The overall radar processing system may have a single global system architect whose direct reports may be the system architects for each of the radio detection, radar interpretation and graphical display subsystems. Each of these subsystems in turn may have hardware and software architects. In smaller computer-based systems…….architect roles to be combined, placing a greater breadth of knowledge pressure on the individuals who assume these roles.

In general the scope of software architect roles will vary depending on the application domain context, the project size and the size of the company. For example in large companies or on large projects a software architect may be the senior designer who leads and shapes the overall design in consultation with the project manager and the client, but the detailed design, its documentation and subsequent programming implementation are done by others. In a smaller company or on a smaller project, a software architect may have to also requirements engineering, detailed design and some parts of the implementation. A significant risk is that there are insufficient critical independent eyes to review the work that gets carried out leading to omissions and/or mistakes.

Another dimension to consider is application domain. Software engineers, like any other engineers, often develop their experience (and many spend an entire career) within a specific application domain in a particular industrial sector1 e.g. telecommunications systems, web-based enterprise resource planning systems, aircraft engine management systems, supervisory control and data acquisition (SCADA) systems used to control industrial chemical engineering, production engineering or assembly plants. The longer that one spends working in one application domain (>5 years), the more difficult it can become to switch to an organisation working in a different application domain. The hiring organisation has to balance the relevant quality and quantity of engineering, management and leadership skills that you do have against your lack of experience of their industrial sector; the design focus, major properties and idiosyncrasies of their products and services; and the commonly used methods, platforms, languages, tools.

A career path to software architect will require a set of career experiences that is likely to include programming, design and some form of team leadership responsibilities. As of 2017, earnings in the UK for software architects are currently around £40k-90k depending on the experience of the individual, the size of the company, the size and perceived level of importance of the software development team in that company (especially if its main business is not software development), the industry sector, geographical location, and the scope of the role. Information about average software Architect pay scales can be found at: 🔗 www.payscale.com/research/UK/Job=Software_Architect/Salary.

Duties, Responsibilities, Skills

Table 2 shows the typical duties of a software architect role. They are separated into duties that are typical on a specific project and duties which are ongoing regardless of a project, and into three different core skillsets: engineering, management and leadership. The emphasis of these activities will vary according to the company and its mission, vision, strategy, size, current portfolio of projects, organisational structure and culture, the scope of its software development activity.

Table 2: Duties, Responsibilities, Expectations of a Software Architect

PROJECT SPECIFIC
Engineering	Requirements Engineering	Engage with business sponsor and business analysts / requirements engineers to provide design perspective on specification of a new product.
	Design	Lead the creation of an architecture Provide the software architecture perspective at team meetings of all different types of architects on a computer-based system Lead documentation and communication of a software architecture to all stakeholders
	Implementation	Decide on the methods, tools, languages and technologies unless this has been built in as a design constraint
	Evaluation	Lead analysis and evaluation of a software architecture. Lead the construction of the system test specification and its execution Work with the business analysts to shape a presentation to the sponsor.
Management	Business Understanding	Most, but not all projects (especially in small companies), have separate Project Manager (PM) roles to drive a software project. The PM’s key technical conduit is the software architect. The software architect will be required to support the PM in cost estimating, staffing allocations, writing progress reports. Cost estimations include capital (hardware and software) and revenue (labour charges and expenses) costs. Planning decisions involve constructing different design options with reduced or enhance functionality, using different toolsets, to fit different budget or time to market envelopes.
Leadership	Communication	Understand and communicate the vision to the design teams especially about how the product fits into the business strategy Be a team builder and mentor Anticipate and write progress report for manages and sponsors
ONGOING
Engineering	Technology Foresighting	Monitor and evaluate new methods, languages, tools by engaging with vendors, commissioning technical feasibility studies, establishing short- life working groups of designers/programmers Give talks as public conferences to share and receive experiences and best practices
Management	Planning	Work with Divisional Managers to allocate staff to different projects. Plan and monitor the skills and career development of teams for which responsible and self.
Leadership	Sales Support	Support the sales team either when visiting potential new clients and/or they are writing preparing new bid proposals (especially with technical feasibility, human resource management and cost estimations (see Business Understanding above)

Professional Development

Having a reputation for being professional means embracing and developing means you are known for:

your breadth and depth of specialised knowledge

your reliability i.e. getting the job, keeping promises

your attitude i.e. you will find solutions and not complain when there is a setback

your honesty and Integrity

your accountability and willingness to take responsibility

your manners and courtesy especially under pressure

your image i.e. dress appropriately; speak calmly, politely, authoritatively; exude confidence.

The development of the breadth of the technical and business knowledge and skills that enable all of the duties in Table 2 to be performed at least competently and at best very well, takes hard work, natural flair and luck. Hard work in this context means having a positive attitude toward and aptitude for deliberately planned continuous learning about (i) software engineering processes, methods, techniques, patterns, languages and tools across all the different stages of software engineering (ii) the complexities of and lessons learned from deploying software in different application domain contexts. The phrase “deliberately planned” here means reading different technical professional resources (see 📖 Sidebar: Professional Development Organisations), broadening your reading outside software to other disciplines e.g. mechanical/electrical engineering, social sciences, health; attending technical and management courses; engaging with other like-minded professionals at external professional development seminars, and following and/or engaging with technical standards development (see section 3).

An outstanding software architect will be known for having a blend of deep technical knowledge and business acumen; being able to identify and represent problems at different levels of

abstraction and invent new or reuse and adapt existing solutions; being open-minded and flexible to new ideas but pragmatic in arriving at designs that satisfy requirements but also fit resource constraints; social skills to manage the relationships, confidence and perceptions of the client (business sponsor), the supplier’s managers (e.g. project manager and above) and the supplier’s technical design team; confidence in communicating and convincing people of the merits or limitations of different ideas; and a sense of aesthetics i.e. an appreciation of excellent design wherever it appears in life and a passion for developing elegant solutions to complex problems.

Professional Standards

Good software architects will keep abreast of commonly used and emerging standards. Standards are documented agreements containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose. If followed they often add to the quality of and hence confidence in the product and service that was built. Standards can help ensure integration between different independently developed products and services, and can be instrumental in facilitating international trade. They can be normally separated into one of two categories:

“De Jure” i.e. “from law” meaning that the development of the standard has followed a rigorous process, usually with input from international colleagues around the world, and its maintenance is managed by an independent body e.g. the International Standards Organisation (ISO, 🔗 https://www.iso.org/home.html), the Institute of Electrical & Electronic Engineers (IEEE, 🔗 www.ieee.org/), the World Wide Web Consortium (W3C, 🔗 https://www.w3.org/Consortium/), the Object Management Group. Examples include ISO 12207 Systems and Software Engineering ISO 27001 Information Security Management, ISO 9001 Quality Assurance Management, and ISO/IEC 10746-3:2009: Information technology - Open distributed processing - Reference model: Architecture; IEEE 1028-2008 - Software Reviews and Audits; OMG Common Object Request Broker Architecture; W3C HTML 5.1 Second Edition

“De Facto” i.e. “in practice” meaning that the creation of a standard often emerges from market competition development of a standard is undertaken by the has been adopted often because of market forces e.g. Microsoft’s Windows operating system, along with commonly used business applications such as Microsoft Word and Excel, have long been the de facto standard for business and home users.

Standards often have to be adopted for different reasons:

To transfer ’good practice’

To benchmark against “good practice”

To meet contractual demands of clients

To meet the demands of a certifying body

To have a political safety net

To ensure product and/or service integration.

To adhere to requirements of other standards or software process improvement initiatives.

Standards by their very nature seek to abstract and unify whilst aspiring to retain some flexibility but organisations and projects vary enormously. The relevance of any particular standard will be proportional to the size and scale of the organisation adopting it. Sometimes working to a standard can have significant resource implications e.g. following all the steps of process, buying tools that support the process, buying licences and needing to upgrade hardware to use the latest version of a programming language.

Organisation Capability

Some organisations understand the role of a software architect and some do not. That’s life. If you have some idea that taking on an architect role might be enjoyable and rewarding at some point in your life then it will help to spend part of your career in an organisation where the role is valued and where there is a supporting infrastructure. Supporting infrastructure means: software engineering is a recognised as complex engineering discipline2 (many organisations still do not understand this); there is actually a role description in the HR database labelled software architect and that role sits on one more documented illustrative career paths; senior managers, project managers and functional business leaders value the role; the organisation’s software development process and practices are documented and people understand and implement the concept of an architectural review board as the place where a critical review and analysis of draft architectures take place.

This module explores the concepts of architectural design and detailed design, the relationship between them and the use of design patterns to support activities. The architecture of a system describes the main structural components, the connections between these structural components, the connections between the components and the external world with which the system will interface (users and/or other systems), system behaviour, and system performance. It is the highest level of design description of system.

Architectural design is a set of design decisions that lead to the design of an architecture. It is a complex messy problem because many different viewpoints need to be considered e.g. structural, behavioural, implementation, deployment (e.g. across one or more hardware devices), legacy (i.e. existing systems), sustainability, performance, financial, timescales (that may impose resource constraints). Each one often has an effect on the other. Once a system is up and running changes are often required. If changes (“quick fixes”) are made just to a low level design or code component without also taking an architectural perspective, often there are significant unintended consequences. Not keeping the architectural design consistent with the actual implementation is the usually the biggest reason why many systems prove difficult to maintain.

The shaded area of Figure 2 shows the focus of this module in the context of a broader software engineering development process framework. Having developed the requirements during a Requirements Engineering process, a functionality-based architectural design process considers the high-level structural design components needed to deliver those requirements. The resultant draft architecture is then revised in the light of known quality and resource constraints. This is an iterative process. When there is agreement between different stakeholders on the architecture, the detailed design work begins.

Sometimes detailed design issues and implementation issues also cause revisions to the requirements some aspect of the architecture (though these scenarios are not shown in Fig 2). Figure 2 makes no mention of the specific software engineering process e.g. waterfall, spiral, agile, devops. In recent years agile and devops processes have assumed greater prominence in software development teams and departments. Devops is an approach to software development in which the product development teams and the operations and support teams collaborate on designing and developing the product. For example, the desire to deliver many different versions and releases quickly should inform architectural decisions.

The description of a software architecture and its subsequent detailed design can be enhanced and speeded up by using design patterns. A design pattern captures the wisdom and experience of others who have seen similar problems to the one you are addressing and arrived at a design solution that for the most part can be reused. A design pattern is an informal description of a solution that can be implemented in different ways. Different companies (and even different groups in the same company) often use different combinations of different modelling notations (formal and informal) to describe architecture and patterns. In this module we will often use natural language and the Unified Modelling Language to describe patterns.

There are many tens and hundreds of patterns. Some are for systems of any type, some are for systems of specific types. Some capture architectural design aspects, some capture low level design aspects. Some patterns use other patterns. Ideally there is an existing fully or partially coded implementation of the pattern(s) you wish to use in a pre-existing code framework or library. However even when there is not, patterns are useful for shaping the detail of designs and communicating about them.

The purpose of this module is to make you aware that much previous development experience may have already been captured in pattern descriptions. You should seek out that documented experience during development.

Learning Outcomes

On completion of this module, you should be able to:

Understand the use of patterns in the design of software systems

Construct an architectural design using patterns

Evaluate and apply patterns to the development of software systems.

Software Tools Required

You will be required to use some form of modelling tool for the coursework. For example, Star UML is available from the GCU Virtual App Store. It is a diagramming tool to support the development of diagrams using the UML notation. However you can choose any other diagramming or modelling tool.