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 Slovenia by GPS Group, 2021 ISBN 978-91-7697-245-8
6
Contents
2.4 2.4.1 2.4.2. 2.4.3.
1. Introduction
12
1.1.
Introduction to IT Architecture
12
1.2.
IT Architecture Example: Anna and Mix Anna’s Challenge IT Architect Roles
13 13 15
1.3
Five Roles and Functions of Enterprise Architecture
16
1.4
A Word Before You Start
17
1.2.1. 1.2.2.
2. Enterprise Architecture (EA) 18 2.1. 2.1.1. 2.1.2. 2.1.3. 2.1.4.
2.2. 2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.2.5. 2.2.6. 2.2.7.
2.3. 2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.3.5. 2.3.6. 2.3.7. 2.3.8.
2.4.4. 2.4.5. 2.4.6.
2.5
Management of Significant Business Events 30 Examples of Significant Business Events 30 Acquisitions 31 New Business Venture 31 New System 31 Crisis-driven Savings 32 Success Factors 32 Collaboration Between Different Architectural Roles
2.6
33
How to Anchor an Architecture 2.6.1. Two Types of Anchoring 2.6.2. Anchoring with Decision-makers 2.6.3. Anchoring with Directly Concerned Stakeholders 2.6.4. Summary of Anchoring
38 38 38
2.7
Architecture Governance Governing Architectural Principles Designing Architectural Principles Establishment and Legitimacy Documentation and Description Examples of Architectural Principles
41 41 41 43 43 44
City Planning Organic Growth, Silos and Fragmentation Contract Between Business and IT Benefit and Value Design of the City Plan Architectural Rules of Thumb
45 45 46 47 48 50
Target Architecture Design of Target Architecture Description Mode Reference Architecture How Is the Target Architecture Used? Management of Target Architecture
51 52 53 53 54 54
2.7.1. 2.7.2.
Enterprise Architecture (EA) and the Organization 18 An Organization’s Ability 18 About Enterprise Architecture (EA) 19 Abstraction Models 20 Perspective Models 21
2.7.3.
EA Function Responsibilities of the EA Function IT Strategy Architectural Development Information Management (IM) IT Portfolio Planning Architecture Governance Architecture Capability
22 22 22 22 23 23 24 24
2.8.3.
Strategy and Strategy Work EA and the Organization’s Strategies About Strategies Strategy Elements Strategy Foundation Strategy Objectives Governing Principles Strategy Document Daily Work Strategy
25 25 26 26 26 27 28 29 29
2.9.5.
2.7.4. 2.7.5.
2.8 2.8.1. 2.8.2. 2.8.4. 2.8.5.
2.9 2.9.1. 2.9.2. 2.9.3. 2.9.4.
40 40
2.10 Architecture Governance / Governance 55 2.10.1. Adaptation of Architecture 55 2.10.2. Communicate the Architecture 56 2.10.3. Controlling Change 56 2.10.4. Drive Change 57 2.10.5. Architectural Documentation 57 2.10.6. Architecture Council 57
INTRODUCTION CONTENTS
2.11 Architecture Evaluations 2.11.1. Benefits 2.11.2. How Is Architecture Evaluated? 2.11.3. Evaluation Results
60 60 60 61
2.12. Requirements and organization 2.12.1. Mission, Vision and Goals
62 62
2.13. Requirements Management
64
2.14. EA Work in Practice 2.14.1. Architecture Processes
65 65
2.15 Communication, Decision and Anchoring 69 2.15.1. Why Communicate the EA? 69 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 2.15.5. Participation 71 2.15.6. Decisions and Anchoring 71 2.16. Methods, Standards and Tools 72 2.16.1. 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 Framework (DoDAF) 78 2.16.5. Federal Enterprise Architecture (FEA) 79 2.16.6. Method of Methods 79 2.16.7. Agile Mindset as Part of the Method 80 2.16.8. AgileEA 81 2.16.9. Standards in EA 81 2.16.10. Notations 83 2.16.11. UML 83 2.16.12. Business Process Model and Notation (BPMN) 84 2.16.13. ArchiMate 85 2.16.14. EA Tool Support 86
3. Business Architecture 3.1. 3.1.1. 3.1.2.
Understanding the Business A Business Model Defines Boundaries Operational Structures Realize the Business Model
88 88 90 91
3.1.3.
Non-profit Organizations Also Have Business Models
91
3.2.
What is Business Architecture?
92
3.3 3.3.1.
Why Business Architecture? Benefits of Business Architecture
93 94
3.4.
Business Architecture Modeling
95
3.5.
Designing the Business Logic Architecture 100 Business Model Canvas 100 Goal Models 102 Stakeholder Models 103 End Customer Perspective 105
3.5.1. 3.5.2. 3.5.3. 3.5.4.
3.6.
Designing the Business Operations Architecture 106 3.6.1. Processes and Value Chain Perspective 107 3.6.2. Information Perspective 110 3.6.3. Business Capability Perspective 113 3.6.4. Systems Perspective 116 3.6.5. Other Perspectives of Business Operations 116 3.7. 3.7.1.
Practical Advice for Business Architecture Modeling Visualize for Accessible Overviews
118 118
3.8.
Standards and Patterns for Business Architecture 121 3.8.1. Different Standards and Reference Models 121 3.8.2. How to Use Standards 122 3.8.3. Guidelines for Working with Standards 123 3.8.4. Risks of Using General Standards 123 3.9. 3.9.1.
Business Architecture Work in Practice 124 Formulate Strategic Business Architecture Requirements 124
3.10. Work Collaboratively 124 3.10.1. Deliver Often 125 3.10.2. Focus on What’s Most Important Right Now 126 3.10.3. Business Architecture Working as a Dialogue Ask Questions and Listen to Answers 126 3.10.4. Let the Insight Grow – Don’t Force Decisions too quickly 127
7
8
Establish a Culture of Change
127
3.11. Business-driven IT Development 3.11.1. IT Requirements Management Based on Business Architecture 3.11.2. Business Requirements Management
128
3.10.5.
129 130
3.12. Who Owns the Business Architecture? 132 3.12.1. Importance of Business Ownership 132 3.13. How to Communicate the Business Architecture
134
3.14. Business Architecture and Management Systems
134
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
135 137 138 138 139
3.16. Current State to Future State 139 3.16.1. Transition Plan 140 3.16.2. Implementing Change and Making Visible Progress 141 3.16.3. Retrospective 142
4. Solution Architecture 4.1. Introduction 4.2. 4.2.1.
4.3. 4.3.1. 4.3.2.
4.4. 4.4.1. 4.4.2. 4.4.3.
144 144
Creating a Solution 147 Methodology 148 Integration for Solutions Integration Agreements Integration Pattern Aspects
149 149 152
Typical Integration Types for Solutions 155 Traditional Integration Flows 155 Service-Oriented Architecture (SOA) 157 Event-driven Integration 158
4.4.4. 4.4.5. 4.4.6. 4.4.7. 4.4.8.
4.5. 4.5.1. 4.5.2.
4.6 4.6.1 4.6.2.
REST Orientation API Orientation Microservices Integration IoT Integration Integration with Backup/Restore for Asynchronous Solutions
160 162 163 166 167
Manageability and Integrations 168 Manageability 169 Solution Robustness 169 Choosing Platforms for Solutions Frameworks and Building Blocks Integration Platform (hub)
170 173 174
4.7. Infrastructure
178
4.8. Cybersecurity 4.8.1. Information Protection for Information at Rest 4.8.2. Information Protection for Information in Motion 4.8.3. Information Protection while Computing 4.8.4. Technical Availability 4.8.5. Identity Management
179 182 183 184 185 189
5. Software Architecture
192
5.1. Introduction 5.1.1. What Is Software Architecture? 5.1.2. Coping with Change 5.1.3. Role of the Software Architect
192 192 192 193
5.2.
Software and Quality 193 Quality Attributes 194 5.2.2. Usability and Aesthetics 194 5.2.3. Internationalization, Localization and Globalization 195 5.2.4. Robustness/Complexity 197 5.2.5. Productivity 199 5.2.6. Technical Flexibility 200 5.2.7. Reliable Mean Time Between Failures (MTBF) 201 5.2.8. Customization 203 5.2.9. Administration 204 5.2.10. Vitality 206 5.2.11. Performance and Scalability 207 5.2.1.
INTRODUCTION CONTENTS
5.2.15.
Load 209 Capacity 211 Bandwidth and Network Access 212 Scalability 216
5.3.
Security and Software Development
5.4.
Agility and Lean in Software Architecture 220 Basics of Agile 220 Lean 222 Agile Methods 223 Scrum 224 Extreme Programming (XP) 225 Kanban 225 How Is Everything Related? 226 Building an Agile Architecture 227
5.2.12. 5.2.13. 5.2.14.
5.4.1. 5.4.2. 5.4.3. 5.4.4. 5.4.5. 5.4.6. 5.4.7. 5.4.8.
5.5. 5.5.1. 5.5.2. 5.5.3. 5.5.4. 5.5.5.
5.5.6. 5.5.7. 5.5.8. 5.5.9. 5.5.10. 5.5.11.
5.5.12.
5.6. 5.6.1. 5.6.2. 5.6.3. 5.6.4. 5.6.5. 5.6.6. 5.6.7. 5.6.8. 5.6.9.
Techniques for Refining and Developing Software Architecture Iterative and Incremental Work Incremental Development Iterative Work Prototypes and Spikes Set-based Development: Combining Several Prototypes Constant Code Change: Refactoring Introducing Agility into an Organization Testable Architecture Different Purposes of Testing
219
232 232 233 234 234
234 235 235 236 236 Requirements for the Testability Architecture 238 Impact of Architecture on the Organization or Vice Versa? 239 Role of the Architect in an Agile Organization 240
Software Development Methods and Practices Test-driven Development (TDD) TDD Process Why TDD? Effect of TDD on the Architecture Specification by Example Specify Together Specify with Example What are the Key Examples? Holding a Specification Workshop
241 241 242 243 244 244 245 246 247 248
5.6.10. 5.6.11.
5.6.12. 5.6.13. 5.6.14.
5.7. 5.7.1. 5.7.2.
5.7.3.
Refactoring the Specification Automate the Specification Without Changing It Live Documentation Where Do You Start? Where Next?
249
Domain-driven Design (DDD) Focuses on the Core Domain Explore Models in Creative Collaboration Between Domain Practitioners and Software Practitioners Focus on Language
253 254
250 252 253 254
255 255
5.8.
DevOps: Cultural Shift Towards Better Cooperation for Delivering Software 256
5.9.
Developing for the Cloud Asynchronous Processing and Queue-based Message Handling Data Management and Partitioning for Scale Separating Writes and Reads into Commands and Queries with CQRS Handling User Authentication Across Service Boundaries Container-based Deployment
5.9.1.
5.9.2.
5.9.3.
5.9.4.
5.9.5.
259 259 260 262 263 265
5.10. Software Development and AI 5.10.1. Data Science Process 5.10.2. DevOps for AI and ML 5.10.3. Integrating with Prepackaged AI Services
265 267 267
5.11. Patterns in Software Architecture 5.11.1 Patterns, Pattern Languages and Pattern Families 5.11.2. Patterns in Software Architecture 5.11.3. Architecture Styles and Patterns 5.11.4. Design Patterns 5.11.5. Implementation Patterns 5.11.6. How Do We Use Patterns? 5.11.7. Good Patterns 5.11.8. Describing Patterns 5.11.9. Risks of Using Patterns 5.11.10. Conclusion on Patterns
269
268
270 271 273 274 275 276 277 278 279 280
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
12
1
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.
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 (AI) 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!
In the same way that electricians, plumbers, architects and carpenters together build and take responsibility for creating a successfully functional and satisfactory house.”
15
16
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!
The future for IT architects looks bright.”
17
18
2
Enterprise Architecture
2.1.
A successful business can insightfully anticipate trends, identify changes, and adapt to the environment.”
Enterprise Architecture (EA) and the Organization
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
Architectural Development
Strategy
Enterprise architecture
Operational development
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: • • • •
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
Figure 2.2 FEA architecture levels Source: By Federal Enterprise Architecture Program Management Office, OMB - FEA Practice Guidance, Public Domain
2.1.4.
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.
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
The work on IT portfolio planning is about prioritization, packaging, life cycle planning and change management.”
23
24
• Packaging of the IS/IT environment and the defined services • Risk analysis and risk management • Innovation of new technologies
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
5 Effective 4 Controlled 3 Proactive 2 Reactive 1 Aware Figure 2.5 Maturity model
0 Unaware
292