Fundamentals of Enterprise Architecture (Tanusree McCabe) (Z-Library)

📄 File Format: PDF

💾 File Size: 6.7 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

Fundamentals of Enterprise Architecture Proven Frameworks for Effective Architecture Decisions Tanusree McCabe

📄 Page 3

Fundamentals of Enterprise Architecture by Tanusree McCabe Copyright © 2024 Tanusree McCabe. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Louise Corrigan Development Editor: Corbin Collins Production Editor: Gregory Hyman Copyeditor: nSight, Inc. Proofreader: Helena Stirling

📄 Page 4

Indexer: Ellen Troutman-Zaig Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea September 2024: First Edition Revision History for the First Edition 2024-09-05: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781098159375 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Fundamentals of Enterprise Architecture, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without

📄 Page 5

limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights. 978-1-098-15937-5 [LSI]

📄 Page 6

Preface Once upon a time, a respected colleague declared that enterprise architecture, as we knew it, was dead. With unprecedented transformations such as cloud and artificial intelligence, it did appear that enterprise architecture in its original form was too archaic to add value. How could a function formalized in the 1980s hope to not only keep up with such rapid technological changes, but also to ensure that such changes would lead to positive business outcomes? Yet having witnessed reboots and resets, and having driven changes to architecture myself, I have come to the conclusion that enterprise architecture, when delivered effectively, is still undoubtedly essential to any organization seeking to deliver technology solutions better, faster, and cheaper. Enterprise architecture aligns business’s strategies, processes, and technologies to achieve business goals. As if that weren’t enough, enterprise architecture also defines the structure and operation of an organization’s technology. Enterprise architecture establishes architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies,

📄 Page 7

and ensures that systems and processes are efficient, effective, and cohesive while allowing scalability and flexibility in changing business needs. Organizations that try to fulfill business needs without first defining their enterprise architecture strategy are at risk of experiencing siloed delivery and arbitrary uniqueness. Without an effective enterprise architecture practice, investments are made without a defined purpose, and problems are solved without understanding the full implications of the solution. The best architects and engineers can only get so far on their own without an effective enterprise architecture practice. This book is a defense of enterprise architecture, and a guide to establishing enterprise architecture so that it operates effectively. Throughout this book, I cover proven frameworks from my experiences that you can tailor to meet your own needs. Who Should Read This Book? This book is for anyone involved in delivering software products. Architects, engineers, product managers, executives, data scientists—all are necessary in effective enterprise architecture.

📄 Page 8

This book is especially relevant for those undertaking the challenge of leading or performing enterprise architecture. By the end of this book, you will understand what enterprise architecture is and why it is important to have an effective enterprise architecture practice, and who needs to be involved to make enterprise architecture successful. You will learn about common pitfalls through my presentation of case studies that inhibit effective enterprise architecture. You will be able to assess the current state of your organization’s enterprise architecture practice to identify opportunities for improvement, establish your own enterprise architecture strategy, and strengthen your ability to help yourself and others make great architecture decisions. Any organization seeking to use modern technology with a cogent strategy can benefit from adapting the frameworks and applying the concepts presented in this book. Conventions Used in This Book The following typographical conventions are used in this book: Italic

📄 Page 9

Indicates new terms, URLs, email addresses, filenames, and file extensions. TIP This element signifies a tip or suggestion. WARNING This element indicates a warning or caution. O’Reilly Online Learning NOTE For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com.

📄 Page 10

How to Contact Us For updates and information on this book and the topics it covers, please visit the author’s website at https://www.funeabook.com. You can also address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-889-8969 (in the United States or Canada) 707-827-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://oreilly.com/about/contact.html We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/fundamentals-enterprise-architecture.

📄 Page 11

For news and information about our books and courses, visit https://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media Watch us on YouTube: https://youtube.com/oreillymedia Acknowledgments I’d like to thank my daughter, Ashley, for inspiring me to take a chance and my son, Ryan, and husband, David, for their love, support, and confidence in me. Similarly, thank you to my sister, Mamani, my parents, Kalpana and Dipankar, and my in-laws, Susan and Michael, for being my biggest champions. I’d also like to extend my gratitude to Aaron Rinehart, who opened up doors. This book is a culmination of many years of experience, and I appreciate all the people that I learned from, and worked with, to shape my views and perspectives. I extend my gratitude to Brandee Pierce, David Geen, Allison Boulais, Arjun Dugal, Mark Pender, Zach Blizzard, John Andrukonis, Pete Davies, Kiran Ramineni, Joe Reunthirisak, Keith Gasser, Tony Reynolds, Kathleen Devalk, Lakshmi Seetharaman, Vince Gutosky, Tariq

📄 Page 12

Shaikh, Todd Safford, Parvez Naqvi, Liz Ashton, Alejandra Rios, Jeanine McGinniss, Michael Arroyo-Young, Anantha Bangalore, Keith McCloskey, John Hughes, Dan Katz, Prashant Sarambale, and Alok Awasthi. Thanks to Doron Beit-Halahmi, Doug Holland, Naveen Krishnaraj, and Sivakumar Ponnusamy for giving the manuscript a read for technical accuracy. Also, thank you to the O’Reilly publishing and editing team for all your hard work and constructive feedback. Thank you to all the architects who work so hard to make a difference and to all of their partners who are allies in the quest to achieve value through architecture. Last but not least, thank you to readers who have taken the time to learn more about effective enterprise architecture.

📄 Page 13

