Ecosystems Architecture E-Book

Philip Tetlow

• Herausgeber: Van Haren Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 227

Veröffentlichungsjahr: 2023

Beschreibung

Today, modern business is adrift in a sea of connectivity and potential. Where once an organization’s IT needs could be met from within its four walls, we now see many mission-critical systems reaching out beyond an enterprise’s traditional boundaries. This is pushing solutions design well beyond the comfort zone of Enterprise Architecture and out into a world of hyper-enterprise systems. This is a world of complexity and scale, where the changing status quo demands that organizations keep up or die. To survive, their IT systems must also evolve as the context of their environment(s) ebbs and flows. The result is a dynamic, interconnected web of critical business advantage, balanced against uncertainty and risk, and infused with AI. This is the world of Ecosystems Architecture. This book will introduce you to the challenges of designing hyper-enterprise IT systems and the tools you will need as the era of Ecosystems Architecture dawns. It explains the proximity of new thinking to long-held architectural tenets and outlines how and why thinking has moved on. It also reviews existing frameworks and explains how and why they fit into the broader landscape of architectural thinking. About The Open Group Press The Open Group Press is an imprint of The Open Group for advancing knowledge of information technology by publishing works from individual authors within The Open Group membership that are relevant to advancing The Open Group mission of Boundaryless Information Flow™. The key focus of The Open Group Press is to publish high-quality monographs, as well as introductory technology books intended for the general public, and act as a complement to The Open Group Standards, Guides, and White Papers. The views and opinions expressed in this book are those of the authors, and do not necessarily reflect the consensus position of The Open Group members or staff.

Leseprobe

Ecosystems Architecture

The Open Group Publications available from Van Haren Publishing

The TOGAF® Standard, 10th Edition:

Introduction and Core Concepts

Architecture Development Method

Content, Capability, and Governance

Leader’s Guide

ADM Practitioners’ Guide

Business Architecture

Enterprise Agility and Digital Transformation

A Pocket Guide

TOGAF® Business Architecture Foundation Study Guide TOGAF® Enterprise Architecture Foundation Study Guide

The TOGAF Series:

The TOGAF® Standard, Version 9.2

The TOGAF® Standard, Version 9.2 – A Pocket Guide

TOGAF® 9 Foundation Study Guide, 4th Edition

TOGAF® 9 Certified Study Guide, 4th Edition

The Open Group Series:

The IT4IT™ Standard, Version 3.0

IT4IT™ for Managing the Business of IT – A Management Guide

IT4IT™ Foundation Study Guide, 2nd Edition

The IT4IT™ Reference Architecture, Version 2.1 – A Pocket Guide

Cloud Computing for Business – The Open Group Guide

ArchiMate® 3.1 Specification – A Pocket Guide

ArchiMate® 3.2 Specification

The Digital Practitioner Pocket Guide

The Digital Practitioner Foundation Study Guide

Open Agile Architecture™ – A Standard of The Open Group

Hospital Reference Architecture Guide: The Complete and Expanded English translation of the Dutch ZiRA

The Open Group Press:

The Turning Point: A Novel about Agile Architects Building a Digital Foundation Managing Digital

Ecosystems Architecture

The Open Group Security Series:

O-TTPS – A Management Guide

Open Information Security Management Maturity Model (O-ISM3) Open Enterprise Security Architecture (O-ESA)

Risk Management – The Open Group Guide

The Open FAIR™ Body of Knowledge – A Pocket Guide

All titles are available to purchase from:

www.opengroup.org

www.vanharen.netand also many international and online distributors.

Titel:

Ecosystems Architecture

Subtitle:

New Thinking for Practitioners in the Age of AI

Authors:

Philip Tetlow, Neal Fishman, Paul Homan, and Rahul

Series:

The Open Group Press

A Publication of:

The Open Group

Publisher:

Van Haren Publishing, ’s-Hertogenbosch, www.vanharen.net

ISBN Hard copy:

978 94 018 1110 1

ISBN eBook (pdf):

978 94 018 1111 8

ISBN ePub:

978 94 018 1112 5

Edition:

First edition, first impression, December 2023

Layout:

The Open Group

Copyright:

© 2023, The Open Group. All rights reserved.

Document Number:

G23B

Published by:

