CONTENTS OF THIS CHAPTER

This chapter covers the following topics:

• what is architecture?
• architecture patterns;
• enterprise architecture;
• solution architecture;
• software architecture;
• stakeholders and roles in architecture;
• architecture management;
• references and further reading.

INTRODUCTION

Anything that we can classify as a system has an architecture, including buildings, living organisms (including humans), organisations, complex enterprise IT systems, software applications and individual components of those. When referring to IT systems, a core definition of what is meant by the term ‘architecture’ is provided by the ISO/IEC 42010:2011¹ ‘Systems and software engineering – Architecture description’ standard:

‘The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.’ (ISO, 2011)

This standard considers an architecture to be ‘a conception of a system’, in other words it is in the human mind, which can exist without being written down. This abstract idea of an architecture can be captured and communicated in the form of an architecture description.

The ISO standard also reinforces the idea that no architecture exists in isolation; it exists in a context which needs to be understood so that the architecture’s relationship with its context can also be described.

The objective of anyone working on architecture is to determine the appropriate way in which to represent this architecture description; and this is often in the form of documentation containing an appropriate set of models.

In many respects, this chapter is an extension of Chapter 7 (‘System modelling techniques’) in that a lot of architecture is about modelling and so much of the theory about forms of abstraction and levelling contained therein applies equally apply to this chapter. It is therefore recommended that you read Chapter 7 before this one unless you are familiar with these concepts:

• abstraction; classification, idealisation, composition and generalisation;
• black- vs white-box models;
• the difference between a model and a diagram.

Architecture is more than just structure

It is worth re-reading the ISO 42010 definition again, particularly the last part; ‘... and the principles guiding its design and evolution’. This emphasises that an architecture includes aspects such as requirements and constraints (in particular architecture principles) that inform what that architecture needs to be to satisfy key concerns of major stakeholders.

While the ISO 42010 standard is specifically aimed at systems and software engineering, the definitions contained are used consistently to refer to related types of architecture.

Types of architecture

Many related architecture disciplines have evolved over the last 20 years, each focusing on different forms of systems. This chapter begins with the broadest and then focuses in on more specific architectures. The chapter will consider three levels of granularity:

• Enterprise Architecture;
• Solution Architecture;
• Software Architecture.

Before these are described, the following section explains some common patterns that all of these architecture types share.

ARCHITECTURE PATTERNS

Architecture structures are typically models and there are some fundamental patterns that apply in various contexts, as will be discussed later in the chapter.

Modular architecture

In the early days of information systems, monolithic software architecture (where various aspects such as data input and output, data processing and the user interface were not architecturally separated into modules or components) was common. This was not such an issue, as the technical architecture was somewhat simpler (often a single physical node) and much of the data processing was batch-driven and managed by job control software; each executable program tended to be limited in functionality.

There would, however, be issues associated with applying certain aspects consistently across the suite of executables where a change to a single business rule or to the structure of a data element might typically require multiple changes to ensure consistency and prevent processing errors.

Structured programming languages and tools introduced the ability to write software library modules containing routines that dealt with such issues that could be shared and invoked by multiple executables, although these would often be statically linked into a single executable during compilation and linking; this meant that a change to one of these modules would require that all executables that used it would need to be recompiled.

The introduction of dynamically linkable modules, or libraries, meant that this static, compile-time dependency could potentially be broken. The library modules could be updated independently of the calling modules, although these often needed to be updated too. Issues would frequently arise when a developer changed a library module to support their program’s requirements without realising the impact on other programs.

Configuration and version management was key to prevent chaos. It was not until independently defined interfaces were available that these modules could be loosely coupled (see below), allowing them to be maintained independently. Software architectures, and consequently the physical architectures, could become truly modular and flexible. Modules began to possess properties that led them to be called components to distinguish them from their predecessors.

Loosely coupled architecture

Coupling is a term used to refer to the level of dependency between two software components, although the term applies equally to hardware components. The earlier modules described above tended to have a high level of dependency, in other words they were tightly coupled. Table 10.1 compares some features of loose and tight coupling.

