Applying Agile Values to Enterprise Architecture

Download Applying Agile Values to Enterprise Architecture

Post on 16-Apr-2017




2 download


<p>Applying Agile Values to Enterprise Architecture<br><br>Software Architectural Trends<br>Past, Present, and Onwards</p> <p>by: Benjamin Scherrey</p> <p>Chief Systems ArchitectProteus Technologies, Co. Ltd.</p> <p>Twitter: @proteusguyEmail: scherrey@proteus-tech.com</p> <p>Architecture</p> <p>Architecture is Form not Structure</p> <p>Keeps the effort focused on Value</p> <p>Identifies the Stable Parts of the System</p> <p>Introduces Constraints (Architectural Drivers)</p> <p>The result of tough decisions made now in order to make future decisions easier</p> <p>Debate: Does Form follow Function (Behaviour) or does Function follow Form?Answer: Form follows failure. Architectural styles evolve after years of trial and error.What do we mean by form then?Jim Coplien offers the example of a bottle plant. The bottle is the structure. The form (mold) could be injected with a variety of materials and still provide it's value. The FORM is the bottle's ESSENSE. The space created gives it's use. Pleasing asthetics makes us want to use it. This is a BIG DEAL!</p> <p>Value = Crossing the Chasm</p> <p>Stability != StaticCodify Business processes so we don't have to worry about them.</p> <p>Embodies the critical design decisions that typify a system.Constraints paradoxically give us freedom!</p> <p>Significance of design decisions need to be understood and assessed.</p> <p>Goals of Architecture</p> <p>Reduce Cost of Change</p> <p>Reduce Coupling/Increase Cohesion</p> <p>Support Locality of Decision Making</p> <p>Shared Vision Upon Which Whole Team Can Proceed</p> <p>Reduces the significance of decisions because the hard decisions have been made and make the easy ones easier.Making easy decisions first constrain your options and make hard decisions harder.</p> <p>Larry ConstantineCoupling is the degree to which each program module relies on each one of the other modules.Cohesion is a measure of how strongly-related or focused the responsibilities of a single module are.In a highly-cohesive system, code readability and the likelihood of reuse is increased, while complexity is kept manageable.</p> <p>Loosely coupled systems allow for decomposition based on Time (when we need to know/decide) rather than strictly based on Code Structure.</p> <p>Enterprise Architecture<br>Pitfalls</p> <p>Bigger Budgets, Lowered Expectations</p> <p>Throw It Over the Wall Design</p> <p>Beautiful Works of Fiction</p> <p>People confuse the rules of drawing with the rules of construction not realizing that they are not the same. -- Leon Battista Alberti Italian Renaissance Architect (1404-1472)</p> <p>Never the intention (except perhaps for Vendors!) but often the result. Attaching the word Global to it almost guarantees it will never be delivered.</p> <p>Distributed development means you can't silo your architecture decision making yet that's what most companies do with their Ivory Tower Architects.If your architects aren't producing code to back up their designs then you have a problem.Coplien's version of Conway's Law - "If the parts of an organization (e.g. teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble. ... Therefore: Make sure the organization is compatible with the product architecture."</p> <p>Blueprints document the FINAL decisions once completed.Not only Customers but also Designers get enthralled by the beautify of large UML diagrams so that they forget the Business Justifications. This is not a new problem.</p> <p>Heavy documentation actually eliminates the ability to determine the significance of a decision.</p> <p>Enterprise Architecture<br>Pitfalls</p> <p>Magazine Architecture</p> <p>Don't forget about the people who will besubjected to your system!</p> <p>Magazine Architecture is pretty pictures of empty rooms before you put the people into them.</p> <p>Keep it REAL.</p> <p>Make it sustainable!</p> <p>How Much Architecture?</p> <p>Big Upfront Designvs.No Upfront Designvs.Rough Upfront Design</p> <p>BUFD Classic Waterfall FAILDesign Movement from 1980s. ISO-9001CASE Tools Knowledgeware's ADW/ TI's IEFProgrammers would become obsolete once this code generation stuff started working.Couldn't deal with EMERGENT requirements.Presumed to know things we can't possibly have known therefore doomed to fail to deliver VALUE to stakeholders from the beginning.</p> <p>NUFD suggested by early XP/TDD proponents. Basically a myth. Having 10-20 years domain knowledge helps but what if it's the first time you're doing this? </p> <p>RUFD Rough sketch of map. Point out land marks and things to watch out for.Explore options.Result must be working code.</p> <p>Agile Values</p> <p>"Programs must be written for people to read, and only incidentally for machines to execute." <br> Hal Abelson <br> (Structure and Interpretation of Computer Programs, Second Edition)</p> <p>"Having the faculty of quick motion. Nimble. Active. Readiness." Oxford English Dictionary </p> <p>An Architecture makes you Ready. James Coplien</p> <p>Software Development is a Human Endeavor</p> <p>Agile as a process recognizes and aligns itself with this realization better than any other.</p> <p>So what is the CORRECT definition of Agile?</p> <p>Agile is an adjective not a NOUN or VERB.</p> <p>To be Agile you must first be strong.</p> <p>How do we achieve readiness?</p> <p>Agile Architecture</p> <p>An Agile ModelThe Agile Manifesto Utah 2001</p> <p>Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan </p> <p>Agile is a Direction, not a Destination. There is more than one path!</p> <p>Agile Architectural Values</p> <p>Mayo-Smith Pyramid</p> <p>Beware: Grandiose Designs Incur Grandiose RisksScope fixed, budget &amp; schedule may suffer.</p> <p>Focus: Immediate, practical functionality maximizes value of each increment while reducing risk. Scope flexible, budget, schedule under control.</p> <p>Focus is on ALWAYS delivering VALUE to CUSTOMER.</p> <p>To deliver value we must manage risk!</p> <p>Classic Waterfall / Big Upfront Design</p> <p>If you fix scope then budget &amp; schedule become variables (and they never go down).</p> <p>Pharoh StoryPharoh got two levels down and died... huge waste.</p> <p>Deliver value early &amp; often.</p> <p>Fix your budget &amp; schedule then focus on delivering incremental value as early as possible.</p> <p>LEAN vs AGILE (OPTIONAL)</p> <p> For our purposes they are equivalent. Difference is priority of focus when executing.</p> <p> Initial reaction of an Agile team when encountering an obstable is to go around it.</p> <p> Initial reaction of a Lean team when encountering an obstable is to remove it.</p> <p>Agile Architecture How-to</p> <p>Agile is a reaction against methodological excesses"Plans are useless, but planning is everything." Dwight D. Eisenhower</p> <p>Put a Stick in the Ground</p> <p>Design Lives in Code</p> <p>Fight methodolofical excess. Rejects Ivory Tower Architects &amp; Silo'd teams.Focus on DOING.Piecemeal growth, local adaption.</p> <p>Sometimes reactions can go too far. Don't abandon planning when you abandon over detailed plans.</p> <p>How to get started doing?It's OK to know stuff. Leverage local domain knowledge.Document your assumptions &amp; be prepared to change them as you learn new things.Find the stable parts of the system (typically data)</p> <p>Don't build big documents.Build shared (executable!) vision.Make docs that summarize what the code provides details for.Write an email don't call it a document!</p> <p>Agile Architecture How-to</p> <p>SCRUM (An actual discipline!)Everybody all together from the beginning.</p> <p>Test Driven Development &amp; Continuous IntegrationYou can't implement what you can't test.</p> <p>SCRUM (Jeff Sutherland 1993) inspired by LEAN and the Toyota Way. High Innovation, High parallelism. Working on the edge of chaos.Time boxing, incremental &amp; iterative development + standup meetings from Bell LabsDon't work overtime.Can't fit arbitrary work to an arbitrary schedule.</p> <p>Small Cross functional teams - no silosWe will deliver what we can to an agreed upon level of quality.</p> <p>Constant design. Everybody's an architect.Automation and frequent execution &amp; feedback critical.</p> <p>How else can you actually measure what value is being delivered or that you've met your agreed-upon quality levels?No more optional than double entry ledgers for accountants or clean room procedure for surgeons.</p> <p>SPIKEsIdentify with certainty those things that are uncertain.As they are also User Stories and prioritized together there is local control over when this value/risk must be identified. Not all risk is equal. Managing risk mitigation is essential.</p> <p>Iteration ReviewsFrequent reviews and feedback loops gets the project on track and also revaluates how well the process is working for us in the first place.</p> <p>Architecture without the Architect</p> <p>No Software Architects in Asia (Few Anywhere)</p> <p>Think Like an Architect (identify value stream/fit into ecosystem)</p> <p>Send out Scouting Parties (Fail Fast)</p> <p>Hire a Guide (proper use of consultants)</p> <p>(SKIP IF LESS THAN 15 MINUTES REMAINING)Takes 10-15 years of solid experience in a variety of technologies to become an architect.Zero Technical Career Paths == Lots of incredibly smart people with little experience and little exposure managing 20 other people one chapter behind them. This is an issue that will take 10-20 years to fix if we start today. No movement towards that however.Have to import them until then. Demand is insanely high. (Auto mechanic anecdote)</p> <p>ADD MORE HERE</p> <p>21st Century Architecture Challenges</p> <p>FAT Object Interfaces (Enterprisey)</p> <p>Brittle Distributed Dependencies (SOAP)</p> <p>How to Test for Value?</p> <p>General Loss of Cohesion</p> <p>OO has been an unqualified success in terms of improving our ability to model and implement systems.Unfortunately the most successful objects in our systems get used by many parts of their system so their interfaces get fat &amp; complex, especially Enterprise objects like Javabeans.</p> <p>Distributed systems have really helped break up some of the issues of monolithic architectures and generally increased cohesion. Coupling, however, has not been significantly reduced and, in fact, can be increased because you're tightly coupled with a system that you don't have control over. Remote objects exposed as SOAP services suffer much of the same brittleness issues as CORBA did in the 90s. RESTful systems help this and it's nice to see Microsoft getting on board now and dropping SOAP.</p> <p>Original proponents of TDD suggested it as an alternative to ANY upfront design. The concept of YAGNI and refactoring using a 100% discovered approach replaced thinking and designing as an activity. This may be fine for systems where the entire business value model and entities can fit in your head but fails for anything larger than that. Not saying that anyone should be coding LARGE systems. The Dependency Horizon of anything a team is coding on should be quite visible and small. But the integration of these small systems to compose LARGE systems absolutely requires an architecture that clearly identify VALUE STREAMS and how each part fits into the ECOSYSTEM.To wit TESTs should demonstrate value delivered so where and how we test is just as important as the fact that we do test. This is hard to identify with current architecture &amp; design processes.</p> <p>I just said distributed systems improved cohesion, right? Yes but abandoning procedure &amp; structured coding practices has also made it difficult to identify the actual ALGORITHMs we are implementing. They are broken up and strewn across multiple classes &amp; object methods so as to be unidenfifiable. Functional languages (for all their advantages and promising applicability to parallel systems) swing the pendulum too far by prohibiting any side effects and most stateful coding. There is a clear loss of cohesion for any processes that must cross multiple class boundaries.</p> <p>New Architecture on the Horizon</p> <p>Failures of the Object Oriented ModelProgramming in Classes rather than Objects</p> <p>Lost our Use Cases</p> <p>Responsibility Driven Design</p> <p>Design &amp; Architecture hasn't stopped. There are serious issues to address and a promising new option to consider.</p> <p>Object Oriented Revolution of late-80s &amp; early 90's originated in late 60s with Simula 67 and fully realized with SmallTalk.Objects should be independent, anthropomorphic entities acting as self-aware computers.GUIs exposes objects to Users MVC (Trygve Reenskaug 1978) Unifies programmer's vision of program with data model of program.Languages expressed objects solely as classes good at modeling data and fairly static.Unfortunately classes are poor at modeling behaviour Users vision of the program. Behaviour often does not fall along class/data lines.</p> <p>Computers hold data in classes. Intelligence is in the Use Case.Ivar Jacobson 1986Use Cases best model behaviour using Actors or Roles (which we interpreted as Class Objects) but we kinda lost touch with this fact because even class oriented OO was paying big dividends.</p> <p>My OO Experience</p> <p>(Responsibility Driven Design 1989) - Rebecca Wirfs-Brock</p> <p>Domain Context Interaction</p> <p>Trygve Reenskaug &amp; James Coplien</p> <p>What Object Oriented Intended</p> <p>What the System Isvs.What the System Does</p> <p>Orthogonal to MVC</p> <p>So Trygve meets Rebecca on a boat in Norway and figures out that classes don't have responsibilities, Roles do! Coplien meets him and helps take it forward as a discipline.</p> <p>OO is supposed to engage the end user &amp; capture their mental model. Got it half right (data not behaviour). ROD was an attempt to fix this.Focus on class based got us off track.</p> <p>Classes model data and structure What the system is the Domain Objects. Mental model of how the system works on the inside. What about usage behaviours?</p> <p>Behaviours set the Context for how the Domain objects are Used. Described in Use Cases.A use case should:Describe what the system shall do for the actor to achieve a particular goal.Include no implementation-specific language.Be at the appropriate level of detail.Not include detail regarding user interfaces and screens. This is done in user-interface design, which references the use case and its business rules.</p> <p>Roles/Interfaces come from UXHelping programmer separate Use Case part of code from Data model.MVC is matching Objects from bottom with Roles from TopSo if Classes aren't properlly Roles where do we get those?</p> <p>Domain Context Interaction</p> <p>Roles(vs. Classes)</p> <p>Proc TransferMoney( SrcAccount, DestAccount )Class SavingsAccountClass Checking Account</p> <p>StatelessImplement Behaviour of Algorithm</p> <p>Taxonomy: Data (Class) + Algorithm (Role) -&gt; Object</p> <p>Are Injected &amp; Removed from Classes at RUNTIME</p> <p>A Role is simply a name or label</p> <p>Source Account &amp; Destination Account in the Context of a TransferMoney Transaction.What are the class types for the Accounts?</p> <p>Who here has a Source Account?</p> <p>Classes talk about Objects in terms of Form/Structure.Roles talk about Objects in terms of Behaviour (how it's...</p>


View more >