The Open Group Press, October 2023.

Comments relating to the material contained in this document may be submitted to:

The Open Group

Apex Plaza

Forbury Road

Reading

Berkshire, RG1 1AX

United Kingdom

or by electronic mail to: [email protected]

The top right image in Figure 6 is sourced from https://commons.wikimedia.org//wiki/File7_bridges.svg, and is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license. For details of the license, see: https://creativecommons.org/licences/by-sa/3.0/deed.en.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner.

Table of Contents

Preface

The Open Group Press

The Open Group

About the Authors

Contributors

Trademarks

Acknowledgements

Foreword

Prologue

History and Background

1. From Enterprise to Ecosystem

1.1. Scale, Structure, and Human-Centric Purpose

1.2. Sociotechnical Systems

1.3. Within a Hairsbreadth of Enterprise?

1.4. Attributes and Components, then up through Systems and Enterprises, Followed by Nodes

1.5. Emergent Structure, Taoist Thinking, and Abstract Workspaces

1.6. Natural Successors

2. What is all the Fuss About?

2.1. Evolution Over Change in IT Systems (Universal Darwinism)

2.2. Things We Know About Complexity and Scale in Sociotechnical Ecosystems

2.3. Commerce and Ecosystems

2.4. Minimum Effort in Organization and Structure

2.5. How and Why Ecosystems Form

2.6. Business Response and Beyond

2.7. Revelation Not Revolution, and on to Emergent Intelligence

2.8. Pseudo Ecosystems and the Restricted Use of Collaboration Tools

2.9. Autocatalism and the Extremes of Complex Systems

2.10. Back Down to Earth

3. Tooling From First Principles — None of This is New

3.1. Model Driven Architecture

3.2. Toward an Ecosystems Framework

3.3. Graph Theory and Graphs

3.4. Graphs, Architectural Schematics, and Semantic Extensibility

3.5. Applying Measurement Systems to Graph Context

3.6. Continuous Cartesian Spaces

3.7. Vectors

3.8. Graph Node Comparison Using Vectors and Trigonometry

3.9. Cosine Similarity

3.10. Bringing This All Together

3.11. The Value of Vector Spaces in Modeling Ecosystems

3.12. Asset Approximation Using Vector Proximity

3.13. Star Gazing and the Search for Black Holes

3.14. GenAI

3.15. What Does this Mean for Architectural Practice and Tooling?

3.16. Limitations and Inference

3.17. GenAI Patterns for Ecosystems Architecture

3.18. So What?

4. That is All Well and Good — Coping Mechanisms

4.1. Prior Art

4.2. Software Lifecyle Approaches

4.3. The VIE Framework

4.4. The Seeds of a Hyper-Enterprise New Method

4.5. Cells

4.6. From VIE to VIPER

4.7. The 7+1 Keys of Viable Enterprise Ecosystems

4.8. End Thoughts

5. Existing Ecosystems Thinking and Practice

5.1. Social Machines

5.2. Gaia-X

5.3. Semantic Web-Enabled Software Engineering

5.4. GenAI and Intermediate Modeling Languages

5.5. Quantum Semantics and Applied Quantum Computing

5.6. Feet Back on the Ground

6. Summary and Final Comments

Appendix A: Referenced Documents

Index

Preface

The Open Group Press

The Open Group Press is an imprint of The Open Group for advancing knowledge of information technology by publishing works from individual authors within The Open Group membership that are relevant to advancing The Open Group mission of Boundaryless Information Flow™. The key focus of The Open Group Press is to publish high-quality monographs, as well as introductory technology books intended for the general public, and act as a complement to The Open Group standards, guides, and white papers. The views and opinions expressed in this book are those of the authors, and do not necessarily reflect the consensus position of The Open Group members or staff.

The Open Group

The Open Group is a global consortium that enables the achievement of business objectives through technology standards. Our diverse membership of more than 900 organizations includes customers, systems and solutions suppliers, tools vendors, integrators, academics, and consultants across multiple industries.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:

• Working with customers to capture, understand, and address current and emerging requirements, establish policies, and share best practices

• Working with suppliers, consortia, and standards bodies to develop consensus and facilitate interoperability, to evolve and integrate specifications and open source technologies

• Offering a comprehensive set of services to enhance the operational efficiency of consortia

