EA 3.0 Chapter 3 Architecture and Design

Transcription

1 EA 3.0 Chapter 3 Architecture and Design Len Fehskens Chief Editor, Journal of Enterprise Architecture AEA Webinar, 24 May 2016 Version of 23 May 2016

2 Truth in Presenting Disclosure The content of this presentation is not a position of, nor does it represent endorsement of that content by, the Association of Enterprise Architects. The content of this presentation is not an editorial position of, nor does it represent endorsement of that content by, the Journal of Enterprise Architecture. This is a work in progress. 2

3 Recall The Fundamental Premise 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. Everything, not just the one (or a few) most important thing(s). While this may sound trivial, it is undeniably true. Furthermore, this (the set of everything that is essential to success) is something that can (and should) be designed. 3

4 Concepts of Design The word design has different connotations in different cultures and subcultures: The artful or stylish aspects of a consumer product, or the creation thereof. The activity that occurs during the design phase of a system development life cycle, or the result of that activity. The general activity of purposeful decision making in service of achieving some desired outcome, or the result of that activity. For the purposes of this talk, design is used to mean the last of these. Note that this interpretation of design means that every phase of an SDLC is a design phase ; they focus on the design of different aspects of different things. 4

5 Traditional Concepts of Architecture The word architecture has different connotations in different cultures and subcultures: The art or science of building, specifically the art or practice of designing and building structures, especially habitable ones. The style of design and method of construction of buildings and other physical structures. 5

6 Our Kind of Architecture In information technology, especially computers and more recently networks, architecture is a term applied to both the process and the outcome of thinking out and specifying the overall structure, logical components, and the logical interrelationships of a computer, its operating system, a network, or other conception. (Computing Fundamentals Glossary) (system) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (ISO/IEC/IEEE 42010) 6

7 Four Concepts of Our Kind of Architecture Amdahl/Blaauw/ Brooks Zachman Software Architecture ISO ~ 1964 ~ 1987 ~ ~2011 Focus Product Industrial product Program System Primary Concern Properties of product required for product to be a member of a product line Complete description Fundamental structure Properties fundamental to system Target Audience All stakeholders All stakeholders Downstream designers and implementers All stakeholders 7

8 Architecture and Design Assertion: Architecture is a specific kind of design. If architecture as a kind of design deserves its own name, we ought to be able to say exactly what kind of design it is (i.e., what distinguishes it from other kinds of design) and why this kind of design deserves special recognition. Whatever distinguishes architecture from other kinds of design ought to have a distinct and compelling value proposition. Specifically, we ought to be able to explain what makes a design decision architectural, and how this distinction adds value to the design process. 8

9 Where We re Going Proposition Architecture is the design of everything that is essential to success. This is closer to the idea of critical success factors, which can serve as the starting point for developing an architecture for a successful endeavor, than it is to ideas of architecture that are rooted in thinking about software intensive systems. 9

10 A Temptation to Avoid It may be tempting at several points during this talk to draw inferences about temporal sequencing. This would be mistaken. It is better to think about these ideas as being about information structures rather than as process flows, i.e., about relationships between different kinds of information, that imply nothing about the order in which the information elements are created and integrated with one another. 10

11 So, Always Bear in Mind More specifically, there is nothing in these ideas that is inherently incompatible with incremental and agile development. The expectation is that in real world situations, an architecture will grow and evolve organically, and that it only need do so far enough to clearly see one s way forward. Formal completeness is a concept, not a requirement, that probably cannot be achieved in the real world. Most importantly, architecture is a means, not an end in itself. 11

12 Endeavors as Artifacts An artifact is a made thing, i.e., something that does not occur naturally. Artifacts are designed, made and used by people. An endeavor is a conceptual artifact. The design, make, use pattern will recur throughout this series of talks, with particular emphasis on the unduly neglected use element. It is not meaningful to talk about the design and designing of an artifact without reference to its intended use, which is itself something that can be designed. 12

13 Endeavors and People Without sentience, an endeavor cannot undertake itself, and in fact, cannot even exist. I.e., an endeavor entails people acting in concert to achieve some intended outcome. This intended outcome may be arbitrarily complex. 13