It should not be assumed that loose coupling is always preferable to tight coupling; there are situations where tightly coupled components are required, for example to achieve demanding performance levels.

Table 10.1 Features of loose and tight coupling

The fundamental structural element that enables loose coupling is an interface that is abstractly defined separately from the module’s implementation code, this defines the signatures of the module’s functions, operations, methods, algorithms, strategies or services (these terms are interchangeable depending on context). Clients should ideally be dependent on the abstract function definition rather than the implementation. This allows the implementation of the module to be updated, replaced or dynamically interchanged providing that the interface is supported.

The important role of interfaces means that their definition is a key focus of architecture. When modelling how ‘black-box’ modules can be assembled to create a system, the functional requirements of those modules can be defined through defining the system’s interfaces, both at a logical and physical level. Once these requirements are defined, then the modules can be implemented in the most suitable way for the solution to meet all requirements (including non-functional requirements).

When coarse-grained components or sub-systems are being referred to, then the term ‘Application Programming Interface’ or API is commonly used.

‘Coupling and cohesion’ are often used in the same phrase. As we have seen, coupling relates to how dependent modules are on each other. Cohesion looks at how closely modular elements need to operate or be changed together; where this is the case, then there is high cohesion (and probably tight coupling). It is less problematic if these modules are co-located within the same coarser-grained component, which means that they will be deployed and maintained together.

Tiered/layered architecture

There are different kinds of functional elements in any solution or software architecture based upon its responsibilities; for example, those that represent and manipulate data as compared with those that handle the system’s interface. These can be organised into distinct layers or tiers of modules with similar responsibilities.

Hierarchical architecture

It is preferable in layered architectures the higher layer is dependent on the services provided by the layer below, but not vice versa. This provides flexibility in that components at one layer can be servicing multiple clients at the layer above; for example, application components sharing common infrastructure services (and their underlying components).

Specific examples of layered and hierarchical architectures are provided later in the chapter when discussing Solution and Software Architecture, for example Figure 10.2.

COMMUNICATION AND INTEROPERATION PATTERNS

An architecture composed of, or assembled from, discrete components or sub-systems needs those components to communicate and interoperate. Some basic patterns are evident at both logical and physical views of business, application and infrastructure architectures.

Point-to-point

This is the most direct and, in many respects, simplest pattern and can range from logically indicating that a particular client communicates directly with a specific server to physically laying a cable between two geographic locations or attaching a mobile device to your computer via a USB cable. Point-to-Point tends to be tightly coupled, as the components are specifically linked logically or physically and they need to share common protocols, data formats and so forth.

Problems arise when multiple point-to-points are required to connect a number of nodes, as the number of links required potentially increase exponentially when new components are added.

Hub-and-spoke

Where a significant number of components need to interoperate, this can be set up as a set of point-to-point connections between each component and a single hub component. This component primarily exists to provide the means of connecting any component with any other. In doing so, the hub is potentially de-coupling each component pair to some extent and it can achieve this, first, by acting as an introduction broker or discovery agent, dynamically linking client to server component pairs on demand.

The hub can also offer other brokering services such as determining whether the client has security access to the server or by performing translations of communication protocols or data structures. It can even take over some of the logic processing and manage complex distributed transactions, at which point it has become a processing server component in its own right.

Service-oriented architecture

The service-oriented model is fundamentally about how components can be defined by the services they require as a service consumer (or client) and provided as a service provider (server). These components are typically as de-coupled as possible in all aspects,

This model also applies to how we organise our business functions and it is the model that allows organisations to outsource certain functions, where they are defined, and interoperate according to the services they provide rather than according to how they perform the service. If done properly, it should not be evident to a service consumer whether the service is provided by an internal or an outsourced provider.

In a service-oriented IT architecture, there is typically a broker hub, often in the form of a service bus, that allows:

• service providers to register their services with a service registry held by the hub;
• service consumers to ‘look up’ or discover service providers as required.

The consumer and provider can then interact in one of two ways:

• a temporary point-to-point connection may be set up between them, across which they communicate directly;
• the interactions are conducted through the hub acting as a broker.