• Developing and operating the industry’s premier certification service and encouraging procurement of certified products

Further information on The Open Group is available at www.opengroup.org.

The Open Group publishes a wide range of technical documentation, most of which is focused on development of standards and guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details and a catalog are available at www.opengroup.org/library.

About the Authors

Philip Tetlow, PhD, C.Eng, FIET, is CTO for Data Ecosystems at IBM (UK & Ireland) and a Distinguished IT Architect in The Open Group Open Professions program. He is a one-time Vice President of IBM’s Academy of Technology, a W3C member, a Visiting Professor of Practice at Newcastle University and an Adjunct Professor at Southampton University.

Neal Fishman, BSc, is an IBM (US) Distinguished Engineer and a Distinguished IT Architect in The Open Group Open Professions program. He is a former distance learning instructor at the University of Washington. He has written several published works, including Enterprise Architecture Using the Zachman Framework, Viral Data in SOA: An Enterprise Pandemic, and Smarter Data Science: Succeeding with Enterprise-Grade Data and AI Projects.

Paul Homan, MSc, CITP, FBCS, is the CTO for the Industrial Sector in IBM Services (UK & Ireland). He is an IBM Distinguished Engineer and Distinguished IT Architect in The Open Group Open Professions program. With over 30 years’ experience in IT, he is highly passionate about and practically experienced in Architecture & Strategy; in particular, as applied to the Industrial sector. He is well known for applying an Architected Approach to delivering strategic business transformation, and has been a long time contributor to The Open Group, significantly in relation to the TOGAF Standard.

Rahul, MCA, BSc, is a Senior Research Engineer for the Emerging Technology Lab at Honda R&D Europe UK. He primarily focuses on deep tech strategy, data privacy, and decentralized architecture research for next-generation systems and services.

Contributors

The authors gratefully acknowledge the following contributors:

Steve Nicholls, BSc, is the Account Technical Lead Manager at DXC Technology (UK). He is skilled in Digital Strategy, IT Strategy, Data Center Management, and Project Portfolio Management.

Mark Dickson, BA, is the Architecture Forum Director at The Open Group. He is an experienced Chief Architect, Enterprise Architect, and expert in Agile delivery.

Christopher Hinds, MEng, CEng (Mech), is Head of Enterprise Architect for Applications at Rolls-Royce PLC. He has been with the company since 2006 and worked across Engineering, Manufacturing, and IT. Chris sits in Group IT and works in an ecosystem of more than 20 Enterprise Architects and more than 30 third parties influencing architectural direction.

Stuart Weller, BSc, is an Enterprise Architect at Rolls-Royce PLC. He is TOGAF® 9 Certified and is responsible for Enterprise Architecture standards.

Trademarks

ArchiMate, FACE, FACE logo, Future Airborne Capability Environment, Making Standards Work, Open O logo, Open O and Check certification logo, OSDU, Platform 3.0, The Open Group, TOGAF, UNIX, UNIXWARE, and X logo are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness, Digital Practitioner Body of Knowledge, DPBoK, EMMM, FHIM Profile Builder, FHIM logo, FPB, IT4IT, IT4IT logo, O-AA, O-DEF, O-HERA, O-PAS, O-TTPS, Open Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, Sensor Integration Simplified, SOSA, and SOSA logo are trademarks of The Open Group.

Betamax is a trademark of Sony Corporation.

Box is a registered trademark of Box, Inc.

Facebook is a registered trademark of Facebook, Inc.

Forrester is a registered trademark of Forrester Research, Inc.

Gartner is a registered trademark of Gartner, Inc.

Google is a registered trademark of Google LLC.

IBM is a registered trademark of International Business Machines Corporation.

JavaScript is a trademark of Oracle Corporation.

McKinsey is a trademark of McKinsey Holdings, Inc.

MDA, Model Driven Architecture, and UML are registered trademarks and Unified Modeling Language is a trademark of Object Management Group, Inc.

Mural is a registered trademark of Tactivos, Inc.

Python is a registered trademark of the Python Software Foundation.

Twitter is a trademark of Twitter, Inc.

VHS is a trademark of the Victor Company of Japan (JVC).

W3C and XML are registered trademarks of the World Wide Web Consortium (W3C®).

