Emergent Architecture - March 2011

3,279 views
3,112 views

Published on

Balancing Up-Front Planning and Emergence

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,279
On SlideShare
0
From Embeds
0
Number of Embeds
309
Actions
Shares
0
Downloads
81
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • What are the challenges with this description? There are two: 1) It assumes that EA is an ivory tower, and 2) it assumes that EA is about BUFP. Successful EA is neither of these things!
  • Evolutionary architecture and emergent design: Investigating architecture and designhttp://public.dhe.ibm.com/software/dw/java/j-eaed1-pdf.pdf
  • Why is it hard to accept? Because we’re wired for hierarchy. We’re trained accordingly. We live in conventional contexts. And we really, really, want to control.
  • Establish constraints: boundaries and goals. Because complexity science doesn’t tell you to simply wait for the rightsolutions to emerge. The way managers define boundaries andconstraints strongly influences what emerges from a self-organizing team[Lewin 2001]. You don’t manage the people. You manage the system.
  • Emergent Architecture - March 2011

    1. 1. Enterprise Architecture<br />Balancing Upfront Planning and Emergence<br />
    2. 2. Published Description of this Talk<br />“How do we handle the balance between the big up front plan, the ivory tower EA team, with the need to inspect and adapt and respond to the emerging needs of our customers? <br />Can you identify the challenges with this description?<br />
    3. 3. Survey Question #1What stakeholder groups are represented in the audience?<br />End-Users<br />The Business (sales, marketing, key management, etc)<br />Customers<br />Domain Experts (analyst, architect, systems engineer, etc)<br />Developers (designer, coder, tester, etc)<br />
    4. 4. Survey Question #2How many of you consider yourself an “agilist”?<br />Agile Development<br />Waterfall Development<br />Iterative Development<br />Iterative and Incremental Development<br />Parallel Test Development<br />Acceptance Test Driven Development<br />Measure of Success<br />Conformance to Plan<br />Constant Flow of Business Value<br />Process<br />Handoffs/Sequential<br />Teamwork/Parallel<br />Culture<br />Command and Control<br />Leadership and Collaboration<br />Design<br />Big Design Up Front<br />Continuous<br />QA<br />Big Test on Backend<br />Continuous<br />Tool Support<br />Highly Specific<br />Fully Integrated<br />Lean and Efficient Value Streams<br />
    5. 5. Which is Better?<br />Predictive?<br />Adaptive?<br />
    6. 6. Which is Better?<br />Trick Question<br />Obviously Both Are Required<br />Balance Is Required<br />Balance is the Real Trick!<br />Predictive<br />Adaptive<br />
    7. 7. Balance Is The Trick<br />“Any development effort should be a balance between anticipation (planning based on what we know) and adaptation (responding to what we learn over time).”<br />Jim Highsmith, Embracing Change, 17th March 2011 <br />
    8. 8. How Do We Find The Right Balance?<br />“It Depends”<br />“It’s Situationally Specific”<br />“It’s All About The Context”<br />Shucks! I Want It To Be Easy!<br />Don’t you hate those answers?<br />
    9. 9. How Do We Make It “Easier”?<br />Focus On The Goal!<br />Huh? What’s the Goal?<br />
    10. 10. What Is Our Goal?<br />Every Business Is Exactly The Same<br />Every Business Has Exactly The Same Goal<br />Every Business Is In Business… <br />TO MAKE MONEY!<br />
    11. 11. So, How Much Should We Plan?(How do we find the right balance?)<br />Plan as much as necessary to receive a positive ROI on the planning investment<br />We Plan Only To<br />Maximize Value<br />Delivery<br />
    12. 12. Balance Is The Trick<br />“If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a start-up company before it has to turn a profit.”<br />Balancing Agility and Discipline, Barry Boehm and Richard Turner<br />
    13. 13. Survey Question #3On A Scale of 1 – 5, How Important Is Planning?<br />Planning Is The Purest Form Of Evil<br />…<br />…<br />…<br />Planning Is The True Secret Sauce of Development<br />Another Trick Question. Have You Been Paying Attention? <br />
    14. 14. Agenda<br />Introduction<br />What is Architecture?<br />What is an Architect?<br />What is Emergence?<br />How Can We Foster Emergence?<br />How To Maximize Value Delivery<br />Conclusion and Q&A<br />
    15. 15. Survey Question #4How large are the companies represented by this audience?<br />< 500 Associates<br />501 – 1,000 Associates<br />1,001 – 5,000 Associates<br />5,001 – 25,000 Associates<br />> 25,000 Associates<br />
    16. 16. Definition of Architecture<br />“Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” [IEEE 1471]<br />IEEE Computer Society, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems: IEEE Std 1472000. 2000.<br />
    17. 17. Definition of Architecture<br />“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”<br />Bass, Len; Clements, Paul; & Kazman, Rick. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003.<br />
    18. 18. Definition of Architecture<br />Software Architecture encompasses the set of significant decisions about the organization of a software system:<br /><ul><li>Selection of the structural elements and their interfaces, by which a system is composed
    19. 19. Behavior as specified in collaborations among those elements
    20. 20. Composition of these structural and behavioral elements into larger subsystems
    21. 21. Architectural style that guides this organization</li></ul>G. Booch, P. Krutchen, K. Bittner and R. Reitman. The Rational Unified Process — An Introduction. 1999. Definition derived from Mary Shaw’s definition presented in 1995 at the First International Workshop on Architectures for Software Systems.<br />
    22. 22. Definition Of Architecture<br />"Architecture is about the important stuff. Whatever that is.“<br />Who Needs An Architect?, Martin Fowler<br />http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf<br />Architecture is the stuff that's hard to change later. And there should be as little of that stuff as possible.<br />Martin Fowler via Neil Ford<br />Evolutionary architecture and emergent design: Evolutionary architecture<br />http://public.dhe.ibm.com/software/dw/java/j-eaed10-pdf.pdf<br />
    23. 23. Setting The Record Straight<br />Architecture Has A Tremendous Impact On Results<br />Few properties have as much impact on an organization’s success as does architecture.<br />There is ALWAYS an Architecture<br />Architecture is an inherent property of your organization and your software. You may not understand it. You may not communicate it. You may not have planned it. But it’s there!<br />Architecture <> Documentation<br />Architecture is that inherent property of the system – not the artifacts that describe it.<br />Architecture <> Infrastructure / Hardware<br />Architecture encompasses the myriad of perspectives and concerns that make up a solution - and enable its production. That includes hardware, software, operations, support, organization, etc.<br />These Concepts Apply To Both “Enterprise” and “Application”<br />For purposes of today’s discussion – how does emergence apply to architecture and planning – there is no difference between “Enterprise Architecture” and “Application Architecture”<br />
    24. 24. Agenda<br />Introduction<br />What is Architecture?<br />What is an Architect?<br />What is Emergence?<br />How Can We Foster Emergence?<br />How To Maximize Value Delivery<br />Conclusion and Q&A<br />
    25. 25. Why Do We Do Architecture?<br />To capture the stakeholder perspectives that affect design<br />To embrace change and to reduce the cost of solving problems<br />To create a shared vision across the team and stakeholders<br />To smooth the decision-making process<br />- Lean Architecture, Jim Coplien and Gertrud Bjørnvig<br />Focus On The Goal!<br />
    26. 26. What Is An Architect?<br />“Leads the development of the system's software architecture, which includes promoting and creating support for the key technical decisions that constrain the overall design and implementation for the project.” <br />- Rational Unified Process<br />
    27. 27. What Is An Architect?<br />“An architect is a business-minded person who best understands how to leverage technology to maximize profitability.”<br />- Paul Preiss, IASA (paraphrasing)<br />
    28. 28. What Is An Architect?<br />“A true software architect is one who is a domain expert, who knows how to apply the domain expertise to the design of a particular system, and who materially participates in implementation.” <br />- Lean Architecture, Jim Coplien and Gertrud Bjørnvig<br />
    29. 29. Competencies By Role<br />A Perfect 10! <br />
    30. 30. Architect Focus Over The Life of a Project<br />Discovery<br />Invention<br />Implementation<br />Focus<br />The Architect <br />is accountable from <br />“Concept to Cash”<br />Project Lifecycle<br />IBM – Brian Selic<br />
    31. 31. Survey Question #5True of False: My Organization Has Individuals Specifically Assigned To The Architect Role.<br />
    32. 32. Why Do We Do Architecture?<br />“Architects” are not required, but these outcomes must be satisfied!<br />To capture the stakeholder perspectives that affect design<br />To embrace change and to reduce the cost of solving problems<br />To create a shared vision across the team and stakeholders<br />To smooth the decision-making process<br />Lean Architecture, Jim Coplien and Gertrud Bjørnvig<br />
    33. 33. Agenda<br />Introduction<br />What is Architecture?<br />What is an Architect?<br />What is Emergence?<br />How Can We Foster Emergence?<br />How To Maximize Value Delivery<br />Conclusion and Q&A<br />
    34. 34. Survey Question #6True or False?<br />Emergence is a principle that<br />encourages us to defer decisions to the<br />“Last Responsible Moment” and avoid<br />“Big Up Front Planning” or <br />“Big Up Front Design”<br />
    35. 35. One Definition Of Emergence<br />Emergence is what happens when the whole is smarter than the sum of its parts. It's what happens when you have a system of relatively simple-minded component parts… and they interact in relatively simple ways. And yet somehow out of all this interaction some higher level structure or intelligence appears, usually without any master planner calling the shots. These kinds of systems tend to evolve from the ground up.<br /><ul><li>http://www.oreillynet.com/lpt/a/1574</li></li></ul><li>Another Definition Of Emergence<br />"They are bottom-up systems, not top-down. They get their smarts from below. In a more technical language, they are complex adaptive systems that display emergent behavior. In these systems agents residing on one scale start producing behavior that lies one scale above them: ants create colonies; urbanites create neighborhoods; simple pattern-recognition software learns how to recommend new books. The movement from low-level rules to higher-level sophistication is what we call emergence.“<br />- Emergence, Steven Johnson<br />
    36. 36. Shorter Definition Of Emergence<br />Collective Intelligence<br />
    37. 37. Stop The Insanity<br />Emergence is notabout the timing of decisions.<br />Emergence is about harnessing the incredible intelligence that lies dormant in our organizations – trapped in antiquated and outdated philosophies of management.<br />Emergence is about enabling and empowering the people to achieve a greater purpose.<br />
    38. 38. Agenda<br />Introduction<br />What is Architecture?<br />What is an Architect?<br />What is Emergence?<br />How Can We Foster Emergence?<br />How To Maximize Value Delivery<br />Conclusion and Q&A<br />
    39. 39. Simple Principles Of Emergence<br />The source of emergence is the interaction among agents who mutually affect each other.<br />Attend to relationships characterized by mutuality among people, among teams and among companies in order for novelty to emerge.<br />Small change can lead to large effects.<br />Seek to lead change through many small experiments, which search the landscape of possibilities.<br />Emergence is certain, but there is no certainty of what it will be.<br />Create conditions for constructive emergence rather than to plan a strategic goal in detail. Evolve solutions, don’t design them.<br />Greater diversity of agents in a system leads to richer emergent patterns.<br />Seek a diversity of people, cultures, expertise, ages, personalities, gender so that when they interact in teams, creativity has the potential of being enhanced.<br />- Complexity: life at the edge of chaos, Roger Lewin<br />Simple to Describe. Hard to Accept!<br />
    40. 40. How Do We Foster Emergence?<br />Accept that there is in fact a “Complex Adaptive System” <br />Provide leadership in the design of the system<br />Manage the system – not the people<br />Quit thinking linearly <br />Passionately apply a “new management model”<br />
    41. 41. A New Model For Management<br />Management Needs Changing<br />New model leveraging “Complexity Theory”<br />Acknowledge that organizations are really networks<br />6 Important Practices (“views”)<br />Energize People<br />Empower Teams<br />Align Constraints<br />Develop Competence<br />Grow Structure<br />Improve Everything<br />- Management 3.0, JurgenApello<br />
    42. 42. View #1: Energize People<br />People are the most important parts of an organization and managers must do all they can to keep people active, creative, and motivated.<br /><ul><li>Complexity Versus Lean, JurgenApello
    43. 43. “http://www.slideshare.net/jurgenappelo/complexity-versus-lean</li></li></ul><li>View #2: Empower Teams<br />Teams can self-organize, and this requires empowerment, authorization, and trust from management.<br /><ul><li>Complexity Versus Lean, JurgenApello
    44. 44. “http://www.slideshare.net/jurgenappelo/complexity-versus-lean</li></li></ul><li>View #3: Align Constraints<br />Self-organization can lead to anything, and it’s therefore necessary to protect people and shared resources, and to give people a clear purpose and defined goals.<br /><ul><li>Complexity Versus Lean, JurgenApello
    45. 45. “http://www.slideshare.net/jurgenappelo/complexity-versus-lean</li></li></ul><li>View #4: Develop Competence<br />Teams cannot achieve these goals if team members aren’t capable enough, and managers must therefore contribute to the development of competence.<br /><ul><li>Complexity Versus Lean, JurgenApello
    46. 46. “http://www.slideshare.net/jurgenappelo/complexity-versus-lean</li></li></ul><li>View #5: Grow Structure<br />Many teams operate within the context of a complex organization, and thus it is important to consider structures that enhance communication .<br /><ul><li>Complexity Versus Lean, JurgenApello
    47. 47. “http://www.slideshare.net/jurgenappelo/complexity-versus-lean</li></li></ul><li>View #6: Improve Everything<br />People, teams, and organizations need to improve continuously to defer failure for as long as possible.<br /><ul><li>Complexity Versus Lean, JurgenApello
    48. 48. “http://www.slideshare.net/jurgenappelo/complexity-versus-lean</li></li></ul><li>“Nurture” Emergence<br />Passionately Apply a New<br />Management Model That<br />1. Establishes Clear Context, and<br />2. Energizes and Empowers The People<br />
    49. 49. Agenda<br />Introduction<br />What is Architecture?<br />What is an Architect?<br />What is Emergence?<br />How Can We Foster Emergence?<br />How To Maximize Value Delivery<br />Conclusion and Q&A<br />
    50. 50. Recipe For Value Delivery<br />Create The Opportunity<br />Design The “System”<br />Nurture Emergence<br />Apply A New Management Model<br />Execution Loop<br />Do Just Enough Planning<br />Create The Context<br />Establish The Guard Rails<br />Lubricate Execution<br />Get On With It<br />Sense and Respond<br />Repeat<br />
    51. 51. What Planning Do We Need To Do?<br />Plan the right things at the right time<br />Just enough to “accomplish the goal” by:<br />Establishing Clear Context<br />Energizes and Empowering The People<br />Typically Focus On These Outcomes:<br />Capture the stakeholder perspectives that affect the priority aspects of the design<br />Embrace change and to reduce the cost of solving problems<br />Create a shared vision across the team and stakeholders<br />Smooth the decision-making process<br />
    52. 52. Emergence and Decisions<br />Making decisions sets the context required to enable emergence<br />There are often multiple “scales” involved<br />Decision cycles are different at different scales<br />Every scale can operate in an emergent fashion<br />Strategy/Vision/Mission -> Enterprise -> Application<br />Vertical feedback loops are required<br />
    53. 53. How Much is “Enough”?<br />“In these systems agents residing on one scale start producing behavior that lies one scale above them.”<br />- Emergence, Steven Johnson<br />
    54. 54. Establishing Context<br />Context for Energizing and Empowering<br />Context for Safety<br />Context for Efficiency<br />
    55. 55. Context For Energizing / Empowering<br />A compelling description of the goals<br />Sense of urgency and purpose<br />Alignment with vision, mission, and strategy<br />
    56. 56. Empowerment<br />“If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.”<br />- Antoine de Saint Exupéry<br />
    57. 57. Emergence and Uncertainty<br />Emergence involves some degree of uncertainty<br />Empowerment introduces independence<br />Does the Heisenberg Uncertainty Principle play?<br />
    58. 58. Emergence and Leadership<br />"Good leaders create the conditions for constructive emergence rather than trying to plan every strategic goal in detail.“<br /><ul><li>Step Back & Emerge, Dr Paul Thomas
    59. 59. http://businessdoctorme.blogspot.com/2010/07/step-back-emerge.html</li></li></ul><li>Context For Safety<br />Clarity of enterprise strategy and objectives<br />“Good enough” description of the enterprise target architecture<br />Essential architectural requirements and constraints<br />
    60. 60. Emergence and Boundaries<br />Boundaries Establish Freedom<br />Is This contrary to popular belief? <br />Freedom is Required For Speed and Agility<br />
    61. 61. Context for Efficiency<br />Not all decisions are created equal<br />Some things are harder to change than others<br />Some decisions are more “core” or “fundamental” and get the ball rolling<br />Don’t forget “strategic” vs “tactical”<br />Evolutionary architecture and emergent design: Evolutionary architecture<br />http://public.dhe.ibm.com/software/dw/java/j-eaed10-pdf.pdf<br />
    62. 62. Agenda<br />Introduction<br />What is Architecture?<br />What is an Architect?<br />What is Emergence?<br />How Can We Foster Emergence?<br />How To Maximize Value Delivery<br />Conclusion and Q&A<br />
    63. 63. Can We Let Go?<br />Understanding emergence is about: giving up control; being more tolerant of that exploratory phase where the rules don't make sense and where few goals have been clearly defined; letting the system govern itself as much as possible; and letting it learn from its own footprints.<br /><ul><li>http://www.cleanlanguage.co.uk/articles/articles/216/1/Self-Organising-Systems-Findhorn/Page1.html</li></li></ul><li>Nurture The Freak<br />a<br />r<br />F<br />k<br />e<br />
    64. 64. The World Is A Fractal<br />“Once you start thinking of strategy as an emergent phenomenon, you realize that we have often attacked the wrong end of the problem. Strategists and senior executives have too often worked on "the strategy," rather than on the preconditions that could give rise to strategy innovation. In essence, they've been trying to design complex, multicell organisms, rather than trying to understand and create the conditions from which such organisms will emerge.”<br />- “Strategy Innovation and the Quest for Value, Gary Hamel (http://www.strategos.com/articles/questforvalue.htm)<br />
    65. 65. Q&A<br />
    66. 66. Agenda<br />Introduction<br />What is Architecture?<br />What is an Architect?<br />What is Emergence?<br />How Can We Foster Emergence?<br />How To Maximize Value Delivery<br />Conclusion and Q&A<br />Appendix (Gartner On Emergent Architecture)<br />
    67. 67. Gartners “New” Emergent EA<br />“Enterprise architects must adopt a new style of enterprise architecture (EA) to respond to the growing variety and complexity in markets, economies, nations, networks and companies, according to Gartner, Inc.  Analysts advised companies to adopt ‘emergent architecture’, also known as middle-out EA and light EA, and set out definitions of the new approach.”<br />Key Characteristics of the Emergent Approach<br />“Summarised as ‘architect the lines, not the boxes’, which means managing the connections between different parts of the business rather than the actual parts of the business themselves.” <br />“Models all relationships as interactions via some set of interfaces, which can be completely informal and manual – for example, sending handwritten invitations to a party via postal letters - to highly formal and automated, such as credit-card transactions across the Visa network.”<br />Bruce Robertson, research vice president at Gartner<br />Gartner Press Release, Egham, UK, August 11, 2009<br />http://www.gartner.com/it/page.jsp?id=1124112<br />
    68. 68. Gartner Emergent EA Principles#1 Non-Deterministic<br />Non-deterministic - In the past, enterprise architects applied centralized decision-making to design outcomes. Using emergent architecture, they instead must decentralize decision-making to enable innovation.<br />I've heard about this "deterministic" EA practice. And I've also heard about unicorns. Every effective EA practice I've seen recognized its role as one of leadership - and context. One of the biggest drivers in business today is Agility - the need to respond rapidly to changing needs and opportunities. By definition, then, we are operating in a climate where the future is not pre-determined or predicted. As such, at some scale, the specific outcomes are obviously non-deterministic. But there's a huge risk of this property being abused (see Agile Is Not "Make It Up As You Go"). As a whole, any organization with an EA practice absolutely has some destination in mind... some target. It's our job to create context and to provide leadership that helps the organization translate that target into actionable goals... and to adapt its way to success.<br />http://blog.softwarearchitecture.com/2009/09/effective-enterprise-architecture.html<br />
    69. 69. Gartner Emergent EA Principles#2 Autonomous Actors<br />Autonomous actors - Enterprise architects can no longer control all aspects of architecture as they once did. They must now recognise the broader business ecosystem and devolve control to constituents.<br />Again, the idea that an Enterprise Architect could ever "control all aspects of architecture" is a farce. The power of an organization always lies with those that are serving the organizations clients - the business units. Our role in EA is to serve those people on the front line and empower them to better meet the needs of their customers - and at the same time advance the organization as a whole towards its targets. This is a role of leadership - not control - and I wrote about it in Leadership - The Secret Sauce. Emphasizing the value of "collective intelligence," that post reminds us that we can "achieve outrageous levels of performance by harnessing the intellect and energy of the people." This also came up in Nurture The Freaks where we contemplated these words from Gary Hamel, "Going forward, no company will be able to afford to waste a single iota of human imagination and intellectual power."<br />http://blog.softwarearchitecture.com/2009/09/effective-enterprise-architecture.html<br />
    70. 70. Gartner Emergent EA Principles#3 Rule-Bound Actors<br />Rule-bound actors - Where in the past enterprise architects provided detailed design specifications for all aspects of the EA, they must now define a minimal set of rules and enable choice. <br />It's a reasonably well accepted principle that an EA practice should never make a decision (or set a constraint) that could be left to the business unit or development team. In fact, enabling choice and encouraging participation are important vehicles for gaining buy-in and goodwill (see Governance Without Goodwill Is Dead). This is yet another reminder of how we need to establish context by creating guard rails that keep the organization out of the ditch.<br />http://blog.softwarearchitecture.com/2009/09/effective-enterprise-architecture.html<br />
    71. 71. Gartner Emergent EA Principles#4 Goal-Oriented Actors<br />Goal-oriented actors - Previously, the only goals that mattered were the corporate goals but this has now shifted to each constituent acting in their own best interests.<br />With the guard rails in place, responsibility for driving rests on the individual drivers, each in their own vehicle with both hands on the wheel.<br />http://blog.softwarearchitecture.com/2009/09/effective-enterprise-architecture.html<br />
    72. 72. Gartner Emergent EA Principles#5 Local Influences<br />Local Influences - Actors are influenced by local interactions and limited information. Feedback within their sphere of communication alters the behaviour of individuals. No individual actor has data about all of an emergent system. EA must increasingly coordinate.<br />There is a massive amount of information flowing through the modern organization, and the majority of it originates and circulates right on the front line where the dynamic nature of today's agile organization demands a high degree of "in the heat of battle" decision-making. This suggests EA add value by encouraging a broad community that is willing and able to actively contribute to and consume a real-time, high-bandwidth stream of communication. It's not our job to assimilate it all and make decisions. Instead, as individual consumers at the trough of the information stream, we help drive the information out to those who need it the most. I don't really like the use of the word "coordinate" here. We're only coordinating in the indirect sense. Perhaps this role is some combination of the Connector, Maven, and Salesman roles described by Malcolm Gladwell in The Tipping Point.<br />http://blog.softwarearchitecture.com/2009/09/effective-enterprise-architecture.html<br />
    73. 73. Gartner Emergent EA Principles#6 Dynamic or Adaptive Systems<br />Dynamic or Adaptive Systems - The system (the individual actors as well as the environment) changes over time. EA must design emergent systems [that] sense and respond to changes in their environment.<br />This is one of the most important functions of the Enterprise Architecture discipline in a modern organization. We have a responsibility to bring a "systems thinking" perspective to the table and influence the design of flexible and adaptive systems - systems that have the ability to learn from and respond to their experience. When talking about systems, here, it's critical that we deliberately design this adaptive nature into our products AND our organizations. I'm happy to see that Gartner is beginning to recognize organizations as a type of "complex adaptive system".<br />http://blog.softwarearchitecture.com/2009/09/effective-enterprise-architecture.html<br />
    74. 74. Gartner Emergent EA Principles#7 Resource-Constrained Environment<br />Resource-Constrained Environment - An environment of abundance does not enable emergence; rather, the scarcity of resources drives emergence.<br />Most of us are operating under the influence of unprecedented economic conditions, and these times demand that we become more creative. In fact, creative isn't really the right word. To respond to the reality of the corporate climate of today (and tomorrow), we're going to need to be "clever" - adroit, nimble, resourceful, and mentally quick. The organizations that thrive in the future will be those that respond today by building a sustainable system of Agile capabilities that maximize the contribution of every associate.<br />http://blog.softwarearchitecture.com/2009/09/effective-enterprise-architecture.html<br />

    ×