Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

Solution Architecture Foundations
Solution Architecture Foundations
Solution Architecture Foundations
Ebook526 pages6 hours

Solution Architecture Foundations

Rating: 3 out of 5 stars

3/5

()

Read preview

About this ebook

Solution architecture is a relatively new specialism but is at the very heart of the relationship between business and IT. This book is an authoritative and practical introduction, suitable for new entrants to the field but also of benefit to experienced professionals wishing to consolidate their knowledge and skills. The tools and techniques of solution architecture are presented in the context of a framework and life cycle, taking a problem or idea through logical steps to design a holistic and evidence-based solution. There is a focus on collaboration with the business as well as other disciplines such as enterprise architecture, business analysis and cyber security.
LanguageEnglish
Release dateAug 9, 2021
ISBN9781780175676
Solution Architecture Foundations

Related to Solution Architecture Foundations

Related ebooks

Systems Architecture For You

View More

Related articles

Reviews for Solution Architecture Foundations

Rating: 3 out of 5 stars
3/5

2 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    Solution Architecture Foundations - Mark Lovatt

    1INTRODUCTION TO SOLUTION ARCHITECTURE

    This book is a foundation-level introduction to the discipline of solution architecture which uses a holistic approach to analyse problems and design solutions using the best available evidence from all relevant sources.

    LEARNING OUTCOMES

    When you have completed this chapter, you should be able to demonstrate an understanding of the following:

    Key architecture concepts

    Solution architecture as a discipline

    Viewing a business or organisation as a system

    Aligning solutions with business and IT strategy

    Typical activities involved in solution architecture

    The outcomes of solution architecture

    The solution architect’s role

    The components that make up a solution

    The objectives and benefits of taking a solution architecture approach

    1.1 ARCHITECTURE

    An architectural approach to solving problems involves:

    Seeing the ‘big picture’ of the problem, including how it may be solved conceptually.

    Breaking the problem down into components and making models to see how they work together logically to solve the problem.

    Itemising the physical changes that are required to move from problem to solution, possibly in incremental stages.

    This approach is strategic, holistic and progressive and is an alternative to applying tactical ‘quick fixes’ that are short-term and narrowly focused. Even if a tactical solution is required as an urgent response to a factor beyond the control of the organisation, this can be fitted into a schedule that leads to a longer-term solution. The worst outcome is that a short-term fix is put in place that subsequently needs to be undone in order to continue with the strategy. This is wasteful of resources and is likely to delay progress. Having a target architecture means that tactical solutions can be introduced as part of an intermediate architecture that has a defined way forward.

    Anything beyond a limited, local change will benefit from an architectural approach that addresses as much of the organisation and its environment as is needed to solve the problem. Note that problem includes business issues and risks as well as opportunities that might otherwise be missed.

    There exist many different definitions of architecture that describe both the process of architectural design and the essence of that design which must be represented using models and descriptions. Architecture depends on treating businesses, enterprises and solutions as systems with components that interact with each other to exhibit functionality. The following definition is adapted from TOGAF 9.2 (TOGAF 9.2, 2018) and ISO 42010 (ISO/IEC/IEEE 42010:2011, 2011):

    Architecture: the inherent structure and behaviour of a system which may be present as a result of design and/or evolution.

    Structure refers to the components or building blocks from which the system is composed and how they are connected together.

    Behaviour refers to the effects of the operation of the system.

    Design refers to proactive decisions made to improve the business value of a system.

    Evolution refers to the reactive adaptation of a system in response to its use within its operating environment.

    The fact that architecture is inherent means that all systems have an architecture even if it has not been analysed, designed or documented.

    The term architecture may also be used to mean the documentation describing the structure and behaviour of a system. This documentation is more formally known as an architecture description (AD).

    Architecture is also used to mean the discipline or set of activities concerned with the analysis and design of systems and the production of architecture descriptions.

    ISO 42010

    ISO 42010 is a standard that addresses the creation, analysis and sustainment of architectures of systems through the use of architecture descriptions.

    The ISO 42010 standard defines a number of terms:

    Architecture: fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.

    Architecture description: work product used to express an architecture.

    Architecting: process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle.

    The scope of architectural activity (see Figure 1.1) and architecture descriptions may include:

    an enterprise such as a business or government department;

    a specialist domain within an enterprise such as security, business, data, applications, or infrastructure;

    an information system, software system, or a system component;

    a solution to a business problem or opportunity.

    Figure 1.1 Scope of architectural activity

    Models are used extensively in architecture. A model is an abstraction of something more complex. Architecture models are used to represent systems in the real world. Such models may be used to understand the current state of the system and to assess the effect of changes. Abstraction is used to simplify models using generalisation, composition and idealisation.

    Architecture descriptions and models may represent both current and future states to demonstrate the scope and effect of change.

    1.2 SOLUTION ARCHITECTURE

    Solution architecture is a discipline concerned with the production and management of a blueprint for a comprehensive solution, that addresses a business need, problem or opportunity, and integrates with the business, in alignment with its strategy, while minimising negative impacts.

    Blueprint refers to a plan or outline (high-level design and definition of the structure and behaviour) of a solution to be put in place.

    Production and management refer to the dual responsibilities of solution architecture to coordinate the design activities whilst ensuring that changes are tested, validated and agreed at every stage.

    Solutions address business needs, problems or opportunities to improve the operation of a business system by, for example, increasing performance efficiency or reducing risk.

    Negative impacts must be minimised and any that cannot be eliminated must be identified so that their effects can be mitigated.

    On the positive side, solutions must contribute to the success of the business and therefore align with the business strategy.

    What is a solution?

    A solution addresses a problem, risk or opportunity facing a business. Over time many solutions are produced, even if they are not named as such, and once established they become indistinguishable from each other and part of the fabric of the enterprise. Solutions may address newly arising situations or seek improvements to the business by modifying existing provision in a specific area, in other words replacing an existing solution.

    In the modern age, most solutions contain some technology, but it is important to recognise that other elements such as people and information are required to make them work. A solution therefore is holistic, considering all relevant aspects of the situation to find the best possible outcome for the business.

    Solution architecture treats a solution as a system with component parts that interact to produce the required behaviour. The components may be new or existing and may be shared with other solutions. The interactions occur via interfaces between the components where information is exchanged.

    Solution components may be classified into a checklist of five areas – people, organisational structures, processes, information and technology – to ensure they are not overlooked in the design.

    To illustrate the concepts presented here, a case study will be used. The Fallowdale Hospital scenario (as described in the box below) will provide examples throughout this book to support the various aspects of solution architecture as they arise. The main objective in the scenario is to address the problems associated with the way the hospital communicates with patients.

    Fallowdale Hospital case study

    Fallowdale District Hospital is a general hospital providing a range of healthcare services to the medium-sized town of the same name and its surrounding district.

    The majority of patients are referred to the hospital by a doctor, such as a general practitioner (GP) in their local surgery or health centre. Patients are then invited to attend for an appointment with a health professional, such as a specialist doctor, nurse or therapist, or for a diagnostic test or scan. Patients can also attend without an appointment at the emergency department and some other walk-in services.

    The hospital currently communicates with all patients by letter to offer or confirm appointments and to provide results of tests and other outcomes of attendance. Letters are also sent when the patient or hospital cancels or reschedules an appointment.

    A number of issues with patient communication have been identified:

    High cost of sending letters.

    High rate of non-attendance at appointments.

    Confidentiality risks of using the postal system.

    Three separate business problems have been identified, although they may be related, and the hospital can therefore benefit from taking an architectural approach to addressing them. Some of the key aspects are:

    Problem statement: focused on a single issue (communicating with patients), the business problems are cost, missed appointments and confidentiality.

    Blueprint: the action plan for achieving the improvement they are seeking in patient communications.

    Side effects: imperative that the solution has zero negative impact elsewhere in the hospital.

    Strategy: the solution must support and ideally enhance the business and IT strategy.

    1.3 THREE LEVELS OF A BUSINESS OR ORGANISATION

    A business or any other organisation can be viewed as a system and modelled at three levels: business system, information system and IT system (see Figure 1.2).

    Figure 1.2 Three levels of a business system

    A business system is an organisation (or organisational unit) treated as a system with its own internal structure and behaviour, typically presenting services through external interfaces to customers and partner organisations.

    Note the word ‘business’ in this context does not imply a commercial organisation but applies to any organisation or enterprise, representing what it does to achieve its aims and objectives.

    An information system is a hybrid of human-managed processes and computer systems that manages business information. It may incorporate a range of information technology systems as well as manual activities within the context of a business system.

    An IT system is typically a combination of hardware and software that is often used by an organisation to handle data and information within the context of an information system.

    Fallowdale Hospital business system

    The hospital operates a business system to enable patient referrals from GPs. This is offered as a business service to GP surgeries and local health authorities.

    The referral system is based around an information system where many pieces of data and information are exchanged between people and sometimes with a computer system. Many exchanges are largely verbal, such as the initial assessment by the GP and appointments between specialists and the patient. Some information is recorded and transmitted on paper.

    Parts of the referral system involve an IT system. These include the transmission of referral requests from the GP to the hospital, the schedule of hospital appointments and the healthcare professionals involved, and a record of any diagnoses, prescriptions and ongoing management of patient care.

    Solution architecture is concerned with solutions that represent business systems that include within them information systems and IT systems. Some solutions have as their focus a new or modified information or IT system, but it is extremely rare for there to be no wider business involvement or impact.

    1.4 ALIGNING SOLUTIONS WITH BUSINESS AND IT STRATEGY

    Solution architecture must be aligned with business and IT strategy. VMOST analysis (Sondhi, 1999) is a technique for strategic planning that can be used to define strategies, refine strategic ideas and promote a consistent approach at multiple levels within the business (see Figure 1.3). There are many variations of VMOST, including a simplified version that does not include vision as a separate entity, called MOST (Cadle and Paul, 2021). VMOST is the most widely used of these techniques.

    Figure 1.3 VMOST analysis

    1.4.1 Vision

    This represents the ideal future situation. Vision can be at multiple levels. There can be an overall vision for the organisation or enterprise and separate ones for specific business areas. There is often a vision for a problem area that can become the vision for a solution. A vision does not have to be achievable, or at least it does not have to be clear how it can be achieved. The vision just needs to be something that everyone can agree is how they would like things to be.

    For example, part of the vision of a supermarket company might be that people are excited to shop there. This gives everyone a mental picture, and this is often the basis for the carefully selected images that are presented in advertisements.

    The vision is closely linked to the mission, but will change as the organisation makes progress and the environment in which it operates changes.

    Fallowdale Hospital vision

    The board of the hospital has identified the following vision which it hopes will become reality within the next five years:

    ‘We treat every person as an individual and provide the very best service available, tailored to the individual.’

    1.4.2 Mission

    This is the enduring concept behind the organisation. In a fast-changing world, even the mission may change but, if this happens, it probably indicates that something fundamental has changed about the organisation.

    An organisation whose mission has probably not changed since its founding is the World Wildlife Fund. The current stated mission is ‘to create a world where people and wildlife can thrive together’ (World Wildlife Fund, 2021). This clarifies the point that humanity exists as part of nature and individual species cannot be conserved in isolation from the rest of the environment.

    Fallowdale Hospital mission

    ‘To improve the health of our patients and communities through delivering the best in clinical care, research, innovation and education.’

    1.4.3 Objective

    This is a target that must be met to achieve the vision and mission.

    Multiple objectives are usually needed for any significant change, such as the implementation of a new solution, and their achievement marks the progression towards change.

    A useful checklist for objectives is SMART. A SMART objective must be Specific, Measurable, Actionable, Realistic and Time-bound (Doran, 1981).

    Specific: to the organisation and situation so stakeholders can understand it and determine when it has been achieved.

    Measurable: so stakeholders definitively know whether it has been met (or partially met); sometimes expressed using key performance indicators (KPIs) and critical success factors (CSFs).

    Actionable: alternatives such as attainable or achievable overlap with realistic, so actionable is preferred as the organisation must believe that action can achieve the outcome.

    Realistic: otherwise no one will take it seriously. Judgement can be based on past experience or modelling the future to assess the proposed actions.

    Time-bound: internal or external deadlines or the dependency of another piece of work may constrain its achievement, or a purely project-based time limit may be imposed.

    Fallowdale Hospital objectives

    Two of the key objectives that have been identified as necessary to the achievement of the vision are:

    Hospital staff must have access to all relevant information about the patient or service user at the time when it is needed to provide care. Each type of care offered must have a specification of what information is required by each party, including the patient, and when it is needed in the episode of care. A specification must be in place before care can be offered and must be reviewed at least annually.

    Patients must have access to relevant information in sufficient time before receiving care. Delivery of information from the hospital must be guaranteed with acknowledgement by the patient if required in the specification.

    Activity 1.1

    An internet service provider is looking for a solution to providing help and assistance to existing and new clients. The company is fairly successful, but it has a mixed reputation for customer service. No decision has been made as to what type of solution it will choose. It is a public company with shareholders and is listed on the stock exchange.

    Create a SMART objective for the proposed solution based on the business problem identified.

    1.4.4 Strategy

    Strategy describes what an organisation or individual intends to do to achieve its objectives.

    Strategy: detailed plan for achieving success in situations such as war, politics, business, industry, or sport, or the skill of planning for such situations.

    (Cambridge Dictionary, 2021)

    An organisation may have multiple strategies at different levels. At the top level are those for business and IT that apply to the entire organisation or enterprise. At lower levels, there may be sub-strategies that apply to parts of the business such as divisions and departments and initiatives such as geographical expansion.

    Strategic decisions must be recorded and communicated to relevant stakeholders within the organisation whilst acknowledging that parts of the strategy may be confidential.

    Each strategy should be consistent with itself and other strategies. To be consistent here means that there is no conflict between strategies; even if they are trying to achieve different things, they should not work against each other.

    Strategies must aim to support the organisation’s mission and vision and achieve its stated objectives. These are the measures by which the success of a strategy can be measured.

    Strategies can change, especially if they are not succeeding, but also if circumstances change. All strategies should be reviewed regularly and strategic decisions communicated to all relevant stakeholders.

    Fallowdale Hospital strategy

    The main strategic decision that the board has agreed on is to dramatically improve communication between the hospital and those who use its services. On reflection, it was agreed that the provision of care is also dependent on efficient and effective communication between those providing the care.

    The business aspects of this strategy are to:

    communicate in a consistent way, irrespective of source or destination;

    focus on communication that is relevant to the provision of care.

    The technological aspects of this strategy are to:

    automate communication wherever appropriate;

    use existing systems and devices if possible;

    use communication technologies that are appropriate and compatible with their users.

    1.4.5 Tactics

    A tactic is an action that has been identified as an appropriate way to achieve one or more strategic outcomes. Each tactic only addresses part of a strategy and therefore multiple individual tactical actions are required to achieve all the strategic aims.

    Since tactics are smaller units of work, they each involve less effort, money and time than the strategy they support. This means it is easier to modify or abandon a tactic if it is judged to be ineffective. However, tactical changes can have side effects and so it is critical to assess the impact of all changes to the approach being taken.

    Fallowdale Hospital tactics

    The tactics that have been suggested so far are shown in the following table:

    1.5 TYPICAL ACTIVITIES INVOLVED IN SOLUTION ARCHITECTURE

    A considerable amount of work is required to achieve a successful solution, which typically starts very simply with an idea of how things could be better and must then be developed into a business change that can be put in place.

    This work is carried out or governed by various people in the business, collectively known as stakeholders.

    Stakeholder: ISO 42010 defines stakeholder as an ‘individual, team, organisation, or classes thereof, having an interest in a system’.

    (ISO/IEC/IEEE 42010:2011, 2011)

    At the centre of these activities is the solution architecture function, typically led by a solution architect. Complex solutions may be broken down into smaller units, with each one being led by a solution architect and the overall solution coordinated by a senior solution architect.

    The activities include:

    organising the process;

    interacting with stakeholders;

    building models;

    analysing the problem and recommending solution options;

    advising the business about the solution;

    governing the delivery.

    1.5.1 Organising the process

    The solution architecture function has some responsibilities that overlap with those of a project manager. In fact, the solution architecture process or life cycle is very much like a project or programme in that it has defined objectives and is composed of tasks and dependencies and is subject to the constraints of time, scope and resources. The difference is that solution architecture is concerned with designing and elaborating a solution, whereas project or programme management, in this context, is concerned with delivering the solution that has already been designed.

    There is nothing to stop the solution architecture function from using the facilities provided by a programme management office (PMO) to organise meetings and manage communication, but all the activities are under the control of solution architecture.

    An important aspect of organisation is managing timescales. This includes:

    Estimating and setting the duration of phases; for example, the sign-off by the business to start the solution architecture process is based on an estimate of the time and resources that will be required to complete the discovery phase.

    Agreeing dates and sequences of events, such as meetings, deliverables and who will review them.

    Handling any delays, for example to the production of artefacts.

    Another aspect that requires a degree of control is the scope of the solution and of the architecture work required to deliver its design. Controlling scope is made easier if the problem or opportunity being addressed by the solution is clearly defined.

    1.5.2 Interacting with other stakeholders

    Each individual stakeholder must by definition have an interest in or concern with the solution. Stakeholders as a group must represent the business through the specification, design and delivery of the solution. Solution architecture is responsible for ensuring that the correct stakeholders have been identified. If the stakeholders are not fully representative of the business, there is a risk that the solution will not be fit for purpose. This could be because not all business needs were identified, or that there is a negative impact on business services in an unrepresented part of the business.

    Solution architecture is also responsible for facilitating appropriate communication with and between stakeholders. Stakeholder communication is required for the following purposes:

    Information: important for transparency and keeping everyone aware of developments; usually one-way, but can result in requests for clarification and requests for closer involvement.

    Consultation: captures business expertise relating to the solution and allows the best-placed stakeholders to make fully informed decisions; this is two-way and proper records are essential for traceability.

    Accountability: records the approval of decisions and actions by specific stakeholders and may depend on authenticated and verifiable signatures.

    Responsibility: allocates and tracks tasks that are given to individuals and teams to manage and complete, including constraints and deadlines; interaction may be between stakeholders rather than via solution architecture.

    These types of communication are part of the RACI model (Jacka and Keller, 2009), which is often represented as a matrix as a way of organising stakeholders and activities (see Figure 1.4).

    A RACI matrix has rows representing activities and columns representing roles. The cell at the intersections of a row and a column is used to indicate the type of involvement of the role in the activity. An ‘R’ is used where the role is responsible for performing the activity. An ‘A’ indicates accountability for the success of the activity and is nearly always assigned to a single role. ‘C’ indicates that the role is consulted during the activity and ‘I’ means roles are informed of its progress and outcome.

    Figure 1.4 RACI matrix

    A RACI matrix is useful for summarising the involvement of stakeholders and others involved in architecture or project work. It also acts as a checklist to ensure all roles have been included. If no role has been made responsible for an activity, for example, it is unlikely to happen. If no role is to be consulted then it must be true that the responsible role has all the necessary information to perform the activity, and so on.

    A good way to structure communication with stakeholders is to create a design authority (DA) for the solution. A design authority ensures the solution is aligned with the business by making decisions in accordance with its terms of reference as well as facilitating discussion and promoting understanding among stakeholders.

    Design authorities are given responsibility for completing specific tasks and contribute to the overall governance of the design process.

    Governance of solution architecture

    For any type of organisational change, including designing and implementing a solution, governance means controlling activity and decision making to ensure that the change delivered matches the specification agreed with the business. The control required is achieved through the use of processes and organisational structures that provide a framework of authority and accountability within which the change can be delivered.

    For solution architecture, the business is represented by stakeholders who agree the specification for the solution and are also involved in the governance of its delivery.

    Governance must include assuring that products that are delivered match the specification but also account for the fact that the specification may need to be refined or altered during the delivery of the solution. This could be to fill in details that were not originally specified or because of changed circumstances in the business.

    A key stakeholder role for solution architecture

    Enjoying the preview?
    Page 1 of 1