ENTERPRISE ARCHITECTURE

For many organisations, a significant development has been the adoption of enterprise architecture (EA) as typically the highest level and most holistic form of architecture developed and evolved about the organisation (the enterprise) over a strategic timeframe. The organisations in question can be massive, global multi-nationals employing hundreds of thousands of employees all over the world and operating in many geographical marketplaces; or they can be a small businesses run by families. One is clearly a lot more complex than the other, but fundamentally both are systems with similar features. For example, both have:

• a context or environment within which they exist;
• a mission, the reason why they exist;
• a set of products and/or services that they provide to a customer base;
• an organisational structure with individuals fulfilling roles;
• a set of processes that they execute to conduct their operating model;
• information and data that they process and maintain about their organisation (and all the above) for either their own purposes or to meet legal and compliance requirements.

Strategy versus tactics

Most important of all, any organisation should have:

• a vision of what their future context or environment is likely to be and what they want to be in the future to remain relevant to that future:
• the need therefore to evolve through changes to meet the challenges presented by their constantly changing context or environment:
• a strategy to achieve that over a period of time.

Enterprise architecture is primarily concerned with these highest-level, long-term, strategic issues. The individual changes conducted to support this strategy can usually be seen as shorter-term, tactical changes, which include some business as usual activities intended to support the strategy; for example, a shift in the marketing messages to effect changes to customer perceptions and potentially alter the customer base.

These tactical changes are typically evolving and different aspects of the business, particularly its operating model, which includes:

• organisational units of people;
• business practices such as business processes;
• IT systems used by the business to execute its processes.

Architecture domains

Enterprise architecture is usually broken down into distinct architecture domains. EA frameworks relevant to most business or government enterprises typically use the following four domains:

• Business architecture;
• Data and/or information architecture;
• Application(s) architecture;
• Infrastructure or technology architecture.

These domains each contain a subset of the overall EA; they are interdependant and there will be overlaps of interest between them (see Figure 10.1).

Figure 10.1 Architecture domains in enterprise architecture

Organisations often employ other domains that cut across the main domains, the best example being security architecture, which is concerned with the consistency and completeness of security aspects across the whole enterprise. These domains will be discussed in more detail under solution architecture.

EA processes, content models, organisation and frameworks

As with any development function, an enterprise architecture function needs to determine:

• Organisation: How it is to be organised internally into roles and responsibilities as well as how it will fit within the organisation as a whole.
• Process: What activities the EA function is going to perform and when.
• Content: What information about the enterprise will be recorded, how it is classified, organised and cross-referenced.

There are many frameworks available that organisations may adopt and/or adapt to fit their needs. Some well-known generic frameworks include:

• ‘The Open Group Architecture Framework’ (TOGAF), which covers all these aspects;
• ‘Zachman Framework for EA’, which focuses on classification of EA content.

There are frameworks specifically aimed at particular countries and organisations, for example:

• FEAF, the US government ‘Federated Enterprise Architecture Framework’, aimed at most US government departments and agencies;
• DODAF and MODAF are frameworks specifically for the US Department of Defense and the UK Ministry of Defence.

EA governance

An important function of enterprise architecture is to put in place principles and policies that constrain any change in activities to ensure that the strategic objectives are met. These will obviously have an effect on any solution, software or infrastructure architecture and the resulting development work.

ARCHITECTURE PRINCIPLES

Architecture principles are high-level constraints that are not directly actionable but that represent underlying rules and guidelines that drive the architecture.

‘Architecture principles fill the gap between high-level strategic intentions and concrete design’ (Greefhorst and Proper, 2011). Principles can be defined that relate to any domain or aspect; for example:

• ‘business units are autonomous’, is clearly a business domain principle relating to the organisational structure;
• ‘routine tasks are automated’, relates to business and application domains;
• ‘primary business processes are not disturbed by implementation of change’ relates to all domains;
• ‘applications have a common look and feel’, relates to application design;
• ‘only in response to Business needs are changes to IT systems made’, is actually an application and technology domain-focused principle.

These examples are taken from Greefhorst and Proper (2011).