WhatsApp is a trademark of WhatsApp LLC.

YouTube is a registered trademark of Google LLC.

Zachman Framework is a trademark of John A. Zachman and Zachman International.

All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.

Acknowledgements

The foundations for this book were laid down by a project under the auspices of the IBM Academy of Technology. Accordingly, the founding members of that project must be credited, with a specific mention going to John H Bosma, William Chamberlin, Scott Gerard, Carl Anderson, and Richard Hopkins. Their kind input significantly helped incubate the ideas in this book.

Next, we must thank Mark Dickson, who worked tirelessly to steer our team within The Open Group as we captured and composed our thoughts while writing.

We are also indebted to James Hope, who helped implement and test some of our ideas on homology in Chapter 3.

Finally, we must thank the late Ian Charters, Grady Booch, and Professor Barrie Thompson for their inspiration, support, and encouragement over the years. They are the ones who set the compass.

Foreword

Simply stated; it is time!

In other words, we are at a point where both business and Information Technology (IT) communities must establish practices designed to embrace the various ecosystems upon which their enterprises depend.

A pragmatic place to start is with architecture; specifically, IT architecture aimed at the ecosystems level — at the hyper-enterprise level, as it were, and with an ambition to augment informal practice already in place in and around Enterprise Architecture. This comes from domains like Electronic Data Interchange (EDI), Information Retrieval (IR), Generative Artificial Intelligence (GenAI), and Blockchain, and covers ideas not yet consolidated or formalized — as is the case with Enterprise and/or Systems Architecture.

So, let us start with a caveat. Ecosystems Architecture, as presented here, is an additive discipline to that of Enterprise Architecture, meaning that Ecosystems Architecture is not intended to replace or compete with that discipline. On the contrary, the work of an Enterprise Architect is seen as a necessary pathway, or even a prerequisite, toward becoming an Ecosystem Architect, by drawing upon skills already mastered.

The business side of the enterprise has eternally relied on the broader support of its surrounding ecosystems. To that end, ecosystems and ecosystems thinking are nothing new. What is new, however, is the recognition that IT architecture can play an instrumental role in how ecosystems and the enterprise interact. Hundreds of universities around the world already offer courses containing an ecosystems element. For instance, majors can be obtained in Supply Chain Management, Logistics, and so on. Yet, while optimization is often covered in these programs, the role of IT architecture in that optimization is not. IT architects, therefore, have invariably played a passive role when organizations think in terms of the world around them.

That needs to change.

Why? Simply because today’s enterprises swim in the sea that is the global digital ether, and without the support of the dynamic electronic connections around them, they would drown. As a case in point, the supply chain crisis brought about by COVID mortally wounded many organizations who were blasé about their extended digital dependence. It thereby quashed any fallacy of ecosystems being extraneous to mission-critical business concerns. So, if “being digitally extended” is considered to be important, then Ecosystems Architecture and the role of Ecosystems Architects must also be seen as imperative. In saying that, and as an aside, it is important to note that although global data exchange protocols, like TCP/IP, EDI X.400, and NIEM, have been successfully used for years, and although they may indeed be part of any Ecosystems Architect’s kitbag, Ecosystems Architecture should not be considered synonymous for any or all of them. Its scope is far greater, with a broad affinity to Enterprise Architecture — while being distinctively different.

All of this means that Ecosystem Architects must sit alongside their business counterparts as their organizations build out in their surrounding ecosystems. This, of course, requires an eye to the technologies involved, and the support of unbiased, systematized, and standardized practice.

As an example of bias, naïve organizations often make the mistake of believing that they live at the epicenter of their customer and supplier networks. This is rarely, if ever, the case as Ecosystems Architecture is keen to point out. Not only does centrality skew an organization’s worldview, but it can serve to restrict its opportunities. This is important because, as the grander context of business scales and becomes more complex, retaining objectivity will become ever more important. Aspiring to create a discipline that can transcend the reach of personal and organizational viewpoints was, therefore, the primary motivation behind the push for Ecosystems Architecture as a distinct and discrete discipline.

Neal FishmanDistinguished Engineer, IBM

Prologue

History and Background

“Problems cannot be solved at the same level of awareness that created them.” —

Albert Einstein

