Architecture enabling business

Last Wednesday I attended a meeting of the New England chapter of the International Association of Software Architects, where Roger Sessions, CTO of ObjectWatch, gave a great talk based on his “Simple Architectures for Complex Enterprises” book. (I bought the book during the talk using the Amazon iPhone app … the last thing I needed was more enablement to buy stuff from Amazon.)

Below are my raw notes. Anything annotated “Thought” is something I was thinking, but didn’t say; generally I haven’t edited these, so some are addressed later in the talk (and some are just plain wrong). Further, I offer no guarantee that I haven’t misinterpreted something Roger said.

• Address the “problem of complexity” – the “biggest problem in IT”
• Federal IT
• • $71B in federal IT projects; $47B invested in “at risk” projects
  • • Opportunity cost? (What government can’t do without the projects delivered)
    • • Estimated at 5x; a company would demand 5x ROI on an IT project
  • 100% of defense-related projects on the “at risk” list
• Map to private sector
• • $14T GDP; assume 5% in IT => $700B in IT (? something wrong)
  • Assume 33% at risk (no evidence) => $231B in at-risk projects
  • Thought: aren’t there already good studies on this stuff?
  • Now assume 5x in opportunity cost again => $1.115T
• Back to federal IT
• • FEA rollout in 2006, specifically to address the problem if at-risk IT projects
  • Trend in IT projects considered at risk:
  • • 30% iin 2007; 43% in 2008; 66% in 2009
  • Thought: why would anyone think that FEA would address this?
• Epidemiology
• • In medicine, we assume some common factor when many exhibitions of common symptoms (illness, death)
  • How?
  • • Look at all the characteristics of the individuals involved to identify commonality, and assume that it is the common factor or a contribution to it
• What is the common factor for IT risk/failures?
• • Not geography, industry, methodology, technology
  • Roger’s belief: complexity: the only common factor across all failures
• Thought: what are the long-term trends? Are we at a new peak of complexity relative to failures?
• Questions
• • What’s complexity? all-in: organizational, data schema, code
  • My question: presume you consider also organizational complexity as well as systems complexity?
  • • A: Mostly organizational, actually; can rebuild systems
  • Is communication the problem?
  • • A: A sympton, not the cause.
  • Why not identified sooner? What happens to at-risk projects?
  • • A: Some fail because they run out of money. Some because they don’t meet the needs of the business.
• Can’t build architectural quality attributes (security, as an example) into a complex system. Much harder than doing so for a simple system.
• Complexity
• • Glass’s Law
  • • For every 25% increase in problem complexity, there is a 100% increase in solution complexity.
    • • (Not stated by Glass, but implied by his “Facts and Fallacies of Software Engineering”)
  • If you have a system with 10 functions, how many functions can you add before doubling the complexity? 2 or 3.
  • If you double the number of functions in a system, you increase complexity by 8x.
• Implications
• • Methodologies that work well for small projects don’t work well for large projects.
  • • e.g. agile
• Thought: isn’t the solution to make our “systems” smaller. This is what SOA was about – autonomy.
• Methodologies/frameworks don’t explicitly address complexity, so won’t succeed.
• Questions
• • Isn’t agile about breaking large projects/systems into small ones?
  • • A: Agile doesn’t tell you how to do that, but if you can conceive small systems/projects, agile be effective.
  • Examples of projects/companies that have succeeded?
  • • A: A current client: a state government replacing their IT system. Using “this” methodology to decompose.
    • • Who could respond to a 400 page RFP? Only 3 or 4 firms. Predetermines the solution.
  • Problem is lack of cohesion and loss of knowledge? Doesn’t this increase complexity?
  • • A: Problem is when we lose knowledge of complex systems, not the root.
    • A: If complexity is managed as a primary concern, the others won’t manifest.
  • Doesn’t this imply that we just spend more time on up-front design?
  • • A: Yes, but we need to design explicitly to manage complexity.
  • Survivability of requirements/stability of organizations?
  • • A: Also symptoms. Need to address holistically.
• Model for complexity: a function of the number of states a system can be in
• • A penny has two; two have four (or three?); a six-sided die has 6
  • Thought: this is unmeasurable for a software system of any relevance. Does that matter?
  • Generally: (number of states)^(number of objects)
  • Justifies Glass’s law: if we add functionality, we add variables linearly. If we add variables linearly, we add complexity exponentialy.
• Questions
• • What’s a database row in this model?
  • • A: <shrug/> Consider database columns as variables.
• If we split up “systems”, we manage:
• • One system of 12 6-state objects => >2B states
  • 2 systems of 6 6-state objects each => < 2 x 45K states
• Glass’s Law
• • 100 -> 1164 functions => 2048x increase in complexity
  • 2 x 582 functions => 2 x 250 complexity measure
  • Keep going …
• (Mentions SOA in passing; presumes independence of systems; clearly motivated by previous work on Software Fortresses)
• • Thought: Estimate independence with autonomy?
• As number of subsystems increases, you reach a complexity minimum, then complexity begins increasing
• • => need to know when to stop decomposing
  • Workflow and management complexity increases – need to address coordination among subsystems
• How to partition? Different complexity curves for each:
• Goal of architects should be to find the simplest possible solution
• • Thought: slight misuse of Einstein’s “but no simpler” quote; impossible to be “too simple” in this model, but possible to over-decompose such that simplicity is lost
• Ha: “decibel-driven decision making” – whoever yells loudest
• How do we know which partitioning is simplest?
• • Equivalence relations
  • • Five characteristics
    • • Binary function: F(x, y)
      • Boolean: F(x, y) in {true, false}
      • Reflexive: F(x, x) = true
      • Symmetric: F(x, y) = F(y, x)
      • Transitive: F(x, y) = true ^ F(y, z) = true => F(x, z) = true
    • Can drive a unique partition with an equivalence function; e.g. same-category-as
    • But can you convince yourself that there’s an equivalence function that is correlated to simplicity?
    • Example: synergy
    • • Two functions are synergistic if, from the business perspective, neither is useful without the other
      • Perhaps the optimal equivalence relation
      • Issue is separating business function and IT realization
      • • Need collaboration between IT and business to get it right
• Process
• • SIP: Simple Iterative Partitions
  • Value proposition: dramatically improves return on IT investment by addressing complexity.
  • Thought: a motivation for SOA. Ok.
• Recap
• • IT complexity is a major problem
  • Cannot be solved by existing methodologies
  • • Can’t judge architectures today without building them
    • • Thought: scenario-based assessments (like LAAAM and ATAM) can help
  • To solve complexity, must understand it
  • • SOA by itself isn’t the answer, because it pre-supposes a decomposition (?)
  • Can only be solved by “best possible” partitioning
  • Best partitions are driven by equivalence relations
  • SIP is based on best possible partitioning through equivalence relations
• Thought: partitions today are temporal – groups of things built at the same time
• My question: is there stability in the synergy equivalence relation?
• • Argued not, Roger suggested that its the implementations that change, not the partitions
  • Same argument as documented in Enterprise Architecture as Strategy, Motion (Microsoft’s business architecture methodology – unsure of its current state)
  • Neeraj Sangal of Lattix: multi-allocation based on equivalence relation?
  • • IT is a problem, because they want to select a single solution (implementation) for multiple business problems. e.g. scheduling, but scheduling of different kinds of things
• Partition: “Autonomous Business Capability”
• Thought: (on my way home) What about on-the-same-P&L-as as an equivalence function? Substantially stable