Enterprise Architecture 3.0: Designing Successful Endeavors Chapter II the Way Ahead Leonard Fehskens Chief Editor, Journal of Enterprise Architecture Version of 18 January 2016
Truth in Presenting Disclosure The content of this presentation is not a position of, nor does it imply an endorsement of this content by, the Association of Enterprise Architects. The content of this presentation is not an editorial position of, nor does it imply an endorsement of this content by, the Journal of Enterprise Architecture. This is a work in progress that continues to evolve. 2
Map This talk is organized as seven chapters : I Introduction and a Context for EA 3.0 II The Way Ahead III Design and Architecture IV A Sketch of EA 3.0 V Errors of Omission and Errors of Commission VI Constraints as the Medium of Design VII Wrapping Up 3
Chapter II: The Way Ahead The difficulty lies not so much in developing new ideas as in escaping from old ones. John Maynard Keynes Men build too many walls and not enough bridges. Joseph Fort Newton 4
Recapitulation EA 1.x, 2.0 and 3.0 Temptations to resist The elevator pitch Words I will use sparingly Words I will use a lot 5
EA 1.x, 2.0 and 3.0 EA 1.x What most people practice today as enterprise architecture Many different variants, no single universally accepted definition EA 2.0 What the EA community might soon practice as enterprise architecture, given the emergence of a separate business architecture community EA 3.0 A completely rethought from scratch concept of enterprise architecture 6
Temptations to Resist Some of the ideas introduced in this talk will seem similar to ideas familiar from EA 1.x and related subjects. Please resist the temptation to interpret them as being the same ideas, or to interpret them in the frame of EA 1.x. To help you do so, I have deliberately used different words to denote the ideas of EA 3.0. More importantly, please do not misconstrue this talk as arguing that EA 1.x is wrong, that it is not enterprise architecture, or that it has no utility or value. That is not what this talk is saying! At the end of the series I will talk about how the ideas of EA 3.0 relate to the ideas of EA 1.x. 7
The EA 3.0 Elevator Pitch No matter what you are trying to do No matter what it means to succeed at what you are trying to do You will not succeed at what you are trying to do unless you do everything that is essential to success. While this may sound trivial, it is undeniably true. 8
The Path to EA 3.0 Suppose we assume only that: The primary goal of all endeavors is to be successful, in whatever way(s) the endeavor s stakeholders define success, and regardless of the nature of the endeavor. Suppose then that we set aside everything we already know about enterprise architecture and undertook to (re)design it from scratch, based on the above concept? What would such a discipline look like? Could such a profession include all the various ideas about what enterprise architecture and business architecture are or should be, as specializations? 9
Concepts vs. Words Concepts are more important than the words we use to denote them. So, this is not about defining a given set of words; it is about identifying the necessary concepts and then finding appropriate words to denote these concepts. Some words may be more suggestive of the concepts we use them to denote than others. Sometimes it is necessary to use words that may seem like synonyms to denote different, though related, concepts. 10
Words (and Concepts) I Will Use Sparingly The concepts I will denote by these words are peripheral to the ideas this talk is about: Enterprise Company, Corporation, Firm, Business Technology Optimization That doesn t mean they are not relevant; only that I don t need them to make the points I want to make. 11
An Important Concept A system is an aggregation of interacting (i.e., connected), individually identifiable parts that together exhibit behavior not exhibited by any of the parts individually. 12
Words (and Concepts) I Will Use a Lot The concepts I will denote by these words are central to the ideas this talk is about: Endeavor Artifact Purpose and Intent Design Architecture Fitness for purpose Essential (vs. fundamental) 13
32 Essential Ideas These ideas form the backbone of this series of talks. They will be motivated, justified and elaborated as the talks progress. 14
Idea #1 The thing that makes something an endeavor (an undertaking that is relatively ambitious and complex) is people acting in concert to achieve some intended outcome. Without people, an endeavor cannot undertake itself, and in fact, cannot even exist. 15
Idea #2 People act in concert by organizing themselves into organizations, the means by which their endeavors will be realized. 16
Idea #3 An endeavor is distinct from the organization(s) that realize(s) it. These talks are mostly about endeavors and less so about the organizations that undertake them. 17
Idea #4 The applicability of architectural thinking to endeavors and the organizations that undertake them is not limited to the business and the technology that supports it. 18
Idea #5 To succeed at an endeavor, an organization must: Do everything essential to the success of the endeavor Prevent anything that jeopardizes the success of the endeavor Do little else. 19
Idea #6 Everything essential to the success of the endeavor and anything that jeopardizes the success of the endeavor are properties of the endeavor and its context, that determine what it means for the organization to be fit for purpose (i.e., able to successfully undertake the endeavor). 20
Idea #7 Even for technology-based businesses, the business/technology partition too often leads us to limit our interest in the business to whatever can be supported by a particular technology (often, whatever technology is currently fashionable), and little else. 21
Idea #8 It would be an extraordinary coincidence if everything that was necessary for all endeavors to succeed was defined by this particular set of technology-supported aspects of the business. 22
Idea #9 To do everything essential to the success of the endeavor, prevent anything that might jeopardize the success of the endeavor, and not waste time and resources on anything else, we must: Understand what we mean by success Understand what everything and anything include Understand what makes something essential. 23
Idea #10 We too often believe that success requires that our endeavor be optimal in some sense, when all we really need is for it to be acceptable. This distinction is critical to understanding what we mean by success. The goal is to avoid unnecessarily foreclosing acceptable alternatives. 24
Idea #11 We fail to do everything essential to success by making errors: Of commission we do the wrong things, or we do (the right) things wrong. Of omission we fail to do something 25
Idea #12 We can understand why we make errors of commission and omission, and thus how to avoid them, by investigating the ways we make such errors. 26
Idea #13 Whatever we do as part of an endeavor, the thing about it that most influences its contribution to the success of the endeavor is its fitness for purpose. 27
Idea #14 Thus, everything that is essential to the success of an endeavor must always be fit for purpose, over the life of the endeavor. This is a dynamic, not a static, requirement. 28
Idea #15 We achieve fitness for purpose by designing. 29
Idea #16 We design things so we can make and use them. 30
Idea #17 The idea that endeavors, i.e., concerted acts of people, can and should be designed to be successful, strongly suggests that enterprise architecture as a discipline lies at the intersection of the design sciences and the social sciences. 31
Idea #18 Designing entails making multiple decisions that constrain (i.e., limit in particular ways the options for) subsequent downstream design and implementation decisions. These decisions typically cannot be made independently of one another. 32
Idea #19 A design element is a system of related and codependent constraints on subsequent design and implementation decisions, that makes sense considered as a unit. 33
Idea #20 A design (the outcome of the activity of designing) is a system of related and codependent design elements, i.e., a system of systems of constraining decisions. 34
Idea #21 An architecture is a particular kind of design, that specifies particular kinds of constraints, specifically, those constraints that are essential to fitness for purpose. Thus, an architecture is a system of related and codependent architectural elements, i.e., a system of systems of constraints that are essential to fitness for purpose. 35
Idea #22 The purpose of an endeavor is to achieve some outcome. The purpose of the organizations that undertake the endeavor is to successfully realize the endeavor. These are two different though closely related purposes, which thus imply two different though closely related manifestations of fitness for purpose, and thus two different though closely related architectures. If we do not keep these distinctions clear, we risk making unnecessary bindings that can adversely affect agility (i.e., dynamic fitness for purpose), among other things. 36
Idea #23 As an endeavor is carried out by people, who are not infallible, we must detect, diagnose, correct and prevent whatever errors occur or might occur during the execution of the endeavor. This is something that is essential to the success of every endeavor, and thus something that must be designed as an integral part of every endeavor. 37
Idea #24 Everything essential to the success of an endeavor can be thought of as one of the following: Activity (something we do) Artifact (something we make) Resource (something we use) Role (a description of the activities, or the outcomes of activities, that people are responsible for) Environment (anything that affects the success of the endeavor, but that we have little or no control over, or that we cannot change fast enough, and thus must accept as a given) These are not mutually exclusive categories. 38
Idea #25 Design Making Of Artifact Design Artifact Design Using Of Artifact Make Artifact These connections are not process flows; they are influence relationships. Use Artifact 39
Idea #26 Recursive dependencies are everywhere: The designing, making and using of resources, artifacts, activities and roles are activities. The resources, artifacts, activities and roles necessary to design, make and use resources, artifacts, activities and roles will almost certainly differ from one another. A design is itself an artifact. An endeavor is itself an artifact. The environments within which resources, artifacts, activities and roles are designed, made and used will almost certainly differ from one another. The skills and knowledge necessary for people to design, make or use resources, artifacts, activities and roles will almost certainly differ from one another. All of these considerations will affect what everything essential to success means. To the extent that we do not explicitly design the designing, making and using of artifacts, we leave that up to others to improvise, possibly incorrectly. 40
Idea #27 Undertaking a successful endeavor requires that we know three things: The criteria by which we will judge whether the endeavor is successful; this is a conceptual artifact which must itself be designed, made (represented) and used. We call this the mission. The means by which the mission is to be achieved i.e., its resources, artifacts, activities and roles, and their acquisition, adoption, adaptation, or design and making, as is appropriate, and their use. We call this the solution. The environments within which the mission and its solution will be designed, made and used. Something is part of an environment if it affects the achievement of the endeavor but must be taken as a given, because we have little or no control over it, or cannot change it fast enough. 41
Idea #28 An architecture is an incomplete design that specifies constraints on the subsequent design of an artifact ( the thing the architecture is of ) at a level of generality such that we can be confident, without the need to design everything in any more detail than is necessary and sufficient to do so, that when implemented in accordance with that design, the artifact will be fit for purpose. 42
Idea #29 The structure and representation of architectural elements are context-dependent. This context comprises at least the nature of the design constraints expressed by the element, and the nature of their audience. 43
Idea #30 Horizontal (endeavor-wide) dimension Vision, Mission, Strategy, Goals Capabilities Vertical (element-specific) dimension EA1 EA2 EA3 EAy EAz Vision, Systems Mission, and Services Strategy, Goals Collateral Capabilities Flows Capital Systems Assets and Services Vision, Mission, Strategy, Goals Collateral Capabilities Flows Capital Assets Systems and Services Vision, Mission, Strategy, Goals Collateral Flows Capabilities Capital Assets Systems and Services Vision, Mission, Strategy, Goals Collateral Flows Capabilities Capital Assets Systems and Services Collateral Flows EAn Element Architecture <n> Physical and Intangible Assets 44
Idea #31 Endeavors, the organizations that undertake them, and their missions and environments, are dynamic entities they are changing continually, often in ways that are neither deliberate nor readily apparent. The notions of an as is state and a to be state are thus simplifying fictions. An architecture, as a means to successfully realizing an endeavor, must take account of this dynamism. This means two things: It must be robust in the face of continuous change, and It must also make clear what must not change, and how this must be accomplished. 45
Idea #32 An enterprise architecture, implied by this line of argument, can be defined as: The set of properties of an enterprise, its mission, and their environments that are deemed essential to the enterprise always being fit for purpose to achieve its mission in their environments, over the lifetime of the enterprise. 46
Until Next Time The core ideas of EA 3.0: A successful endeavor requires that everything essential to success be fit for purpose. People are ultimately the means by which endeavors are successful, and thus must be central to our thinking about how we achieve success. 47
Questions? 48
Thank You Leonard Fehskens Chief Editor, Journal of Enterprise Architecture l.fehskens@globalaea.org 130 Oakview Drive Cranberry Township, PA 16066 USA Tel +1 724 538 5773 www.globalaea.org 49