Policies

Policies are needed as a more actionable implementation of the architecture principles. These may include:

• policies that mandate that certain legislation, standards and industry regulations be complied with; for example compliance with data protection legislation, ISO 27001 security or an industry benchmark regulation;
• policies on how the change activities will be run; for example the role of project management and the involvement of relevant authorities to allocate and spend budget;
• policies on supplier engagement; perhaps limiting choice to pre-approved suppliers or how a procurement exercise must be conducted;
• technical policy that limits the choice of technologies to be used to help with standardisation; this could include the use of certain tools, development languages and infrastructure elements (for example that a single sign-in service be used);
• development standards, such as processes to be followed or style guides to comply with.

All of these are put in place for the benefit of the organisation in the long term, even though – for some change activities – these may be inconvenient or even more expensive.

Governance activities

It is the role of a specific authority (perhaps the EA function) to ensure that the policies are complied with through governance activities; although the ability to grant dispensation to be non-compliant for valid business reasons should always be considered.

SOLUTION ARCHITECTURE

If EA is for long-term, strategic architecture then solution architecture is a shorter-term, tactical form of architecture. EA guides evolutionary changes to the whole enterprise over a period of time, whereas many of those individual changes will require the oversight of a solution architecture.

Holistic solution

First, solution architecture should be distinguished from the conventional design activities described in Chapters 8 and 9 on systems design. Initially, the solution architecture will be a high-level description of the building blocks of the total, holistic solution architecture and how they interface and interoperate to meet the requirements.

Driving and controlling design

This outlines the work for more detailed design and implementation which then needs to be overseen or governed by the solution architect; if any need to change any of the requirements or building blocks is identified, then they are best placed to analyse the impact across the architecture and resolve any issues.

Architecture domains within solution architecture

The solution building blocks described above are not just IT software- and hardware- based. In most organisations, any solution should be regarded as a business solution. Even with organisations that are simply updating the IT infrastructure, there should be a business driver for any solution – in other words, a business issue that needs to be addressed. The domains described above apply equally, therefore, to solution architecture.

For example, any software applications that rely on the infrastructure will typically have service levels that the business needs to be met; and improvements to those service levels required by the business users (such as better performance, availability or reliability) typically involve improving the platform upon which the applications run – that is, the infrastructure and its components.

The domain seemingly missing from that description is the data architecture. This can be seen as cutting across or mapping into the other domains (as it does in Figure 10.1), with different views relevant to each. Simplistically, data might be considered at the conceptual level (meaning) for the business, logically (structure and rules) for the applications and physically for the infrastructure (how and where it is stored or persisted) although other abstraction forms will also be involved.

Hierarchies of architecture domain services

An alternative view of the domains presented in Figure 10.1 is to consider how these domains describe layers of a hierarchical architecture where each layer provides services to the layer above (see Figure 10.2).

Figure 10.2 Hierarchical domain services

This layered architecture, where layers are offering services to the layer above, follows several of the patterns described earlier in the chapter, particularly the de-coupling of the hierarchical layers.

Defining solution scope

Any solution needs its scope to be defined and there are three dimensions of scope to be considered (see Figure 10.3):

• focus;
• breadth;
• depth.

Figure 10.3 Solution scope – focus, breadth and depth

Focus

The scope of a particular change that requires a solution architecture description may involve any or all of the domains discussed above; this reflects dependencies and the fact that the business requirements driving changes to the information systems are effectively from the business architecture. The solution may, however, be focused on changing aspects of the infrastructure architecture, whose requirements are driven by the application and data architectures’ reliance on infrastructure services; thus, business architecture may not figure in this solution. It should not be forgotten, however, that non-functional requirements or the technology are ultimately reflections of business needs (for example for performance and availability).

Breadth

Within each of the domains that are in focus, a solution is concerned with sets of architecture elements. Examples include business processes and people’s roles within the business architecture as well as new application software and infrastructure components and changes to the services being offered and depended on at each layer.

The broader context of a solution architecture is the enterprise architecture. The breadth of the architecture needs to be clearly understood.

