Solution Architecture Foundations
By Mark Lovatt
3/5
()
About this ebook
Related to Solution Architecture Foundations
Related ebooks
Enterprise Solution Architecture - Strategy Guide: A Roadmap to Transform, Migrate, and Redefine Your Enterprise Infrastructure along with Processes, Tools, and Execution Plans Rating: 0 out of 5 stars0 ratingsIT Architect Series: Foundation In the Art of Infrastructure Design: A Practical Guide for IT Architects Rating: 0 out of 5 stars0 ratingsDeveloping Information Systems: Practical guidance for IT professionals Rating: 0 out of 5 stars0 ratingsA Practical Guide for IoT Solution Architects Rating: 5 out of 5 stars5/5Software Engineering: Architecture-driven Software Development Rating: 4 out of 5 stars4/5Principles of Data Management: Facilitating information sharing Rating: 0 out of 5 stars0 ratingsIT Service Management: Support for your ITSM Foundation exam Rating: 5 out of 5 stars5/5Architecting Big Data & Analytics Solutions - Integrated with IoT & Cloud Rating: 5 out of 5 stars5/5The Human Touch: Personal skills for professional success Rating: 0 out of 5 stars0 ratingsPractical Data Migration Rating: 4 out of 5 stars4/5Integration Architecture Rating: 5 out of 5 stars5/5Modeling Enterprise Architecture with TOGAF: A Practical Guide Using UML and BPMN Rating: 5 out of 5 stars5/5Enterprise Architecture Tools Third Edition Rating: 0 out of 5 stars0 ratingsThe People Problem: A Primer on Architecting the Enterprise as an Enterprise Architect Rating: 0 out of 5 stars0 ratingsMastering Non-Functional Requirements Rating: 5 out of 5 stars5/5A Modern Enterprise Architecture Approach: Enterprise Architecture Rating: 4 out of 5 stars4/5Agile Software Architecture: Aligning Agile Processes and Software Architectures Rating: 4 out of 5 stars4/5The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment Rating: 4 out of 5 stars4/5An Introduction to Enterprise Architecture: Third Edition Rating: 5 out of 5 stars5/5Enterprise Architecture: A Pocket Guide Rating: 4 out of 5 stars4/5Agile Business Architecture for Digital Transformation Rating: 5 out of 5 stars5/5Cracking the IT Architect Interview Rating: 5 out of 5 stars5/5Enterprise Architect’s Handbook: A Blueprint to Design and Outperform Enterprise-level IT Strategy (English Edition) Rating: 0 out of 5 stars0 ratingsDefining Enterprise: A Systems View of Capability Management Rating: 3 out of 5 stars3/5Enterprise Architecture Complete Self-Assessment Guide Rating: 0 out of 5 stars0 ratingsPragmatic Enterprise Architecture: Strategies to Transform Information Systems in the Era of Big Data Rating: 0 out of 5 stars0 ratingsArchitecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children Rating: 0 out of 5 stars0 ratingsSolution Architecture Complete Self-Assessment Guide Rating: 0 out of 5 stars0 ratingsCollaborative Enterprise Architecture: Enriching EA with Lean, Agile, and Enterprise 2.0 practices Rating: 4 out of 5 stars4/5Architecting High Performing, Scalable and Available Enterprise Web Applications Rating: 5 out of 5 stars5/5
Systems Architecture For You
Computer Science: A Concise Introduction Rating: 4 out of 5 stars4/5Top-Down Digital VLSI Design: From Architectures to Gate-Level Circuits and FPGAs Rating: 0 out of 5 stars0 ratingsEngineering a Compiler Rating: 0 out of 5 stars0 ratings.NET Core in Action Rating: 0 out of 5 stars0 ratingsAdvanced API Security: OAuth 2.0 and Beyond Rating: 0 out of 5 stars0 ratingsVirtual Boy Architecture: Architecture of Consoles: A Practical Analysis, #17 Rating: 0 out of 5 stars0 ratingsPlayStation 2 Architecture: Architecture of Consoles: A Practical Analysis, #12 Rating: 0 out of 5 stars0 ratingsCompTIA ITF+ CertMike: Prepare. Practice. Pass the Test! Get Certified!: Exam FC0-U61 Rating: 0 out of 5 stars0 ratingsArduino Projects For Dummies Rating: 3 out of 5 stars3/5Modeling Enterprise Architecture with TOGAF: A Practical Guide Using UML and BPMN Rating: 5 out of 5 stars5/5The IT Support Handbook: A How-To Guide to Providing Effective Help and Support to IT Users Rating: 0 out of 5 stars0 ratings"AI Innovations: How Technology is Pushing the Boundaries" Understanding and Using Artificial Intelligence: An AI Book Rating: 0 out of 5 stars0 ratingsWii Architecture: Architecture of Consoles: A Practical Analysis, #11 Rating: 0 out of 5 stars0 ratingsCompTIA A+ CertMike: Prepare. Practice. Pass the Test! Get Certified!: Core 1 Exam 220-1101 Rating: 0 out of 5 stars0 ratingsBlockchain Basics: A Non-Technical Introduction in 25 Steps Rating: 5 out of 5 stars5/5AutoCAD 2023 : Beginners And Intermediate user Guide Rating: 0 out of 5 stars0 ratingsRaspberry Pi Projects For Dummies Rating: 5 out of 5 stars5/5Software Architecture with Python Rating: 0 out of 5 stars0 ratingsPSP Architecture: Architecture of Consoles: A Practical Analysis, #18 Rating: 0 out of 5 stars0 ratingsDevOps for Web Development Rating: 0 out of 5 stars0 ratingsCompTIA Network+ CertMike: Prepare. Practice. Pass the Test! Get Certified!: Exam N10-008 Rating: 0 out of 5 stars0 ratingsEmbedded Hardware: Know It All Rating: 5 out of 5 stars5/5The Tao of Microservices Rating: 0 out of 5 stars0 ratingsHaskell Design Patterns Rating: 0 out of 5 stars0 ratingsFault-Tolerant Systems Rating: 0 out of 5 stars0 ratingsMastering Kubernetes Rating: 5 out of 5 stars5/5Spring Batch in Action Rating: 0 out of 5 stars0 ratings
Reviews for Solution Architecture Foundations
2 ratings0 reviews
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