We are still amid a technological epoch. Not since the harnessing of steam power have we seen such a change. During the Industrial Revolution, innovation moved from small-scale artisan endeavor to widespread industrialization, which started the upward spiral of globalization and eventually spat out an ever-expanding network of effective electronic communications. In short, rapid technological advances began to catapult human potential beyond its natural limits as the 20th century dawned.

As the world’s communication networks expanded, and our brightest minds connected, the take-up of applied know-how became transformative. So much so, that by the end of the 20th century, technology in general had irrefutably changed the course of history. As a key indicator, and even taking into account deaths due to war and conflict — rounding off at around 123[1] million [1] — our planet’s population grew three times faster than at any other time in history, from 1.5 to 6.1 billion souls in just 100 years [2].

But amid all that progress, one episode stands out.

As the demands of World War II pushed the world’s innovators into overdrive, a torrent of advance ensued. Where once crude equipment had proved sufficient to support mechanization, sophisticated electronic circuits would soon take over as the challenges of war work became clear — challenges so great that they would force the arrival of the digital age.

Whereas previous conflicts had majored in the manual interception and processing of military intelligence, by the outbreak of war in 1939, electronic communications had become dominant. Not only were valuable enemy insights being sent over the wire, but, with the earlier arrival of radio, long-distance human-to-human communications were literally in the air. World War II was, therefore, the first conflict to be truly fought within the newly formed battlegrounds of global electronic communication.

Warring factions quickly developed the wherewithal to capture and interpret electronic intelligence at scale. That advantage was coveted throughout the war and long after. That and the ability to harness science’s newest and most profound discoveries. Both provided the impetus for unparalleled advance, as security paranoia gripped the world’s political elite. On the upside came the rise of digital electronics and the whirlwind of information technology that would follow, but in parallel, we developed weapons of mass destruction like the atomic and hydrogen bombs.

At the heart of it all was information and kinship, in our voracious appetite for knowledge and the unassailable desire to find, share, and protect that which we hold true. Nowhere in human history will you find better evidence that we are a social species; all our surrounding computers and networks do today is underline that fact. Grasping that will be key to understanding the text to follow. For instance, as a race, we have often advanced by connecting to maximize our strengths and protect our weaknesses; whether that be how we hunt mammoth, build pyramids, or create our latest AI models. This is the tribe-intelligence that has bolstered our success and welcomed us in the onward march of technology to augment our strengths and protect our weaknesses. It speaks to the fact that evolution cannot be turned back and, likewise, neither can the advance of any technology that catalyzes or assists its progress. Information technology will always move forward apace, while the sprawling threads of the world’s networks can only ever extend to increase their reach.

These things we know, even though we might poorly distill and communicate the essence of the connected insight they bring. What is certainly lesser known, though, is what ongoing impact such expansion and advance will have on professional practice, especially since future technological advances may soon surpass the upper limits of God-given talents.

As technologists, we wear many hats. As inventors, we regularly push the envelope. But as architects, engineers, and inquisitors, we are expected to deliver on the promise of our ideas: to make real the things that we imagine and realize tangible benefit. In doing so, we demand rigor and aspire to professional excellence, which is only right and proper. But in that aspiration lies a challenge that increasingly holds us back: generally, good practice comes out of the tried and tested, and, indeed, the more tried and tested the better.

But tried and tested implies playing it safe and only doing the things that we know will work. Yet how can such practice succeed in the face of rapid advance and expansion? How can we know with certainty that old methods will work when pushing out into the truly unknown, and at increasing speed?

There can only ever be one answer, in that forward-facing practice must be squarely based on established first principles — the underlying tenets of all technological advances and the very philosophical cornerstones of advancement itself, regardless of any rights or wrongs in current best practice.

So, do any such cornerstones exist? Emphatically yes, and surprisingly they are relatively simple and few.

Scale and Complexity

As we become more proficient with a tool or technology, we largely learn how to build bigger and better things with it. Be they bridges, skyscrapers, or Information Technology (IT) solutions, their outcomes largely become business as usual once realized. What really matters though, is that the tools and techniques used for problem-solving evolve in kind as demand moves onward and upward. For that reason, when a change in demand comes along, it is normally accompanied by an equivalent advance in practice, followed by some name change in recognition. For instance, IT architects talk of “components”, whereas Enterprise Architects talk of “systems”. Both are comparable in terms of architectural practice but differ in terms of the scale and abstraction levels they address. In that way, IT architecture focuses on delivering IT at the systems level, whereas Enterprise Architecture is all about systems of systems.