Depth

For any solution architecture description, there comes a point where the architecture description stops and detailed design takes over; this is the depth. There are various ways of defining architecture levels; the perspectives of the Zachman Framework are worth considering as a classification.

Architecture contract

As with any work specification, the solution architecture deliverables, related activities, roles and responsibilities should be defined before work begins. This is typically done in the form of an architecture contract. This can be considered as the architecture’s terms of reference. The deliverables can be defined using the three dimensions of scope discussed above.

Solution architecture governance

In our three levels of architecture granularity, solution architecture fits between enterprise architecture and software architecture. In terms of compliance, two issues are involved:

• Compliance: the solution architect needs to be aware of the constraints placed on the solution by the EA function (if one exists) as well as any placed by the solution specific requirements.
• Enforcement: the solution architect in turn creates constraints on the underlying detailed architectures and designs, for example the software architecture and design, where these need to comply with issues apparent in the holistic solution architecture.

Within this governance brief, the solution architect needs to be able to respond and react to issues that arise from the ensuing work, such as when technologies do not behave as expected or where non-functional requirements are not achievable without compromise or a change in the architecture.

SOFTWARE ARCHITECTURE

Software architecture is fundamentally concerned with the purpose and structure of software applications, including software components, that may be considered to deliver platform services within the Infrastructure architecture. If operating within a described solution architecture, then its purpose is typically to break down the solution architecture functional building blocks or components into more granular, decomposed and eventually more physically implementable software components where appropriate.

The software architect incorporates more implementation-specific factors such as:

• choice of development languages and tools;
• structural constraints presented by platform technologies chosen for the solutions that already exist or need to be procured;
• identifying and employing appropriate logical and physical design patterns that encourage robust software design and implementation.

There is clearly a significant overlap between this level of architecture and the solution design activities described in Chapters 8 and 9.

Tiered software architecture

The concept of tiered or layered architecture as a basic pattern was introduced earlier in the chapter. We now explore the concept in more detail.

Figure 10.4 Client-server patterns

Two-tier, client-server

An early, basic version of this tiered pattern is a client-server arrangement, as illustrated in Figure 10.4.

In this arrangement we see:

• A server module the responsibilities of which are to read and write the data to and from storage, maintaining aspects of the data’s integrity. It provides a defined set of services to a client.
• A client module, which is dependent on the services provided by the server. This could be an application run by users on remote devices that calls the services provided by the server, for example by sending queries to and from the server. As well as interacting with the users, this client application can apply business rules and logic.

This arrangement was common in the 1980s and 1990s, when PCs, as opposed to dumb terminals, became common on user’s desktops. Typically in this arrangement, both the client and the server may each be performing different aspects of business logic. Where there was a lot of this business logic occurring on the part of the client, it would be referred to as a ‘thick client’; where most of this was on the server, it would be called a ‘thin client’.

Hierarchical client-server

This arrangement has usually involved tightly coupled client and server components, where the client was dependent on that specific server and the server was in turn dependent on that specific client. This may have solved the immediate problem of deploying clients but it did not provide sufficient flexibility for future development.

This problem could be addressed by de-coupling the client from the server, where the server delivers its services in a more generic manner (typically through the interface pattern). Multiple alternative clients could be developed for different platforms, each of which could access the services. Typically, the servers became thicker and the clients thinner in order to ‘centralise’ as much business logic as possible on the server.

Three-tiered software architecture

The client-server approach works well when the application exists within a silo; typically a single database dedicated to that application, even with its multiple clients. In most organisations, these silo-ed applications needed to be integrated – particularly where databases needed to be shared by multiple applications and clients potentially require data from multiple sources.

A third, middle tier provides the means to achieve this, where the business logic is de-coupled from the data sources and components within that layer can be shared by multiple clients. The concept of an application as a silo-ed set of software began to break down and the focus was placed instead on the application being defined by the services provided at the point of delivery to the business users via the user interface client. This is why, in enterprise and solution architecture in particular, application architecture that models and controls this complexity of dependencies across applications to deliver services to the business architecture is important.