14 Intent and Purpose 1 I am going to use the words intent and purpose to denote two related but subtly different concepts: Purpose is a contextually dependent (extrinsic) property of an entity. Intent is a mental state (i.e., a particular kind of property) of a sentient entity (i.e., a particular kind of entity). The point is not to debate what intent means and what purpose means, but rather to distinguish two concepts that for the purposes of this talk I have chosen to call intent and purpose. Thus people have intents, and artifacts have purposes. People formulate and express their intent People attribute purposes to, or infer the purposes of, artifacts. 14

15 Intent and Purpose 2 The relationships between people and intents, and people, artifacts and purposes, are many to many. While intent and purpose are singular nouns, intent and purpose can be arbitrarily complex. We design, make and use artifacts such that they realize our intent. That is their purpose. Our intentions need not be utilitarian. Different people may attribute/infer different purposes to/of the same artifact, and may use it with different intent (and thus in different ways, to different ends). 15

16 Architecture, Endeavors and Organizations The applicability of architectural thinking to endeavors and the organizations that undertake them is independent of the nature of either. I.e., there is no reason it cannot or should not apply to all kinds of endeavors and all kinds of organizations. I.e., there is no reason it cannot or should not apply to all aspects of such endeavors and organizations, individually and in aggregate. 16

17 Success There is no single, universal, standard definition of success that applies to all endeavors. What it means for an endeavor to be successful can be defined only by the endeavor s stakeholders. Different stakeholders may have different intents and thus different concepts of what constitutes success. The reconciliation of these differences is one of the most significant challenges to undertaking an ambitious endeavor. 17

18 Success and Fitness for Purpose Assumption: 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. While we can compensate for lack of fitness for purpose, doing so increases complexity and inefficiency. 18

19 Artifacts, Success and Fitness for Purpose An artifact cannot be successful without being used. An artifact itself can only be fit for purpose. While an artifact can be successfully designed and made, its fitness for purpose can only be confirmed by its successful use. 19

20 Dynamic Fitness for Purpose 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. It is not enough to be able to change quickly; you have to be able to change quickly while maintaining fitness for purpose. Continuous change without achieving fitness for purpose (and the desired outcome) is probably better called thrashing. Assertion Continuous dynamic fitness for purpose is the most useful form of agility. 20

21 Design and Fitness for Purpose We achieve fitness for purpose by designing. 21

22 Intent, Purpose and Design Recall we ascribe purpose to an artifact based on the outcome we intend to achieve by using it. Without an understanding of the outcome we intend, we cannot sensibly design an artifact and its making and using, or judge if these designs are likely to result in an artifact that is fit for purpose. 22

23 Why We Design We design things so we can make and use them. It is just as important that we design the making and the using of an artifact as it is that we design the artifact itself. 23

24 Design as Constraints Designing entails making multiple decisions (choices) 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. These decisions limit the options for the decisions that may be made subsequently; hence, they establish constraints. 24

25 The Expression of Constraints A constraint says what something Must, may or must not Be, have or do. The two most common ways to represent constraints (design decisions) are: Principles Models 25

26 Systems 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. 26

27 A Design as a System A design element is a system of related and codependent constraints on subsequent design and implementation decisions, that makes sense considered as a unit. 27

28 A Design as a Class Definition 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. As such, a design is a set of constraints on further design and implementation. These constraints specify things that an implementation must, may, or must not, be, have or do. A design thus specifies a class of implementations that have these properties, i.e., conform to these constraints. 28

29 Design Completeness A complete design specifies a set of constraints that together define a class comprising a single thing. Every instance of this thing is indistinguishable in any way ( that matters ) from every other instance of this thing. I.e., a design is complete if it has only one possible implementation. Many real designs need only be optionally complete in that otherwise identical implementations may embody differences that the design constraints explicitly allow for, for example, color or unique serial number. 29

30 Architecture as Incomplete Design 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. There are many other decisions that must be made, but as long as they are made within these constraints, their specifics don t matter. Thus, an architecture is a deliberately incomplete design. 30

31 Saying Too Much about Too Little In practice, many architectures are simultaneously over- and under-specified. I.e., they include constraints that are not essential to fitness for purpose, and omit other constraints that are. Over-specifying unnecessarily limits designers and implementers options, and underspecifying allows designers and implementers to make decisions that may interfere with, or at best do not contribute to, fitness for purpose. 31

