Fundamentals of IT architecture 9789176972458
The bestseller in IT architecture. If you want to understand IT architecture, this book is for you. It covers many diffe
122 4 131MB
English Pages 292 [294] Year 2021
Polecaj historie
![The Fundamentals of Landscape Architecture [2 ed.]
1472531442, 9781472531445](https://dokumen.pub/img/200x200/the-fundamentals-of-landscape-architecture-2nbsped-1472531442-9781472531445.jpg)
![The Fundamentals of Landscape Architecture [2 ed.]
1472531442, 9781472531445](https://dokumen.pub/img/200x200/the-fundamentals-of-landscape-architecture-2nbsped-1472531442-9781472531445-e-3587062.jpg)
![The Fundamentals of Landscape Architecture [2 ed.]
1472531442, 9781472531445](https://dokumen.pub/img/200x200/the-fundamentals-of-landscape-architecture-2nbsped-1472531442-9781472531445-n-6924865.jpg)
![Fundamentals of Software Architecture: An Engineering Approach [1 ed.]
1492043451, 9781492043454](https://dokumen.pub/img/200x200/fundamentals-of-software-architecture-an-engineering-approach-1nbsped-1492043451-9781492043454-p-6314240.jpg)
![Fundamentals of Software Architecture: An Engineering Approach [1 ed.]
1492043451, 9781492043454](https://dokumen.pub/img/200x200/fundamentals-of-software-architecture-an-engineering-approach-1nbsped-1492043451-9781492043454.jpg)
![Fundamentals of Computer Architecture and Design [2nd ed.]
978-3-030-00222-0](https://dokumen.pub/img/200x200/fundamentals-of-computer-architecture-and-design-2ndnbsped-978-3-030-00222-0.jpg)
Citation preview
Fundamentals o
ch tecture Daniel Akenine Jörgen Dahlberg Eva Kammerfors Sven-Häkan Olsson Robert Folkesson
FUNDAMENTALS OF IT ARCHITECTURE
Fundamentals of
IT Architecture Daniel Akenine Jörgen Dahlberg Eva Kammerfors Sven-Häkan Olsson Robert Folkesson
Fundamentals of IT Architecture Copyright © Daniel Akenine, Jörgen Dahlberg, Eva Kammerfors, Sven-Håkan Olsson, Robert Folkesson, 2021 www.thearchitectbook.com Design: Cecilia Pettersson, Pica Pica design, www.picapicadesign.se Published by Kunskapshuset Förlag, Helsingborg, Sweden, 2021 www.kunskapshusetforlag.se Kunskapshuset Förlag (The Knowledge Publishers International) is part of Hoi Publishing. Printed and bound in Bosnia and Herzegovina by GPS Group, 2021 ISBN 978-91-7697-245-8 MIX NO
FSC
Paper from responsible sources
FSC• C118234
1.
Introduction
12
1.1.
Introduction to IT Architecture
12
1.2.
IT Architecture Example: Anna and Mix
13
1.21.
Anna's Challenge
13
1.2.2.
IT Architect Roles
15
1.3
Five Roles and Functions of Enterprise Architecture
1.4
A Word Before You Start
2.
Enterprise Architecture (EA)
2.1.
Enterprise Architecture (EA) and the Organization
Management of Significant Business Events
30
2.4.1
Examples of Significant Business Events
30
2.4.2.
Acquisitions
31
2.4.3.
New Business Venture
31
2.4.4.
New System
31
2.4.5.
Crisis-driven Savings
2.4.6.
Success
2.5
Collaboration Between Different Architectural Roles
2.4
Contents
16
2.6
How to Anchor an Architecture
2.6.1.
Two Types of Anchoring
2.6.2.
Anchoring with Decision-makers
2.6.3.
32 32
33 38 38 38
Anchoring with Directly Concerned Stakeholders
40
2.6.4.
Summary of Anchoring
40
2.7
Architecture Governance
41
17
18
Factors
2.7.1.
Governing Architectural Principles
41
2.7.2.
Designing Architectural Principles
41
2.7.3.
Establishment and Legitimacy
43
2.7.4.
Documentation and Description
43
2.7.5.
Examples of Architectural Principles
44
2.8
City Planning
45
2.8.1.
46 47
2.1.2.
About Enterprise Architecture (EA)
18 18 19
2.1.3.
Abstraction Models
20
2.1.4.
Perspective Models
21
2.8.2.
Organic Growth, Silos and Fragmentation Contract Between Business and IT
2.2.
EA Function
22
2.8.3.
Benefit and Value
Responsibilities of the EA Function
22
2.8.4.
Design of the City Plan
48
2.2.1.
Architectural Rules of Thumb
50
2.1.1.
An Organization's Ability
45
2.2.2.
IT Strategy
22
2.8.5.
2.2.3.
Architectural Development
22
2.9
Target Architecture
51
2.2.4.
Information Management (IM)
23
2.9.1.
Design of Target Architecture
52
2.2.5.
IT Portfolio Planning
23
2.9.2.
Description Mode
53
2.2.6.
Architecture Governance
24
2.9.3.
Reference Architecture
53
2.2.7.
Architecture Capability
24
2.9.4.
How Is the Target Architecture Used?
54
2.3.
Strategy and Strategy Work
25
2.9.5.
Management of Target Architecture
54
2.3.1.
EA and the Organization's Strategies
25
2.10
2.3.2.
About Strategies
26
Architecture Governance / Governance
55
2.3.3.
Strategy Elements
26
2.10.1.
Adaptation of Architecture
55
2.3.4.
Strategy Foundation
26
210.2
Communicate the Architecture
56
2.3.5.
Strategy Objectives
27
2.10.3.
Controlling Change
56
2.3.6.
Governing Principles
28
2.10.4. Drive Change
2.3.7.
Strategy Document
29
2.10.5
Architectural Documentation
57
2.3.8.
Daily Work Strategy
29
2.10.6.
Architecture Council
57
57
CONTENTS
2.11
Architecture Evaluations
60
2.11.1.
Benefits
60
2.11.2.
How Is Architecture Evaluated?
60
2.11.3.
Evaluation Results
61
2.12. Requirements and organization 2.12.1.
Mission, Vision and Goals
62
3.1.3.
3.2.
Non-profit Organizations Also Have Business Models
91
What is Business Architecture?
92
3.3
Why Business Architecture?
93
3.3.1.
Benefits of Business Architecture
94
3.4.
Business Architecture Modeling
95
62
2.13. Requirements Management
64
2.14. EA Work in Practice
65
3.5.
Designing the Business Logic Architecture
100
Business Model Canvas
100
2.14.1.
Architecture Processes
2.15
Communication, Decision and
3.5.2.
Goal Models
102
Anchoring
69
3.5.3.
Stakeholder Models
103
69
3.5.4.
End Customer Perspective
105
2.15.1.
Why Communicate the EA?
65
3.5.1.
2.15.2.
Don't Keep the Architecture a Secret
69
2.15.3.
Before Work Begins
70
2.15.4.
During the Work
70
3.6.1.
Processes and Value Chain Perspective
107
2.15.5.
Participation
71
3162.
Information Perspective
110
2.15.6.
Decisions and Anchoring
71
3.6.3.
Business Capability Perspective
113
3.6.4.
Systems Perspective
116
3.6.5.
Other Perspectives of Business
2.16. Methods, Standards and Tools 2.16.1.
72
You Can Put the World Together with a Hammer and a Nail
72
2.16.2.
TOGAF
73
2.16.3.
Zachman's Framework
76
2.16.4.
Department of Defense Architecture
2.16.5.
3.6.
Operations 3.7. 3.7.1.
Framework (DoDAF)
78
Federal Enterprise Architecture (FEA)
79
Designing the Business Operations Architecture
3.8.
106
116
Practical Advice for Business Architecture Modeling
118
Visualize for Accessible Overviews
118
Standards and Patterns for Business Architecture
121
2.16.6.
Method of Methods
79
2.16.7.
Agile Mindset as Part of the Method
80
3.8.1.
Different Standards and Reference Models 121
81
3.8.2.
How to Use Standards
3.8.3.
Guidelines for Working with
2.16.8.
AgileEA
2.16.9.
Standards in EA
81
2.16.10.
Notations
83
2.16.11.
UML
2.16.12.
83 Business Process Model and Notation (BPMN) 84
2.16.13.
ArchiMate
85
2.16.14.
EA Tool Support
86
Standards
123
3.8.4.
Risks of Using General Standards
123
3.9.
Business Architecture Work in Practice 124
3.9.1.
Formulate Strategic Business Architecture Requirements
3.10. Work Collaboratively
3.
Business Architecture
88
3.1.
Understanding the Business
88
3.1.1.
A Business Model Defines Boundaries
90
3.1.2.
Operational Structures Realize the Business Model
91
122
3.10.1.
Deliver Often
3.10.2.
Focus on What's Most Important Right Now
124 124 125 126
3.10.3.
Business Architecture Working as a Dialogue -
3.10.4.
Let the Insight Grow — Don't Force
Ask Questions and Listen to Answers Decisions too quickly
126 127
7
8
Establish a Culture of Change
127
3.11. Business-driven IT Development IT Requirements Management Based on Business Architecture 3.11.2. Business Requirements
128
3 10.5
3.11.1.
Management 3.12. Who Owns the Business Architecture? 3.12. 1_ Importance of Business Ownership
129
132 132
134
3.14. Business Architecture and Management Systems
134
3.16. Current State to Future State 3.16.1. Transition Plan 3.16.2. Implementing Change and Making
135 137 138 138
141 142
4.
Solution Architecture
4.1.
Introduction
144
4.2.
Creating a Solution Methodology
147 148
Integration for Solutions Integration Agreements Integration Pattern Aspects
149 149 152
4.3.1. 4.3.2.
4.4. Typical Integration Types for Solutions Traditional Integration Flows 4.4.1. 4.4.2. Service-Oriented Architecture (SOA) Event-driven Integration 4.4.3.
168 169 169
167
4.6 4.6.1 4.6.2.
Choosing Platforms for Solutions Frameworks and Building Blocks Integration Platform (hub)
170 173 174
4.7. Infrastructure
178
4.8. Cybersecurity I nformation Protection for Information 4.8.1.
179
4.8.2.
4.8.3.
at Rest Information Protection for Information in Motion Information Protection while Computing
182 183 184 185 189
4.8.5.
Technical Availability Identity Management
5.
Software Architecture
192
5.1. Introduction What Is Software Architecture? 5.1.1. Coping with Change 5.1.2. Role of the Software Architect 5.1.3.
192 192 192 193
5.2. Software and Quality Quality Attributes 5.2.1. Usability and Aesthetics 5.2.2. Internationalization, Localization and 5.2.3.
193 194 194
139 140
3.16.3.
4.3.
4.5. Manageability and Integrations 4.5.1. Manageability Solution Robustness 4.5.2.
4.8.4.
139
Visible Progress Retrospective
4.2.1.
160 162 163 166
130
3.13. How to Communicate the Business Architecture
3.15 Business Architecture as a Platform for Innovation 3.15.1. Fail Fast 3.15.2. Innovation Readiness Assessment 3.15.3. Balanced Risk 3.15.4. Challenges with Business Architecture and Innovation
REST Orientation API Orientation 4.4.5. 4.4.6. Microservices Integration loT Integration 4.4.7. 4.4.8. Integration with Backup/Restore for Asynchronous Solutions 4.4.4.
144
5.2.4. 5.2.5. 5.2.6. 5.2.7.
155 155 157 158
5.2.8. 5.2.9. 5.2.10. 5.2.11.
195 Globalization 197 Robustness/Complexity 199 Productivity 200 Technical Flexibility Reliable Mean Time Between Failures (MTBF) 201 203 Customization 204 Administration 206 Vitality 207 Performance and Scalability
CONTENTS
5.2.12.
Load
209
5.6.10.
Refactoring the Specification
5.2.13
Capacity
211
5.6.11.
Automate the Specification Without
5.2.14.
Bandwidth and Network Access
212
5.2.15.
Scalability
216
5.3.
Security and Software Development
5.4.
Agility and Lean in Software Architecture
5.4.1.
Basics of Agile
219
220 220
5.4.2.
Lean
222
5.4.3.
Agile Methods
223
5.4.4.
Scrum
224
Changing It
249 250
5.6.12.
Live Documentation
252
5.6.13.
Where Do You Start?
253
5.6.14.
Where Next?
254
5.7.
Domain-driven Design (DDD)
253
5.7.1.
Focuses on the Core Domain
254
5.7.2.
Explore Models in Creative Collaboration Between Domain Practitioners and
5.7.3.
Software Practitioners
255
Focus on Language
255
5.4.5.
Extreme Programming (XP)
225
5.4.6.
Kan ban
225
5.4.7.
How Is Everything Related?
226
Better Cooperation for Delivering
5.4.8.
Building an Agile Architecture
227
Software
256
5.5.
Techniques for Refining and
5.9.
Developing for the Cloud Asynchronous Processing and
259
5.9.1.
Queue-based Message Handling
259
Developing Software Architecture
232
5.5.1.
Iterative and Incremental Work
232
5.5.2.
Incremental Development
233
5.5.3.
Iterative Work
234
5.5.4.
Prototypes and Spikes
5.5.5.
Set-based Development: Combining
5.5.6.
234
Several Prototypes
234
Constant Code Change: Refactoring
235
5.8.
DevOps: Cultural Shift Towards
5.9.2.
Data Management and Partitioning for Scale Separating Writes and Reads into
260
5.9.3.
Commands and Queries with CQRS
262
5.9.4.
Handling User Authentication Across Service Boundaries
263
5.9.5.
Container-based Deployment
265
5.5.7.
Introducing Agility into an Organization
235
5.5.8.
Testable Architecture
236
5.10. Software Development and Al
5.5.9.
Different Purposes of Testing
236
5.10.1.
Data Science Process
267
5.5.10.
Requirements for the Testability Architecture 238 Impact of Architecture on the Organization
5.10.2.
DevOps for Al and ML
267
5.10.3.
Integrating with Prepackaged
5.5.11.
or Vice Versa? 5.5.12.
Role of the Architect in an Agile Organization
5.6.
239 240
Al Services 5.11. Patterns in Software Architecture
265
268 269
5.11.1
Patterns, Pattern Languages and Pattern Families
270
5.11.2.
Patterns in Software Architecture
271
Software Development Methods and Practices
241
5.6.1.
Test-driven Development (TDD)
241
5.11.3.
Architecture Styles and Patterns
273
5.6.2.
TDD Process
242
5.11.4.
Design Patterns
274
5.6.3.
Why TDD?
243
5.11.5.
Implementation Patterns
275
5.6.4.
Effect of TDD on the Architecture
244
5.11.6.
How Do We Use Patterns?
276
5.6.5.
Specification by Example
244
5.11.7.
Good Patterns
277
5.6.6.
Specify Together
245
5.11.8.
Describing Patterns
278
5.6.7.
Specify with Example
246
5.11.9.
Risks of Using Patterns
279
5.6.8.
What are the Key Examples?
247
5.11.10.
Conclusion on Patterns
280
5.6.9.
Holding a Specification Workshop
248
9
10
6. Recognitions and use cases 282 6.1. Centiro - use case
282
6.2. Skill-IT - use case
284
6.3. Waymark Solutions AB - use case
286
7. About the writers
288
8. References
290
CONTENTS
11
Introduction
1.1. Introduction to IT Architecture Instead of starting with a simple question, let's begin with a difficult one: What is IT architecture? This may seem like something that should be obvious, especially for a book about IT architecture. Nevertheless, the definition of IT architecture is something that has been debated for many years and can be seen from several different perspectives. Although definitions are sometimes unclear, it is clear that to create IT architectures, you need IT architects. But what is such a role? What tools and methods help an IT architect build an IT architecture? The purpose of this book is to help you as an IT architect gain a better picture of how IT architecture works and where you can contribute the most with knowledge. The book aims to give you an overview of modern methods in IT architecture and the different parts, specializations and tools that are available today. To define IT architecture, it helps to break it down into two questions: What is IT? What is architecture? The idea of architecture has been around for a long time: about 2,000 years ago, the Roman architect Vitruvius defined the concept as a balance between beauty, durability and function. During the 2,000 years since the fall of the Roman Empire, new concepts have been added such as sustainability issues, but the core remains. It is about creating a balance between values. The term IT (information technology) includes both hardware such as
INTRODUCTION
smartphones, computers and networks, as well as software such as operating systems, apps and servers. If you combine these concepts, you realize that IT architecture, at its core, is about the art of balancing different types of values for the business (business value, cost, performance, agility) with the help of IT. You could summarize it like this: "IT architecture is the art of creating a balance between important values for the organization with the help of IT." This means that to create an IT architecture, an IT architect must be knowledgeable about these "important values" for the organization. Of course, this also means an IT architect needs to understand IT and technology. In the same way that a building architect must understand and balance values such as design, sustainability and function, he or she must understand the limitations and possibilities of the building material to succeed in creating an experience that works optimally.
1.2. IT Architecture Example: Anna and Mix 1.2.1.
Anna's Challenge
Let us exemplify how IT architecture can help a modern company today. Anna was sitting in the car on the way home from a meeting with the management team and thought about what they had just discussed. She saw the challenges. The company, Mix, for which she was the Chief Information Officer (CIO), consisted of 6,000 employees in ten countries and worked in the insurance industry. Over the past year, they had faced fierce new competitors and as a result, Mix had decided to make several strategic acquisitions and remove parts of their own business that were based on an older business model, a business model that although innovative a few years ago, was no longer competitive. Anna understood that during the next 12 months, the company would ask her to ensure that the company's existing processes and information could continue to function after the reorganization and that she would, at the same time, be responsible for integrating all the information, technology and processes that came from the companies Mix would acquire. She wondered if the rest of the management really understood how complex this would be. Let's press pause and reflect on Anna's situation. During the four years Anna had worked as the CIO at Mix, she had focused on creating a new IT architecture function and organization. Within the IT organization, she had a chief architect reporting to her, who in turn led a team that worked with enterprise architecture. There was also a central function of solution and business architects that often was loaned out to various projects within the
IT architecture is the art of creating a balance between important values for the organization with the help of IT."
13
14
company, as well as software architects with responsibility for implementing new software. At the time Anna joined the company, Mix had significant problems with its IT capabilities. The company was founded in 1979 and many of its core systems were built using Cobol on older mainframe computers. Over the next 30 years, they created hundreds of integrations and support systems based on new customer requirements and a changing world.
11 The data center eventually went by the nickname `The Zoo'."
Each new project designed its own systems and used the technology platforms that were modern at each project start. The data center eventually went by the nickname "The Zoo", as it contained almost all databases, products and development methods that had been on the market for the past 30 years. Every year, around 150 developers invested 1,300 hours each in building software for various projects in the company. This meant about 200,000 development hours per year. During the 30 years, they thus invested around six million hours - several thousand working years - in their systems. Productivity in the IT department fell radically around the year 2010. New functions the company wanted to offer or changes to the existing services required disproportionately large development efforts. Developers and projects had to deal with a huge number of dependencies between different systems, bad and redundant data and increasing conflicts over who would pay for all the changes that needed to be made in the various systems, which were often owned by different business area managers in the company. To address the problem, the company initially made a significant investment in Service-Oriented Architecture (SOA). This concept was based on ideas to reduce dependencies between different systems through more independent systems. Systems that exposed services available to everyone could be reused in the organization. In connection with this investment, the company hired many architects with responsibility for designing an information and service architecture for the entire company. They gave the project a substantial budget for three years but shut it down when it turned out to be too complicated. This meant that in many ways, the company was back to where it started when Anna was hired. The company had systems and code in which they had invested thousands of working years, and the systems almost consumed the company's entire IT budget just to be maintained. The IT budget was also high, close to 18 percent of the company's costs. This, combined with a need to create more digital services and use Artificial Intelligence (Al) to compete, would require substantial future investments to reach out to new customers and keep the old ones. The company had employed four different CIOs in the same number of years before Anna started, and she understood that it would be a great challenge to reduce all the technical complexity that had been integrated. At the same time, the company's operations were complex and built on ad-
INTRODUCTION
vanced financial systems that required advanced IT solutions. Her goal was to bring order from chaos and find a common approach for the company's own IT capabilities. Through her previous work at a major international bank, she had seen how the bank had made strategic investments in IT architecture for several years. They had trained a few strategic IT architects, who had worked together to create a model that worked well for that particular bank. But all organizations are different and what works well in one company does not necessarily fit well in another. During her four years at Mix, Anna's strategy was to form a company with fewer systems, reducing unnecessary technical complexity and getting the company to start looking at IT not as a cost problem, but as a resource to reach various business area goals. She knew that it would be necessary for those who worked in IT to work together towards common goals, and she promoted IT architecture as a tool to communicate and simplify. She wanted to avoid the mistake of development projects only considering the project and nothing else in the company. It was also crucial that everyone involved knew what was expected of them and what their responsibilities were in the bigger picture, in the same way that electricians, plumbers, architects and carpenters together build and take responsibility for creating a successfully functional and satisfactory house. Anna felt satisfied with the organization of IT architects who had been established and trained at the company and who were competent to work with the processes, information and integration of the change that the company would make over the next year.
1.2.2.
IT Architect Roles
What Anna's company and many other organizations have been focusing on for the past decades is using IT architecture as a tool for digital transformation. In the early 2000s, when all companies became technology companies, the number of IT architecture roles exploded. Roles such as database architects, security architects, SOA architects, information architects, etc. were created, which resulted in a confusion of responsibilities. Modern IT architecture must be built on a more well-thought-out foundation and in recent years, many companies have switched to a model based on five main IT architecture roles that work strategically together. They work with a different focus, level of details, technology and operational issues. This is essential because IT now exists as an integrated and necessary component for all of a company's operations. If you are not convinced, then try to remove all mobiles, servers and computers in your company and see what happens!
I
I
In the same way that electricians, plumbers, architects and carpenters together build and take responsibility for creating a successfully functional and satisfactory house."
15
1.3. Five Roles and Functions of Enterprise Architecture There are five important roles and functions of enterprise architecture.
Whole
Enterprise Architect Business Architect
Infrastructure Architect Solution Architect Software Architect
Figure 1.1 Five main IT architect roles
Detail Business
Technology
In this book, however, we have chosen not to divide the content based on different architectural roles, but instead we have focused on four different architectural areas. As the roles often blend into each other, various roles have an interest in different types of IT architecture. For example, a solution architect should also understand the field of software architecture and vice versa. You may even have several of the roles in your job description! The areas we will cover in the book are therefore enterprise architecture, business architecture, solution architecture and software architecture. Enterprise Architecture In this section, we cover how enterprise architecture (which is usually simply referred to as EA) relates to the company's business model and how to handle significant business events (e.g., the challenges Anna faces in the fictional story above). We discuss how to manage EA with the help of tools and how to evaluate an architecture as successful or unsuccessful. We also discuss how EA works in practice, its methods, standards and tools. Business Architecture In the same way that EA relates to your company's business, business architecture is also close to the business. We discuss what business architecture is, what benefits it provides and discuss differences between
INTRODUCTION
business architecture and EA. We discuss models and provide practical advice for those who want to work as a business architect. We look at how to use different views of the business such as strategic or operational views, standards and industry models and go through the practicalities of how to work with business architecture. Solution Architecture In this section, we look at integration issues and infrastructure. We discuss how to move data, build event-driven architecture and the essential considerations when choosing platforms. We also cover security aspects and the cloud. Software Architecture In the section on software architecture, we go through the vital concept of agility, a topic that also reappears in other areas. We talk about how to build an Agile architecture and quality attributes. We look at concepts such as test-driven development and domain-driven design (DDD). We discuss frameworks and their use, as well as the important concept of patterns.
1.4. A Word Before You Start The future for IT architects looks bright. Organizations will not need less IT and technology in the future, but rather the opposite. It is becoming increasingly important for companies to use digital capabilities to compete, and at the center of this transformation, there will be an IT architect. Understanding a company's processes and technical ability will make the IT architect a key role in organizations of the future. Good reading!
I I The future for IT architects looks bright."
17
Enterprise Architecture
2.1. Enterprise Architecture (EA) and the Organization
11 A successful business can insightfully anticipate trends, identify changes, and adapt to the environment."
A modern organization must have the ability to change rapidly when the environment changes. At the same time, the organization must also be able to develop in the long term towards a strategic goal. To achieve both these goals, EA is a core enabler.
2.1.1.
An Organization's Ability
A successful business can insightfully anticipate trends, identify changes, and adapt to the environment. It is continuously working to develop its operational capabilities (which include people and organizations, processes and IT) to meet new needs and requirements. This is about turning challenges into opportunities and maintaining competitiveness. Business development is about what type of services and solutions the company or the organization should deliver, which customer segments to target, what markets to operate in and what market shares to reach, how to compete with other players and which economic objectives and frameworks to apply. Operational development is about developing the operational capacity concerning needs and opportunities. The strategy expresses the desired change and the way to reach a set of goals. EA, finally, is the essential link between strategy and operational change, enabling a structured transition from what is to what will be. The chain of dependencies is shown in Figure 2.1.
ENTERPRISE ARCHITECTURE
Business development
Needs and opportunities for the organization Figure 2.1
Business development with architecture as an instrument of change
The development of the architecture itself creates new opportunities and future needs in the business, which will also result in a modernized architecture. In this way, the work is cyclical, and change is ongoing. This cycle's name is the Architecture Business Cycle (ABC).
2.1.2.
About Enterprise Architecture (EA)
2.1.2.1. Practice, Architecture and Ability EA is about describing, structuring and arranging complexity involving people, processes, information and technology. The concept includes practice, architecture and ability in the organization. EA covers the entire architecture stack. It provides an essential link between strategy and operational change, aiming to deliver benefit and value with the whole business in mind. The architecture is a framework and structure to ensure efficient management of the resources and assets needed to compete in the market. An organization that has matured in its approach towards EA establishes a specialized team or function in the organization with the mission to develop and manage architecture and use that architecture to guide change efforts.
2.1.2.2. Definition There is no single, universal definition of what EA means. The boundaries remain fluid. The many interpretations appear to be quite similar on the surface but differ when it comes to aspects such as scope and abstraction.
19
20
Boundaries Although there is no single, universal definition, a common view is that EA covers four layers, or areas: • • • •
11 Information architecture concerns the management and dissemination of the business's information assets."
Business (B) Application (A) Information (I) Technology (T)
The BAIT view occurs in different variants with different orders, denominations and decompositions. In some contexts, one or more layers are excluded or rescoped. A frequent modification is a merger of the Information and Application layers and another is the inclusion of Infrastructure in the Technology layer. Business architecture is not always part of the responsibility of the EA function and in many contexts, there is a clear distinction between groups responsible for business architecture and EA (as we present in this book). Application architecture explains how to enable business processes with solutions and applications. The architecture includes the classification and design of systems (usually using reference architectures), packaging of technologies and infrastructure services in apps, the choice of strategic platforms per focus area e.g., Customer Relationship Management (CRM), Product Lifecycle Management (PLM), Supply Chain Management (SCM), Enterprise Resource Planning (ERP) and integrations. Information architecture concerns the management and dissemination of the business's information assets, both accountability and related to the system landscape. The architecture includes classifications of information and data, quality, modeling, Master Data Management (MDM), inventory of critical source systems and primary information flows. Technology architecture is about describing the choice and management of technology intended for the business's information management. Within the framework of architecture, decisions over selecting suppliers and about different technology areas are described.
2.1.3.
Abstraction Models
The US EA Framework, the Federal Enterprise Architecture (FEA), argues that EA is about the business (holistic approach) at a high level of abstraction. Unlike Zachman's framework (Figure 2.3), there is a clear demarcation between the level of abstraction and detail that the EA encompasses. This boundary is, among other things, why EA differs from other forms of architecture, such as solution architecture, which is more focused on detail.
ENTERPRISE ARCHITECTURE
Level
Scope
Detail
Impact
Audience
----,...., Enterprise Architecture
Strategic — Outcomes
•
All Stakeholders
f Segment Architecture
; Line of Business
Solution Architecture
F?notion/
Pr°Cer
2.1.4.
Business Outcomes
0
tigh
ational , s
Business Owners
Users and Developers
----...---
Figure 2.2 FEA architecture levels Source: By Federal Enterprise Architecture Program Management Office, OMB - FEA Practice Guidance, Public Domain
Perspective Models
Zachman's framework for EA includes a structural model that consists of six aspects (Why, How, What, Who, Where, When) and five abstraction levels (Contextual, Conceptual, Logical, Physical, Detailed). The model focuses on different abstractions but does not present a defined scope — everything can be included, right down to the lowest level of detail.
Contextual
Goal List
Process List
Material List
Organisational Unit & Role List
Geographical Locations List
Event List
Conceptual
Goal Relationship
Process Model
Entity Relationship Model
Organisational Unit & Rote Relationship Model
Locations Model
Event Model
Rules Diagram
Process Diagram
Data Model Diagram
Role Relationship Diagram
Locations Diagram
r Event Diagram
F Rules Specification
Detailed
Rules Details
Process Function Specification
Process Details
Event Role Location Data Entity Specification Specification Specification Specification
Data Details
Role Details
Location Details
Event Details
Figure 2.3 Zachman's EA framework Source: Wikipedia
21
22
2.2. EA Function The purpose of the EA function is to ensure that IT fully supports the organization's business and operations strategies. The EA function ensures that systems and services are realized efficiently and with a sustainable approach over time.
2.2.1.
Responsibilities of the EA Function
The EA function can be divided into several functional areas. Organizations implementing an EA function generally use a combination of the six areas to define the scope of the EA function.
Figure 2.4 Different responsibilities of the EA function
IT strategy
Architectural Development
Information Management (IM)
IT Portfolio Planning
Architecture Governance
Architecture Capability
2.2.2.
IT Strategy
The development of EA has a strategic bearing on the business as a whole. The EA function therefore participates closely in the development of the IT strategy. The IT strategy is about translating the business's needs and opportunities for planning and future direction for the Information System/IT environment (more in chapter 2.3)
2.2.3.
Architectural Development
The EA is a specific interpretation of the strategy and constitutes an essential link between strategy and operational change. The work on developing the architecture is about describing the transition and explaining how the change should be carried out.
ENTERPRISE ARCHITECTURE
The architecture is established based on principles of architecture to meet given requirements. There are several methods available that can be used when creating an EA. Perhaps the most famous currently is The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM), but other frameworks, taxonomies and processes also contain traces of this methodology or application. Examples include Zachman, SAFe and Gartner's Methodology (see also section on Methods, Standards and Tools). While it is the responsibility of the EA function to develop and describe the architecture — typically based on the four layers discussed above — it is the responsibility of development projects to build and change the system landscape to meet the needs of the business. Architecture balances the short-term needs of the company with long-term value. The work takes place within the framework of an architecture process. The result is a cohesive architecture that, if enforced in operational development, guarantees a holistic approach and the realization of the IT strategy for the good of the business .
2.2.4.
Information Management (IM)
A crucial area concerns the ability of the business to efficiently manage information assets and is considered, in many cases, so important that it is managed as a separate area of the EA function. This area includes: • Development of a separate Information Management (IM) strategy (part of the IT strategy) • Development of an IS architecture • Data Governance • Business Intelligence (BI) & Analytics To be successful with IM, there is a need for frameworks and in-depth components, but also for operational capabilities within the organization to work in close cooperation with each other. Support for development projects is also necessary to ensure success and capture the knowledge generated.
2.2.5.
IT Portfolio Planning
The work on IT portfolio planning is about prioritization, packaging, lifecycle planning and change management. Depending on the maturity of the business, portfolio planning may include: • Lifecycle management of technology, application, data and infrastructure • Change management and transformation processes
I
The work on IT portfolio planning is about prioritization, packaging, lifecycle planning and change management."
23
• Packaging of the IS/IT environment and the defined services • Risk analysis and risk management • Innovation of new technologies
11 Architecture governance is about managing, guiding and following up on the development and realization of the EA."
Further areas may also be part of the IT portfolio planning, but the examples above are the most common. IT portfolio design is essential to arrange and structure complex and comprehensive content. The goal is to allow oversight of portfolio content supporting accessibility and insight, ensuring manageability (e.g., lifecycle management). It may be the EA function's responsibility to work with the IT portfolio design and create the context needed for traceability and transparency. For this purpose, a so-called meta-model is used, describing the content of the portfolio and establishing essential relationships between elements. However, the EA function's responsibility does not typically include the management of the actual content of the portfolio.
2.2.6.
Architecture Governance
Architecture governance is about managing, guiding and following up on the development and realization of the EA within the framework of a governance process. One responsibility is establishing applicable architectural standards and managing and following up on exceptions in the IT portfolio. A second responsibility concerns guiding and directing operational development through checkpoints so that development follows the EA with few exceptions.
2.2.7.
Architecture Capability
Effective Controlled Proactive Reactive Aware
Figure 2.5 Maturity model
Unaware
ENTERPRISE ARCHITECTURE
In addition to EA, the capability to perform EA-related work must be developed to increase the benefit and value of EA. Maturity of the capability is usually considered within a maturity model: at the highest level of maturity, business assets and resources together with the EA capability support development of business and IS/IT towards the set targets. Effort towards developing EA capability is mostly about establishing the EA function, but also about developing the capability of the whole organization. It may involve describing a vision and introducing clear goals (mission, vision, and objectives), establishing mandates, prioritizing, establishing roles and responsibilities, and educating. Crucially, it's also about communication. To gain buy-in and create the proper mandates, it is of great importance to demonstrate the usefulness and value of EA. The discipline itself, as well as the resulting architecture as such, must be anchored. Therefore, it is crucial to measure and follow up on the change.
2.3. Strategy and Strategy Work A strategy is an action plan aimed at achieving a specific objective. A strategy is not the same as tactics. In military terms, a tactic involves the implementation of a mission while strategy is concerned with how different missions are connected. In other words, how a battle is fought is a matter of tactics; whether it should be fought at all is a matter of strategy. The involvement of an enterprise architect or chief architect in strategy work usually occurs in two different ways: through supporting work on the overarching organizational strategies and by leading or participating in the work on IT strategies.
2.3.1.
EA and the Organization's Strategies
The organization's overall strategies form the basis for IT strategies. Competence within EA is necessary to develop a long-term strategy for the business. The more critical IT is to the business, the more important EA competence is. Since EA operates across both business and IT, EA is in a unique position to assess the plausibility and scope of various strategic initiatives that require changes to IT.
I
Strategy is not the same as tactics."
25
About Strategies
2.3.2.
11 The strategy should focus on how the organization should work but not go into what precisely must be done."
Strategies may be used at many levels within an organization. Our focus is on the work needed to develop an IT strategy, but most of our guidance can be applied to other types of strategies as well. The confidence and trust awarded to IT architects means that they often lead the work to develop strategies. The practical work on the strategy, however, involves many different roles and people. The time horizon for the strategy may extend to several years, possibly five. In today's business climate, it is not unusual to find strategies that stretch no further than one to three years at a time. Any strategy must be concise and comprehensive. The strategy should focus on how the organization should work but not go into what precisely must be done or in what order things should happen. A strategy must never prevent the organization from exploiting emerging opportunities. In terms of form, reasoning should be avoided with focus instead on concrete advice. The strategy should not bypass controversial topics but take a clear stand. If this is not possible because an issue is not yet settled, this should be stated with clarity. A strategy is a tool and like all tools, it should be motivating and straightforward to use. It should be easy to understand and execute, and technical terms should be kept at a minimum; if they are needed, they should be explained.
2.3.3.
Strategy Elements
A strategy may come in many forms and shapes, but in this context, we assume it is a document, covering the following main elements: • Foundation — the basis of the strategy • Objectives — the target(s) the strategy will achieve • Governing principles — how the target(s) will be achieved Below we discuss how each element can be developed, and later we propose how it can be presented in a document.
2.3.4.
Strategy Foundation
Strategies must support the long-term objectives and overall priorities of the business. Strategies within IT are based on other strategies, which relate to the entire organization. Elements of the strategy foundation include the current situation in IT and the business in general. The foundation must be correct and precise and is developed through the
ENTERPRISE ARCHITECTURE
exploration of existing material as well as interviews and conversations with the Chief Executive Officer, IT manager and other people from the management. Ideally, all necessary inputs should be written down and the different elements should not clash with each other. In practice, however, large parts of the input are often implicit, outdated, inaccurate, or inconsistent. Discussions and reasoning are necessary, sometimes supplemented by meetings and presentations. Even if the quality of the written material is high, it is still essential to talk to all stakeholders to get a complete picture. All these discussions, meetings and presentations are also part of the anchoring of the strategy. The most crucial aspect of the strategy foundation is the organization's priorities. Whatever the focus may be, cost reductions, new business ventures, quality improvement, better service to customers, they cannot all be most important at the same time, although this is sometimes portrayed to be the case. Guiding questions must be asked: what are the unique prerequisites of the organization? In what maturity phase is the business and what is the market situation? What is crucial for success in the long run? It is necessary to make clear choices and be able to opt out of things. It is vital to challenge what is said, even if it comes directly from the CEO. For example, if the organization is expansive, should the main objective of IT be to cut costs? It may be more important to invest so that IT can get better at managing change and thus quickly support future changes! As an architect, you may have the opportunity to explain and discuss this with the CEO and the management team. Usually, it's good to explain even what seems obvious to you, because it may not be obvious to people from other practices. The important thing is to highlight what the consequences may be for the business; the business depends on the choices IT makes. In this context, technical arguments are not relevant and can interfere with communication. Not infrequently, facts and reasoning affect not only the strategy within IT but the organization at large. In larger organizations direct access to the CEO or management team is not always possible, which can make the work more difficult. In such cases, it is best to work with those who have an impact (e.g., CIO, Chief Data Officer [CDO], or equivalent) and provide them with the material and understanding about anything essential. When the strategy foundation becomes clear, it should be written down and communicated to all involved parties.
2.3.5.
Strategy Objectives
The work to develop the objectives of the IT strategy involves the IT management team, complemented by various experts. The work is usually carried out through meetings, because it requires much discussion between roles with different skills. The objectives must meet the requirements defined by the strategy foundation.
V Even if the quality of the written material is high, it is still essential to talk to all stakeholders to get a complete picture."
27
28
If the business's strategy is to expand rapidly through acquisitions of companies, IT's goal is likely to be to implement processes and solutions to support this as smoothly as possible. If the company must reduce costs, this is also the goal for IT. For a government organization, the main goal may be to communicate as smoothly as possible with citizens; in this case, smooth communication with citizens becomes the crucial goal for IT to support. Once the meetings have concluded on an agreed view of the objectives, these should be added to the written strategy. Often, the results of meetings still require much work to achieve consistency and clarity in the strategy document. It is therefore essential that all participants have the opportunity to express their views on the final result, as formulated in the strategy document.
2.3.6.
1 The core and active part of the strategy is the governing principles."
Governing Principles
The core and active part of the strategy is the governing principles. These are simple rules that guide those using the strategy towards meeting the goals. They serve as governing guidelines on essential issues for the coming years and should always be followed unless there are strong reasons not to do so. The various principles must act as a whole, which requires focused work. Subject experts should be involved in the development for each principle. The principles express choices, priorities and scope in a variety of areas, such as: • • • • • • • •
IT security Sourcing Technical choices Competence supply Methodology Architectural principles Integration Strategic partnerships
For some of the goals, it can be challenging to find sound governing principles. The principles need to be concrete and express a position, and they shouldn't be too detailed. The following are examples of governing principles that are good in the sense that they are articulated (though for some organizations, of course, their exact opposite may be the most appropriate): Technical operation and application operation will be outsourced The software should be developed where it is either economically beneficial or gives a competitive advantage All stages of handling payment transactions must be protected by encryption.
ENTERPRISE ARCHITECTURE
If appropriate for the organization, it should be possible for employees to use their private mobiles and computers at work The governing principles need to be explained and bound together by a text in which the purposes behind the principles are succinctly expressed. Arguments, more extended reasoning and detailed explanations of the link between the objectives and the individual principles should not weigh down this text.
2.3.7.
Strategy Document
As mentioned above, the strategy document should not be too lengthy. The most important part is the management summary. The document should include a concise statement of the foundation, objectives and main features of the strategy. The summary needs to be designed with familiar business terms so that the company's CEO or a board member can read and understand it without becoming confused by incomprehensible technical detail. The management summary is then followed by the main elements: the foundations, objectives and governing principles.
2.3.8.
Daily Work Strategy
For the strategy to succeed in day-to-day operations, anchoring is essential. The IT strategy should be determined by the company's management or, if it involves radical changes, possibly by the Board of Directors. An effect of the anchoring procedure is that the entire organization is bound by the strategy. Anyone who opposes the strategy has the burden of proof on their side, whether they are the CEO or the IT manager: they need to prove their argument against the strategy with evidence. On the other hand, when the strategy provides clear guidance, minimal discussion is needed to make decisions and move forwards. For the strategy to work in practice, it is crucial that it is well anchored in the company and that it is understood. It takes effort to disseminate the content of the strategy to employees and managers. Even those who have been directly involved in its development need help to see how the strategy affects day-to-day work. In conclusion, therefore, the most appropriate solution is to create an event to present and discuss the strategy with all involved stakeholders. Architects should execute projects guided by the strategy; this, as explained above, means that there are many issues the architect does not need to consider in daily work because the decisions are obvious. Sometimes, however, it is necessary to deviate from the governing principles. However, this should be done openly and only after discussion and an investigation of the facts. Principles can be right and appropriate in gen-
For the strategy to succeed in day-to-day operations, anchoring is essential."
29
30
eral cases, while being wrong for a specific case. To quietly work around a strategy or directly counteract it is unacceptable. On the other hand, the governing principles should be questioned in the long term for the next revision of the strategy for improvement. What hasn't worked well must then be improved. A good strategy does not mean that we can stop thinking, but that we can reserve creativity for essential things.
2.4. Management of Significant Business Events
There are situations where significant events in the business must be prioritized over pretty much everything else."
Imagine working in a well-functioning business. A business where everybody knows what you are doing and why. The work is long term and proactive. There is a strategy in place and work is performed in accordance with it. Gradually, costs are lowered and documentation is in order. Then the IT manager calls. The architect needs to help integrate a newly purchased company into the business. The first meeting is the next day at 9 AM. The situation is challenging for any architect because the foundation of the profession is to work systematically, with a long-term horizon. But when management introduces drastic changes, there is often a rush and it is essential to deliver. It may even be necessary to take shortcuts and violate several rules. This may appear in conflict with what architects do every day; however, the only purpose of architecture work is to support the business. It is therefore necessary to embrace the challenge as a chance to support the business in a crucial way. It is essential to this kind of situation to get involved in the process. The earlier architectural and IT skills are included in the talks, the fewer adverse effects on IT structures and operations are likely. The architect needs to be someone who can contribute to the work: to succeed, we must have an open mind in dialogue with everyone involved.
2.4.1.
Examples of Significant Business Events
There are situations where significant events in the business must be prioritized over pretty much everything else. Some examples are when: • • • • •
Various forms of acquisitions are executed A company is purchased and to be included in the business The organization's own business is to be merged with another Part of the business is to be separated and sold Management decides on a new strategic business venture based on technology
ENTERPRISE ARCHITECTURE
• Management buys a new big system (without consulting IT) • An economic crisis requires savings everywhere • External dramatic events, pandemics or natural disasters affect the business
2.4.2.
Acquisitions
As an architect, you may become involved in acquisitions in different ways depending on the type of deal and where in the organization your role is. The goal is to achieve a good enough solution under the time pressure. The requirements of the business must be met, while decisions about the IT environment must not risk impeding future development. In this context, it is crucial to plan for a clean-up phase after production. This is necessary firstly to deal with any operational issues that have not been initially resolved and secondly because a complex IT clean-up is often required. Superfluous systems should be phased out, the infrastructure needs to be cleaned up and any quick temporary solutions must be eliminated. Time and funding need to be allocated and reserved for this process right from the start when the budget is available and the focus is on success. Since the venture is forward-looking and everyday rules do not apply, it is usually possible to reserve funds for this type of effort.
2.4.3.
New Business Venture
New significant business initiatives that require new IT support are often urgent. Someone may have discovered a new business opportunity that needs to reach the market quickly. This situation is similar to acquisitions in that a structural approach is needed to solve the problem. There may be the opportunity to negotiate for more time to implement change gradually or first carry out a test of concept and, based on lessons learnt from this, build a longer-term solution. However, if there is a time pressure, there is a significant risk that you have to take shortcuts to arrive at a solution sufficiently quickly.
2.4.4. New System Management may purchase a new system without involving architects or IT. It can be a difficult challenge to take care of a system if it doesn't fit into the existing structures. Unfortunately, this situation is not entirely uncommon. Often a skilled salesperson has sold a cloud service "that is ready to run day one, without awkward projects" or a service may have been purchased
'JI If there is a time pressure, there is a significant risk that you have to take shortcuts to arrive at a solution sufficiently quickly."
31
When there is a crisis, minimizing effects is even more important because the damage could be huge."
that lies "between IT and business", which can lead to false expectations. Here it is essential that the architect minimizes adverse effects by ensuring that the new system is incorporated into the business in the best possible way. In this situation, the architect can often do much valuable work with good outcomes. When the deal has been made without IT skills, many details may not yet have been defined: which parts of the system are to be used, what platform it should run on and how integration with other systems should be achieved. It is essential to focus on solving the problems that motivated the purchasing decision and otherwise remain practical. For example, sometimes you may have to convince others that the best and cheapest solution is to simply not use a particular feature, although it's included with the purchase.
2.4.5.
Crisis - driven Savings
When there is a crisis, minimizing effects is even more important because the damage could be huge. The architect's role is not as evident in this scenario as in the examples above, but the need for fact-driven, creative individuals is high. Often the strategy focuses on removing higher fixed costs — that is, staff, whereas the focus needs to be on trying to push for long-term savings rather than for savings which simply defer costs to the future or create new costs in the form of technical debt.
2.4.6.
Success Factors
Common to the different types of scenarios discussed above is that the most critical challenges for the architect have little to do with technical skills. The most important thing is that you are present in the room when vital architectural issues are decided. This often happens when the business solution is discussed rather than in meetings concerning architecture and architects are required to explain any architectural implications which decisions may have. So, you have to make sure you are invited to and attend the right meetings. Often when discussing with people who are not experts in technology, the discussions must be centered on the consequences of different technical choices in the business, not on the technology itself. Such meetings may result in negotiating positions requiring some giving and taking. Architects shouldn't be afraid to make counterclaims. Here, too, it is a matter of anchoring and creating alliances around the common goal. A useful tool in this context is technical debt. If you include the technical debt created in the event of the change in the calculations, it is easier to manage cleaning costs. It may make sense to shorten the delivery time by
ENTERPRISE ARCHITECTURE
choosing a more straightforward solution. However, if this introduces a future cost of 500,000 USD to introduce a solution to comply with regulations, this cost should be included in the project estimate so that the funds can be reserved.
2.5. Collaboration Between Different Architectural Roles Although the EA function has an overall role in a business, it cannot function without the help of others. In some ways, the work within the EA function can be compared to the responsibility of any management function. Any responsibility is challenging to manage without involving others, and without an agreed roadmap, other stakeholders may find it difficult to achieve the desired goal or to realize a strategy. The EA function is strongly dependent on other architectural roles. These can be shared in smaller companies by a small group of people, but in larger companies there tend to be separate and more distinct specializations. In other words, the size of the business affects the work performed within the EA function, and the more extensive the company, the more technology, resources and planning are required. The driving force remains the needs of the business and the impact that the requirements have on a project (e.g., change in work). The architecture work is divided into smaller, more manageable pieces where the EA function can be seen as the coordinator and, in some cases, the controller. The various challenges that exist in all organizations necessitate the other architecture roles, such as business architect, solution architect, infrastructure architect and software architect. Let's discuss some challenges in architectural roles.
Challenge 1: How can the business continuously improve and meet new external requirements? When the business is facing a change, meets new external requirements, or just needs to process existing solutions, it uses a business architect. The business architect is the specialization closest to the business itself. The business architect makes sure that information reflects the capabilities, processes, resources and other qualities currently existing in systems as well as potential sources. The idea is to offer alternatives to process improvements, which may be new ways to manage orders or logistics; this is done by modeling the present and setting up target architectures and scenarios. These models may depend on the need for visualizations and
The EA function is strongly dependent on other architectural roles."
33
34
19 Recurrent meetings with stakeholders from different levels of the organization must be held by the business architect to stay on top of changes."
narratives and be at both a high level and a more detailed level. Given the skills the architect offers a business, it is natural that he or she works closely with management, on projects or in other teams relevant to where the latest development is most profiled. In this way, the business architect can stay informed about the latest trends, the political situation and external events and directly reflect the implications of IT for organizational ideas and decisions. A business architect must have the ability to keep up with the rapid changes in the organization. New external requirements often result in small or large IT projects or operational, input and change projects. In such situations, the business architect is responsible for ensuring that the projects are scoped to available skills, resources and that they can fully be reused. One effective way of ensuring this is to make the milestones of the projects manageable and aligned towards the business architecture. The business architect works with visualizations and descriptions (e.g., process maps, scenario charts, service maps, concept models, information models and capability maps) of the organization and activities. Another part of the work revolves around delivering and maintaining the overall architecture plan; the EA function manages this to deliver reliable IT solutions. To meet the requirements of the business, the business architect must have in-depth knowledge of process-, conceptual- and information modeling, requirements management and understand how processes and information connects to the (usually complex) system landscape. Recurrent meetings with stakeholders from different levels of the organization must be held by the business architect to stay on top of changes. The development work takes place together with the solution architect, where analysis and requirements for various IT solutions are put to the test and where the ultimate goal is to jointly produce evidence that the architect can later use to form a plan.
Challenge 2: What should the IT solution look like? The solution architect works to plan the realization of IT solutions based on the business's needs and within the conditions of existing IT services in the organization. Like the business architect, a solution architect is tasked with ensuring that as much functionality as possible is reused. It is part of the solution architects' responsibilities to ensure that the overarching architectural principles and guidelines on standards are followed in the technical architecture. In other words, the solution architect focuses on solutions that span several different systems: in-depth knowledge of relevant quality attributes determines whether the solution architect can successfully balance them against the functional requirements. This knowledge later prepares the basis for all the critical priorities and compromises that may come from management and the business architect.
ENTERPRISE ARCHITECTURE
The solution architect ensures that IT solutions are appropriately realized; this should be done according to the requirements of the business and IT. In addition to providing a functional perspective that includes management and governance perspectives, the solution architect often also formulates the non-functional requirements that may exist in the context of technology choices. Since the solution architect within the EA function acts between business and technology, they should have the ability to turn the business architecture into sustainable technical solutions. This requires a deep technical understanding, framework skills and good modeling skills for profitability assessments as well as the ability to communicate on these topics. The business architect assists with the exchange of expertise and supports cooperation, while the solution architect works with development teams (i.e., the software architect) and the infrastructure architect to achieve their work goals.
Challenge 3: What is needed for everything to fall into place? An organization's infrastructure consists of physical and virtual resources such as hardware, networks, technical platforms, tools, software and services and IT personnel, which allows us to move on to the topic of the next role. The infrastructure architect works primarily to structure, document and propose the infrastructure that matches the organization's needs best. Most IT-related projects have an infrastructure architect involved, but this role may also support the ongoing operation and improvements in IT. Compared to other architectural roles, the infrastructure architect fulfills a more supplier-like function and the responsibility lies in how the infrastructure components affect the different quality characteristics (non-functional requirements) in a project. Therefore, the infrastructure architect works on the design and optimization to enable IT infrastructures; this is done by developing physical views of solutions, network maps, concept validations, monitoring and technical guidelines (for example, around authentication, databases, application servers and networks). An infrastructure architect ensures that the organization has the right IT infrastructure supporting the business (e.g., capacity calculation with scaling models, cost and quality calculations for various solutions and assessment of operational options). The 'right infrastructure' is one which is kept up to date, at a pace matching the needs of the organization. The infrastructure architect manages handover of the software, supervising this in the operations part of the organization, e.g., according to IT Infrastructure Library (ITIL) processes. The infrastructure architect also ensures that there are applicable governance models and maintains the infrastructure's documentation. For all the pieces of the puzzle to fall into place, the infrastructure architect needs to be familiar with the organization's technology. The infrastruc-
ee The 'right infrastructure' is one which is kept up to date, at a pace matching the needs of the organization."
35
36
ture architect interacts with most of the technical roles, such as solution architects, software architects, network technicians and hardware experts, but is mostly focused on the long-term goals within the EA function.
Challenge 4: Execution
I
I
The software architect works at a more detailed level than the solution architect."
The software architect works to structure and design software; this is done to meet both the functional requirements and the different architectural quality requirements placed on the systems. However, the software architect works at a more detailed level than the solution architect; the role can be seen as a specialization of the solution architects. The role of the solution architect can cover the role of the software architect and responsibilities for both roles. In such cases, a distinct software architect role may not exist. When there is a need for a software architect, this usually happens within a project. At the detailed level, the software architect is responsible for the framework and business components within the project, ensuring that they can be reused and returned to the solution architecture. Since the software architect is usually a technical leader, who holds detailed knowledge of the particular product or system to be changed or developed in an organization, the role is usually also the foundation for Agile methodology. The software architect should, therefore, have the ability to maintain the software and keep it in a condition relevant to its position in the lifecycle. The software architect ensures that selected patterns are used and decides where resources for different requirements in the software need to be allocated. In the solution architect's eyes, the software architect acts as an expert with whom they can discuss new solutions, based on the software architect's artifacts. These can be scenario descriptions, computer models, process models, design recommendations and descriptions of the intended lifecycle and management. Of course, the software architect should have in-depth technical knowledge corresponding to specialist expertise in one of the leading platforms and be competent in software development with skills in modeling and design and design patterns. The software architect must fulfill the role interacting with solution architects, development teams, requirements analysts and others and above all in the project.
Collaboration with stakeholders and peers The EA function is a function for all architectural roles. That is why it can be said that EA is not an isolated phenomenon. A well-executed EA arises when the interaction between the roles responsible for developing and managing architecture works, i.e., business, solution and infrastructure architects and the roles that own and use the ar-
ENTERPRISE ARCHITECTURE
chitecture. The EA function provides different supporting structures that all contribute to a good interaction between the roles described in this section. The EA function can, depending on the type of operations and the size of the organization, either lie with a group or be jointly managed by the various architects of the organization. Regardless, all architectural roles share the joint EA roadmap, frameworks and steering models presented in the face of the change to an activity, in which the organization, for example, has chosen to use IT. The responsibility of the EA function is to balance goals and ensure a holistic architectural perspective of the joint roadmap and architecture. The aim is to deliver an efficient and sustainable IT solution and business solution that supports the organization's strategic goals. The IT solution or business solution should also be prepared for future changes in business models and new business requirements so the business can benefit significantly from its systems as a whole, so the business has a comprehensive strategy for future functions and IT investments and the IT architecture is cost-effective. The EA function is responsible for establishing a suitable steering model and other structures to develop, manage, plan and follow up on the architecture work. It establishes and manages structures for cooperation between different types of architects and other stakeholders, with a particular focus on users of architecture. One analogy is to compare the EA function's work with the work a CEO has to do in ensuring that all departments and employees of a company work optimally and adequately using planning, strategies and rules.
Whole
Enterprise Architect Business Architect
Infrastructure Architect Solution Architect Software Architect
Detail Business
Technology
Figure 2.6 Examples of collaborations with other architects
37
2.6. How to Anchor an Architecture
Anyone who has tried to lead a group of system developers knows how difficult it can be to agree on change. Active cooperation helps with this process."
A central task for architects is to ensure commitment to the architecture with all stakeholders. If this fails, whether the architecture is any good becomes irrelevant. The word 'anchoring' is sometimes interpreted as having regular meetings with stakeholders. We argue in this section that such a definition is a short-term and inefficient way of working. It can work to get a quick decision, but a compelling long-term change requires working differently; this requires all those concerned to understand the background, be committed to the change and, ideally, to support the change actively. What someone creates alone on a computer tends to stay there — regardless of the amount of persuasion, advertising and formal decisions that takes place. Instead, successful anchoring is achieved through active cooperation. Anyone who has tried to lead a group of system developers knows how difficult it can be to agree on change. Active cooperation helps with this process. The best solutions are created in meetings between people with different competencies. No matter how smart you are, others contribute new insights and perspectives, making the result far better. Anchoring is, therefore, crucial and it should be carried out by those affected in different ways by a change or by those who are involved in the process of designing it.
2.6.1.
Two Types of Anchoring
Almost all architects need to work on anchoring their various initiatives. The chief architect must anchor strategies, solutions, forms of work and concrete efforts. The architect of the solution must anchor suggestions for architecture and solutions, etc. The anchoring work usually needs to be conducted for two different groups. First, for the decision-makers, who will fund and support the initiative and secondly, for those directly affected by it. The two types of anchoring take place in different ways. Let's take a look at the different types.
2.6.2.
Anchoring with Decision- makers
The anchoring of decision-makers is about getting decisions, resources and support to implement initiatives. The latter is perhaps the most important thing. Support means that there is an enduring sponsorship that protects the effort from various threats during the time it takes to implement it. This also requires understanding the consequences of a decision on future decisions when they reach touchpoints so that, for example, parallel solu-
ENTERPRISE ARCHITECTURE
tions are not being worked on to address the same problem. In other words, it is vital to be involved in management team meetings, steering group meetings, business planning, strategy discussions, etc. When you have an essential issue, it is your responsibility as an architect to work to address it. Often, the architect does not have a seat at the table at the most appropriate management level. This means that much of the anchoring must be done through agents (e.g., IT director or CIO). Management's IT maturity varies between companies and industries. Companies in the financial sector are in practice IT companies while manufacturing companies tend to see IT more as a service function. Either way, the discussion should take place as much as possible using the same terms that the management use. All management teams tend to see the benefit of dismantling old systems that involve risk and high costs. The benefits of consolidation of technology platforms can also be explained without going into details of the individual platforms. One should focus on the consequences of the changes rather than technical details. The following aspects are essential: • Economy — costs, savings and possible increased revenues • Speed — the opportunity to quickly meet changes, e.g., in the form of a new business offer • Risks — e.g., for outages, customer malpractice, intrusion, crime, dependence on a supplier, personal dependency • Legal requirements — do we risk breaking the law in any way? • Customer relationships — will it support improved relations with existing customers, such as through smoother service or better information? • New business opportunities — will the change allow for entirely new types of deals? As an architect, you may frequently be the person who sees most clearly the consequences of choices within IT. It is, therefore, essential to participate in the discussions and ensure that the relevant issues are on the agenda. The very best dialogue is when others explain problems and the architect can propose solutions. This stimulates motivation on both sides. However, as an architect, you also must be proactive and take initiatives, raising issues that are of importance to the business. Regardless of who raises an issue, the discussion should take its starting point from concrete business problems. It is much better to start with a discussion around the problem than around selling a predesigned solution. What is it that is perceived as a problem? How serious are the issues? How much would it cost to eliminate the issues? How urgent is it? In addition to anchoring through dialogue in groups, it is essential to have a private conversation with key management members — especially if you are a rare guest in the management team.
I
I
Much of the anchoring must be done through agents."
39
40
Again, this provides invaluable input, and it helps to share understanding of architectural issues. Take advantage of all the opportunities for informal discussions available. Ask for help, ask questions and work on ideas. As always, be eager to listen.
2.6.3.
11 The time an architect dedicates to sitting down and creating models and other documentation becomes shorter and shorter."
Anchoring with Directly Concerned Stakeholders
Anchoring with directly concerned stakeholders is about succeeding in implementing an initiative with the people most directly involved with it. Project managers, other architects, business-savvy users and developers should feel part of the initiative. How do you achieve that? A fundamental aspect for the initiative to work is that those concerned understand what the change means and the motives behind it. The easiest way to achieve this is to give them an active role in shaping the initiative. This is once again about leaving the computer and working actively with others. The work has two purposes. Firstly, information is shared, both regarding the operational needs and the technical challenges. Here everyone can contribute. The architect has his or her picture, but it is incomplete and needs to be complemented with different perspectives. Secondly, the solution is jointly developed. Here, too, different skills and detailed knowledge can contribute valuably. It is also in the architect's mission to create a consistent whole solution from various ideas and document the results. It is not wrong to let the most engaged take a more significant part of the work as long as everyone is involved and no one feels excluded. Group meetings should be used often to map out, develop ideas and test solutions. Referral rounds of documents are essential for disseminating and quality control of accuracy of information. Here, however, for efficiency reasons, individual reviewers should be identified. Anchoring can be particularly challenging in cases where the architecture is carried out by an external party, perhaps a consulting company in a country at a considerable geographical distance and with a significant time difference. Although personal meetings are just as essential, they can be replaced by video or other technical cooperation platforms for both time and cost reasons.
2.6.4. Summary of Anchoring The time an architect dedicates to sitting down and creating models and other documentation becomes shorter and shorter. As a result, the architect creates better documentation and brings more benefits to the business. The proportion of anchoring work varies greatly depending on the archi-
ENTERPRISE ARCHITECTURE
tect's position, the size of the organization and the focus of the work. The more technical and specialized the work, the less anchoring is necessary. However, what is often lacking, even among the most experienced architects, is cooperation and dissemination of information — in short, anchoring.
2.7. Architecture Governance 2.7.1.
Governing Architectural Principles
A principle expresses an approach or general rule that governs what something should be like or how it should be handled. Governing principles are tools that can be used to control a variety of things at different levels within an organization. One of the areas that can be governed with principles is architecture. The principles governing architecture are called 'governing architectural principles' or just 'architectural principles'. The purpose of the architectural principles is to guide people working with architecture in making decisions. They are, therefore, a pillar of architecture and should control all architectural choices and design decisions, directly or indirectly.
2.7.2.
Designing Architectural Principles
Designing architectural principles is about capturing and describing the organization's needs and conditions and translating them into concrete guidelines for how to design architecture. This work is usually carried out by architects. It may be the chief architect or a team of architects who design them. If principles are already written in policy or strategy documents with higher-level governing principles, these are essential inputs. The parameters are interpreted, valued and translated into architectural choices expressed in the form of architectural principles. When architectural principles are to be designed, the following approaches can be used. The starting point is that each principle has a purpose and is intended to have a specific effect. • What effect is to be achieved? • What needs to be controlled and in what way? • In what direction does it need to be guided for the desired effect to be achieved? These principles are the foundation of architecture and for them to function well, they need to support the organization's strategies and objectives, be
I
I
Governing principles are tools that can be used to control a variety of things at different levels within an organization."
41
42
sustainable over an extended period, be consistent and support architectural decisions. Support the organization's strategies and objectives All architectural principles are designed to control architecture in a direction that supports the organization's goals and strategies. How an architectural principle is meant to support the business's goals also needs to be made clear. Sustainable over a more extended period Architectural work is long term: changing architecture takes a long time. architectural principles should be designed so that they do not need The I Architectural to change unless the organization changes direction, or if the business technological shifts or some equivalent work is long changes radically due to significant reason.
term: changing architecture takes a long time."
Consistent The principles of architecture must guide architecture in one direction. The principles cannot be contradictory, and it must be possible to apply them without them conflicting. Support architectural decisions The principles of architecture need to be translated into architecture. They lay the foundation for architectural choices, which in turn point to the direction of the target architecture and real solutions. Further, there should not be too many principles. The more governing principles that need to be applied, the higher the risk of conflict between principles and problems with trade-offs between them. It is therefore better to have a smaller number of principles to govern the most important aspects. One important aspect faced when designing principles of architecture is identifying the appropriate level. If there are principles expressed in policy or strategy within the organization that have apparent architectural influence, these can be translated into architectural principles at a slightly lower level. If higher-level principles that affect architecture are missed, there is likely to be a gap in the architecture principles that needs to be filled. One approach is to set the architecture principles at a higher level. In many organizations, there are design guidelines for producing new IT solutions, especially in custom development. Such guidelines can often have an impact on architecture. If there are design guidelines, the architectural principles can be added at a slightly higher level. But if design guidelines are missing, some aspects may need to be guided by architectural principles instead.
ENTERPRISE ARCHITECTURE
2.7.3.
Establishment and Legitimacy
For the principles to be useful and affect the organization, they must be formally established and present in people's minds. Otherwise, there is a significant risk that the principles will only become wise thoughts and rather pointless, especially as architects often lack decision-making mandates. Well-formulated, entrenched and established principles, on the other hand, can be handy tools. Identify who or what role should determine the principles of architecture. This needs to be a role or a group with mandates because application of the principles can have a significant impact on projects and IT activities. Although defining the principles is essential, a large part of their implementation depends on anchoring and communication. Stakeholders need to understand the principles and the impact they are expected to have on the organization. For the principles to become effective instruments, it is essential to anchor them with the people who apply them.
2.7.4.
Documentation and Description
Architectural principles have many stakeholders. Some stakeholders may only need to understand the principles at an overall level. In contrast, other stakeholders need to understand their meaning and purpose to apply them actively in decision-making and when making choices. The latter case places higher demands on how the principles are expressed and documented. Architectural principles are typically formulated as a concise and impactful guideline or rule, e.g., "IT solutions should primarily be purchased as a service." But what is the purpose of the principle and what effect is expected from its implementation? Is it based on the assumption that it is always more cost-effective to base IT support on cloud services, or is it about the organization needing great flexibility over what a cloud strategy is expected to provide? For the principle to be understood and applied in the way intended, the purpose and the expected effect also need to be described.
Principle
Short and clear rule or guideline.
Purpose
Describe the effect and benefit of the principle. Relate the principle to the organization's objectives and strategy. Describe relationships with other architectural principles and how the principles should be weighed against each other, if they conflict with each other.
11 Although defining the principles is essential, a large part of their implementation depends on anchoring and communication."
43
44
2.7.5.
Examples of Architectural Principles
Below are examples of architectural principles, which reflect the conditions and strategy of a competitive company, operating in a fast-moving market. These architectural principles operate at a high level.
Principle
IT solutions to be purchased primarily as a service.
Purpose
The organization acts in a rapidly changing environment. Competitiveness is based on the ability to adapt according to the needs of the market. That capability needs very flexible IT support that can quickly be expanded, changed and phased out.
Principle
IT support should be based on standard systems and custom development avoided.
Purpose
The organization's competitive advantage lies in the ability to change rapidly. Rapid change is achieved by using off-the-shelf IT products, not by developing systems from scratch. Differentiation of IT solutions through in-house development does not provide a competitive advantage for the organization.
Principle
The organization should prioritize customer focus and rapid market establishment.
Purpose
The organization's success is based on early market presence, when margins are high, rather than on competing with squeezed costs and small margins.
The last principle is not a pure principle of architecture and does not have a direct influence on architecture. Instead, the principle is part of the organization's marketing strategy. However, it provides a clear signal to design IT landscapes and architecture: easy change is more important than cost focus. This principle may be the basis of the first two principles above. Although this principle originates from other governing documents in the organization and only has an indirect impact on architecture, it contributes to clarity, if included in the principles of architecture. Lower-level architectural principles are often more specific, but they can be described in the same way and they also need to include the purpose and desired effect, meeting the characteristics of architectural principles described above. This also applies to architectural principles of a more concrete nature, as demonstrated in the examples below.
ENTERPRISE ARCHITECTURE
Principle
Integrations between different systems should go through the integration platform.
Purpose
Integration through the integration platform creates fewer dependencies and enables centralized management and monitoring of integrations. Using the integration platform also increases the possibilities of implementing adaptations that may be needed to integrate standard systems.
Principle
A system that stores information, for which another system is master, should be supported with updates directly from the master.
Purpose
Information that is flowing from different directions increases the risk of quality deficiencies in information and creates unnecessary dependencies between systems, which reduces mobility and flexibility in the IT landscape.
2.8. City Planning The city plan is an overview of the most crucial system in the organization. It has a structure and order based on principles of architecture and is needed for overview, prioritization, planning and optimization. With the help of the city plan, it is possible to develop the system landscape (i.e., to expand the overall portfolio of IT solutions) and how the business manages its information.
2.8.1.
Organic Growth, Silos and Fragmentation
Distribution of the system landscape In a smaller business, the need for IT support is not as extensive as in a larger business. The system landscape is smaller and less complicated, but as a business grows, the system landscape increasingly broadens with more systems and solutions. Naturally, this occurs over a long time. Organic growth and silos Unfortunately, it is not uncommon for the system landscape to grow organically in uncontrolled ways. In a larger business, the organization is divided into branches of operations, or functional units, such as product design, marketing and staff. Each entity often has its own agenda, business-related goals and requirements to meet.
I
I
The city plan is an overview of the most crucial system in the organization."
45
46
Without an agreed plan and coordination, the system landscape will, over time, reflect the functional silos and isolated objectives and requirements adopted by the business. When the environment changes and new, potentially cross-functional business opportunities arise, the sub-optimizations introduced become a problem. Fragmentation and increased complexity Organic development has negative consequences for the integrity of the system landscape. Typical examples include: • • • • • •
V Without an agreed plan and coordination, the system landscape will, over time, reflect the functional silos and isolated objectives and requirements adopted by the business."
Fragmentation and functional silos Integration complexity Overlapping functionality and duplicated information Information islands Conceptual confusion and scope for interpretation Data quality problems
Due to increased scope, fragmentation and complexity, lock-ins, etc., implementing changes in the system landscape will cost more, take longer and be associated with higher risks. The business may suffer and struggle with long transition times and quality problems. Ultimately, it may be that IT becomes an obstacle to the continued development of the business. Planning and coordinating the development of the system landscape is therefore essential.
2.8.2.
Contract Between Business and IT
Contract To support a capability or process-oriented approach in which information can flow across and between organizational functions, the system landscape needs to be partially decoupled from both organization and processes. The system landscape should be structured and arranged holistically — for the needs of the whole business — around subject areas for information and the ability to handle that information. This structure and order are described in the city plan, which essentially constitutes an agreement, or a contract, between business and IT. It is the responsibility of the enterprise architect to draw up the contract. The design of the city plan with its structure and order must then be reconciled with both operations and IT to create a joint agreement and understanding.
ENTERPRISE ARCHITECTURE
2.8.3.
Benefit and Value
Several uses There are naturally many different uses and applications for the city plan — the imagination sets the limits. Some primary applications include to: • • • •
Visualize Plan, rationalize and optimize Control and lead Describe
Other uses are about communication and consensus. Visualize The nature, maturity, ability and change of the system landscape can be visualized using so-called heat maps, based on the structure and order of the city plan. • • • •
What is the distribution of cost across the system landscape? Where is IT support complete/incomplete? Where is old technology used? Where is development taking place?
Plan, rationalize and optimize Planning, rationalization and optimization of the system landscape are executed following the city plan to meet the needs of the business as much as possible. The actual work is addressed in portfolio planning (project and application) and provides a basis for decision making: • • • • •
What are the priorities? How do we differentiate and where is an investment required? What should the content of the project portfolio be? Which applications are needed? What must be managed according to the lifecycle?
Control and lead If the city plan is a description of the business's need for information and its ability to handle that information, it also serves as a tool to coordinate, control and lead the development of the system landscape to meet the needs of the business. The city plan is a governing artifact and is used to make strategic as well as tactical decisions. Separate and describe Delimiting and describing change projects and solutions is a natural application of the city plan as its structure and order form a framework to relate
The city plan is a governing artifact and is used to make strategic as well as tactical decisions."
47
48
to. Proposed solutions can also be evaluated and validated vis-à-vis the framework (e.g., applicable integrations between systems).
2.8.4.
Design of the City Plan
The city plan includes an imaginary structure and order under which the system landscape (systems, solutions and services) can be arranged (although not all needs will necessarily be realized with IT support). The aim is to create overviews and conditions for prioritizing, planning and leading the development of the system landscape on rational grounds. Ultimately, it is about meeting the business need for information and the ability to handle that information effectively. One of the more essential functions of a city plan is to visualize and create an overview. It is first essential to determine what needs to be included in the city plan and what does not. The city plan must be designed so that it captures border lines for the business, strategic priorities, relations with external parties, etc. to answer: • • • • •
What is the core business? Where are the internal and external limits to the business? What are the value chains? What relationships with external parties are essential? What is the need for information?
A well-described model creates the ideal conditions for communication and consensus. Model The way the city plan is expressed can, of course, vary from one business to another, but the overall structure is usually a hierarchy. Usually, it is a context, a division into overall areas and a list of the most critical systems (Figure 2.7).
2. Domain
Figure 2.7 City plan hierarchical breakdown
Internal and external context
Area of interest to the business
reakdowns a bsystems
Collaboration with the surroundings
Systematic grouping of areas
ormation processing ased on subject
Focus on relations and roles
ENTERPRISE ARCHITECTURE
COMPANY LTD CITY MAP OF INFORMATION SYSTEMS Suppliers
Customers
Company Ltd Business Development
r Authol • I I J
r Supplier -1
J
Product Development Part Structure
Strategic Sourcing
Product Product Otter Dentition Requirement:,
Product Semce Dell-non
Sourcing
Pion-yam & Solution Oevelopment Cnange Management
Design Solution
Ounlity Assurance
Product Dennton
Product validation
Consumer Relationship Management
Partner Relationship Management
Procurement Material Ordering
Distntuton Partner Management
Consumer Management
Supplier Partner Management
Customer Interaction
r Market '
J
r
Retau -1
1
r eOfiSutner -' Product Primary Value Chain Marketing & Sales
Manufacturing Order Scheduling
Production Control
I Outcound Logistics
Production Support
Prepare Production
Innound Logistics
J
Servke (Afterrnarken
Order Market & Sales Bona Management Management Management Product Offer I E..1,11:e, DevelopMent Pm ning &
Pena Service hlanagemem Management
Software Management
Product Lsecycie
Technical Support
Warranty Management
tionagernent
FOroca.St
Business Administration Human Resources
Financial Management Fnamal
e rut., {.....teo)
AnatrAs
Msnaprr.,
P...,,
Accov iiio
'Arca: 5.w,, Craw .4,,,,,t
6V, .....
5,-..1,-nert
,,,, 1.1.v...,vre,
.----,.,,,
.,,,,,,*
S4,4. 4-arrpenerS
P,,,,o et U.,,,
Gb.ty It Uvrov+vont
,-.9.,.'
.,,, ,..,,,,,,
irs.w ...,—.Pon ...a 1 Kars, • . drof t.
Company Ltd IT, Enterprise Architecture
Corporate
Indirect Purchasing
I.-t ty & /..,..:•••
Version: 2013 Q2
11.11111111111.1,
Figure 2.8 Example of a city plan
Although the model can be broken down into more levels — e.g., information objects and features — it should be kept as simple as possible to contribute to the overview. There is, of course, nothing to prevent exploring additional levels in the background. The three main divisions are: Internal and external context A first division of the city plan is about the internal and external context, i.e., the activities in collaboration with the surroundings: the value chain, flow, relationship with external actors and boundaries are captured at the contextual level. When the city plan is designed and the internal as well as external context is to be described, proven models and standards, or similar tools can be helpful. This context is usually referred to as the Extended Enterprise but viewed from the perspective of the business. The internal and external contexts must be broken down and described conceptually to understand the boundaries of the business. The need for information and the ability to manage information is systematically grouped
49
50
into many domains and represented in several information systems for subject-area information management. Domain In this context, a domain is an area of interest in the business. Each domain is a systematic grouping of several closely related or related areas (including processes, information needs and system solutions). Examples of frequently used domains include Product Development, Marketing, Sales, Finance and HR.
11 A city plan's implementation should take place according to a functional or logical method and not according to how the business is currently organized."
Information systems An information system is defined as the capability to collect, store, structure and integrate, process, analyze and distribute information within a demarcated subject area. Figure 2.8 presents an example of a city plan. Perspective In general, understanding of the city plan must be possible from different perspectives so it should be presented to highlight what is important for different audiences or individual stakeholders. Presentation of the city plan for different stakeholders can be achieved in different ways: Details: Someone may be mainly interested in a given area or part of the city plan so only this part is presented in detail. Highlighting: Some may be mainly interested in certain issues related to different parts of the city plan so that highlighting these areas is relevant and can be achieved in different colors or degree as in so-called heat maps. Map: Different phenomena can be mapped, described, or related to in terms of the city plan by matching to individual elements on the map. Matched phenomena are presented in unique views of the city plan, either together or separately. Design: To describe other complex areas of interest or individual domains, completely new views of the city plan can be designed. The internal context can be related to the external in new constellations, perhaps based on new concepts and models.
2.8.5.
Architectural Rules of Thumb
Principles of architecture A city plan's implementation should be expressed according to a functional or logical method and not according to how the business is currently organized. Often, some concessions are necessary to represent boundaries, priorities, cross-functional needs, etc. The structure and order of the city plan constitute an agreement (between business and IT)
ENTERPRISE ARCHITECTURE
and therefore compromises are necessary. The enterprise architect must consider that organization, processes, responsibilities and many other mechanisms in the business will change over time and that changes may emerge suddenly. If the city plan is to be used to plan and develop the system landscape, it must remain stable and persistent over time. Changes in the systems can often take longer to implement than changes in how the organization works. The structure and order of the city plan should be based on principles of architecture. The purpose of the principles is to guide priorities and orientations when the city plan is designed. Examples of such principles may be holistic and model-driven, natural borders, or commonness. Target architecture In general, the city plan is to be regarded as a target architecture at a macro level. It describes a desired structure for the system landscape. If the city plan deviates far from the target architecture, it means that the city plan is more an 'as-is' description. The individual elements of the city plan can also serve as place holders for more specific target architectures.
2.9. Target Architecture The current architecture of the organization is an 'as-is' architecture, which is never the most optimal for the needs of the organization. The needs of the organization change and the architecture may not have been changed in pace with the needs. The target architecture, on the other hand, is fully adapted to the needs of the organization and the business, but it is a fictitious paper product. Should the target architecture exist in reality, it would support the needs of the organization in the most optimal way. The concept of target architecture is generic and can be applied to arbitrary architectural perspectives or architectural domains. There may be a described target for information architecture and a described target for application architecture or infrastructure architecture. Usually, the concept of target architecture is associated with technical architecture for the core systems. If there are other architectural descriptions described, they should also be counted as the target architecture. The target architecture and city plan describe architecture at different levels. The city plan describes at a reasonably high level what capabilities, information needs and systems exist and the role of systems in different parts of the business. The target architecture describes the systems more concretely but without going into details. In organizations where a city plan is missing, the target architecture is sometimes allowed to carry parts of the description and modeling that we would otherwise find in the city plan.
The target architecture, on the other hand, is fully adapted to the needs of the organization and the business, but it is a fictitious paper product."
51
2.9.1.
Design of Target Architecture
The difference between the present and target architecture is often significant and the target architecture cannot be achieved overnight. It's going to take years. Therefore, the target architecture should aim to be achieved a few years into the future. It is impossible to know all the details of the IT landscape a few years into the future. Therefore, the target architecture needs to be described at a conceptual level. However, what we do know about the desired IT landscape, including any details, should be described in the target architecture. Often, some parts of the target architecture are more elaborate and concretely described, while others may be relatively abstract. It is common that certain parts of the target architecture are only placeholders, showing that an area has been identified but that the target is not yet described. In some organizations, there may be a need for several target architectures. Alternatively, the target architecture may be divided into several distinct parts. If activities and conditions look radically different for different parts of the organization or different parts of the IT landscape, the target architectures for these different parts are also likely to look different. The city plan's division into different domains is the natural starting point for identifying the need for division in the target architecture. What does the target architecture describe? The target architecture may describe a variety of aspects of architecture that reflect choices out of possible solutions. Each organization needs to select the relevant perspectives to be described to define the organization's goal architecture. The organization's governing principles should provide guidance to help focus both on what perspectives are most important and how to design the target architecture. The list below shows some typical examples of perspectives that a target architecture can describe. The possibilities for different perspectives, variations and combinations are infinite.
I The target architecture needs to be described at a conceptual level."
• What applications should be available (related to the city plan)? • What features should the applications have? • How will the systems be implemented (rent/buy/build)? • What might the dependencies between different parts of the system landscape be? • How will different parts of the system landscape coordinate with each other? • Are there common platforms? • What integrations are necessary? • What product or design choices need to be made?
ENTERPRISE ARCHITECTURE
2.9.2.
Description Mode
There are several ways to describe a target architecture. The different ways of expressing the target architecture can be used separately or in combination. However, expressing the same thing in several different ways should be avoided. One of the most common ways is to use a set of conceptual models, displaying architecture from different perspectives using images and descriptive text. One model may show operating systems while another shows infrastructure and storage solutions, etc. The models must, of course, be consistent and fit together because they are views of the same whole. Another way of expressing target architecture is by using concrete architectural principles. For a principle to describe a target architecture, it needs to be so concrete that it can be directly translated into a solution. Direct design guidelines can also be used to describe a target architecture, such as how to use the target architecture, or that a platform or a particular design pattern should be used. It is also useful to include non-functional requirements for how to design architecture. These are then handled in the same way as other non-functional requirements in the organization, although the architect should take ownership of architecture-related non-functional requirements. The description of the target architecture needs to be as concrete as possible to facilitate the work of developing solution architectures. However, a very detailed description of the target architecture can become obsolete faster than a more conceptual description, can create more maintenance work and can also present the target architecture as cumbersome, requiring frequent changes. One way of dealing with this is to extract very concrete design guidelines and product choices into a separate annex that can be updated more frequently than the target architecture itself, which can then be kept more conceptual and stable.
2.9.3.
Reference Architecture
Reference architecture focuses on a particular area or an architectural domain in more detail than the target architecture. A reference architecture is a generic but detailed architectural template that can be copied straight into solution architecture and given to system architects or developers. A reference architecture is developed to complement the target architecture and guide the architecture in more detail in specific areas where this is justified. For example, it could be for an area where the organization has chosen to develop IT solutions internally. The reference architecture thus supports control of architecture so that development is done in the same way, with the same tools, towards the same platforms, etc.
I
I
Reference architecture focuses on a particular area or an architectural domain in more detail than the target architecture."
53
2.9.4.
91 Target architecture needs to be a living document."
How Is the Target Architecture Used?
Architectural principles govern architecture and solutions at a high level; from the abstraction level of a principle down to a solution is enormous. The city plan scopes the solution a little more, but it is still at a high level. Architectural principles and city plans provide a focus and some support in designing new solutions, but there is room for more concrete guidelines. Here, the target architecture comes in and points out the focus for new solutions at a relatively concrete level. It describes the already defined architectural choices and boundaries, making the design of new solutions easier, as the number of architectural questions that need to be investigated and answered decreases. When a new solution is to be developed, it needs to be designed in a way that fits and can coexist optimally with an architectural environment. If a new solution is to be designed to fit into an upcoming architecture, the upcoming architecture needs to be described. The target architecture does just that. It is then also reasonable for it to be used as a reference when examining new solutions. Another use for target architecture is as a basis for designing IT strategy and IT plans. By predicting a future situation, the target architecture can drive conclusions and orientations for future outsourcing and the need for skill-set changes in the IT organization, etc., so that these aspects harmonize with future architecture. An additional way to use the target architecture is to identify (through comparisons with the current activities) what needs to be carried out to move towards the target architecture. A prerequisite to this is that the current architecture needs to be described in the same way as the target architecture. Usually, there are more detailed descriptions of the 'as-is' architecture. These are often needed in many different contexts, but for this purpose, a more conceptual description that matches the description of the target architecture is the most useful. With the present mode and target mode expressed in the same terms and models, it is relatively straightforward to make comparisons and complete GAP analyses to identify what needs to be done to move the architecture from the present mode towards the target architecture.
2.9.5.
Management of Target Architecture
Target architecture needs to be a living document. The conditions and needs of the organization are constantly changing, thus also changing the business's IT needs. IT is beginning to be used in new ways and new needs arise. The organization's knowledge of IT as enablers and their own IT needs also mature and change over time. All this needs to be reflected in the target architecture.
ENTERPRISE ARCHITECTURE
Technological opportunities are also continually changing, perhaps even faster than the organization and business. Technology and architecture trends come and go, products and components change, markets change, dominant suppliers lose ground while new starters stabilize and become established. These factors are also the basis for the target architecture. Target architecture needs to be developed in line with its conditions. Work to maintain the target architecture needs to continue and be ongoing. It is often difficult to establish new versions continuously because this involves some work in anchoring, determining and communicating a new version. However, such work should not be addressed too infrequently either. A balanced trade-off depends on several factors. A new version per year may be a good benchmark but depends on the type of scope and organization.
2.10. Architecture Governance/Governance In architecture, governance - or architectural governance - is about controlling the architecture, as well as the model it uses to achieve this. How do you control architecture? If we don't know which direction to take, there's no point in governing. The architectural principles, city planning and target architecture described above are all about defining how we would like the architecture to be, to describe the desired state. With one or more of these in place, we know what we are steering towards. What does architecture governance contain? Many different models, methods and frameworks address architectural control, ranging from concise, good practice to extensive and complex frameworks. These frameworks can best be viewed as toolboxes. Not all tools fit for everything and in all situations, however. It can also be difficult to use too many tools at the same time, particularly if you operate in a medium- or small-sized organization. The size and maturity of the organization often determine which architectural control methods are suitable for use. This section describes some architectural control tools that should be in the architect's toolbox.
2.10.1. Adaptation of Architecture The needs, objectives and strategic direction of the business, together with the IT strategy, govern how architecture needs to be designed. The desired architecture, the architectural target, is designed primarily according to these parameters. However, it's a moving target. New needs, changes and trends both within and outside the organization are continually creating new conditions for architecture. The map of the architectural target needs to be continuously reviewed and updated so that development projects can be steered in the right di-
In architecture, governance — or architectural governance — is about controlling the architecture."
55
56
rection. This work needs to be carried out continuously. However, updating the target image requires a relatively comprehensive effort. Pre-study and design work, documentation, anchoring, fixing and rolling out all need to be carried out. One approach is to work continuously on these issues in cycles, with each cycle ending in a new release of the target. How often the target image needs to be updated is primarily driven by how fast the business changes. In a more static business, a frequency of every three to five years may be enough, while the target may need to be updated more frequently in a more frequently changing business.
2.10.2. Communicate the Architecture It is not enough to develop and determine the goal of the architecture. If it is not communicated, no one knows about it and it will not exist in practice. A minimalistic approach is to publish the architecture on an intranet, but that's not enough. The architecture needs to be communicated and marketed to different stakeholders in a way that fits the addressed target group. People in management positions need to understand the business benefits. Since adherence to the target architecture often involves more cost or at least some inconvenience to development projects, management needs to understand, support and defend architecture. Those who are going to use the architecture, e.g., solution architects who shape solutions adapted to the architecture's target, need to understand the architecture in more detail. This group requires more communication and possibly education.
2.10.3. Controlling Change
I
I
It is not enough to develop and determine the goal of the architecture."
The change made in the IT landscape and any effects on the architecture need to be steered in the right direction. In principle, this can be done in two ways: partly by supporting and guiding projects in the right direction and partly through formal governance. Support and guidance can be provided in many ways, e.g., by describing and explaining the benefits and positive effects of the desired architecture for the entire organization. In this way, it is often possible to influence the individual project to move in the right direction. The most important thing is that the architect is involved early on in the solution design. It is preferable to aim for a balanced solution that meets the needs of the project while harmonizing with strategic architecture. However, this doesn't always work out, in which case there is no formal governance of the project's solution. Governance needs to be based on governing principles, city plans and target architecture and should be carried out through the Architecture Council's review.
ENTERPRISE ARCHITECTURE
2.10.4. Drive Change Directing the development projects that are being implemented is one aim. Bringing about change for purely strategic reasons is a separate aim. Changes in the IT landscape are almost always driven by some concrete business needs. It is often difficult allocating space and resources for a strategic development that, for example, establishes the architecture for future projects but cannot demonstrate a directly measurable business benefit here and now. Sometimes such a plan is the best way forward for the organization although perhaps only the architect sees this. Other possible yardsticks may be reduced risks or reduced technical debt. Another challenge may be that the benefits of the strategic venture cannot be brought home in the same profit unit where the cost are accrued. The architect can often see these connections, but it can be an educational challenge to convey the insights and clarify consequences to the responsible(s) who control the relevant budget.
2.10.5. Architectural Documentation Strategic architecture documents serve several purposes. Strategic architecture documents — such as the city plan and the target architecture — are vital to the management process because they describe where we want to control architecture. The fact that we produce these documents means that we have to design and describe an architecture that best supports the needs and objectives of the organization and that fits well with the IT strategy. The architecture documentation is also a tool for communicating the architecture, e.g., to the projects that will realize the architecture, or to help harmonize with such projects. How can the project be realized or harmonized if these stakeholders don't know the plan? Architecture descriptions of the current situation are also relevant. In addition to the fact that current descriptions are part of the basis for the strategic direction of architecture, the current descriptions are a vital tool for development projects. For stakeholders to realize their contribution towards the city plan or target, they don't just need to know what the target means, they also need to know what the architecture looks like today. It's not enough to know where to go. You also need to know where you are.
2.10.6. Architecture Council An Architecture Council can fill several functions, but one of the most important is to monitor the development of IT landscapes and architecture and compare with current strategies, guidelines and governing principles. From this point of view, the Architecture Council is a quality assurance body that
Architecture documentation is also a tool for communicating."
57
58
I
The Architecture Council reviews all initiatives that have the potential to influence the IT landscape."
helps to ensure that IT investments have maximum effect. The Architecture Council reviews all initiatives that have the potential to influence the IT landscape. Even minor changes made within an organization need to be examined, because even small changes can have a significant impact on architecture. A review of the architecture needs to take place before the change begins. Before the review, an intended solution must have been defined; otherwise, there is nothing to review. An effective way of regulating the time of review is to have the Architecture Council as a checkpoint that must be passed before the project is allowed to progress to the implementation phase. Integrating the Architecture Council into the regular governance of the business eliminates the discussion that many organizations enter into over which projects and other changes need to go through the Architecture Council. An Architecture Council can review different types of IT-related issues. What issues the Architecture Council reviews are governed by what issues the organization has chosen to regulate in their guidelines and governing principles. It's sensible to monitor adherence to strategies, city planning and the target architecture. Issues the organization wants to govern don't necessarily all need reviewing by the Architecture Council, but it is vital to identify and agree on which issues the Architecture Council reviews and takes a position on. Most commonly, the Architecture Council looks at issues related to technological architecture, security and infrastructure. Questions about information management are also often examined, such as adherence to master data or conceptual harmonization principles. Issues linked to processes can often be more controversial raising the query over whether IT should dictate operational processes. Many issues are, of course, not usually dealt with by an Architecture Council. The Architecture Council is staffed by individuals with competences relevant to the issues the council reviews. Relevant expertise must be represented. If architectural governance has a broader organizational scale, there also need to be representatives from the various branches of the organization, sister companies or other interested parties. Large organizations can have several Architecture Councils to cover the whole of the organization. It is also possible to divide Architecture Councils according to architectural practices, such as a council for application and information architecture and another for infrastructure architecture. But multiple Architectural Councils mean more bureaucracy so there is then a need to find a reasonable balance between the ability to review projects and the amount of bureaucracy. The Architecture Council is tasked with reviewing and assessing issues based on a regulatory framework. For the Architecture Council, the regulatory framework consists of governing principles, architectural principles,
ENTERPRISE ARCHITECTURE
city plans and target architecture. But these rules are not always enough and may not provide answers to all the questions that arise. The Council also needs to have good analytical abilities to assess whether the proposed solution is the best to support the needs of the organization. As an example, if the review finds gaps in a city plan or target architecture, it is essential to capture the issue and return feedback on the work of city plans and target architecture. The approved solution will be a contract between the project and the architecture governance, which in turn describes the solution the project may build. It is not uncommon for the solution to deviate from the audited solution description. Often this is done on reasonable grounds because conditions or the project objective may have changed. However, it can also happen because the project is trying to take shortcuts or ignore a shared architecture responsibility. One way to deal with this is to let the project report to the Architecture Council on what has been built. Although it is usually too late to change anything, the variation will not go unnoticed. For the Architecture Council to operate effectively, it must have legitimacy. Management must be behind the Architecture Council and the Council's actions must be sanctioned by management. After all, the Council serves as management's right hand in ensuring that guidelines and strategies are followed. Management backing also facilitates everyone understanding why the Architecture Council exists and what benefit it has to the organization. Legitimacy is essential because the Architecture Council's view of various issues does not always match the project team's view. Project teams and Architecture Councils, therefore, sometimes disagree. This is a natural part of the process of weighing up short-term focused perspectives and long-term holistic perspectives. Often, we can resolve such issues through reasoning, discussion, argumentation or compromise, but for when we cannot agree, there must be a controlled way of dealing with the issue. The Architecture Council rarely has a mandate to stop a solution or a project altogether, so if councils and projects do not reach consensus, the issue escalates. There then needs to be a body with a sufficient mandate to decide on the issue. For example, this might be an IS/IT Council, CIO, director of administration, or a higher Architecture Council. The important thing is that the body can weigh the need for activity against the consequence of introducing the proposed solution. It may be commercially appropriate to depart from principles, guidelines and target images. However, if this approach is adopted, it should be done with the knowledge of risks, future additional costs, or technical debts which may be incurred.
11,
The approved solution will be a contract between the project and the architecture governance."
59
2.11. Architecture Evaluations The quality of an IT system depends much more on its architecture than on code-related factors such as implementation language and detailed design. Aspects such as performance, scalability, modifiability, security and reliability are typical quality metrics directly influenced by the system's architecture. It may be virtually impossible in an IT system to achieve sufficient quality in these respects if the wrong architecture has been chosen from the beginning. Architecture assessment is about assessing from a description of the architecture, whether a system can achieve the architecture-related quality measures required.
2.11.1. Benefits
11 There are two basic approaches to finding defects in IT solutions."
There are two basic approaches to finding defects in IT solutions — one is to review different artifacts describing the system and the other is to test the complete system. Both approaches have their value and to find defects for each system to be developed, a trade-off needs to be found to best divide effort between the two approaches. When it comes to a system's architecture, it is often too late to take remedial action when the system testing phase begins. While bugs or minor design errors tend to be relatively easy to fix, if the system has been built on the wrong architecture, you may need to start again from scratch. Even in a best-case scenario, changing the architecture is often very costly. In a project with a tight timetable and limited budget, it may be impossible. The result is a project delivering a system with flaws that are too costly to fix. An architecture evaluation aims to detect flaws or risks related to architecture. An early-stage architectural evaluation can predict severe problems in an upcoming system. The bigger and more critical a system is, the higher the consequence of a flawed architecture. For these systems, a comprehensive architecture review is a well-spent allocation of resources. An appropriate time for architectural evaluation is when the architecture has been defined and described, but before the implementation begins. At this point, there are sufficient documents for the basis if an evaluation and the costs of addressing any deficiencies in the architecture are still relatively low.
2.11.2. How Is Architecture Evaluated? To evaluate architecture, two types of evidence are mainly needed: a description of the architecture and quality measures against which to evaluate. In addition to a pure architecture description in the form of different models, sketches and descriptive texts, a list of architectural requirements provides a sound basis. Even architectural decision-making documents with the
ENTERPRISE ARCHITECTURE
evaluations of different candidate architectures provide useful evidence. The quality measures against which the architecture should be evaluated must be clear and measurable. It is not enough to say that the system should be safe and have excellent performance. What should the system be safe from and from what perspective? What does 'excellent performance' mean and under what conditions? Quality measures should also be prioritized. An architecture may meet specific quality measures at the expense of others and the choice of solution is then guided by which measures are most important. One way to deal with this issue is to have traceability between business needs and quality measures. With traceability, it is also easier to weigh the costs of any architecture-enhancing measures against the benefits they create. A standard method for the actual implementation of the evaluation is to set several scenarios based on quality metrics and evaluate how the architecture handles these scenarios. A credible architectural evaluation is not conducted in 15 minutes. It contains several work-intensive moments and can take several days in its entirety. The evaluation is run by a team that, in addition to architectural expertise, also knows what an architecture evaluation is about as well as the goals. In addition to the team, roles such as project architects, project clients, business analysts and requirement owners need to be represented during the evaluation, even if not everyone needs to be involved in the whole process. Several established methods are available for the architectural evaluation of which Architecture Tradeoff Analysis Method (ATAM) is the most common.
2.11.3. Evaluation Results The most important result of an architecture evaluation is identification of any risks and deficiencies related to architecture, which can be managed at an early stage. Ultimately, the process leads to better architecture and a higher-quality system. A completed architectural evaluation also has positive side effects. A prerequisite for the evaluation is that the architecture must be documented in detail. The quality measures that the architecture is evaluated against need to be both described and quantified. This is an excellent basis, for example, for system design, sizing infrastructure and, not least, tests.
'J1 A credible architectural evaluation is not conducted in 15 minutes."
61
2.12. Requirements and organization As previously discussed, EA work is based on the strategy both within the business at large and within the IT organization. Strategic goals give us a simplified picture of where we want to go, and the principles provide guidelines on how to get there. Together, these EA functions provide a good foundation for how to navigate in the long and medium term.
2.12.1. Mission, Vision and Goals
One of the EA feature's most essential tools for controlling architecture is communication."
Mission The EA function is responsible for the high impact of the business benefits from its systems, a comprehensive strategy for future functions and IT investments and for ensuring the business's IT architecture is cost-effective. The EA function is responsible for balancing goals and funds so that the company gets the maximum benefit from the money invested in IT. Although the EA function often lacks formal decision-making power in individual projects, it has excellent opportunities to exert its influence, partly by being responsible for several governing documents, such as principles and guidelines and partly through recommendations to the project and the steering group through the Architecture Council. Vision Projects and changes initiated or proposed by the EA function should, by definition, be rooted in strategic objectives and principles and be in line with agreed visions. One of the EA feature's most essential tools for controlling architecture is communication. If established strategic objectives and principles are well communicated to different governing audiences within the business, the likelihood that projects are in line with a shared organizational vision increases. In organizations with a more mature architecture approach, ambassadors serve in various architect roles around the organization to catch early deviations from strategic goals and principles and manage them. In organizations to which architectural thinking is being applied, you need to find allies who sit in critical positions, such as IT management, possibly project offices and different decision forums in the business, etc. As an architect, you should develop a communication plan. Continuous communication through dialogue keeps the vision alive and thus also affects daily work. Goals — project objectives All organizations have some initiatives that go against the architecture for many reasons. It is still vital to approach these initiatives positively. To di-
ENTERPRISE ARCHITECTURE
rectly try to shut down the initiative or cite strategic objectives and principles often fails to lead to anything constructive. Keep in mind that much time, energy and prestige lie behind the initiative. To meet the initiative with a negative and blocking attitude creates distrust and a sense that the EA function is serving to police the organization. A better way to meet these initiatives is to engage in dialogue with the people who are behind the initiatives to understand why they have chosen a certain approach. These dialogues can lead to changes in the objective of the initiative, which makes the initiative fit better into the shared vision. Even if this doesn't work for a specific case, you will at least have the opportunity to explain how the initiative doesn't fit in and the future consequences in terms of costs, complexity, quality, etc. Be prepared to compromise in the dialogue. What is most important for the business? If the most important thing is to maintain a central order flow, it may be possible to accept that the project needs to build direct communication with the carrier, without going through the designated integration platform. Try to get the people behind the initiative to present themselves what can be improved, by helping them. For example, consider a company using a web publishing tool, A, for 20 markets and eight focus sites entirely according to established web principles. A project wants to create a ninth focus site to be based on the tool B, recommended by the advertising agency. You can then ask questions about who the editors will be and whether they want to work with several tools and what training is required. You can ask about management, future development and upgrades. If this dialogue is managed constructively, the people involved in the initiative will hopefully actively seek out the EA function for future projects. The important thing is not to go into the discussion to win. Sometimes deviations from strategic goals and principles are also a way of learning new things. There are situations where the EA function needs to make a decision, either by itself or with the support of IT management or other decision-making bodies. Examples of this are when solutions that do not conform to legal requirements or government regulations to which the business must comply. Objectives — priorities Projects and changes often relate to the classic "Time, Cost, Quality" triangle, where you can prioritize one or two items but not all three. Quality is often the focus for the EA function, but it is also important to spend time on projects that prioritize time and cost. If the project has access to a solution architect, this is the most logical way to ensure that the project follows set goals and principles and that any deviations are documented and justified. There are, of course, priorities other than Time, Cost and Quality that influence architectural work. For example, an important customer may re-
ee Be prepared to compromise in the dialogue."
63
64
quire communication through an old network protocol that goes against the current principles. The important thing here is to keep a systematic track of the exceptions and have a regular review of documented exceptions.
2.13. Requirements Management In general, the EA function doesn't work with requirement management on individual projects. However, the EA function should offer a set of template requirements based on the strategic goals and principles. These template requirements are basically of two different types. Product requirements — describe the results of the project Examples of product requirements could be the characteristics of a system (the system must log all incorrect login attempts with IP numbers, a timestamp and user ID), characteristics of documentation (the management documentation must contain...) or other aspects of what the product should deliver.
ee In general, the EA function doesn't work with requirement management on individual projects."
Project requirements — describe what or how the project should work Examples of project requirements are that the preliminary study should evaluate at least two different solution proposals and make a recommendation for a solution. Other examples might be that the project should use tool X to document the architecture of the chosen solution or that the project should synchronize with the Architecture Council for each milestone. By having a thoughtful structure of principles that in turn are broken down to project and product requirements, the EA function can quickly help projects do the right things from the start. If the requirements come from principles that are not relevant to the project, they can be marked as non-applicable. The great advantage of working in this way is the traceability from strategy down to requirements on individual projects, which helps with prioritizing work. If the project team reports that they don't have time or can't implement requirement X, it's easy to see which principles suffer as a result. It is important to point out that the requirements of the EA function rarely affect the actual functionality one wants to get out of the solution, but rather how the solution should fit into the larger landscape.
ENTERPRISE ARCHITECTURE
2.14. EA Work in Practice 2.14.1. Architecture Processes So, what does an enterprise architect do in practical terms? No EA work is similar to another, although some basic activities recur. Where in the organization you do the work plays a big role, just like how mature the architecture in the organization is and what resources you have for help. Working with change The EA will help the organization to set strategies and visions to improve the organization's ability to change. It should, therefore, be used, maintained and updated continuously as the organization changes and strategies are reviewed. An organization is constantly changing. Like any process, the architecture process has a starting point, a clear end and activities in between. The completion of the process does not mean that the EA is complete but after completion of the architecture process, the result is handed over and used depending on the company strategy and purpose. Purpose A general purpose of EA is to facilitate the change of an organization and to unite the business with IT. The start-up of the architectural work can be directly derived from the long-term plans and business objectives. If a leading strategy for an organization is to consolidate its business to become more flexible and cost-effective, architectural work can be initiated to support this strategy. Different types of architectural work need to be distinguished. EA work is not the same as, for example, IT architecture work. It is easy to stare blindly at system landscapes. However, for an EA, the system landscape is only a part of several things to be considered, such as processes, roles, interactions and business capabilities. What is the purpose of your EA work? Is it a holistic approach to the overall organization for a first implementation, or is it a focused work in a particular area? The purpose of the work should be considered before starting the work. It is not uncommon for architecture projects to be questioned by those who do not work with architecture daily. You can save much time and energy if all project members are involved from the outset and they understand the work. Project members can then help share their knowledge and help raise awareness. Delimitations Work should be delineated to be made realistically and practically feasible. Many large architectural programs end prematurely; by setting an ap-
65
66
propriate scope, you can create better opportunities to succeed. A clear scope also contributes to a clear end with a clear final delivery. TOGAF advocates four dimensions for demarcation: • Business scope - should work be delimited to one or more departments? Which departments? Architectural domains - which domains should be affected? • • Level of detail - at what level of detail should the work be done? If it is an overall 'to be' map, there will be fewer details, and if it is a short-term effort in a specific area, the level of detail should be higher. • Time limitation - how long is the work expected to take? Sponsors and steering group If the work is a major project with a strategic impact, you should identify sponsors and form a steering group. The members of the sponsor and steering group should represent both the business and IT. One risk of architecture work is that it fails to have sufficient support and priority in the organization. To get support, you have to educate and inform staff about the value of work because the value of EA is not always obvious to the uninitiated. Take the time necessary to inform staff about the work and its expected value to all involved before the work is started.
I
One risk of architecture work is that it fails to have sufficient support and priority in the organization."
Tools and aids Before starting with the implementation phase itself, it should have been decided which tools to use for documenting and which methods to use. The choice of tools, such as for documentation of artifacts and results, should reflect the organization's maturity and the level of ambition of the architecture. MicrosoftTM Visio may be an excellent choice for one organization and an entirely different tool suite may be required for another. Implementation phase The purpose and conditions identified in the start phase set the framework for the implementation phase. The choice of method determines how to work, and the choice of tools determines how to document the results. Everyone who works with architecture must work according to the same method. The architecture work itself does not always have to be so structured, but what is produced as a result should be structured to facilitate reuse, among other things. Activities The activities of architecture work are partly guided by the framework or method. Many general activities are usually carried out in EA work. Usually, you start by collecting materials to analyze. The extent and detail of information to be collected are set for the purpose and demarcation
ENTERPRISE ARCHITECTURE
identified and determined in the start-up phase. Collecting information can be done in different ways. Common ways are workshops and interviews with selected people who hold valuable knowledge, to review already produced results or documentation such as process flows, strategies and system maps. When the information has been collected, it should be analyzed to shape a hypothesis. The analytical activities can be done in pairs or together in groups. It can be difficult for a person to analyze all the information and shape the hypothesis. In smaller organizations, it is not uncommon for there to be only one architect. Find stakeholders to discuss ideas and conclusions with. Hopefully, the conclusions, in turn, lead to an activity to be realized: this may be a new design or direction, for example, for the creation of a new design or orientation—a domain area or development project. The implementation of a new design should be planned and mapped. For example, a conclusion of the analysis work may be that a new guideline for technical solutions in the CRM area needs to be developed. This guideline must, of course, be explained and communicated for the organization to be able to enlist the organization's help. Don't get caught up in theory! A common misconception about EA is that it is only paperwork with boxes and maps, frameworks to be followed and principles to be developed. In other words, static work that easily ends up and stays on a theoretical level. But EA is much more than that. EA is a tool of change. Don't get caught up in methods, frameworks and tools. In the end, it is the result of the architecture work that is most important. Producing a result that supports the organization practically and promotes change work provides a greater understanding of architecture. Act in an advisory and solution-oriented manner and be an architect that facilitates work. Closures and handovers The result should be decided and documented when it is formally handed over to the role that owns and manages the work. A decided and documented EA result does not mean that it is set in stone and must not be questioned or developed. The EA must continue to develop as the organization is re-evaluated in the face of major strategic events. As an architect, you should be open to dialogue and receiving feedback and even criticism. If the feedback is so tangible that you can see the architecture needs to be re-evaluated or developed, this should be done formally with a new decision. The EA will guide and support the organization in its development, but it must also be followed as well. This stage is supported well by the EA role being open to communication and being able to discuss the meaning of the decision without being defensive. No EA is set in stone, but you must be able to take questions and new points of view and evaluate whether this affects the EA or not.
Don't get caught up in theory!"
67
68
EA covers the entire organization and not just the entire IT organization."
Different types of EA activities There are many different types of EA activities. One of the most common examples is creating a roadmap. An EA roadmap visually describes a company's entire organization, such as processes, roles, interactions, business abilities and system support. Traditionally, you start by documenting the current situation, i.e., IT landscapes, processes, capabilities, etc. and then build a 'to-be' target. Then a detailed roadmap is created; plans are made that describe how the organization can get from the existing situation to the future solution. It is important to build and plan roadmaps based on the company's visions of the future and strategies. What long-term business models should one support with EA? EA roadmaps can also be used as decision support through direct input to development and change projects. In some cases, it may be better to start with the stock market situation, for example, when dealing with future information needs, as today's image can sometimes distract and make work more complex than necessary. These major EA activities take longer both to implement and to get decisions for starting. One way to show rapid, concrete results of EA work is to do so on a limited scale in the context of consolidation or efficiency work. In this way, understanding and acceptance of the value of architecture can be acquired. Where in the organization is the EA function? EA is usually linked to IT and technology, but it is important to remember that EA covers the entire organization and not just the entire IT organization. An EA work should, therefore, be driven by the business and carried out by both the business and IT together. Depending on the scope of the work, your EA work may focus on IT parts and that requires extra strong commitment and sponsorship from the business. It is common for EA work to be run from a staff unit, such as Corporate IT or similar, which is not so strange because the enterprise architects are usually placed there. Wherever it is driven from, the work must be done together with architects, analysts, process owners, product owners and others, throughout the whole organization. Many enterprise architects comes from the IT business, which has resulted in a focus on IT. However, the EA responsibility is now creeping closer to the business side and with extra focus on skills and governance that bridges the borderland between IT and the business.
ENTERPRISE ARCHITECTURE
2.15. Communication, Decision and Anchoring It is at least as important to communicate and spread the EA as to work it out. Working with architecture is to work socially and communicatively. It doesn't matter how many hours you've spent developing the "perfect" EA for your organization, if no one knows it exists or how to use it.
2.15.1. Why Communicate the EA? As an architect, you should avoid creating ivory towers; that is avoid developing an architecture that only architects know exists or understand. If you have closed your doors in this way, it's going to be hard to reopen them. It will be an almost impossible job to make an impact with an architecture that no one knew existed and even harder to get it anchored.
2.15.2. Don't Keep the Architecture a Secret There are many different aspects of communication in architecture work that should be considered. The work should be communicated before you start doing the job, regularly during the job and, of course, when results are published. You should start by communicating the purpose of the EA work as soon as it is decided that the work should begin. This should not be communicated before a formal decision is taken that work will begin. Otherwise, in a worst-case scenario, the communication will lose your credibility, if a goahead decision is not awarded. Communicating at an early stage is mainly aimed at creating an interest, commitment and a sense of participation. Communicating during the work is mainly aimed at maintaining the interest and commitment that hopefully laid the groundwork. Architecture work can span over a long period. It is, therefore, particularly important to keep the interest alive so that the work is not forgotten, or worse — that the people you took time to include at an early stage start to feel excluded. It is also essential to communicate the effects and results of architecture work. EA jobs tend to be seen as theoretical, so this is a great chance to show something concrete. Keep in mind that only a model or map is not enough. What does it mean? How should it be used? How can support be facilitated? Be personal and show practical examples for a specific role or group in the organization. Keep in mind who you need to present the result to and highlight the aspects that most concretely affect their work or interests so that they recognise the relevance.
69
70
2.15.3. Before Work Begins
VV It is too late to start communicating when the architecture is already complete."
Imagine you're a group of architects secretly living in your virtual city map. You know every part of your virtual city, but no one knows who you are or what you're doing. This is unlikely to make you popular. Employees may become anxious and suspicious. They may wonder what you are doing in their neighborhood and why you are looking around without informing them first. It is extremely important to take advantage of the skills that employees, who are closest to the processes and system solutions, have. Giving people a sense of participation helps them to feel included and helps them to work towards common goals. Please communicate for preparatory purposes. It is too late to start communicating when the architecture is already complete. Transparency and communication are required by the architect to gain participation and commitment. That's why communication about the intended EA work should be started before starting the work. For example, the work may be about saving time when choosing integrations, predefined functional divisions between systems, evaluations of new technologies and how well they fit in or belong in the organization's strategies. Start by communicating that this work needs to be done, why it should be done, what its purpose is and what the expected benefits of the result will be. Focus on your target audience and how they fit into the big picture. A product owner or product developer may not see the benefits of EA at first, as it is often strongly associated with IT. A system architect may at first think EA sounds way too high-flying to have an impact on what he or she does. A product owner probably doesn't want to look at system maps and integration but is more interested in the business functions used to deliver and develop the products.
2.15.4. During the Work It is generally more difficult to assimilate, understand and accept completely new information, which falls outside your comfort zone. It can also be more difficult to convey information you are completely familiar with at the right level to someone who knows nothing about it. The entry threshold will be high and the gap between intermediaries and recipients is very large, because recipients and intermediaries have very different frames of reference. By communicating continuously during the work, frames of reference are developed together, which encourages participation. The architect's communication habit plays a huge role here. How often and how much one should communicate varies on a case-bycase basis and also depends largely on the target group. Some target groups only want new information, while other target groups want continuous communication, with valuable information repeated. Some audiences see repetitions as trusting and safe, while other audiences see it as a waste of time.
ENTERPRISE ARCHITECTURE
2.15.5. Participation We need to include project members who are actively involved, but participation is also required at a higher level with various stakeholders such as internal sponsors and steering groups. It is worth repeating that EA should not be carried out by an isolated group of architects, who, in many cases, have organizational affiliation with IT. In this way, the activities are easily perceived by outsiders as pure IT initiatives, whereas EA should be driven from the business together with IT. If you have been part of a job, you usually support it as well, because you have been engaged.
2.15.6. Decisions and Anchoring A decision doesn't have to mean anchoring. Sure, you can try to force anchoring through a decision, but then it will not be much more than a decision on paper. Such decisions are called into question and may be rescinded. How a company handles and follows decisions reflects, to some extent, the corporate culture. Smaller companies with shorter decision-making ranks and more transparency tend to handle decisions and anchoring in a different way to large companies with deep hierarchies and much information buzz. EA is not about making it more difficult for anyone in the organization. On the contrary, it is a tool for change management. Policing or hindering development is the last thing you want to do. Results are more easily achieved by creating participation in and commitment to the architecture work with continuous communication in the organization. A result with a traceable purpose and concrete value is also more easily anchored. With such an outcome, the organization can make a decision that does not need to be advertised. The goal of the EA should be to get the work understood, anchored and used throughout the organization.
2.16. Methods, Standards and Tools Behind every EA, there is a plethora of views and choices that have led to the realization of an organization's city plan. This section deals with some of the resources available to enable architects to transform the city plan and the work processes available in an organization into some form of useful support.
If you have been part of a job, you usually support it as well, because you have been engaged."
71
72
2.16.1. You Can Put the World Together with a Hammer and a Nail In the same way a carpenter uses a hammer and nails to build a bookshelf, architects can use frameworks and tools to build parts of a business, expressed in the form of a class, a conceptual model, or perhaps a whole IT solution. The recipe behind a successful EA is discussed in the EA3 framework. From this framework, we can picture an enterprise architect's toolbox as different components, all of which work together to create support for the business's IT. Methods, artifacts, standards, frameworks and good practice thus help EA and in turn help businesses to both achieve their vision and to maintain it most efficiently and cost-effectively. Artifacts in this case are things that show how the strategic analyses of an activity, business plans, security, workflows, systems and databases, etc. should be documented and stored. Artifacts, along with standards, create a base for which the framework can be shaped around.
Governance
Good practice
Figure 2.9 Main components for sustainable IT development
Frameworks
ENTERPRISE ARCHITECTURE
A standard must first be identified. Then it needs to be described to ensure that the standard is used by the architecture. A standard may also be affected by other applied standards, may be business-specific or may be found in the methods developed for the establishment and management of an EA. A framework identifies and expresses the scope and possible nature of the relationship and connection to underlying architectures and domains. The idea of a framework is to integrate a meaningful whole for EA; this is done through the framework, through a structure that classifies and organizes strategies, business processes, technologies, services, approaches, design concepts and standards, etc. for different architectures. Frameworks also show how the work, overall, can be done practically to create architectures that capture an organization's information needs. The important thing is to create architectural views that satisfy the architectural roles involved in EA. The blueprint for the EA is a set of resources used to develop support for an activity and is made up of the six components just described. These components should be based on good practice and guided by proven ways of implementing parts or the whole of an EA, in line with the management plan setup. Frameworks, methods, standards and tools common in EA are described below.
2.16.2. TOGAF TOGAF® is based on the technical architecture of information management in the US Department of Defense Technical Architecture Framework for Information Management (TAFIM). TOGAF has since its introduction in 1995 been reworked several times and is now available in a license-free version 9 that came out in 2009. The framework is based on an iterative process model in which good practice around its use and a combination of reusable architectural components, existing models and working methods create a clear work process to develop architectures and a method to be able to describe the information system to be developed in clear building blocks. TOGAF thus provides an opportunity for the architects to show how these building blocks shape an architectural whole (i.e., the blueprint), a common vocabulary and a collection of standards. TOGAF thus supports the EA in guiding what in the organization should be communicated for an EA work and how this should be created and maintained. The framework reflects the structure and content that architecture can have within an organization, based on four architectural views: Business, Application, Data and Technology Architecture. TOGAF is adapted to work with other frameworks as it is largely based on experience from them.
11 TOGAF is adapted to work with other frameworks as it is largely based on experience from them."
73
74
When working with TOGAF, three parts are assumed: • The Architecture Development Method (ADM) helps to develop an organizational EA based on the requirements specified. • The Enterprise Continuum is the virtual storage space where you collect all architectural assets such as models, patterns, architecture descriptions, etc., used in both the organization and IT. These support functions serve as reminders to the architect during the work. • The Resource Base is a collection of resources such as guidelines, templates, facts, etc., that help the architect to work with the ADM section.
Prelim: Framework and Principles
A. Architecture Vision
H.
B. Business Architecture
Architecture Change Management
G.
C.
Requirements Management
plementation Governance
Information Systems Architectures
F. \
Migration Planning
E. Opportunities and Solutions
1. create baseline
8. conduct gap analysis
Figure 2.10 The Architecture Development Method (ADM), TOGAF® 8, (Open Group, 2020)
7. define arch.
2. consider views
D Technology Architecture
6. determine criteria
3. create arch.model
4. select services
5. confirm bus. objs.
ENTERPRISE ARCHITECTURE
The most important part to be discussed in this book is ADM as it guides and describes in detail how the iterative work on EA should be structured to capture the architectural views that exist within an organization. The iterative steps take place both throughout the ADM process or in individual steps. All steps in the process are based on the requirements that the business provides. If a requirement needs to be addressed in one of the steps, it can help to extend a step to respond to the requirement, or if the requirement is extensive, a step can be broken down into a single dedicated process. A requirement can also lead to the removal of a step. With ADM, the architect can drive forward a change effort within an organization by controlling the business and business needs that can be translated into real benefit. Let's start with the preliminary step, which is the initiating step to build the foundation on which further ADM work rests. Therefore, it is natural that the basic requirements for the business concerning EA work start here. In the first iterative phase (Architecture Vision), the ADM itself starts the flow. The first action is to develop an overall architecture for the business, setting targets, purposes and other expectations or limiting the work of complying with the business requirements set. The next phase, known as Business Architecture, visualizes a present state followed by the desired future state. This phase describes how the business supports the organization's business goals by developing business processes, roles, structures and functions, common concepts and terms and goals and purposes for them. A gap analysis will have been carried out for different scenarios to demonstrate the need for change. It is important to remember that when we are inside the ADM work itself, there is a central phase that you always go back to, linking the work of ADM to the requirements of the business. This is called Requirements Management and can, for the iterative work of ADM, be seen as an important point of connection that affects the other phases and brings them in line with the change needs of the business. Regarding the more technical aspects for ADM, a view of what information is used in the business is required, and this work is done in the Information Systems Architecture phase, in which data architecture displays the existing data of the business. In contrast, application architecture represents the systems that support the business data. The Technology Architecture phase describes what becomes the basis of the IT infrastructure, which is based on the organization's hardware and software and where servers are located. Here everything is documented in detail according to the internal iterative process. To develop a good and thoughtful implementation plan from the previous phases, it is important to see how the work on intended solutions needs to be implemented. This is done in Opportunities and Solutions by developing an analysis of how all the solutions might affect each other. All these
se The most important part to be discussed in this book is ADM."
75
76
intended solutions are eventually implemented as initiatives in the project and Migration Planning is used to prioritize these initiatives and later update the implementation plan based on the needs of the work. A comprehensive phase is Implementation Governance, which takes all the projects implemented within the framework of EA and makes recommendations on how to implement and manage them as a whole. The final phase of ADM is to create a process of change that allows new implementations of architectures while monitoring them to ensure that they follow the development of operations in technology, needs and other aspects developed during the ADM work. When this phase is complete and as long as the architectures are not complete or corresponding to the current needs of an organization, a new iterative round of all the phases presented here begins to ensure that the architectures reach a satisfactory state.
2.16.3. Zachman's Framework
11 Zachman's framework is one of the most famous frameworks in the field of EA."
In addition to TOGAF, Zachman's framework is one of the most famous frameworks in the field of EA. Zachman began shaping EA in 1987 with "A Framework for Information Systems Architecture". In this article, Zachman suggests that a set of models can be specified by information systems and their contexts. To succeed with this, the models of these systems need to be constructed in the same way as aircraft or buildings. This evolved into the release of a version of the framework (version 3) in 2011 aimed at EA. This framework (pictured below) is based on a matrix containing six columns linked to the basic issues (what, how, when, who and why) posed about an organization, as well as six rows that represent focus based on data, function, network, people, time and motivation. Answering the six questions in the columns based on the rows, delivers composed and integrated descriptions. These descriptions correspond to the set of models that specify the IT needed to provide support in an organization but also the other types of support needed. The point of the framework is thus to support EA regardless of purpose. Zachman's framework can thus be said to be a two-dimensional organizational and classification tool that defines and organizes artifacts in such a way that it includes targets (i.e., users) and purpose in a system. The framework as a tool is based on an overall level that keeps the organization's perspective and looks down in the matrix towards the technical descriptions at a more detailed level.
ENTERPRISE ARCHITECTURE
Why
How
What
Who
Where
When
Contextual
Goal List
Process List
Material List
Organisational Unit 8 Role List
Geographical Locations List
Event List
Conceptual
Goal Relationship
Process Model
Entity Relationship Model
Organisational Unit & Role Relationship Model
Locations Model
Event Model
Logical
Rules Diagram
Data Model Diagram
Role Relationship Diagram
Locations Diagram
Event Diagram
Physical
Rules Specification
Data Entity Specification
Role Specification
Location Specification
Event Specification
Detailed
Rules Details
t
Process Diagram
Process Function Specification
Process Details
r
Data Details
Role Details
Location Details
Event Details
Figure 2.11 Zachman's EA framework Source: Wikipedia
If we look at Zachman's framework and start with the first column, describing the points of view, we first have the organization's goals that tell us how the organization is governed to achieve the goals of the business. This overarching view of the organization leads us straight down the business models of the organization to find out what is being done in the business, how this work is structured and what functions there are. The information system model shows in more detail how the information is structured within the business based on a logical approach anchored in the technology models. The models here include databases, the languages you have programmed in and which platforms are used. They show us basically how all the underlying technologies have been developed. The specified representations highlight the information behind the technical solutions (e.g., applications, networks, user interfaces) that effectively implement the technology models. System features finally describe how each column, in its part of the organization, translates its content into the form of ready-made solutions. Each line in the matrix must then be described based on the six columns where each asks a question. The questions are: • • • • •
What data are already available in the business (What?) How is this data used in the business (How?) Where is the information that data handled (Where?) What roles within the organization are related to the data (Who?) What are the lead times and the sequence in which data management is carried out (When?) • What reasons (objectives and strategies) are there for the data (Why?)
77
11 DoDAF is a conceptual model developed for guidance and rules in the development, use and management of architectures."
With the help of the framework, it is therefore possible to get an overall logical picture of the organization. This insight can be used to control and develop the organization in the most optimal way based on the structure it now has for information and processes. This knowledge creates better control over the IT infrastructure and, thus, also helps underpin faster and more effective decisions on the change work that an organization is facing. Zachman's framework thus creates a better and closer understanding between IT and business, which means that the organization's visions and goals can be ensured.
2.16.4. Department of Defense Architecture Framework (DoDAF) The US Department of Defense developed an EA whose framework is called the Department of Defense Architecture Framework (DoDAF). DoDAF is a conceptual model developed for guidance and rules in the development, use and management of architectures aimed at large systems that require complex integration. DoDAF provides a structured method that facilitates the evaluation of possible options for implementation, business changes and the development of new systems. This method comes with guidelines used to understand, develop and ensure EA and its usefulness. Version 2.0 of DoDAF divides the EA into four parts: all view, operational view, systems view, and technical standards view, all of which have their sets of models. These can be documents, graphic models, etc. and represent data for different levels within the framework. When these data are organized in the models, they are called view and when they are collected, they are called viewpoint. DoDAF has seven so-called viewpoints (capacity, data and information, functions, projects, services, standards and systems). DoDAF mainly contributes to the architectural models but also contains information about these. The interpretation of models is made through a so-called generic architecture description process consisting of six steps: 1. Determine the intended use of the architecture. 2. Fix the scope of architecture. 3. Determine the tasks needed to support architectural development. 4. Collect, organize and store data for architecture. 5. Carry out analyses in support of achieving the objectives of architecture. 6. Present results following the needs of decision-makers. Analysis between these views, together with a process-oriented solution plan for what it shows, are lacking. These things are found in most frame-
ENTERPRISE ARCHITECTURE
works in one way or another and it is precisely these that are important to remember, no matter what framework you look at as a solution for the organization. Interestingly, sometimes methods do not accommodate the rapid development an organization can face. It is, therefore, difficult to show how the methods can dynamically adapt to the changes. Remember that a method provides a structure, and a structure is mostly static, although with good points to follow, but this can make it difficult to complete projects in EA satisfactorily. DoDAF is usually used in the Armed Forces, but it can also be used for commercial activities. A similar military framework based on DoDAF was used in the UK, called MODAF V4 (UK Ministry of Defense Architecture Framework). This guidance was withdrawn on 15 January 2021 and has been replaced with the NATO Architecture Framework (NAF); this differs from DODAF in that its focus is creating opportunities to manage network-oriented processes.
2.16.5 Federal Enterprise Architecture (FEA) Whether you have a ready-made EA or not, the FEA (Federal EA) framework can assist with a method for defining or creating one. The FEA is defined as an organizing mechanism for managing the development, maintenance and facilitation of decision-making in federal EA. The framework is, as it sounds, focused on authorities and provides a structure for organizing government resources and managing their activities within EA. The framework consists of five reference models that together try to create a language within the EA that can be understood by the business, and this is done through common concepts. The reference models are business, service, components, technology and data. The framework also provides a taxonomy to collect assets in and an approach for measuring business values reached through EA.
2.16.6. Method of Methods Structured working is necessary for EA and this structure is provided by the applied method. The method describes how the work should be carried out. Today there are usually already established methods within organizations, but sometimes you must use other methods than those above. Some issues recur in most methods in terms of EA: the creation of an EA with a clear purpose, a description of the current state followed by a target view and the gap between them together with a process-oriented solution plan for what is lacking. These things are found in most frameworks in one way or another and it is precisely these issues that are important to remember, no matter what framework you look at as a solution for the organization.
I
I
DoDAF is usually used in the Armed Forces, but it can also be used for commercial activities."
79
2.16.7. Agile Mindset as Part of the Method
Agile development is done as close to the client as possible."
The most important thing that comes with the Agile mindset of EA is that it can create a strategic balance between the business, users and technology as well as an open communication link between them. In short, agility leads to stability! One way to solve the desired dynamics of the EA method is to apply the basic thoughts behind Agile system development. To meet new demands and requests from clients, it should be people and communication that lead the success to a successful job and not the exchange of reports or other documents. Therefore, all Agile development is done as close to the client as possible, with frequent and regular meetings following the development work that takes place iteratively with incremental small deliveries that serve as a basis for decision-makers. The Agile mindset lends itself well to an organization if it already applies Agile project management and Agile system development and expresses dynamic changing business behaviors. However, Agile EA will have few positive consequences in an organization that does not apply any of these approaches. Many things can influence an organization, such as events abroad, the customer, internal processes, the product and needs. All these factors indirectly affect Agile behaviors and EA: • Response to change: a flexible approach that assumes and plans for change based on short iterations and priorities of activities. • Value-driven: activity is driven by providing value to a business. Priorities are focused on deliverables with the highest value. • Practical applications: a kind of learning by doing mentality, more efficient than building a business from a theoretical basis. • Autonomous teams: working side by side but with separate responsibilities and deliveries. • Customer communication and collaboration: working closely with the customer and taking on their changing needs with time. • Continuous improvement: corresponds to the internal momentum of an organization and this should be answered by the architecture following the iterations. • Respect for people: people should always be treated with respect and as the resource whose contribution can most strongly change architecture.
ENTERPRISE ARCHITECTURE
2.16.8. AgileEA AgileEA (AEA) is a framework that focuses on an operational and EA-driven process. It is based on free open source and aims to adapt itself to the existing organization or to create a new architecture. The idea of AEA is that it should mainly be used in line with TOGAF. However, it can also work with the Rational Unified Process (RUP), Enterprise Unified Process (EUP), FEA and others. AEA applies Scrum as a working method where goal-driven sprints produce partial deliveries in phases. Agile EA can create harmony in the organization with transparency as a keyword for the Agile approach. Agile EA creates a dynamic structure where the organization's vision and goals can be incorporated even though the organization's ecosystem is constantly changing.
2.16.9. Standards in EA Standards in EA need to cover a broad front of environments operating within an organization. and this may include software, hardware, networks, applications, data, security and project management, but also environments that operate at an organizational level, such as an organization's policy. Each such environment is represented by a domain that contains the organization's guidelines and standards to support its vision and goals. Applying standards in EA supports the management of each separate domain and its architectures and methods. ISO 42010 — Architecture Description ISO/IEC/IEEE 42010:2011, System and Software Quality is an international standard that specifies how a system architecture is organized in the form of architectural views, frameworks and languages to be used in an architecture description. This standard is based on a conceptual model or a so-called meta-model and consists of the terms and concepts required to understand an architecture description. The conceptual model in ISO is presented using a UML class chart: classes of devices and their relationships capture terms and concepts for a system and the architectures used. Many frameworks described in this chapter are based on this standard, and for architects, regardless of the role, it may be well worth the time to learn the framework. ISO 42020 Architecture Process ISO/IEC/IEEE 42020:2019 Software, Systems and Enterprise - Architecture Processes is an international standard that contains a set of processes centered on governance, management, conceptualization, evaluation and elaboration of architectures.
I
Applying standards in EA supports the management of each separate domain and its architectures and methods."
81
exhibits ►
System-ofInterest
Architecture
4 identifies
♦ expresses
A has interests in
41 identifies Stakeholder
Architecture Description Architecture Rationale
0 has •
1 identifies
Correspondence Rule
Correspondence
Concern
frames A
Architecture Viewpoint
1 addresses
governs ►
Architecture View
1..*
Figure 2.12 ISOAEVIEEE 42010 conceptual model
Model Kind
govems ►
Architecture Model
ISO 42030 Architecture Evaluation ISO/IEC/IEEE 42030:2019 Software, Systems and Enterprise - Architecture Evaluation Framework is an international standard that outlines a generic framework for how to plan, execute and document evaluation of any architecture. ISO 19439:2006 Enterprise Integration — Framework for Enterprise Modeling This framework provides a uniform conceptual basis for model-based EA. It does not include process-based methods, but simply creates compatibility between the different methods and tools chosen within an organization. Compatibility is based on the view provided in the standard to identify and coordinate different modeling standards needed to describe an organization. ISO 26000:2010, Guidance on Social Responsibility The ISO 26000:2010 standard guides all types of organizations with concepts, terms, definitions, principles and practices related to social responsibility. The aim is to raise issues of social responsibility and to implement and promote socially responsible behavior throughout the organization, and this is important, especially when you divide the EA into views and viewpoints. It becomes even more important if you apply agility to the pro-
ENTERPRISE ARCHITECTURE
cess of developing the architecture of an organization, where people are more important than processes. Other governing standards for the work of EA can be extensive and require some time to understand. They are however related to EA and can be very useful: • ISO 15704:2000, Industrial Automation Systems — Requirements for enterprise-reference architectures and methodologies • ISO 15745:2003, Industrial Automation Systems and Integration • Open Systems Application Integration Framework • ISO/IEC 15288:2008, Systems and Software Engineering — System Life Cycle Processes A comprehensive and clear overall description of the functions or processes of the business provides a good additional basis for a dialogue about which parts of the business are critical. • ISO 19440:2007, Enterprise Integration — Constructs for enterprise modeling • ISO 18629:2004, Industrial Automation Systems and Integration — Process specification language • ISO/IEC 15414:2006, IT — Open distributed processing (reference model — enterprise language)
2.16.10. Notations Architectures in systems are usually defined in static structures, modules and classes, as are visualized relationships between these. For new systems, therefore, the architecture itself becomes the specification of development and the best way to define these structures is to use an illustrative graphic notation. There are many different notations, and this chapter addresses some of those most used in EA.
2.16.11. UML Unified Modeling Language (UML) is a broadly recognised method of notation and a visual language to model different types of systems, business processes, etc. from an object-oriented perspective. It is mostly used for developing software but is applicable in many other areas, such as for using software. For the EA, it is beneficial for modeling the reality to be targeted, to make it easier to understand and build.
I I Architectures in systems are usually defined in static structures, modules and classes."
83
84
Diagram
Structure Diagram
Behaviour Diagram
A State Machine Diagram
Activity Diagram
Interaction Diagram
Class Diagram
Use Case Diagram
Composite Structure Diagram
Component Diagram
Deployment Diagram
Object Diagram
Package Diagram
Profile Diagram
Figure 2.13 UML diagrams
Source: Wikipedia, public domain
11 UML has great support with different tools but is not a tool by itself."
Communication Diagram
Interaction Overview Diagram
Sequence Diagram
Turning Diagram
Notation: UML
The Object Management Group (OMG), which owns and further develops UML, has expanded the model language with the Meta-Object Facility (MOF); the current version 2 basic specification forms a basis for model-driven architecture (MDA) meta models. MOF thus contributes to the basis of OMG's concept of MDA, which helps simplify and clarify the steps between business modeling, development, integration and architecture management. MOF integrates these steps for MDA so that development and integration can take place, which means that all models that instance a MOF-defined metamodel can make use of the characteristics given through MDA. UML has great support with different tools but is not a tool by itself; instead, it can be seen as a visual language for communication, modeling, specification and definition of systems. People who believe in following methods and working systematically use UML for everything from use cases to analysis and design objects, which can be defined by various domain specifications that OMG has developed. The purpose of these domains is to provide a standardized way of representing models and design objects in UML across different scopes. Therefore, UML is an appreciated approach to EA's multifaceted applications.
2.16.12. Business Process Model and Notation (BPMN) Another graphic representation technique is the Business Process Model and Notation (BPMN). This illustrates processes for business models and can allow the business to understand internal business processes based on graphic notation communicating them in a standardized way. Also, the standard supports an understanding of the level of effort needed in the
ENTERPRISE ARCHITECTURE
Working group active
Friday at 6 PM Pacific Time
"41111111
Figure 2.14 Example of BMPN notation
Issue list
business's collaborations and business transactions, thus allowing the organization to adapt quickly to new internal and external business situations. The BPMN notation is therefore based on the process modeling that makes it possible to control who does what and which business systems to use in the processes. Process monitoring is a term used within BPMN and acts as a reporting function that tells you how good or bad the business processes and workflow operate in the real organization.
2.16.13. ArchiMate ArchiMate is an open and independent modeling language and framework developed for EA. Open Group took over and accepted ArchiMate's metamodel as a technical standard in 2009. The meta-model consists of three layers: business, application and technology. Each layer, in turn, consists of many classes and relationships between them. Each layer's class is categorized by three EA aspects that perform the behavioral aspects: • A passive structure where modeling of information objects takes place. • A behavioral structure in which modeling of an organization's dynamic events takes place. • An active structure modeling the components of the architecture. ArchiMate 3.1 is fully in line with TOGAF by supporting an independent set of concepts, enabling models of TOGAF ADM. ArchiMate's structure of
Source: Mikelo Skarabo Wikipedia, CC BY-SA 4.0
85
86
language here also corresponds to other fourth phases. Version 3.1 thus give the EA the right tools and concepts, with which views applications, processes and dependencies can easily be expressed with the same notation (UML 2.0).
2.16.14. EA Tool Support
11 A tool should be able to produce models that can represent, store, manage and share details."
What you primarily want to think about when building systems using design tools is the model you want to create and how it should be visualized. Different types of charts are used to express the different processes of a business, and it is only the finished result, i.e., the model, that counts for the EA. The choice of EA tools should be for the software that best corresponds to the development, use and handling that is expected for the artifacts to be built for the organization. Thus, a tool should be able to produce models that can represent, store, manage and share details for architectures that can be used as test tools or directly entered as decision support for the organization. Some of the most common tools on the market are those most used in EA: • Qualiware Lifecycle Manager: a tool for modeling, visualization and optimization of organizations and processes. This provides great support for business and architecture modeling. One of Qualiware's strengths is being able to engage the entire organization through a web interface in the work of models, which provides good conditions for creating common models that everyone understands and agrees on. • Sparx Enterprise Architect: this allows modeling, visualization, analysis and design of complex processes, information flows, strategies and structures found in an organization. It provides robust and effective visualization by supporting a variety of standard frameworks (e.g., TOGAF and Zachman's frameworks). The traceability of the tool creates a good opportunity to generate code and database scripts. • Archi: an open source tool that supports all levels of EA and is a popular tool for first-time users, academia but also for industry. • iServer: a collaborative modeling tool for Microsoft Office and Visio users. iServer's tools collect and manage models, documents, Visio forms (e.g., processes, applications and technology components, etc.) and other Office documents (e.g., requirements). • Software AG's ARIS Business Process Analysis Platform: a
ENTERPRISE ARCHITECTURE
repository-based tool that was originally developed from a Business Process Model (BPM) perspective but also works nicely for modeling other architecture practices with an emphasis on business architecture. Depending on the requirements of the architect, a tool can have many types of support. For example, the great advantage of UML is that since 1998 it supports an XML-based and structured format to publish and exchange UML-models called XML Metadata Interchange (XMI). This has more or less become a standard for exchanging metadata between different UML tools. XMI creates XML-based representations of UML and other objectoriented computer models, from which the files can be distributed and recreated in the same or another tool. Other types of support can be visualization or publishing models.
87
Business Architecture
Establishing, running and developing companies and organizations is a creative process. From defining the vision and ideas driving the business forward, to continuously developing and refining the operational structures so that it meets the desired goals, the work must be continuously ongoing. The main target of the business architecture is to keep all these operational structures in balance and at the same time ensure it is contributing effectively to the overall business goals and strategies.
3.1. Understanding the Business
Challenges are both internal and external."
The environment in which companies and organizations are located is constantly changing. The challenges are both internal and external. Continuously acquiring and developing new knowledge and new technology and at the same time maintaining an efficient internal business with a high service level for customers and users is an internal challenge. At the same time, there are many factors that challenge companies and organizations today. These may be changes in legislation, new market trends, new competitors, new industry standards and — not least — new customer and user behavior. The situation may seem chaotic but can be handled through a thorough understanding of the external parameters as well as the relations to — and within — the organization's internal structures and capabilities. An organization is a system with strong interdependencies. An organization is also under constant change. Harold Leavitt (19222007), who worked as a professor of psychology and leadership at Stanford University, studied behavior within organizations. In 1965, he created
BUSINESS ARCHITECTURE
the diamond-shaped system model to visualize organizations as systems with strong dependencies. He clarified four system parts and argued that if you change one of these parts it always affects the other parts.
Structure
Technology
IMINIMMMNI=MIIIMMET
People
Some examples of external factors or events within the organization that can drive a change in the business can be categorized as follows: The task of the company or organization (goal, purpose): • Adaption of changed legislations • Establishment of new customer segments • New ownership / new governance model • New competitor / disrupted market • Establishment of new activities that need to be performed or others to be replaced (e.g., based on acquisitions / mergers with other organizations) The structure of the company or organization: • Introduction of new products and features • Change in pricing strategies • Introduction of new working methods and processes • New geography, establishment of operations in a new location The people of the company or organization • New relationships defined, such as partners and suppliers • Introduction of new roles / new competencies needed for specific tasks
Figure 3.1 Leavitt's Diamond model
89
The technology of the company or organization: • Introduction of new IT applications • Introduction of new infrastructure • Cyber threats
3.1.1.
11 Business architectural work can be performed at any level of a company."
A Business Model Defines Boundaries
The business focus of a company or organization decides what it should deliver, what customer segments to target, what markets to operate in, how to compete with other players and which financial goals and frameworks to apply. These parts are what we often call the "business logic" at a high level. This logic can be described in an architectural model, the Business Model Canvas (which we will return to later in this chapter). The externally focused part of the business constitutes the important platform that defines the conditions for the business. To ensure that the internally focused operational structures are really contributing effectively to the overall business goals and that strategies are aligned to the business logic, the business architecture needs to be formulated and visualized. The externally focused business architecture is typically described in the form of a strategic platform with vision and strategy, one or more business model(s), value proposition(s) and the overall financial model. Even though it is not always labeled "business architecture" these structures are often quite easily found on the company intranet, in the business plan and the annual report. In order to achieve a result that is in line with a defined business vision and strategy, you need to understand the company's or organization's own capacity, what the strategic requirements on operational structures are, its need for business capabilities and its conditions for delivering according to expected value proposition. When you understand the company's or organization's driving forces and have these defined and described in the overall business architecture, you can deduce what capabilities the business needs, the requirements on management and governance structures, business processes, information and supporting technology. This is the main focus of the business architecture work. In the following chapters, you will get a good grip of the work of analyzing, defining, describing and changing a company or organization to effectively realize the business goal and strategies with the help of business architecture. Business architectural work can be performed at any level of a company or organization, but we will start by focusing on the highest level — the entire company or organization.
BUSINESS ARCHITECTURE
3.1.2.
Operational Structures Realize the Business Model
A clearly defined vision and a formulated strategy defines the prerequisites and internal conditions of a business and is used as a guiding star for the entire company or organization. The vision and strategy are equally important, regardless of whether the organization is a traditional profit-making business, where you can measure success in market shares and economic terms or is a non-profit organization, where you can measure success in a different way — perhaps in terms of how many people have fresh water — or how many sick people get help or are cured every day. The vision expresses why the company or organization wants to exist and for whom to create value, while the strategy clarifies the direction and focus. The strategy also sets the time perspective for the entire business operations. The company's or organization's business logic will be defined from the perspective that is best adapted to the business it is providing. It can, for example, be described from a customer perspective, product or service perspective, process perspective or geographical perspective. The operational structures realize the business model by implementing, directing, developing, optimizing, managing, supporting and following up on all the operational work performed in the company or organization This work comprises processes for identifying needs, marketing, selling and delivering the defined offers to the selected customer segments — all based on the same business logic, vision, strategy and business model. Employees with their competencies are organized in (more or less) formalized organizational units which can be internal or parts of external partner networks. In the operational work of a business, the information resources of the company or organization are used in processes that are either manual, semi-automated or fully automated. If you have a good overview of all these operational structures, you have a good starting point for future development opportunities, you know how to keep the structures in balance and are prepared for (constant) change.
3.1.3.
Non-profit Organizations Also Have Business Models
Organizations that do not have a clear profit interest, e.g., authorities, governmental and voluntary organizations, however, also have an external and an internal "focus" regarding their business. It is equally important as in profitgenerating organizations to have a good structural view of the assignment, which stakeholders to approach, what value to generate, what products or services to provide, what financial model to use etc. Even more important for this type of organization should be to ensure effective value realization and keep costs to a minimum so business architecture is a good tool here as well, to ensure business operations are aligned to the business logic.
II
The vision and strategy are equally important."
91
3.2. What is Business Architecture? An EA provides a cohesive picture of a company's or organization's structures and interrelationships. The business architecture focuses on the conditions that exist for the business, the capabilities needed for the business, the business processes, information resources and IT solutions that are needed to plan, perform, manage and follow up the business operations: everything based on — including a good understanding of — the business model to be realized. Business architecture work is about: • Creating a common understanding of the business model and its important dependencies to internal business operations like processes, information resources, IT solutions and capabilities • Harmonizing terminology and understanding of methods and tools • Facilitating optimization of the business and its IT solutions by organizing operational structures and at the same time creating conditions for coordination of change initiatives The business architecture models can be organized in the form of different views for different target groups. The most common organization of a business architecture which we are using in this book is shown in the figure 3.2.
Business model
I
.' Information
Processes
`
Business Capabilities
Figure 3.2 Architectural views: business model, processes/information/ IT Solution and capabilities
IT solutions
BUSINESS ARCHITECTURE
3.3. Why Business Architecture? Many companies and organizations today have fragmented ways of working, different and counteracting cultures, fragmented legacy IT solutions and duplicated processes. This makes them more fragile and vulnerable to damage in case of, e.g., market disruption or need for change, and they cannot move and adapt to change quickly enough. There may be several reasons for this, such as growth, business mergers or acquisitions, often with low architectural maturity and insight. New business activities and organizational departments may have been implemented within their existing working methods, tools and IT solutions that are not harmonized to the common business operations or — even worse — not aligned to the defined business model. A company or organization may have a history and culture of change which implies that parts of the business operations are using new defined working methods while others continue with old ways of working. A quite common reason for this lack of standardization is poor or unclear links between the overall vision and strategy and the supporting structures in the business operations. This misalignment often leads to misunderstandings, inefficiencies, unnecessary costs for the company or organization and — last but not least — negative customer impact. To be properly equipped for future changes and at the same time maintain efficient business operations, the important and interacting structures of the business need to be well known, well aligned and well balanced. Companies and organizations are, as we all know and have already mentioned, complex organisms with many interacting dimensions. To ensure that the company or organization is sufficiently equipped for change, we need to create the "path of understanding" with traceability all the way from the business model, vision and strategy to competencies, processes, information and technology. With business architecture, we have an important instrument that enables controlled change based on the desired direction. Focusing on business architecture has not always been an obvious part of traditional IT architecture work. For some time, however, "Business Architecture" has been defined as an architectural practice in most major international architectural frameworks.
3.3.1.
Benefits of Business Architecture
In this section, important benefits with business architecture work are listed. Stronger alignment between business strategy and business execution Business architecture contributes to organizational learning by creating shared views and a common understanding of how the company or organization works — and why. All employees from different parts of the com-
Companies and organizations are complex organisms."
93
94
pany or organization gain a greater understanding of the common vision, strategy and goals which facilitate prioritization and decisions at all levels. If changes conflict with the current vision, strategy and goals to be implemented, these should be time-limited and documented. By understanding the reasoning behind earlier prioritizations, it is possible to understand why the current situation has arisen and what is needed to change to the desired state. Clarified responsibilities When the important structures in the business are documented and visualized in architectural models, it is easier to establish responsibilities for these structures, whether concerning high-level business models with their corresponding business logic and strategic business requirements on operational structures or business goals, business capabilities, information objects, business processes, instructions or IT solutions. Modern companies and organizations working systematically with business architecture use it as input to their organizational design and organization chart.
If changes conflict with the current vision, strategy and goals to be implemented, these should be time-limited and documented."
Controlled change With a well-documented business architecture, it is easier to understand how business changes can be implemented and how to decrease the time needed for changes in processes, information flows and IT solutions. With a good overview of today's situation, architects are significantly better equipped to understand the business impact of different scenarios and to implement planned changes. A well-documented business architecture provides a good foundation for working with business growth opportunities and innovation. It also reduces distance between different departments, roles and competencies in the company or organization and increases the common knowledge based on established working methods. A significant benefit is the base for communication and increased collaboration between business and IT professionals. Reduced risk The business architecture enables us to plan and control changes with higher precision, which lets us avoid unnecessary or overly expensive development. With an overview of our business, we have good conditions to understand both ongoing changes, what changes can and probably will happen, as well as when and where. The risk perspective is in fact itself reason enough to start a systematic business architecture work — both to understand already known risks and to be able to more easily identify new ones e.g., by analyzing the business architectural models. Consistent processes, information flows and /T solutions With a better overview of the business processes, we can avoid duplicated processes and inconsistent information. A good overview of information
BUSINESS ARCHITECTURE
needs in the company or organization will help us to optimize and secure the storage of information — at least it will be much easier to make factbased decisions instead of creating new information structures when it is not necessary; a sub-optimized IT landscape with corresponding security threats will also be avoided. Smarter solutions with reduced complexity The business architecture enables improved design and development through earlier and better preparation for the use of new technology, better timing of changes with higher precision, reuse of good examples, good practices, standardized design and standard components regarding both process and information as well as IT solution components. The complexity of IT solutions also diminishes in the long term through the ability to identify overlapping functionality. Standardization and harmonization also provide simpler procurement situations, and we are better prepared to explain what we want. Supports investment funding and portfolio management The business architecture provides the basis for prioritization and better planning for a future lifecycle perspective. With a structured description of processes, information and IT, a cost model that better reflects the reality can be developed. Better overview and higher transparency lead to a fairer and correct cost and resource allocation in business operations. A higher degree of reuse and utilization of investments already made will also be possible. By having a systematic approach to business architecture work and a good understanding of the current situation and the target picture, together with existing change plans, helps us to avoid duplicated functionality with corresponding costs. The business architecture creates better decision support and avoids sub-optimization of investments.
3.4. Business Architecture Modeling The creation and use of models that visualize and clarify common issues helps us to have a good dialogue with stakeholders. This dialogue can become much richer and more structured using modeling, which is an important part of the business architecture work. The example below illustrates a reality that consists of trucks and various factories that need raw materials. When people think about this reality, they have different mental models — based on their own context, references, experiences, expectations and knowledge. The same reality can be perceived differently from person to person, and this is exactly why it is so important to use modeling as a tool for communication and collaboration. As a result of the modeling process, a common knowledge picture emerges about how the business is perceived.
The same reality can be perceived differently from person to person."
95
96
11.
Reality
pal •
•
41141. •
•
Model of reality x- ----- is
Mental models Figure 3.3 Mental model illustrations
The greatest thing about modeling is that while you collaborate in developing a model, you simultaneously create common knowledge and get acceptance of the same view of the reality in a team. This anchoring helps us to involve the right people early on in the implementation of a change at the planning stage. It also increases understanding of problems that can arise and need to be solved together, for example, if there is a need for cooperation between certain parts of the company or organization. By creating a model together in a workshop and shaping it over time, people can always evaluate if the common model is in line with their own mental model. With a model, it is possible for everyone to understand both the context of others and also to see their own part in the larger picture. The common model should always be used as the starting point for discussions on business change. Characteristics of a model that are of good quality and can really contribute to a continued successful business architecture work, are as follows: • the model provides overview and structure. As a business architect, the ability to delineate the model is important to provide the level of detail that is relevant for the intended purpose. If the level becomes too detailed and the model gets too complex to explain, it is better to create a high-level model with "sub models" that describe the details for different target groups to understand the context (more of this in later chapters)
BUSINESS ARCHITECTURE
• the model is understood and agreed among all who participate in the creation. All possible misunderstandings need to be eliminated to the greatest extent possible at the time of modeling. A strong recommendation is to perform review sessions to eliminate and reduce misunderstandings and to get the model as correct as possible with the specific purpose in mind • the relationships between the objects are defined. When you work with business architecture, you use relationships between objects and components in the drawings. These relationships can be of the same structural perspective e.g., processes, information objects or IT solution components but can also be used to draw and understand relationships between different perspectives like process-information or information-IT Solution. These relationships are of particular interest in architectural models so the participants in the modeling sessions must also agree on these Modeling is a very powerful tool for creating collaborative knowledge and acceptance among different stakeholders as everyone who participates in the modeling exercise contributes with their important input based on their different perceptions of the business. For this reason, it is important to invite participants with these different perceptions and perspectives.
Curren-/- salu-eons
5-/-aPaje space
-----
X ieov,Le
•- - - -$< Figure 3.4 A common model describing different perspectives
97
For the business architecture to be used as a tool for strategic alignment and a tool for change, we must ensure that it has a strong connection to people's reality and does not become a "paper product". It is important to create consistency in the descriptions of the operations. However, when experts who represent the business talk about how everything works, what information they use and why, they are rarely if ever completely consistent. It is therefore important that modeling takes place in working meetings with several participants, as many new insights emerge when working together. It is also extremely important that you document what is said so that you can return to important discussions and reuse and communicate the results. The business can be modeled and described from different perspectives and on different levels for different target groups. Business architecture modeling and creating relevant architectural models require thinking about the purpose and expected benefits to define the right level of business architecture investment. By using a number of pre-defined business architecture models with symbols in a structured way, you can gather much information into the same model without losing your readers. You can think of it as similar to a regular map — it is made up of a number of basic symbols which are positioned and create a description of a particular area. The description contains far more information than the separate sections. What makes the map interesting is its detail and ability to present so many different perspectives at the same time. As a reader, you can choose at what level of detail you want to consider the map. Depending on what you need to know, you look at different things. In a traditional school atlas, you find different kinds of maps showing geology, climate, economics etc. and in the same way, a business has many different perspectives. The business architecture models constitute the map of a company or organization and are of great support when there is a need to understand what the premises look like when planning reallocation to a new office or when there is a need to understand what processes are automated in a particular IT Solution when planning an upgrade to new technology. These two needs require different kinds of descriptions.
I The business can be modeled and described from different perspectives and on different levels for different target groups."
VI=
Figure 3.5 Business architecture objects, or components with different symbols
BUSINESS ARCHITECTURE
In the business architecture, you represent things in the business that are perceived as important to describe. These things are the objects or components of the business architecture. The descriptions of these objects are captured in models and each type of object is assigned a symbol. For example, you can use an arrow symbol for a process, a parallelogram or a box for information and a rectangle for an IT Solution. By using different symbols, you help the reader understand the context of the model and tell them what it is about. To show how the objects relate to each other, you can use different types of relationships which can be drawn as lines in graphs.
Information IOW
Figure 3.6 Business architecture objects connected in graphical diagrams to illustrate relationships
Matrices and lists are also commonly used to illustrate connections and dependencies.
System A
Process A
System B
System C
x ti
Process B x
x
Process C
Figure 3.7 Managing relationships or dependencies between different objects in the business architecture with matrices
Process A System A f System C Process B ‘System A e System B Process C > System C
Figure 3.8 Listing relationships between business architecture objects
99
3.5. Designing the Business Logic Architecture When we architect the business, we are describing the rationale of how a company or organization creates, delivers and captures value for its customers or users.
Business model
Processes
Information
ii i
MEW 1 Business NNW i Capabilities
• 111
44111111
Figure 3.9 Architectural views: business model, processes, information, IT Solution and capabilities
IT solutions
There are different types of models depending on the purpose and perspective. Typical business architecture models for architecting the business logic are the Business Model Canvas, goal and actor models with customer journey charts.
3.5.1.
Business Model Canvas
To create the "path of understanding" with traceability all the way from busi-
ness logic to operational structures, we want to promote using the Business Model Canvas as a core model in the business architecture. The Business Model Canvas, presented by Alexander Osterwalder and Yves Pigneur in 2001, has had a major impact within the business management community. It summarizes very well the business logic for a certain business in only one picture. It visually describes the relationships
BUSINESS ARCHITECTURE 101
between the value proposition, customer segments and sales channels on the revenue side (right-hand side in the model) as well as important operational structures needed on the cost side (left-hand side in the model) to deliver value to its customers. The model was introduced at a time when companies were starting to make money in completely new ways that turned old ways of describing business ideas upside down. This visual model has had an enormous impact and is part of the explanation of why the concept of business models has spread far beyond the business management community.
The Business Model Canvas
8
Key Activities
Key Resources
0
value PrOpteretions
4111
•
0606 (I) • =...=•••:.:==.":
0
Customer Relabonships
VP
channels
!IS
Revenue Streams
Customer Segments
ii
A
Strategyzer strategyzercom
The Business Model Canvas is a powerful tool for understanding and describing business logic on a high level for any given business. It has its origins in modern management theory and has proved to be a very successful way of linking strategy to business operations. The business model description is an important basis for a joint dialogue about business and operational delivery structures in the company or organization and to visualize and identify what is important. The business model description can also be used to clarify which parts of the business model are undergoing change or are facing challenges. Is it about streamlining production, strengthening customer relationships or being able to develop more unique products to create differentiation in the market? Is it about changing financial flows or establishing new partnerships?
Figure 3.10 Osterwalder's business model canvas Source: Business Model Alchemist, CC BY-SA 1.0
102
Processes Competences Structures
Value Proposition
Customers Channels Relations
Figure 3.11 Variant of the Business Model Canvas Sourced from: Cordial. se
Please note that a company or organization can very well have more than one business model and by working systematically with the business architecture, it can be an eye-opener for companies that struggle with many customer value propositions, different products, duplicate processes or financially separated businesses. Using the Business Model Canvas helps to organize the high-level business logic, makes it easier to understand and is a good basis for discussions about change, improvements and — last but not least — the need for new or changed operational structures. The Business Model Canvas is excellent even for non-profit organizations and is sometimes called the "delivery model" to avoid the "business" term.
3.5.2.
Goal Models
In all companies and organizations, business goals are formulated and should always be linked to the vision and strategic goals defined. The goal formulation is often included as part of the business planning process and should be found in business plans and other strategic documentation. A "goal model" can be used to visualize all or part of a company's objectives and goals and also to show their interconnection. Goal modeling can be relevant for both overall strategic goals and more detailed operational goals. The goal model provides a good basis for ensuring that the strategic goals are truly met by underlying business goals, providing visual traceability. A classic way of working with goal models is to visualize goals that are important for the business in the long term, but it is equally relevant and interesting to model "change" goals or "product" goals that are linked to the direct result (of e.g., a new product introduction) or "result" goals that need to be clarified and understood by all who will be involved in delivering the result. Goal models are conceptual models in which different types of goals are related to each other. This type of model is also used to identify, describe and connect to important operational business capabilities, ensuring alignment between business logic and operational structures.
BUSINESS ARCHITECTURE
Best car hire company in Northern Europe
Booking offices in 8 countries
100 % satisfied customers I
Flexible rental solutions
r
Customer oriented business processes
Suitable IT systems
Business driven IT-investments
Figure 3.12 Example of a goal model
3.5.3.
Stakeholder Models
When describing a business, it is important to understand what stakeholders are involved, both for defining the strategies and goals but also for delivering the result. By modeling the stakeholders, we are better prepared as architects to understand the needs, interests and expectations of the various stakeholders/stakeholder groups. As an example, the electrician, plumber and carpenter all need different views of the drawing that cover their particular interests in a house construction. The same goes for a business. All designs, drawings and models that are produced should always add value to one of the stakeholders. Creating models with the stakeholders who interact within and with the company or organization for a certain business becomes an important basis for ensuring that you as the architect have control over the entire value network. Since neither companies nor organizations are closed entities, this type of model also includes actors outside the organizational boundaries, who affect or are affected by the business. Typical external actors are customers, authorities and suppliers.
103
104
Customer
Government agencies
Steering committee
Product owner
CEO
Change initiative X
HR department
Development team
International office
Figure 3.13 Example of stakeholder model describing stakeholders for a change initiative
Regional office
IT operations
Hardware supplier
IT-manager
The actor / stakeholder model is preferably role-based, using role names instead of personal names or names of organizational units. With the help of a stakeholder model, you can connect to process roles in the business operational structures to ensure that important stakeholders are involved in the process execution — and the other way around: you can verify that you have involved all important stakeholders when you design the processes. The stakeholder model also gives a good overview to clarify who will be specifically affected by a change and you can use this as a basis for the communication and change management plan.
BUSINESS ARCHITECTURE 105
A High I
Fulfill
Continually follow-up Government agencies
Steering committee
Development team
CEO
IT manager
Product owner
111100C1 Monitor
Keep updated HR department
Customer
Hardware supplier
International office
IT operations
Regional office 1111WINNONIIIMEMW...
Low
High
Interest
3.5.4.
End Customer Perspective
For a thorough understanding of the end customer or user perspective, it can be valuable to create a "customer journey map" which is a model describing all touchpoints the end customer has over time with the company or organization. This is a good way to identify any weak points or possibilities in the customer experience and customer expectations that need to be taken care of in business operations, e.g., better sales and customer relations processes, IT solutions that remember customer preferences or maybe more trained personnel in customer support. Useful input to a customer journey mapping exercise includes customer surveys and observations of customer interactions with the company or organization, gathered either by data collection or through customer interviews. It is valuable to perform the exercise for different customer and product/services segments to identify differences and commonalities. This type of map can also be created for other stakeholders who are deeply engaged in the business with whom the business has strong dependencies, e.g., partners or vendors, to further understand and support business improvements.
Figure 3.14 Stakeholder grouping from change management perspective
106
"I found the product." "l have a need." Customer experience steps and touch-points with our company
Customer journey stages
"I searched the website, not user-friendly."
•
Awareness
Timeline
Consideration
Before purchase
"l receive and pay for the product."
I decide to buy
"The product fulfils my needs."
"l want to notify a friend about this useful product."
"I can't trace my order."
Aquisition
During purchase
Service
Loyalty
After purchase
Figure 3.15 Example of a customer journey map
3.6. Designing the Business Operations Architecture To describe and design an entire company or organization with detailed structures, you need several different types of models to reflect a more operational view of the business and its different perspectives. The internal and more detailed structures of the company or organization can be merged into an operational view or the "operating model". The operational view aims to visualize how the organization's internal structures contribute to the realization of the business logic with its vision, strategy, goals, stakeholders and business model. To be able to meet the objectives of the business, you need to ensure that all activities, business processes performed daily by employees with specific knowledge required for the area and information management and IT solutions are well structured and optimized for their purposes. Some processes, subprocesses or activities are automated and performed entirely by IT solutions according to predefined operating rules and principles, while others are performed manually. In order to check that the company or organization is performing the right activities to achieve its goals, is using the right information and gets the right support from its IT solutions, you need to be able to see a connection between all these perspectives. The business architecture creates this platform.
BUSINESS ARCHITECTURE 107
Typical business architecture models for architecting the business operations are process models, business rules, information models and capability models, all preferably connected to the more IT-oriented models like system models and integration models.
Business model
Processes
Information Business Capabilities
IT solutions
11=111111111111
1•11
Figure 3.16 Architectural views
3.6.1.
Processes and Value Chain Perspective
The process perspective in the business architecture describes the logical value flows in the company or organization and is a good way to secure an outside-in customer-oriented business. A process consists of a collection of linked activities. A process is a recurring flow of activities that create value for a customer and can be repeated over and over again. Process orientation makes the business easier to understand. With processes you get an overview and better insight into how each activity is included in the larger context. It is easier to follow the customer's perspective when you have the processes described and communicated and you can identify what activities create actual value for the customer or user. Additionally, you can use process analysis to identify error sources, bottlenecks and find potential areas for improvement as well as clarify responsibilities between different roles/departments/organizations.
ee Processes are often grouped according to three different categories."
It is relatively common that companies and organizations describe the processes within their respective functions, departments or organizational parts only. The processes are also often very detailed and serve as the basis for work instructions and job routines. The reason for this can be historic if the company or organization has grown over time, for example related to reorganization, in or outsourcing, mergers or acquisitions. The challenge is that this leads to a silo-oriented approach where processes are only optimized within each specific business area and not connected end-to-end to ensure the externally focused value creation, which is one of the main purposes with processes. As a consequence, many small chunks of processes exist at detailed levels while unnecessary walls and obstacles exist in the value chains. Due to the level of detail, overview becomes very difficult. A systematic business architecture approach focuses on describing processes vertically throughout the value chain and at the same time provides an overview describing the value creation in detailed activities. Processes are often grouped according to three different categories: main or core processes, management processes and supporting processes. The main or core processes are the processes that realize the business value according to a defined business model, and these are fundamental. As in all business architecture modeling, it is important to ensure that the right conditions are in place e.g., that you have the correct stakeholders in the modeling session and that you really understand the business model and expected value creation. When the first draft is in place, sufficient time must be given for review, refinement and completion. Common mistakes are to place too much focus on producing the draft and rushing through to the next stages or creating the draft without involvement of the necessary stakeholders. For a modeling session describing the overall process map for a company or organization you need the management team or similar as participants. Once the high-level process map describing the business is in place, further modeling sessions can be arranged for different sub-processes as far as is relevant. Process modeling requires good facilitation and instant documentation to ensure that you have a facilitator in place, and it is a good idea to have a documentation responsible who directly shows the result to participants and also acts as extra eyes and ears to catch all perspectives from the modeling session. Ensure also that the facilitator is well acquainted with the business described, e.g., who the customers are, what key values the business creates, what products or services are delivered etc. A process model can be created at different abstraction levels, depending on the target group and purpose. Typical process models are: • A high-level process map, describing main processes, management processes and supporting processes at a high level • A sub-process model, describing how one of the processes
BUSINESS ARCHITECTURE
in the high-level process map is decomposed into a set of sub processes • A process model, describing the flow of operations within a sub process at a middle level, preferably describing reusable process components • An activity model, describing the flow of operations in detail, where each process component is divided into a set of activity steps The high-level process map is fundamental to clarify the overall value flow, and it often provides great value for a common understanding of what the business is all about and becomes a good basis for prioritization of e.g., change initiatives.
Management processes
Main processes TVIP,17';
4ii,niiAmittra6vr
Supporting processes Figure 3.17 High-level process map
Confirm need of rental car
Select booking office Need of rental car
Book rental car Selected booking office
Rental car agreement
Figure 3.18 Example of a sub process model
109
110
Having process models with different abstraction levels provides traceability from top to bottom and the other way around and at the same time ensures value creation at all levels. It becomes much easier to clarify what processes or activities are value-creating and to highlight the areas of responsibility needed in the business. Based on the process models, you can identify and focus on business-critical parts in your company or the organization, identify where you need improved IT support and improved important collaboration in process interfaces and "hand-overs". Routine descriptions, instructions and important guides are advantageously linked to the process model where the documents are used — often these descriptions help us to identify process activities on a detailed level.
3.6.2.
Information Perspective
The information perspective in the business architecture consists of different types of representations of the information structures that must be in place to perform the business. It is important to understand the "terminology of the business" and have the concepts that are important for a particular business defined, as well as their relationships. This is specifically important for further data analysis (data science) and Al practices.
INN
Figure 3.19 Ogden's triangle
Conceptual reality
Symbols
Reality
Ogden's triangle, also known as "the triangle of meaning", shows the connection between reality, our conceptual experience of this reality and our way of expressing the concepts in words. The "concept" is thus the abstract picture of the reality that each of us has in our own head. Ogden's triangle clearly illustrates the purpose with conceptual modeling. We want to express a unified concept of reality which all stakeholders can discuss, review and agree on. Conceptual modeling can, as processes, be performed
BUSINESS ARCHITECTURE 111
at different abstraction levels depending on the target group and purpose. Information models can describe the business without any regard to organization, processes, or IT solutions and yet with the desired accuracy they capture the core business, i.e., what the business is mainly doing. Information is thus the most stable perspective of the business, which is why a certain ambition in the development of information as part of the business architecture is well motivated. Information is sometimes described as the "business DNA" and this is often as stable as the business itself. However, information flows and information withdrawals can be changed based on needs and over time. Typical information models are: • A glossary: a high-level list of terms used in the business • A dictionary: alphabetically sorted descriptions of the business terms, their purpose and meaning. This can be used to highlight and explain key concepts that are important to the business • A conceptual business term model: a graphical representation of the business terms with relationships and synonyms. A more "free form" information model than the more detailed models allowing definition of important principles or business rules by visualizing relationships between business terms • An information model: graphical representation of information needed about the business in terms of information objects and their relationships, e.g., customers, products and orders. The information model is used to group information that logically belong together and should be managed jointly. This type of model shows relationships and associated business rules in a more formalized and rigorous way than a conceptual model. The information model, with its objects, relationships and business rules, forms the basis for flexible and efficient data storage solutions • A data model: graphical representation of how the business information is structured in the IT solutions
112
Figure 3.20 Example of a business term glossary
Term
Description
Booking office
Office where a person can pick or return a vehicle
Vehicle
Rentable vehicle. Can be different types. For example: cars, motorcycles...
Customer
Buyer of the rental service
Booking personnel
Employees handling the bookings
Customer agreement
Document with agreed rental terms
Customer receipt
Document that serves as proof of the rental
Extra articles
Services or products thar are not part of renting a vehicle
creates
Customer receipt
connected to
Booking office
creates
o o CO
Booking personnel
Customer agreement
contains
Figure 3.21 Example of an information model
Extra articles
The high-level business terms and information models are mostly used for communication and agreement between stakeholders as well as for specifying requirements for IT solutions, while the data model is more "physical" than "conceptual" and is a basis for IT realization. In a systematic business architecture approach, information objects are grouped into information groups (or object groups) that additionally can be grouped into business areas or business domains. A business domain is a special category of related information objects that together form a logical part of the business. Every company or organization has its own domains, but certain domains are expected in all types of organizations, such as finance. There are also specific standards and patterns for different indus-
BUSINESS ARCHITECTURE
tries and branches that can be interesting to use as benchmarks. There is value in following the norm regarding domain classification, as it gives a standard structure to the business. With standardized divisions, domains can be compared between companies and organizations, and experiences can be exchanged with others, even outside the organization's industry. By describing information at different abstraction levels, the models will create a good structure, help overview the business architecture and understand the business both at a high level and — when needed — to examine in depth. By analyzing the business information models, you can identify opportunities for improvements. If there are shortcomings in the quality of information, it might be unclear who is responsible, which in turns means that the same type of information may be created and stored in several places in the organization. You may need to review and adjust the business processes to correct this type of problem and if you have created process models, it is easier to connect these two perspectives. Another use of information models is to color-mark what information the business perceives as having sufficient quality, where it needs to be adjusted and where larger action programs are required, e.g., in the form of a master data initiative where the company or organization centralizes the management of certain data, e.g., customer information or product information. A term that is often used when talking about information models is "master data". Master data is information that organizations agree to share and therefore needs to be defined, created and maintained in a coordinated way. Descriptions of important documents that also constitute information carriers and in practice reflect important values created in the business processes, such as orders, product descriptions, invoices, customer prospectuses etc. can be a good and concrete way of identifying information objects. The processes clarify which part of the business takes responsibility for creating these.
3.6.3.
Business Capability Perspective
Operational structures can be designed and described in many different ways. The traditional "line organization diagram" has been the usual way of describing an organization, i.e., dividing the business into organizational parts focusing on various functional tasks or parts of the business. Organizational structures can be an obstacle, however, when it comes to making changes, especially if they are to be implemented quickly. Therefore, it is desirable to be able to describe the business independently of organizational structure and, if possible, to organize the business into smaller, more independent organizational units, which can be combined according to current business needs.
Operational structures can be designed and described in many different ways."
113
114
11 A business capability can be seen as an independent component of the business."
When architecting the business operations perspective in the business architecture, the business capability perspective is very valuable. The business capabilities can be viewed as the company's or organization's "abilities" or "competencies" needed to perform the business and are often used to group objects from other perspectives like processes, information, IT solution and organization. Typical examples of capabilities of many businesses are product development, market communication, procurement and customer relationship management. The capabilities in themselves can be seen as "sub businesses" that need their own architectural modeling to respond to strategies and goals. A business capability can be seen as an independent component of the business within the business architecture. It is a component that can be composed of processes, information, competencies, regulations, IT support and more. Therefore, it is a valuable perspective, especially if you want to describe and understand a business on a high level. Business capability modeling provides an opportunity to identify minor components of the business that can operate relatively independently, but also the opportunity to really focus on the parts of the business that are important. Working with the business capability perspective is a good complement to the more traditional process and information perspectives and can also be a way to force stakeholders to think in new ways and see the business in a new perspective. Business capability modeling provides an opportunity to understand what you need to have in place to realize the expected business model. You can plan and prioritize when in time the capability should be in place and specify requirements on the underlying structure itself — what quality you want a specific process to have, what type of competence you need etc. A capability does not describe how it should be resolved — which gives room to create one or more solutions for the capability and improve it over time. By providing a common view of the business capabilities as part of the business architecture, you have a good instrument to discuss and make decisions of high quality in the early stages, before you have a complete picture of all the operational structures involved. This also means that business capabilities (like information) are very stable over time because they describe what is needed for the business but not how those should be designed or solved. Capabilities can be seen as the competencies or skills of an organization. However, a capability does not need to be implemented with internal resources from the company or organization; they can also be performed by an external party. Even if they are implemented and performed externally, they should always be described as capabilities of the company or organization that you describe. In the event of a change in the business model or the business logic, you may need to change, create or remove capabilities. A business archi-
BUSINESS ARCHITECTURE
tect using the capability perspective as part of the business architecture work has excellent opportunities to both identify redundancies or overlaps in the operational structures but also to reuse capabilities from one part in the entire company or organization. The business capabilities can also be seen as "requirement containers" and serve as good objects to connect business requirements to, even though you may not in an early stage of development know whether the requirement will be fulfilled by a manual process or an IT solution — or whether it should be implemented internally or by an external party. Typical business capability models are: • A business capability map: a model that encompasses key business capabilities to provide a good overview of a business, divided by capability areas or business domains. The high-level business capability map can also be named a "city plan". • A business capability model, a model which describes the implementation of a certain capability, what processes, information, business rules, competencies and IT solutions exist to produce expected results.
BUSINESS DIRECTION
BUSINESS PLAN
BUSINESS MODEL
BUSINESS VISION
BUSINESS STRATEGY
BUSINESS INNOVATION
BUSINESS DESIGN
BUSINESS BUDGETING
BUSINESS PLANNING
BUSINESS CULTURE
BUSINESS CAPABILITY
BUSINESS OFFER
BUSINESS VALUATION
BUSINESS CONTROLLING
BUSINESS MANAGEMENT
RESEARCH
DEVELOPMENT
MARKETING
SALES
PRODUCTION
CUSTOMER SERVICE
PROBLEM IDENTIFICATION
NEED SCOPING
MARKET STRATEGY
PROSPECTING
PROCUREMENT
CUSTOMER EXPERIENCE
HYPOTHESIS GENERATION
SOLUTION DEVELOPMENT
BRAND MANAGEMENT
ACCOUNT DEVELOPMENT
SUPPLY MANAGEMENT
CUSTOMER SUPPORT
EXPERIMENTATION
SOLUTION DELIVERY
CAMPAIGN MANAGEMENT
SALES OPPORTUNITIES
MANUFACTURING
CUSTOMER ANALYTICS
DISSEMINATION
SOLUTION SUPPORT
MARKET ANALYSIS
SALES MANAGEMENT
DELIVERING
DISPOSAL MANAGEMENT
RISK MANAGEMENT
INFORMATION MANAGEMENT
SECURITY MANAGEMENT
FACILITIES MANAGEMENT
RELATIONS MANAGEMENT
BUSINESS SUPPORT
SUPPLIER RELATIONS
CHANNEL MANAGEMENT
FINANCIAL MANAGEMENT
TECHNOLOGY MANAGEMENT
PARTNER RELATIONS
INVESTOR RELATIONS
HUMAN MANAGEMENT
ENVIRONMENT MANAGEMENT
Figure 3.22 Example of a business capability map
115
Business capability modeling can be used to clarify responsibilities, and each capability can be linked to a responsible unit in the company or organization. In addition to using the business capability map to organize and describe business capabilities, the capability map can also be used to group information and IT solution objects. This is valuable e.g., for master data initiatives, defining which capability is responsible for the information quality and management of a certain information object/information group. By assigning an owner to the business capability, the responsibility for coordinating the master data information will also ensure and guarantee the quality of information for other stakeholders. Business capability models facilitate the management of the complexity of the business architecture — as well as the business architecture work — and constitute a good complement to other models such as process maps or information models. Capability modeling is particularly useful in the beginning of a business architecture initiative, when the "map" is relatively unknown. With an overall business capability map, as a business architect, you are well equipped to prioritize actions quickly and to group change initiatives, even if you do not know all the detailed structures yet. A way to quickly identify candidates for overall business capability areas is to first identify the main processes executed by the company or organization, e.g., marketing, production, product and service deliveries, financing or customer support.
I Business capability models facilitate the management of the complexity of the business architecture."
3.6.4.
Systems Perspective
Finally, the systems perspective is the IT solutions or IT services that execute the automated parts of the business. Even though the systems perspective is not specifically part of the business architecture and is described in other chapters in this book, it is very important that this perspective is connected to the business architecture. Companies and organizations that use their business architecture systematically have a good platform to organize, scope and focus all IT change initiatives. One example is that no IT change initiatives may be started without a clear view of impacted business goals, business capabilities, business processes and information structures.
3.6.5.
Other Perspectives of Business Operations
In this chapter, we have described the main perspectives of the business operations part of the business architecture (process, information and business capabilities). There are of course other ways to describe a company's or organization's operational structures, but these are the most common
BUSINESS ARCHITECTURE 117
perspectives in systematic business architecture management. However, it is interesting to mention some additional perspectives that can also be used and included in the business architecture when applicable: Business rules Important business rules and principles that apply to the business can be documented either directly in existing process, information, data or capability models or in separate documents. Business rules from laws and regulations can be clarified by describing where they should be applied e.g., a specific information object group or a certain process. Geographical location models A company or organization should ensure that there are descriptions of the geographical distribution of the business, preferably linked to the company's capabilities and processes. Geographic locations can be visualized in a model that reflects the physical location of the business. It is also valuable to have a graphical overview of the different offices in physical locations, e.g., market units, development units, inventory or production units. If the offices are located in different countries, they are likely to have different prerequisites with specific legislation and operating rules to relate to and probably also require different business rules for IT solutions. Organization models One of the most common business architecture models, even though it is almost never mentioned as being a business architecture description, is the organization schema of a company or organization. Having knowledge of the actual state of the organization design is very important for a business architect. Someone has designed the organization for a specific purpose and for a business architect it will provide valuable input to e.g., candidates for main processes or business capabilities. The organization schema must also be matched to the executing roles/actors in business processes and therefore must be included — or at least aligned to — the process models. Organization design as a subject itself is not covered in this book but keep in mind that the organization schema will also be verified towards the business requirements and answers the question: do we have the right competencies and division of responsibilities in our company or organization?
118
3.7. Practical Advice for Business Architecture Modeling
Color has strong signal value and can do much to improve the clarity of architectural models."
Workshops are a very good method of ensuring that the models you develop are relevant to the stakeholders. When stakeholders are invited to describe how the business works, the perspectives that stakeholders perceive as important and interesting are captured. At the same time, the modeling session provides excellent opportunities to communicate and understand the value of business architecture for the overall and strategic direction. Furthermore, it is possible to ensure that the business architecture is anchored and linked to the business and its change plans. Models that come from such collaboration are well anchored, engage the participants and create ambassadors in the organization who can testify to the quality of the model. We do not want to have business architecture models as "shelf products"; they are very much meant to be used. Color has strong signal value and can do much to improve the clarity of architectural models. As an architect, you should be particularly responsive to how color is used in the company organization. Read a graphic manual or similar to understand the thought process that underpins the principles of color application. Then try to reuse the same principles when describing the business architecture. Modeling is about creating a "common sense", giving and gaining new insights about an area. The business architecture work is a process where all involved create new knowledge. Based on a first version of the model, participants can discuss and get to know each other's perspectives. When the group has a common view and a model agreed on, the next step can be taken and important discussions and suggestions on how the area can be improved, developed or changed can take place. Proposed changes can be directly linked to and visualized in the model, and from here the next lap in the business change process can be started. With new insight you can understand more and get a better overview. With overview you can see new perspectives and find patterns not seen or understood before. Insight provides overview and vice versa.
3.7.1.
Visualize for Accessible Overviews
The business architecture describes several different perspectives of a business. As an architect, you sometimes work on describing one perspective at a time — processes, information, business capabilities, etc. The challenge is to create an overview and at the same time keep important relationships in architecture together. To make models understandable to different stakeholders with different backgrounds and knowledge, different views of business architecture can
BUSINESS ARCHITECTURE
be used in the form of diagrams and descriptive text. When working with a model for a long time, descriptive forms are often developed that are specially adapted for that context or company. These models can be inspired by previously used design language in the organization. Seeking inspiration from e.g., infographics, newspaper graphics, etc. can be successful in allowing the models to carry more business knowledge than is allowed in traditional modeling tools. You can choose to model and describe the business architecture perspective by perspective, e.g., with processes and information needs separated from each other. The risk with this is that you may miss an opportunity for analysis and learning. Since one of the values with systematic business architecture work is the alignment between different perspectives, successful business architects therefore combine several perspectives in the same model and allow the model to emerge in a dialogue with the stakeholders. However, it is the architect's responsibility, in parallel with presenting the models, to keep all objects in the business architecture in their respective architectural perspectives. In business architecture, it is sometimes relevant to have a method to describe specific events that are important for the business, such as recurring important dates for internal planning or events that are important from a customer perspective. These should be identified and linked to various steps in the business processes or connected to the business capabilities needed. Event and scenario descriptions with an external perspective are becoming increasingly important to avoid business architecture work from becoming too introvert; they can increase the whole business's understanding through meetings with external customers, users, partners, and vendors. Methods that can be used to combine different perspectives and visualize these include "The Milky Way". Visualization is extremely important in all architectural work and the key factor is to understand how stakeholders best acquire knowledge and what perspectives they are most in need of. By adapting the architecture models to the target group, you as an architect provide additional opportunities to understand, communicate and discuss your insights. Some practical advice related to visualization and modeling includes: • • • •
combine multiple perspectives in the same model consistently use the models at meetings quickly update the models as new insights appear print the models on paper, publish them on the walls or digital portals, invite questions and new design suggestions • have different variants of models and let the variants coexist until you have either agreed on which one to use or realized that they are so different that they actually describe different things and need to be separated into different models
Visualization is extremely important in all architectural work."
119
120
It is easy to get into too much detail when working with modeling and model analysis. Test the models on the stakeholders the model addresses, remember the model's purpose and remove irrelevant information. We live in a constantly changing world and the models that depict our reality must of course also be subject to changes and updates accordingly. The more you work with the structures of the business logic and business operations, the more you will learn and gain new insights. As an architect, you must ensure that the models developed are managed and maintained, otherwise they will quickly lose value.
Ck
Preparation
Customer journey with touch-points
Get inspired and book course
In class
to Use new knowledge and apply it
Figure 3.23 Milky Way Sourced from IRM, the book "The Milky Way — map, navigate and accelerate change"
BUSINESS ARCHITECTURE
121
3.8. Standards and Patterns for Business Architecture The use of industry standards to quickly benefit from the work and experience of other companies and organizations is good and highly relevant to business architecture. The reasons for using standards for business architecture within a company or organization are multiple and include to: • increase information quality by using or relating to standardized information models • facilitate exchange of information with other actors in the same industry through standardized information models and standardized application interfaces • develop more harmonized and uniform working methods • gain access to proven standard processes that can develop, support and unify the industry • take advantage of other organizations' experience and competence • reduce the need for internal maintenance documentation of standardized concepts and interfaces • gradually build up a well-defined and uniform business architecture and definitions of central concepts and terms based on selected standards.
3.8.1.
Different Standards and Reference Models
There are several different types of standards and reference models that can be applied for business architecture, including: • Industry reference models containing information models or process models for an entire industry or a specific business area. Many examples of extensive and well-described industry models are found in the finance industry and in the telecom industry but there are also many patterns to elaborate in US Department of Defense (DoDAF) and UK Ministry of Defense (MODAF) frameworks. • The Business Process Framework (eTOM) is an important part of Frameworx, TM Forum's business transformation framework. eTOM is a widely accepted and used industry model in the telecom industry. In the IT industry, the ITIL must be mentioned as an established industry model for managing IT services and IT deliveries. • Terminology models containing concepts and definitions
The reasons for using standards for business architecture within a company or organization are multiple."
122
decided by an external party. For example, the International Organization for Standardization (ISO). Typical terminology models that are often used in business architecture are country codes, date definitions, currency codes and industry codes. • Information message models; these are definitions of what a message of a certain type contains, e.g., E-invoice for payment orders and papiNet that standardize electronic documents in the paper and forest industry. Standards and reference models offer good support, especially in the process, information and system interface dimensions. The processes are often illustrated in detailed interaction models or flow descriptions and information is presented in information or conceptual models. System interfaces are often described in detail in message formats or XML charts.
3.8.2.
I
I
The processes are often illustrated in detailed interaction models."
How to Use Standards
Before introducing a standard in a company or organization, it is a good idea to clarify the purpose and what role the standard should play in the business architecture. Three main approaches are presented below: • Standards to support the development and change of the existing business This can be done by using the standard as baseline and reusing the parts that suit the company or organization and situation. Examples of reuse can be system interface documents that complement already existing interfaces, or schemas that complement the existing information architecture. • Standards as industry benchmarks This can, for example, be done by mapping the information used within the company or organization to a specific standard or industry model to gain insight of the level of conformance to the standard. No changes are actually made in the company's or organization's own business architecture. The method can also be interesting for making comparisons between different countries within the same organization. • Standards as replacement directly into the existing business architecture This method can be useful; instead of being responsible for managing a certain information in the business architecture, information is included that an external trusted party manages.
BUSINESS ARCHITECTURE 123
3.8.3.
Guidelines for Working with Standards
The following aspects should be considered when introducing the use of standards and reference models for business architecture: • First and foremost, be clear about the purpose, i.e., how the standard or reference model is intended to be used and what role it should play. • In the documentation of the business architecture, be clear on what parts are implemented based on the relevant standard, including any deviations being made. Possibly also refer to any specific version or variant of the standard, since these are also subject to change • Ensure an active administration function in your company or organization that monitors, manages and encourages change proposals from your perspective.
3.8.4.
Risks of Using General Standards
There are some risks in using general standards and reference models for business architecture: • Standards can sometimes be too open and general which can result in different actors interpreting and applying them in different ways. This risk is important to monitor particularly in large organizations where you have decided to use the standard as a standardization and harmonization instrument in your company or organization. • Needed changes in the standard that arise in your company or organization may not be implemented quickly enough and you are forced to apply internal variants to existing concepts. • If you do not have a uniform management of your business architecture with a coordinated approach to processes, information and system interface management and maintenance, there is a risk that the standard or the reference model will also be interpreted and applied differently within your company or organization. To summarize, use common sense when choosing and using standards and reference models. They can never replace your own business architecture practice, but rather complement it and may give you inspiration. The use of standards and reference models requires a good knowledge and understanding of the current business logic and business operations in the area that the intended standard is to be used. Without a good understand-
II
There are some risks in using general standards and reference models."
124
ing of the current situation, it will be even more difficult to understand what needs to be changed, how the standard should be used and what in the standard is already implemented.
3.9. Business Architecture Work in Practice The work of designing, describing, developing and improving the business and the business structures forms the core of the business architecture work. However, higher demands are made on business architects to work more iteratively and aligned to both the ongoing change initiatives and to the decision-making forums that make the strategic decisions for the company's or organization's direction. When this alignment is in place, the business architecture then becomes the important tool of business change and development as it should be, rather than something which is handled independently.
3.9.1.
Formulate Strategic Business Architecture Requirements
To ensure the strategic alignment between a company's or organization's business logic and its operational structures, it is good to formulate a set of strategic "business architecture requirements" based on the business strategy and goals including the Business Model Canvas. These requirements can be used as guiding star for the design of the operational capabilities including processes, information resources, competencies and IT solutions as well as a basis for the transition planning in change initiatives. The requirements need to be formulated as essential expected business outcomes that can be referred to the business model, the process map etc.
3.10. Work Collaboratively As a business architect, you make a significant contribution to the business development practice, both in figuring out possible ways forward and also in facilitating the actual implementation. With the many methods and model types presented in this book, it is possible to illustrate and prepare for possible future situations with a long-term perspective. It is, however, equally important to understand that it is individuals in the company or organization that together shape the actual situation through the detailed decisions that are made every day. An increasingly important part of the business architecture practice is
BUSINESS ARCHITECTURE
to collaborate with other functions and practices in the business to achieve the required commitment and valuable use of the business architecture. Typical roles you as the business architect must include in your network are business developers, decision-makers, product managers, quality control functions, security responsibles, internal auditors, compliance and risk responsibles, portfolio management offices and others. All of these functions, like the architect, need both insight and overview of the business logic and operations and to verify quality and to identify where improvements should be done from their perspective. These stakeholders are definitely important for your own success in contributing to and participating in the needed business development planning and implementation. Some practical tips to ensure a collaborative, continuous and iterative business architecture practice are described in the following sections.
3.10.1. Deliver Often When you deliver results frequently, you can always change and redesign what you did not understand correctly in earlier deliveries. As an architect, it is important that you can both plan for the future and at the same time understand that you are an important part of today's reality. You need to understand stakeholders' requirements. These can differ over time and sometimes you will need more knowledge and better documentation for a specific area. You may need specific scenario- and model-based input to support fact-based decisions, or there may be other things that decision-makers or change initiatives require to perform their tasks. The business architect has a central role in facilitating the work of developing models and analyzing business architectures and can thus contribute by demonstrating how changes in the business affect or are affected. In a company or organization with successful use of business architecture and a systematic business architecture approach, business architects are often given a natural role that links between strategy and execution as well as different parts in the organization. To work collaboratively and be known as someone who delivers results and value, you always needs to think strategically about the stakeholders around you, both to offer your help but also to ensure that you are where the changes are planned and decided on. As an architect, it is also important to think proactively: what can you do to contribute to the daily work of your stakeholders? Is there anything that may be interesting for a particular transformation, or for a specific decision forum?
I
I
When you deliver results frequently, you can always change and redesign what you did not understand correctly in earlier deliveries."
125
3.10.2. Focus on What's Most Important Right Now
11 Architects who create models of the architecture on their own are not so successful."
It is unusual that a company or organization decides to invest in business architecture as a single activity. It is therefore important to prioritize where it will create the most value since we can't do everything at once. "Dig where you are" is an expression that can be applied here. The business architect must focus on what is considered the most important part of the business that is under discussion for change or improvement to understand and facilitate the business architecture work and take one step at a time. One way to prioritize is to use the business capability map and categorize the capabilities as "standardized" or "tailored". "Standard" capabilities maintain standardized processes and IT solutions, possibly by using industry standards or knowledge from IT system vendors as benchmarks; self-designed solutions are not developed. For this part of the business, you then know that you do not need to go into too much detail. It is way more important to focus your work where it is most needed. Otherwise, you may land in a situation where there are too many semi-finished architecture descriptions instead of a few valuable ones that are relevant and useful for the current needs. If you use this categorization approach, much time can be saved so you really can focus on the capabilities you want to be "tailored". The challenge is always to calibrate the architecture to the right level, and this is a subject which should be discussed between all architects of the organization within their different practices or perspectives. The architect should avoid the famous "analysis, paralysis" syndrome, the risk of getting stuck in modeling and producing too many models that no one uses. The best model is the model that is used.
3.10.3. Business Architecture Working as a Dialogue Ask Questions and Listen to Answers Architects who create models of the architecture on their own are not so successful. Working alone with the architecture for too long doesn't create the value from business architecture that we expect. If you believe as an architect that you can create the "perfect model" without any participation from business stakeholders, you risk nobody understanding it. It is always good to prepare for business architecture modeling sessions by creating a draft; however, this is not to be shown during the session, but rather to be used as a check list to see whether your co-created model contains the things you prepared for in advance. It is important and necessary that you create your business architecture descriptions and models together with your stakeholders and invite dialogue, ask questions and listen to answers. This way you, as facilitator, will allow others to contribute with their business knowledge. The architecture modeling sessions should include open-ended questions, like "Is this true?" and "What do you say?"
BUSINESS ARCHITECTURE
In a modeling session, you as the architect can decide to omit certain parts with the intention of getting others to complete the models. To understand the structure of the business, it is important for the architect to follow the business stakeholders and listen to their reasoning and expressions describing the current perception of the current situation. Furthermore, if there is room for live observations where you can participate as an observer in the background, this can further improve understanding and provides better conditions for increased precision in the business architecture descriptions. Approaching the business architecture work as a dialogue, you don't need to introduce or force the business stakeholders to focus on the architecture, rather on the business itself. You, as the business architect, give the stakeholders a new tool for business design and change by using the combined knowledge from your structural and analytical thinking and the stakeholder's business knowledge. Since the business modeling has been introduced together with everyone involved, the anchoring takes place automatically.
3.10.4. Let the Insight Grow — Don't Force Decisions too quickly There will always be new things to understand and improve. As an architect, you often have the best overview and the greatest insight. This is extremely valuable when supporting decision making. It is very important to try to help others to see the same thing that you see. In the business architecture work, you must never try to "persuade" others about an opportunity or problem. You should rather support them by explaining through different kinds of models or other descriptions. You may need to be creative and find new aspects of the business architecture and find the right level for the relevant stakeholder. A good way to prepare for decisions is to make them more fact-based and use different scenarios with impact analysis. When the level of understanding is reached, the actual decision will not be so dramatic and there is no risk that someone in the decision forum seems less competent and "loses face". As a business architect, you must have respect for the in-depth learning curve and the insights that you have gained during the business architecture work and must not expect others to understand everything in the same way immediately.
3.10.5. Establish a Culture of Change A success factor for an iterative and continuously developed and delivered business architecture is to establish a culture of change throughout the organization. This is not anything you as an architect can establish on your own, but by constantly working with dialogue, shared knowledge, common
11 There will always be new things to understand and improve."
127
128
priorities and allowing insights to grow gradually, you can make a significant contribution to the business development in your company or organization.
3.11. Business-driven IT Development
Formulating the business needs and converting them to well-applied IT solutions is not a simple task."
Formulating the business needs and converting them to well-applied IT solutions is not a simple task. Companies and organizations have many stakeholders, and we can assume that not everyone is used to or has the ability or knowledge to articulate their requirements related to IT. In addition, stakeholders naturally have their own perspectives, and these can sometimes be confusing when they have conflicting requirements or priorities or use different terminology for the same things, which leads to ambiguity and communication challenges. The business analysis and IT requirements management practices have for a long time included methods for business process analysis to identify functional requirements for IT support. Methods to find quality attributes (in other words non-functional requirements) have also existed for some time. Even so, it can be difficult to align the IT solutions to the business itself and ensure traceability all the way up to business processes, targets and goals. If a systematic business architecture approach is applied as a natural part of the company's or organization's business development practice, there are great opportunities for good traceability all the way from strategy through the enabling of operational structures to the IT solutions. The requirement management process is important. Succeeding in creating a real business-driven IT development requires that stakeholders at different levels can cooperate in the requirement management process, and there must be an agreement in place regarding what different types of requirements need to be defined and managed. Here, the business architect can be a good guide over whether to define and manage strategic business requirements, process, information or IT solution requirements only. If you don't know what kind of requirements you need to manage or don't help your stakeholders in their requirements and prioritization processes, you may receive an unmanageably large number of unstructured requirements and changes in these requirements, which could lead to a backlog with accompanying high costs and unsuccessful change initiatives. As a business architect, you need to understand the requirements structure and work it out together with architects from other practices as well as business stakeholders at different levels with different perspectives. In the following section, we present some guidelines about how to use the business architecture to visualize and analyze the requirements for IT solutions.
BUSINESS ARCHITECTURE
3.11.1. IT Requirements Management Based on Business Architecture Requirements management is basically about managing expectations, which can be a challenge. Rarely has it been illustrated as clearly as in the classic tree swing cartoon that appeared as early as in the 70s.
Project lifecycle Thankfully, not all projects are like this ...
11 How the customer explained it
How the project leader understood it
How the project wee documented
What operations installed
How the analyst designed it
How the programmer wrote A
How the sales executive describes it
,M111111111111111MIC
How the customer was billed
How the helpdesk supported it
What the customer really needed
The importance of clarifying many aspects to a change, based on the expectations of different stakeholders, is thus a cornerstone. What problem should be solved and for whom? Well-structured requirements with high traceability and clear ownership is a key to successful informed decisions throughout the change journey. Instead of diving directly into the IT solution, integrations and technical platforms discussions, start with the strategic business requirements and the business capabilities—what capabilities do you want to secure and implement with the support of the IT solution? What value should be created? Should the business introduce a new working method for managing customer relationships and introduce a new CRM process with the associated CRM system? Or is it about increasing the quality of customer information, faster sales processes, deepening customer relationships, new competencies and trained personnel selling the right products?
Figure 3.24 Tree swing cartoon
129
130
IT solutions that are implemented from incomplete or erroneous requirements can be very costly."
If you have identified business capabilities as part of your business architecture, these should definitely be used when you start collecting and defining the IT requirements. The business capabilities are very well suited to be "requirement containers" and you can use them to scope the area to be solved by the IT solution. This gives you a very solid foundation from the start. If you are not using a capability map, an alternative can be to use the high-level process map as the base for organizing the requirements. This way you can always be sure that you start the requirements management process from a business perspective, and you can directly create value from the business architecture. If you do not know how to connect the IT solutions to the business, it will be difficult to design the right IT solution, implement it in the company or organization and get acceptance from the users. As previously mentioned, the business architecture can be used to scope a specific change or change initiative. A business capability or process map works well to set the boundary of the requirements area. The business architecture objects or components that are within this boundary, e.g., certain sub processes, information object groups or competencies, are those that will be used to identify further detailed requirements of the IT solution. The importance of spending time doing the business-IT alignment right from the start cannot be reinforced enough. IT solutions that are implemented from incomplete or erroneous requirements can be very costly. Requirements are needed to specify and express what is to be achieved — and not how. Unfortunately, it is very easy to slip into "solutions mode" far too early in the process.
3.11.2. Business Requirements Management Requirements management should be seen as a process with a clear result, creating value for its stakeholders. As with all processes, the requirements management process should also be documented and implemented, preferably as part of the business architecture. Since requirements need to be managed, it is good to consider whether you need some kind of tool support or whether it is sufficient to manage the requirement documents in spreadsheets. If you want to collect all the requirements from different parts of a company or organization and connect the requirements to business architecture objects or components e.g., a specific capability or a process step, the management becomes more complex and a development management tool can greatly facilitate the process, preferably integrated with the architecture modeling tool. The result of a business-driven requirements management process should be business architecture models together with a feature backlog with text descriptions and business priorities.
BUSINESS ARCHITECTURE
Since existing business architecture models are invaluable as a starting point, the following are important perspectives: • A good definition of boundaries in a capability or process model will express what the IT solution should do and not do and what parts of the business should be supported. • Actors/roles defined in the business processes provide a basis for identifying requirements and which stakeholders to involve in the requirements process. These important stakeholders will be the future users, they have expectations of the IT solution and will influence or will be affected by the IT solution. • Process steps can be translated to functions in the IT solution that need to be further detailed and specified, including important business rules linked to these. • Information models clarify what information should be managed and make important business rules visible by illustrating relationships between information objects. • Process input and output objects will give valuable input to information flows and IT integrations needed in the IT solution. • Requirements linked to process results to be produced, e.g., purchase orders and customer orders. • Use cases and scenarios used as part of the business architecture work can also clarify different scenarios for the IT solutions. Requirement management must be given sufficient time. It is much more costly to discover defects in requirements management during testing than during the requirements work itself. The business architect must also put extra attention into and focus on the quality attributes / non-functional requirements, not only on the functional requirements; the latter are often more straight-forward and easy to identify and extract from the business architecture models. The requirements work can advantageously be an iterative process integrated into today's development methods, allowing you to create architecture prototypes to realize requirements. Whether you choose Agile development methods or not, all requirements should have a clear lifecycle. Use the requirements as cornerstones in the development and implementation work. The requirements descriptions will serve as guiding documents throughout the development and implementation process. Formulate test cases early based on the requirements to clarify how the requirements are to be verified. Include also the process models as a basis for end-to-end test cases. The requirements are always relevant in connection with tests of the IT solution and should be reused when user manuals and training materials
I
Requirement management must be given sufficient time."
131
11 It is important to clarify ownership."
are to be produced. The requirements must also be part of a management system after the introduction of the IT solution. Ideally, the requirements should be linked to change and configuration management tools. The business architecture constitutes an important platform and starting point in the requirement management process. Stakeholders who will work directly and indirectly with the IT solution should be involved, and the owner of the IT solution should take responsibility for the overall business-IT alignment - with support from you as the business architect.
3.12. Who Owns the Business Architecture? For the business architecture to be alive and up to date - just like the business it describes and supports - it is important to clarify ownership of its various components. The strategic view is owned by the organization's management team. To ensure that the enabling business structures and the relevant business architecture descriptions support the business and that there is a clear traceability, a systematic and structured architecture practice should be implemented. If a business capability map is developed, it is advisable to clarify ownership for each business capability area. This is an appropriate level; if you go into more detailed business capabilities, there is a risk that you lose focus on the important high-level ownership. A business capability area owner takes ownership of e.g., information classification, prioritization of business-critical processes, availability of services, competence development and quality. The information classification will result in requirements from processes, support functions and, not least, how IT solutions are designed. Without this ownership, there is no cohesive perspective for the business capability area with increased risk of unclear definitions, insufficient data quality, unclear security solutions, duplicate storage and inconsistent processes.
3.12.1. Importance of Business Ownership In the business operations, owners have the ultimate responsibility for their parts of the business architecture. This means that they must be able to make decisions about their specific process, information object, business rule or IT function, such as clarifying definitions and boundaries, ensuring competencies and training, accessibility requirements and security aspects, understanding implications for low data quality, etc. Therefore, the person appointed as owner needs to understand the business itself. If the owner is too far from the actual operative work, the ownership
BUSINESS ARCHITECTURE
will be ineffective and reactive and possibly lead to wrong decisions or endless meetings in which no one can actually describe the problem in business terms. It is better to make sure the ownership is appointed to someone who is involved where the work is done; in this way, we know that we have the best suited people to make decisions regarding definitions and boundaries, and it ensures business value. In a world of limited, often shrinking resources, priority decisions must be made where it is best to understand the consequences. If those who own and work with the information are those who classify the information, it is also those who own the requirements regarding the storage and management of the information. The owner must balance accessibility requirements and data quality with costs for redundancy and service levels. Taking ownership for business architecture is about being accountable for how the business is designed and ensuring that IT solutions are implemented to support the business. It is also about understanding what obstacles or bottlenecks are built into today's business architecture, how the architecture could be changed to match future needs, suggesting improvements and driving needed changes. Ownership should also include taking control of the cost and efficiency perspective for the relevant part. It is important that management and ownership of architectural models is noticed and rewarded. However, it is common that this becomes a task that is placed "on top" of existing operational responsibilities. With this approach, there is a high risk of failure in creating the expected value from business architecture, since the responsible person must have the time needed for maintenance and development. To avoid unnecessary complexity, it is recommended to relate to and use existing management and governance structures as far as possible when defining responsibility for different parts of the business architecture. Existing governance structures for business development, IT, process, risk or security management are very effective to use as a baseline when appointing responsibility for a certain business model, business capability, process or IT service. Whether the business has a centralized or federated governance model and whether the business is consensus- or top-controlled will also influence the business architecture management. When we integrate the business architecture ownership into the existing governance structures, we can simply add these responsibilities and duties to existing job descriptions and decision forums. Suddenly the systematic business architecture practice is included in the natural day-today work.
11 It is better to make sure the ownership is appointed to someone who is involved where the work is done."
133
3.13. How to Communicate the Business Architecture
V As a consequence, an architect must have good communication skills."
The main strength of the business architecture is the ability to create overview and at the same time provide traceability, show connections and dependencies. Architecture is sometimes perceived as complicated and theoretical. To gain the greatest possible value from architectural work, architects need to demonstrate the value of architecture and at the same time facilitate the process of understanding and absorbing architecture as a tool for business development and change. Architecture is a competence in itself, but too much talk about frameworks and meta-models increases the distance from those who have the greatest benefit of the business architecture, i.e., the business stakeholders like decision-makers and development managers. As a consequence, an architect must have good communication skills. A business architect needs to be able to communicate both what the business looks like today as well as support the stakeholders in describing the future. One success factor is to find other resources in the company or organization that can support the communication of the business architecture. As with all communication activities, the architect needs to set up a communication strategy and plan for organizing the target groups, channels, messages and frequency. When the business stakeholders learn to seek information about the architecture, much is gained and the use will increase. Remember, it is better to start with simple models that may already be used in the organization than to follow a specific architecture notation, method, framework or modeling tool 100 percent.
3.14. Business Architecture and Management Systems When a company or organization discusses innovation possibilities and strategic changes, the business architecture provides a good overview of all the capabilities and operational structures of the organization, both internal and external, covering customer relationships, partners and suppliers. Over the years, companies and organizations have often implemented different types of management systems that have been more or less integrated into the operational procedures and daily work instructions. This is a way to ensure that the operational structures are aligned to the business goals. Industry standards and regulations with included business rules, quality aspects etc. are implemented into the management system and
BUSINESS ARCHITECTURE
these are often used internally as "quality management systems". There are many commonalities with business architecture, but how can these two practices cooperate? Many organizations apply some form of scorecard as a component of their management system. The scorecard's perspective and dimensions are good starting points when the value of business architecture is to be communicated to a management team. In the early 1990s, Kaplan and Norton introduced the Balanced Scorecard (BSC) strategic management system, which is one of the most widespread management systems today. BSC describes the business through the following four complementary perspectives: • • • •
Financial perspective Customer perspective Learning and development perspective Internal processes
Another important perspective is the employee perspective, which is about the company's or organization's attractiveness to staff, professional development etc. To emphasize the importance of governance and its possibilities to contribute to a good culture in the organization, a leadership perspective can also be valuable to add. An organization with a well-structured and implemented management system that itself is managed and continuously updated in line with the business model, is very much prepared for business architecture, as they reinforce each other. With a systematic business architecture work, we can capture all these perspectives of finance, customers, learning and development, processes, employees and management as well as the interrelationships between them, which is an important part of all architectural work.
3.15. Business Architecture as a Platform for Innovation All companies and organizations need to find ways to develop their business constantly. The continuous improvement and learning with daily reflecting on how to improve remains essential as we need to achieve more and more with limited resources. Continuous improvement is based on existing knowledge and is best used for further development and clarification of the previously known performance.
135
Many organizations apply some form of scorecard as a component of their management system."
136
When we use the word "innovation", we rather talk about disruptive or radical development, something groundbreaking, trying new approaches and looking at situations from completely new perspectives. Innovation requires new knowledge to be created. • Innovation holds a great deal of creativity, prototyping and testing, allowing unsuccessful attempts and failures.• The word "innovation" comes from the Latin word "novus" meaning new. • We use innovation with the following definition: innovation is the process that results in the disruption of a whole business or parts of it.
With innovation, we strive for solving a problem or creating business in a completely new way."
The difference between disruptive innovation and continuous improvement affects what results can be achieved and how we approach the problems we have to solve. With innovation, we strive for solving a problem or creating business in a completely new way, unlike implementing an incremental change to an existing solution. Although a specific improvement can open up new opportunities and create value, it basically just means doing what you already do in a better, faster or smarter way. Innovation opens up the opportunity to do something completely new, often untested, and this is where there are opportunities to create disruption — to disrupt the status quo and surprise the competitors in a way that provides an explicit advantage instead of just doing more of the same. Disruptive business and business development have shown significant opportunities; companies like Amazon, Spotify, Tesla, Uber and others have achieved great success with new business models. These companies have developed their business models and operational structures into completely new industries. The number of industries that include companies and organizations that really need to consider working more on their business innovation is increasing. On one hand, companies need to make an "Uber" and find new ways to make money from the expertise and customer base they already have, and on the other hand they have to intensify their external monitoring to be prepared for new offers and competitors in their own industry. Many books have been written on innovation. This book has no room to go into depth on the topic, but let's look at four principles to drive innovation in an organization, specifically where the business architecture practice and the business architect can create value, if integrated into the innovation process.
BUSINESS ARCHITECTURE
3.15.1. Fail Fast Since innovation, by our definition, means creating something that has not previously been tried, no one can guarantee success. This automatically becomes a risky undertaking, and the risk and uncertainty must be addressed in a way that supports the innovation team. Failures are something that are not often seen as acceptable in ordinary activities. However, they are inevitable when working with innovation. Instead of trying to avoid failure, the innovation team must strive to identify a failed idea or solution as early as possible. The business must shift to seeing every failure detected in time as a success. Detecting failures quickly means controlling costs, as we do not waste resources on something that will not succeed and means shorter time to learn lessons that can point the way to success. "If you cannot fail, you cannot learn" — Eric Ries (Ries, 2011).
Ideas
Learn
Build
Data
Product
Figure 3.25 Lean startup Measure
When you have a systematic business architecture approach in your company and organization, it is easy to perform innovation and disruption discussions on the "desktop", using existing descriptions and models like the Business Model Canvas, testing out different scenarios and discussing their impacts on operational structures.
methodology: "Build, Measure, Learn" by Erick Ries
137
138
3.15.2. Innovation Readiness Assessment
11 People in general have greater ability to explore the boundaries of what is possible if the boundaries are defined."
A structured and well-documented business architecture allows you to quickly understand how changes in your business should be implemented. Knowledge about how the existing business works (or is intended to work) with the help of documented capability, process and information models really helps an innovation team to identify where opportunities for innovation exist. Paradoxically, clearly defined boundaries can lead to greater creativity in problem solving and thus greater opportunities for success People in general have greater ability to explore the boundaries of what is possible if the boundaries are defined. When we are forced to define our own boundaries, we see the world in a much narrower way. We simply cannot think outside the box unless we see the box itself! With the help of business architecture, this phenomenon can be exploited to unleash innovation creativity. Clear definitions of where to plug in a new process or model define how far we can go with our ideas before we collide with other areas. With good control over the existing structures, we can quickly see which parts of a business are affected by a proposed innovation. Today there are modeling tools that allow simulations of different scenarios for the future, based on architecture models. Knowing how the business and operations work (using documented business, process and information models) and their connections with IT reduces the time to start new change initiatives, which facilitates innovation.
3.15.3. Balanced Risk The business architecture helps us to understand and manage risks so undesirable consequences can hopefully mostly be identified. Risk-taking and exploring the unknown are very important parts of innovation. Business architecture is an instrument for controlling which parts of the business are exposed to risk and to understand how these changes affect existing parts of the organization. Keeping track of the situation allows you to sustain a high rate of change without raising the risk more than you are willing to accept. Having a good foundation through the business architecture means that you can be braver in making innovative changes because you know which parts of the business are affected by the work you do.
BUSINESS ARCHITECTURE
3.15.4. Challenges with Business Architecture and Innovation Business architecture is a living organism that changes and adapts over time with the business. Therefore, it is important that the architecture is updated according to the business development and that the update itself is not bureaucratic and time-consuming. We have emphasized earlier that the business architect must be careful in choosing what architecture models to use and also maintain communication providing continuous insight to the business stakeholders. The desire to understand, control and document must not lead to rigid, bureaucratic processes that slow down or prevent change, as the architecture and the architect then loses value for stakeholders. A rule of thumb is to strive for a certain business architecture maturity before trying to integrate the architecture practice into the innovation process. Often, the potential for improvement is found within the existing structures e.g., processes or IT solutions.
3.16. Current State to Future State To achieve a change that lasts, all types of organizations need clarity at all stages. Where do we stand, where are we going? What change is needed to make progress and how am I affected as an organization, as a team, as an individual? Over time, the ways to manage and implement company and organization transformations have changed. Since the prerequisites for doing business can change very quickly, we need to prepare and adapt to this fact. Therefore, short, well-defined and focused development iterations have become best practice to make improvements quickly. At the same time, one must keep an ear to the ground and quickly be able to question the existing business context. Many of the models and tools mentioned in this book can be used to describe the current situation. All models can be described in different "states" (e.g., "as is" or "to-be"). The statements, "If you can't describe what you are doing as a process, you don't know what you're doing" (attributed to W. Edwards Deming) or "If you can't explain it simply, you don't understand it well enough" (attributed to Albert Einstein) tell us a little about the need to understand where we are before we do the changes. Here, structural maturity plays a very important role. An organization that has not yet reached a common understanding of the value of standardized processes or the need for structured information and classification as well as clear responsibilities usually has different
Where do we stand, where are we going?"
139
140
challenges to an organization in which there is traceability between the business logic and business operations, process maturity is high, standard processes and development processes are implemented and constantly evolving. On the other hand, a company or organization that has struggled for a long time to refine and improve all details in the same processes is likely to have greater difficulty in abandoning those processes in favor of other, newer processes. Thus, extensive change management may be needed to get the new processes in place, even if the process maturity itself is high. As a business architect, you rarely start with a clean sheet of paper. Business processes and business structures exist whether they are documented or modeled or not. In less mature organizations, they may exist as tacit knowledge among key individuals, while in more mature organizations they are described in models and documents. In both cases, the business architecture still exists and shapes the current state of the organization. Whether the organization's architecture is well documented or not, all organizations have a current state that results from earlier efforts. Consequently, an architecture-driven change initiative always has a "legacy" to consider. And, as the name implies, the legacy was created in another era when other needs and design principles were valid and is therefore rarely built the way needed today.
3.16.1. Transition Plan
I
As a business architect, you rarely start with a clean sheet of paper."
Moving from an existing to a target architecture is no small effort. As already stated in the EA chapter, it requires planning. There are most often a large number of processes and IT changes to consider, and it is almost certain that you cannot implement all changes at once. Therefore, a transition plan is needed to help move the company or organization from the current architecture to the target architecture. The path from a current state to the future state can be incremental and pass several "transition states" to ensure that the business can still operate without interruption. The plan can have other names like "road map", and "change plan" and it details the most important states to be implemented. Developing a transition plan is a complex task that involves architects from all practices. The business architect has an important role to ensure it is in line with the overall target architecture, that the business stakeholders are engaged and committed to the plan and that the plan is aligned to the overall company or organization portfolio of change initiatives. The transition plan is usually built on a rough time scale. Deliveries are scheduled quarterly or possibly monthly. Since the transition plan is a longterm plan, it is also subject to change over time. As priorities and business requirements change, it needs to be reviewed regularly. The architecture plan is important, not only as a planning tool, but also
BUSINESS ARCHITECTURE
as a communication tool for the entire company or organization. The target architecture specifies a target image for the organization and the transition plan communicates how you plan to reach it. With a clear goal and a plan for how to get there, the organization is aligned regarding what changes are to be made when, and this allows decision-makers to monitor and show progress at their own level. Using the organization's transition plan as a starting point, you can define the goals to be reached for each transition state. This gives the organization the basis for transitioning from one state to another and makes it easier to follow up. Along the way towards more efficient business operations aligned to the expected business model, there are different "states" or "stages" that need to be described to clearly show the way towards the target. This means that the organization has instances of its business architecture that describe what states the business architecture should represent. To find out how complex it is and the resources, time and money required to move from its current state to its desired solution, you need to know: • What does the business architecture look like today? • What does the target architecture (the ideal version) look like? • How large a step should the organization take to reach each stage, given the priorities and success factors decided on by the business or operations management? Once you have developed and prioritized a transition plan for the business architecture and decided on the realization efforts, all change initiatives must be aligned to have the same picture of the transition states and timing of the decided transitions. This way the transition plan is an excellent tool in the portfolio management process. It is very important to keep to the transition plan; otherwise there is a risk that solutions are created for a state that no longer exists.
3.16.2. Implementing Change and Making Visible Progress One of the most important motivational factors for staff in an organization is progress towards the goals and showing results. Given that progress is an important factor in maintaining high motivation, an iterative approach will also provide benefits. By clearly showing the progress after each iteration, you retain energy and focus on the stated goals. When implementing a transition to a new way of working e.g., implementing a new IT solution, not everyone in the organization will see the change as positive. As in all change initiatives, it is important to perform activities which encourage and support inclusion, commitment, commu-
What does the business architecture look like today?"
141
142
nication and training. These aspects are extremely important to ensure a smooth transition. A clear and regular flow of information about the transition and the effects it creates will help to reduce uncertainty. Change initiatives should strive to actively involve all stakeholders, so they feel involved and can contribute. The more aspects that are part of the change (e.g., the business model, process, information, IT support, role and competence), the more important is change management support for employees and managers at all levels. The change process already starts when you invite people to business architecture modeling sessions.
3.16.3. Retrospective Once you have achieved your goal and a certain transition state is complete, you can reflect on the results. Often it takes some time after the transition before you can decide if you have succeeded. Whether the achieved results correspond to the desired targets and how the transition itself was performed should be evaluated. The stakeholder's feedback is valuable help — gather experience in a "lessons learned" or "retrospective" workshop to ensure you perform even better next time.
BUSINESS ARCHITECTURE
143
Solution Architecture
4.1. Introduction What do we mean by the concepts "solution architecture" and "solution architect"? Sometimes this role can be relatively difficult to describe since it sits between business and technology. In a report called "Architect roles in the digital organization", an IASA report, the role is described like this: "A solution architect plans the implementation of IT solutions based on business needs and preconditions of existing IT services within the organization. A product or solution rarely stands alone but is usually part of an overall solution in an organization's architecture. Therefore, the interface of the specific solution to the outside world is of utmost importance to the solution architect. The solution architect can often be said to focus on solutions that span several different systems and processes." (IASA, 2021) Let's talk about what this means. The solution architect optimizes how business needs are to be implemented with parts like applications and services. We can interpret "preconditions of existing IT services within the organization" in a relatively generous manner — it is, of course, preferable to reuse existing parts. But quite often, new parts need to be procured or developed.
SOLUTION ARCHITECTURE
•
• •
• • •
off
v
Enterprise architects
•
•
Software architects
•
Solution architects •
•
•
Operations and infrastructure
•
•
•
Business and trend analysists
We would like to emphasize "interface of the specific solution". Much reasoning in this chapter is about interfaces (Application Programming Interfaces — APIs, etc.). This interface focus is equally vital inside a solution made up by parts, as it is to the outside world. Of course, there are also user interfaces, but these are not the focus of this chapter. Lastly, the wording "solutions that span several different systems and processes" is important. This is the reason for this chapter being very much about how to get applications, services and other parts to work together — how to integrate them so that a composite solution will provide increased benefits for the business (or provide savings in IT operations or software maintenance). This chapter is a bit more "hands-on" than the rest of the book, since the solution architect's job gets complicated because of including both overview and details at the same time. Pieces of the concrete reasoning in this chapter might also apply to the actual development of software, otherwise covered in Chapter 5 on Software Architecture. Therefore, some topics are covered in both chapters, but from different perspectives. Some of the solution architect's work is relatively technical, but a lot is also about balancing needs, discussions with other architect roles and cooperating with the business. Thus, a lot of social interaction and negotiation is to be expected. In the end it is often the solution architect that makes a definitive decision, based on a lot of input (e.g., what is found in this chapter). It should also be mentioned that quite often, one choice is roughly as good as another. Then it might be best to make a choice based on the organization's existing knowledge and experience.
Figure 4.1 The solution architect collaborates with many others
145
146
Here is a further extract from the report "Architect roles in the digital organization", that may be beneficial to solution architects: "The solution architect is responsible for ensuring that IT solutions are implemented correctly in accordance with the requirements of the business and in relation to other IT solutions and that the solution has the right life expectancy according to the needs of the business. The solution architect ensures that the company-wide architectural principles and guidelines regarding standards are followed in the technical architecture and that functionality is reused where applicable. The solution architect's area of interest is thus to ensure success of the change initiative in question, that the solution is manageable and to ensure that the company's overall strategies are followed. A solution architect has in-depth knowledge of the significant quality properties, can balance them with the functional requirements and prepare the basis for the necessary priorities and compromises. Together with the business architect, the solution architect is responsible for ensuring that the technical solutions are based on and integrated with, the business architecture. Depending on the architect's focus on the continuum from business to technology, the solution architect may also assume the roles of business, infrastructure and software architect."
SOLUTION ARCHITECTURE
4.2. Creating a Solution How do we create a solution? There are many options and, of course, it is often possible to mix and match: 1.Use existing solutions, applications and parts: In some situations, it may be possible to rely on existing applications and services as building blocks, without modifications. By using them in new ways, often through new integrations with other parts, new benefits may be achieved for the resulting solution. Ready-made applications are often the only reasonable building blocks in some areas, especially for ERP (including General Ledger), Human Resources (HR) and CRM. Almost nobody creates these applications in-house today; it would be far too costly and complex. Instead, packaged software or cloud Software as a Service (SaaS) applications are adapted, configured and integrated. 2. Modify existing solutions: In other contexts, some or all of the existing applications and services must be modified to cope with new integrations to create a solution. Note that these modifications are often, but not always, about programming. Sometimes programming can be avoided by changing an application's configuration so that it becomes integrated in the desired way, or by changing "low-code" definitions. Sometimes it may be enough to change process definitions in a process engine. Sometimes it may be a matter of changing established conventions for the usage of an application. The latter is, for example, typical in connection with General Ledger systems (the way accounts are defined and how account groupings are used is often a convention rather than controlled in traditional program code). 3. New applications or services: At other times, you need to create new applications or services, through procurement or systems development. It is important to state requirements for the new applications/services to expose well-documented APIs, events, data structures, file exchanges and other integration mechanisms to provide good interconnectivity. This way, these applications or services can function in composite solutions, both today and in the future. The core of solution architecture, therefore, is about choosing the right parts and about application integration. Examples of different integration types include: traditional integration using batch files or EDIFACT; integrations resulting from the Service-Oriented Architecture (SOA) trend that was popular for several years; event-driven integration; the more recent focus on APIs and consumption/design of microservices, among others. To understand more about the properties of a specific application or service that participates in a solution, see Chapter 5 on Software Architecture.
The core of solution architecture, therefore, is about choosing the right parts."
147
148
• •
•
• • •
Is created through systems or components from applications, platforms or services
•
■ Figure 4.2 Solution created via integration
Infrastructure / Integration Hubs
4.2.1.
Methodology
Chapter 5 on Software Architecture includes thorough methodology reasoning that should be of good use also for solution architecture work. However, besides that, we suggest that the typical solution architect may need to put extra focus on dialogue and on taking an active part in suggesting what can be done easily, which existing parts can be reused, what would be extra robust or have special flexibility, etc., so that the business is given the opportunity to optimize risk, lead time and cost, relative to different (and sometimes contradictory) requirements. A requirements dialogue is needed. As mentioned above it is often not economical to create new applications or services to base a solution on. A gap analysis should be made, considering the initial business requirements and what would be reasonably easy to implement based on existing parts or parts to be procured or sourced from the cloud. Following this, a dialogue with the business should take place, for example: "Would it be possible to change this requirement slightly in this direction, to better match the structure of the HR system we are to use?" Failure to reach a good compromise in this way is known to yield expensive workarounds, less than optimal function, overly complicated integrations and much future frustration.
SOLUTION ARCHITECTURE 149
The solution architect needs to keep technological details in mind, but of course, not trouble the businesspeople with tech-talk!
4.3. Integration for Solutions Integration is one of the most important techniques for creating solutions that are based on different software and applications. This sub-chapter and the next, are therefore focused on how integrations are constructed.
4.3.1.
Integration Agreements
Integration in this context is to connect data and logic in different software units, applications, or services to create new benefits. In its purest form, integration is about direct data communication between two parts. In other cases, integration means a more complex data communication with many parts and parties involved.
Cost
‹--
ervice level
Legal context
>
Security context
‹--
Legal context
Security context
Process context
Data freshness
Service level
U)
I")" Process context
4E "1
Data i;::,.-wIncss --
o c.)
U) Semantic definition