Figure 10.5 illustrates how multiple applications can share a number of components at the middle and data tiers.

Figure 10.5 Three-tier software architecture with components shared across clients

N-tiered software architecture

The three-tier architecture is, however, simplistic. Typically, in modern architectures, these need to be sub-divided further (see Figure 10.6), for example:

• System interface, boundary or presentation layer: components at this layer provide the means for external entities, such as users or other systems, to interact with the system. Web technology in distributed architectures typically involves at least two sub-layers here:
  • A web-server layer that provides services to browser and other remote clients (for example, mobile apps) and interacts with the lower tiers to achieve this. It may be delivering the HTML or XML content to be rendered by the client, so is part of this presentation tier.
  • A client, which can either be simply the browser that renders the pages delivered by the web server or a client such as an app on a mobile device that exchanges XML or other specific data format through the web server.
• Business logic layer: this performs two roles as defined by the following sub-layers:
  • Process logic or controller layer – these coordinate sequences of logic performed by other components interacting with other to fulfil the system’s functionality, usually supporting the interactions being performed through the system interfaces. Complex transactions involving a number of business entity components can be managed here.
  • Business entity layer – where the system manages representations of data dynamically. Components provide services and encapsulate functionality that apply business rules to particular data classes or entities as data is created, updated and deleted from the system. It interacts with the underlying data layer(s) to ensure the data is persisted on the system.
• Data layer: ultimately, this is the layer responsible for storing data in a persistent state, such as to disk, and retrieving it as required by various clients. In a simple, single database server environment, this may be seen as a single layer; in many complex architectures, however, this is divided into at least two layers:
  • Data services layer – components that provide a one-stop shop for data, hiding the complexity of multiple databases, nodes and data distributed between them. They can also be adapters that resolve different data retrieval protocols for different underlying database technologies.
  • Data management layer – typically Database Management Systems (DMBS) or file handling components.

Figure 10.6 N-tiered software architecture

Not all of these tiers are needed all the time but, as organisations with complex IT systems begin to integrate their applications using enterprise technologies, then several are often required.

Component-based software architecture

Today, most applications, no matter how many tiers are involved, are built as assemblies of components. By doing so they tend to be:

• more maintainable;
• more flexible in how they are deployed in distributed architectures;
• more consistent with each other through sharing components that enforce business rules and perform business logic.

Systems as assemblies of components

The primary role of a software architect is to understand these complex software architectures and to be able to determine any specific solution:

• what software components already exist and whose services can be re-used in their current form;
• what software components already exist, but whose services may need to be added to or updated. In this situation, impact analysis must be performed on other applications that share those services to ensure that they are not disrupted. This conforms with the principle outlined earlier that ‘primary business processes are not disturbed by implementation of change’;
• what software components are not currently present, but which may be procured ‘off the shelf’ and configured to fit into the software architecture;
• what software components are not currently present and cannot be procured off the shelf, and so need to be specified to a sufficient degree that they can be designed and built by either internal or external development teams.

Component diagrams and models are available in the Unified Modelling Language (UML) and other notations to allow such an architecture to be modelled.

Functionality provided through component interactions

Applications deliver their functionality and services through their software components interacting with each other. In Chapter 7, various forms of functional modelling are described, including system use cases, as a means of describing the application services provided to the users. The functional model map shows how system use cases can be realised through UML interaction models, particularly sequence diagrams that are commonly referred to as use case realisations. The participants within the software system in this top level of interaction modelling are typically components. Such modelling shows where existing components and their services can be utilised and where new functionality is required, either as new services on existing components or through new components.

Component specification

Specification of software components at this level can typically be done at a ‘black-box’ level by specifying:

• what interfaces, services and functionality the component needs to provide to its clients (which may be other components) as identified within component interactions;
• what interfaces and services this component is dependent on that will be provided by other components in the architecture;
• any technical requirements including constraints for this component;
• any non-functional requirements that this component needs to meet.

The components can then be designed, built and tested to meet these specifications and the requirements behind them.

Testing components