32 The Architecture of Successful Endeavors As an incomplete design, an architecture defines a class of implementations. All members of this class are equivalently fit for the same purpose, without any observable differences that are considered significant. I.e., it is possible for the same architecture to be elaborated into multiple complete designs that differ in their details, in ways that don t matter. Thus, an architecture is an incomplete design, all possible implementations of which are fit for purpose for achieving the mission. Conjecture: As such, it is the most concise representation of all possible designs of an artifact that is fit for a given purpose. 32

33 Platonic Ideals and Reality Ideally, an architecture specifies constraints essential to an artifact s fitness for purpose 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. This is probably impossible to achieve in practice, but what we do not aspire to we will not even approach. 33

34 Mission, Solution, Environments 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. 34

35 The Architecture of Compatible Environments As we cannot, by definition, design or make an environment (we can only choose them), we can (indeed, must) specify what it must, may or must not, be, have, or do in order for it to be possible for the solution to the mission to succeed in such environments. The idea of environment is thus not about whether something is inside or outside some boundary; it is about whether something can be deliberately rendered fit for purpose, or must instead be recognized as being fit for purpose. The point is not that an environment cannot change, but that we cannot change it to suit our intent. 35

36 Rough Correspondences Endeavor Mission + Solution + Environments Endeavor s Purpose Mission Organization Part of Solution Context Environment 36

37 Mission, Solution, Environments and their Architectures Endeavor Mission Endeavor Architecture Mission Architecture Solution Architecture Environment Architectures Solution Environments 37

38 Recall Continuous Dynamic Fitness for Purpose 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 a fixed as is state and a fixed 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 the acceptable ways by which this can be accomplished. 38

39 Dynamic Mission, Solution and Environments, and their Architectures 39

40 Interpreting this Picture The colors are not meant to imply anything other than continuous change. The reuse of certain colors is coincidental, not significant. The identity of the endeavor remains the same even though its mission, solution and their environments change. At any point, our understanding of the mission, the solution and their environments may be partial and imperfect, and will change over time. 40

41 Expressing Architectures 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(s). An architecture and its representations are themselves artifacts, i.e., things to be designed to be fit for purpose. The fitness for purpose of an architecture is distinct from the fitness for purpose of the thing the architecture is of. 41

42 Example A Mesh of Constraints Horizontal (endeavor-wide) dimension Vision, Mission, Strategy, Goals Capabilities Vertical (element-specific) dimension AE1 AE2 AE3 AEy AEz 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 AEn Architectural Element <n> Physical and Intangible Assets 42

43 The Architecture of Success The architecture of a successful endeavor (i.e., a continuously fit for purpose solution to its mission in their environments), implied by this line of argument, can thus be defined as: The set of properties of an endeavor and its mission, its solution, and their environments that are deemed essential to the solution always being fit for purpose to achieve the mission in their environments, over the lifetime of the endeavor. 43

44 A Fifth Concept of Architecture Amdahl/ Blauuw/Brooks Zachman Software Architecture ISO Architecture of Success Focus Product Industrial product Program System Mission, Solution and Environment Primary Concern Properties of product required for product to be a member of a product line Complete description Fundamental structure Properties fundamental to system Properties of mission, solution and environment essential to solution s continual fitness for mission in their environments Target Audience All stakeholders All stakeholders Downstream designers and implementers All stakeholders All stakeholders 44

45 Other Ways of Expressing This Concept of Architecture Architecture is about the stuff that matters, regardless of what kind of stuff it is. The architecture of a thing specifies those things (and only those things) that must be reproduced exactly to recreate an acceptably equivalent copy of that thing. This is what we really mean by what matters. This is an effective way of thinking about what essential to fitness for purpose means. It doesn t matter if you don t want or need to be able to make a copy. It doesn t have to be an exact copy, it only has to be acceptably equivalent. The required degree of fidelity (what acceptably equivalent means) determines the required level of detail (breadth and depth) of the architecture. Acceptably equivalent is determined by stakeholders concerns. 45

46 Brazen Assertions This concept of the architecture of successful endeavors can accommodate all current ideas of enterprise architecture as practiced, as specializations of an umbrella profession. The value proposition is simple and obvious: by attending to everything essential to success, increase the likelihood of a successful outcome. 46

47 Thank You Leonard Fehskens Chief Editor, Journal of Enterprise Architecture 130 Oakview Drive Cranberry Township, PA USA Tel