Interestingly, the increases in scale and complexity that brought us Enterprise Architecture were themselves a consequence of advances in communications technology as new network protocols catalyzed progress and expanded the potential for connectivity — so that a disparate IT system could comfortably talk to another disparate IT system. Nevertheless, boil the essence of this progress down and only two characteristics remain: the scale at which we choose to solve problems, and the levels of complexity necessary to successfully deliver appropriate solutions.

That is it. In a nutshell, if we can work from a base of managing scale and complexity, then the selection of tools and techniques we use becomes less important.

Considering the lesser of these two evils first, in recent times, we have become increasingly adept at tackling complexity head-on. For instance, we now understand that the antidote to complexity is the ability to abstract. As more and more complexity is introduced into the solutions we build, as professionals we simply step back further in order to squeeze in the overall perspectives we need. We therefore work using units of a “headful”, as the architect Maurice Perks [3] once said — any solution containing more than a headful of complexity [4] needs multiple professionals in attendance. As we step back, detail is obviously lost as the headful squeezing happens, even though we admirably try to apply various coping techniques, like dissecting out individual concerns and structuring them into hierarchies, ontologies, or whatever. But today, that is mostly fine as we have learned to employ computers to slurp up the fallout. This is the essence of Computer Aided Design (CAD) and the reason why tools like Integrated Development Environments (IDEs) have proved so successful. Complexity, therefore, is not a significant challenge. We mostly have it licked. Scale, on the other hand, is much more of a challenge.

Ontologies

An ontology is a formal way to describe and connect knowledge in a specific domain. It is like a schematic or map that helps navigate and understand the relationships between concepts within that domain.

Ontologies are used in many fields, including Artificial Intelligence (AI), knowledge management, and information science. They provide a way to structure information and make it more accessible and understandable for both humans and machines. By defining a set of concepts and their relationships, an ontology can help to standardize terminology and facilitate communication across different disciplines and domains. It also enables the ability to reason over the relationships between concepts involved.

In simple terms, the difficulty with asking the question “How big?” is that there is theoretically no upper limit. This happens to be a mind-bending challenge, especially given that the disciplines of architecture and engineering are built on the very idea of limits. So, before we can build anything, at least in a very practical sense, we must know where and when to stop. In other words, we must be able to contain the problems we want to solve — to put them in a mental box of some kind and be able to close the lid. That is the way it works, right?

Well, actually … no, not necessarily. If we were to stick to the confines of common-orgarden IT architecture and/or engineering then perhaps, but let us not forget that both are founded on the principles of science and, more deeply, the disciplines of mathematics and philosophy in some very real sense. So, if we dared to dive deep and go back to first principles, it is surely relevant to ask if any branch of science or mathematics has managed to contain the idea of the uncontainable? Are either mathematics or philosophy comfortable with the idea of infinity or, more precisely, the idea of non-closable problem spaces — intellectual boxes with no sides, ceilings, or floors?

Not surprisingly, the answer is “yes” and yes to the point of almost embarrassing crossover.

Philosophy, Physics, and Technology at the Birth of the Digital Age

For appropriate context, it is important that we take a historical perspective. This is important stuff, as hopefully will become clear when ideas on new architectural approaches are introduced later, so please bear with the narrative for now. This diversion ultimately comes down to not being able to understand the future without having a strong perspective on the past.

As Alan Turing, the father of modern-day computer science, passed through the gates of Bletchley Park for the last time at the end of World War II, he was destined to eventually go to Manchester, to take up a position at the university there. Contrary to popular belief, he had not developed the world’s first digital computer at Bletchley, but the team around him had got close, and Turing was keen to keep up the good work. Also contrary to popular belief, Turing had not spent the war entirely at Bletchley, or undertaken his earlier ground-breaking work on logic entirely in the UK. Instead, he had found himself in the US, first as a doctoral student before the war, then as a military advisor towards its end. His task was to share all he knew about message decryption with US Intelligence, once America had joined with the Allied forces in Europe.