The ability to specify components in this manner means that their behaviour and non-functional aspects can be black-box tested, providing confidence in them before they are integrated into broader systems for further testing, including regression testing of other components and applications (and even business processes) that may be effected by the change.

STAKEHOLDERS AND ROLES IN ARCHITECTURE

If this chapter has revealed anything, it is that the amount and level of complexity within many organisations in terms of their business functions and the IT they utilise is difficult to manage when organisations are looking to make changes to any aspect. Therefore, a variety of roles can be recognised that contribute to this management.

Enterprise, solution and software architects

Enterprise and solutions architecture can provide a holistic view of all these aspects as indicated in all the various architecture domains. Enterprise architects attempt to model the whole enterprise (at a high level of abstraction) to help specify and oversee long-term, strategic change to these domains in order to deliver the strategic vision; solution architects focus on a subset of the enterprise architecture to specify and oversee shorter-term tactical changes in order to deliver a solution.

Within a solution, the solution architects include software applications and their high-level building blocks, usually alongside business, data and infrastructure building blocks. Software architects typically focus on the software components at the next level of detail, particularly where those components may be reused across a number of applications.

Domain architects

The specific architecture domains cut across these strategic and tactical architectures:

• Business;
• Application;
• Data;
• Infrastructure;
• Security.

Domain architects who work in these areas are typically involved in defining domain-specific standards and governing domain issues that ensure that all solutions are working in a consistent manner to deliver the vision. By doing so, they may also identify and be involved in the resolution of conflicts between different solution activities.

Stakeholders

Each type of architecture needs to engage with the relevant stakeholders, internal and external. The following list is not exhaustive, but provides an indication of the range of stakeholder types that need to be engaged with.

Organisation owners/board

The board is responsible for delivering both long- and short-term returns to the owners. They do this by ensuring that the organisation is fit for purpose to deliver its mission, not only today but also into the future. That requires the organisation to change to meet the challenges of the changing world around it as determined in its strategy.

Strategic change usually involves all aspects of the organisation and is where enterprise architecture becomes a tool for the organisation to understand the complexities involved and to determine how those changes can be delivered over time piece-by-piece, without breaking the organisation in the process. This involves significant investment in change decisions; the board are spending the owners’ money and need to identify which change activities not only provide short-term gains but also support the long-term vision. EA can provide such information and advice.

External legal, standard and compliance regimes

A common driver of change is the legal and compliance environment in which the organisation operates. New legislation and standards may require changes to how the organisation operates and this may require changes to business processes and/or IT systems in order to comply. There are often agencies or other authorities that can be engaged with in order to clarify any compliance issues and minimise risk to the business of being fined, prosecuted or even disqualified from conducting business.

Senior business management

Senior managers across the organisation are typically the ‘owners’ of business units and are responsible for ensuring that they operate effectively. Those units discharge various business functions involving business processes performed by their staff, often through the use of IT applications. Change activities may be funded through their delegated budget and they will be concerned that any outcomes are achieved after the change, particularly those that impact on their unit’s key performance indicators (KPIs).

Project, programme and portfolio management

Significant change activities are often managed by project and/or programme managers. Architects need to work closely with them to ensure that architecture activities are built into the plans, especially any governance activities.

Operations managers

These are often mid-level managers responsible for ensuring that day-to-day business and IT operations are conducted properly. They need to ensure that the correct processes are performed and that the appropriate level of resources are available to meet any performance or other service level targets.

Changes to the operating model obviously have a significant impact on these stakeholders; they are often a key source of change requests, problem statements and requirements that require a solution and they will need to be satisfied that any changes are fit for purpose.

Process workers and application users

Most solutions will struggle to succeed unless the users accept them. They may provide useful requirements that help ensure that any solutions are a good fit for their tasks. They may need to be re-organised and reskilled as part of any holistic solution.

Suppliers

Components of a solution may be procured externally, whether it be software, hardware; or even business or application services. Business functions may be outsourced, but they need to be interfaced with correctly; many application services can be outsourced as cloud services or Software as a Service (SaaS).

Solutions developers

This is a broad definition that includes business and system analysts, designers, programmers and testers. These may be internal, contracted or outsourced resources that will deliver parts of the solution.