Chapter 1. Key Enterprise Architecture Concepts What does the word architecture mean to you? Perhaps it brings to mind visions of Renaissance art and Gothic cathedrals, or if you’ve ever done a home remodel, blueprints of houses and rooms. Perhaps you’re civically oriented and you start thinking about maps of cities and designs of buildings. Whatever comes to mind, I have a strong hunch that design was part of it. So, we can then say that architecture definitely has something to do with designing something new. In the context of modern information technology (IT) organizations, the something is typically a software-based system. How well does architecture help you and your organization deliver software? Perhaps you’ve had bad experiences with ineffective architecture, and the first words that come to mind are things like ivory tower, out of touch, or behind the times. Perhaps architecture seems like an archaic relic of the past, something that’s no longer needed in a modern organization as it attempts to keep pace with rapidly changing technology and business demands.

📄 Page 14

On the other hand, maybe you’ve had great experiences with architecture, and the first words that come to mind are things like clarity, strategy, and shared. Architecture may have provided the clarity needed to set forth a shared strategy with clear goals and blueprints to achieve them. Perhaps architecture allowed for great decisions that met business goals, kept customers happy, and also allowed for innovative technology, or maybe architecture provided the way to connect business to technology strategy. This book aims to set you up for great experiences with architecture. Specifically, it aims to provide you with a path to successfully establish a strong enterprise architecture practice, where enterprise means across the entire company. To do that, let’s first look at the value proposition of enterprise architecture. Why should you, or anyone in your organization, care to invest in enterprise architecture? Why Enterprise Architecture? Enterprise architecture is critical to an organization’s ability to operate effectively with a clear technology strategy that fulfills business objectives. Where architecture as a general function solves problems, enterprise architecture solves complex

📄 Page 15

problems that impact the enterprise and changes the enterprise as a whole. Where architecture in general seeks to deliver well- designed software, enterprise architecture provides the principles, standards, and best practices that enable all software engineering teams to deliver reusable, cost-effective, secure, scalable software that meets business needs. It may be easier to understand the value proposition of enterprise architecture if I first talk about what happens to organizations that don’t have strong enterprise architecture. Organizations without a strong enterprise architecture practice typically fall victim to the development of silos, chaos, and technical debt. Avoiding Silos You may be in a siloed organization if Figure 1-1 looks familiar. In Figure 1-1, each organizational unit makes decisions independently of others. There are only vertical decisions, no horizontal decisions.

📄 Page 16

Figure 1-1. Decisions made within each vertical organizational unit, illustrating siloed decision making Organizational units race to meet their specific business objectives, each thinking that they have unique problems to solve. While they do deliver results in the form of software products, these results are optimized for each organizational unit rather than the enterprise as a whole. This means that the company ends up needing to maintain several similar yet slightly different solutions, and/or outright duplication of

📄 Page 17

solutions, and/or solutions that are unable to effectively integrate with each other. This is both a waste of the company’s resources and an impediment to connected experiences. You see, typically customers don’t want to know the complexity of all of the organizational units behind a product or service that they use; they want a seamless experience across them, and it takes an enterprise perspective to stitch that together. For example, suppose there is a company made of multiple business units. Both business unit A and business unit B need to reach customers with mobile devices. Business unit A decides to build a new mobile app. Since the company is siloed, so does business unit B. Each business unit accomplishes its specific goal of reaching customers via mobile apps. However, given that the units share a customer base, customers are quite perplexed about why the same company was offering two mobile apps with two experiences. Customer loyalty declines as customers decide to try out competition C, which has a much more integrated, seamless mobile app experience. TIP Siloed decisions made with myopic vision lead to shortsighted focus on tactics to resolve near-term fires, rather than strategic investment in the end game. An enterprise perspective allows for making decisions across silos.

📄 Page 18

Avoiding Chaos The second symptom of a weak enterprise architecture practice is chaos. Chaos is a consequence of lacking a clear set of technology standards, as shown in Figure 1-2. Chaos in this context means that each software delivery team makes their own choices, and while there is some benefit in allowing for innovation and competition, there are often significant issues that occur in such an environment.

📄 Page 19

Figure 1-2. The fewer standards there are, the more technology sprawl occurs to increase complexity One issue is in impeding the ability to scale talent.  You need to hire and train talent that understands how to use the various technologies that the teams decided to build with, whether that’s a mainstream industry-leading contender or an esoteric niche product. It can also be difficult to build fungible skill sets and engage in team mobility. This is because teams that use different technology choices cannot easily transfer their knowledge of one technology to another. It can also make it

📄 Page 20

difficult to attract new talent, if there isn’t enough new modern technology in use. Another issue is with sustaining and scaling cybersecurity and governance support and oversight. For each technology in use, typically there are requirements around securing it, and that can be technology specific. For example, the ability to scan software for cybersecurity vulnerabilities: for every software language in use, that’s one more capability needed. There is a cost to maintaining cybersecurity and governance oversight and assurance for each technology choice. A third issue is in inhibiting operational gains or reducing an organization’s agility in terms of adapting and interoperating technology. When standards are introduced after disparate technology is already in use, organizations often have a tough time adapting and adhering to those standards, and in many cases have to invest in refactoring and rearchitecting their software applications. As an example, imagine a company that falls in love with DevOps. Enamored with the idea of automated continuous integration (CI) and continuous delivery (CD), each of the company’s 5,000 teams decides to invest in its own DevOps solutions. Six months later, the company has not one, not two,