ARCHITECTURE MANAGEMENT

Given the wide range of architecture roles and related stakeholders, there are many organisational frameworks to determine where architecture functions are placed within an organisation, including reporting lines.

Architecture planning

Strategic

Enterprise architecture should be a business-as-usual function, constantly helping organisations to manage strategic change. As well as maintaining the EA content, this function should be prioritising and planning tactical change activities, often communicated in the form of a ‘road-map’.

The road-map should show how various streams of change activities will deliver change in the various business segments and domains, particularly where a number of these deliver a tranche of changes, synchronised at a milestone, which represent a significant holistic step change in the enterprise architecture. There will be key business events, such as strategic review cycles, or responses to significant unexpected changes in the environment, to which the EA function will need to respond and update the road-map.

Tactical

Enterprise and solution architects may be involved in a number of projects, such as a programme that delivers a number of changes as outlined in the EA road-map. Where there are a number of separate deliverables to be assembled to deliver a holistic solution, the programme plan can be regarded as a more detailed tactical road-map reflecting inter-project dependencies and synchronisation issues that need to be managed as risks. Day-to-day management of these plans and risks typically falls to programme and project managers, supported by the architects as the governors of the architecture behind these risks.

Other architects, such as domain architects and software architects are also involved in the definition, planning and governance of these changes.

Architecture governance

Governance has been mentioned throughout this chapter. It is a key function of an architect, as it is a crucial part of architecture management. Architecture without governance is like requirements without testing. There is little point in establishing policies, standards and architectures if there is no check that these are being followed and complied with; that is the role of governance.

This chapter began with the ISO 42010 definition of architecture as:

‘The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution’.

Governance therefore needs to oversee all these aspects, particularly through validation and verification of both the final structure and the adherence to principles and other constraints imposed on its development.

Governance therefore requires:

• Something to govern. In the context of architecture, this is mainly the architecture descriptions which define constraints on the outputs and activities of change activities, including:
  • an architecture contract that defines roles, responsibilities and authorities;
  • the target system organisation or structures (components and their relationships) as described at an abstract level in the architecture description;
  • requirements that include applicable legislation, standards, principles and policies should form part of an architecture description.
• Defined governance roles with the authority to govern. Typically, there are levels of governance from corporate, through enterprise architecture to solutions and Specific architecture levels.
• Governance processes. Including:
  • establishing the architecture contract at the outset to outlines roles, responsibilities and authority, including governance roles;
  • defining what will be reviewed through the process (see ‘something to govern’ above), when and by whom;
  • conducting reviews;
  • reporting and acting on the outcomes of the reviews, which may include granting dispensations to those concerned allowing them to vary from the original description for valid reasons;
  • taking action to correct any discrepancies or non-conformities.

REFERENCES

Greefhorst, D. and Proper, E. (2011) Architecture principles: the cornerstone of enterprise architecture. Springer, London and New York.

ISO (2011) ISO/IEC/IEEE 42010:2011 – ‘Systems and software engineering’ – Architecture description. International Standards Organisation.

The Open Group (2011) TOGAF® Version 9.1. Van Haren, Zaltbommel, NL.

FURTHER READING

Buschmann, F., Meunier, R., Rohnert, H., Sommerland, P. and Staf, M. (1996) Pattern-oriented software architecture. Wiley, Chichester.

Fowler, M. (2003) Patterns of enterprise application architecture. Addison-Wesley, Boston, MA.

Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1994) Design patterns: elements of reusable object-oriented software. Addison-Wesley, Boston, MA.

Lankhorst, M., et al. (2009) Enterprise architecture at work: modelling, communication and analysis. Springer, London and New York.

Larman, C. (2005) Applying UML and patterns (3rd edition). Prentice Hall, Indianapolis, IN.

Linthicum, D. S. (2004) Next generation application integration. Addison-Wesley, Boston, MA.

Op’t Land, M., Proper, E., Waage, M., Cloo, J. and Steghuis, C. (2009) Enterprise architecture: creating value by informed governance. Springer, London and New York.