Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Architecture Entropy

1.788 visualizaciones

Publicado el

Architecture Entropy is a term used to describe the slow design erosion away from the structured, governed and organised towards a more disordered state.

Regardless of how well designed a computer system is, it will be subjected to the laws of Architecture Entropy.

This presentation attempts to define the term and start some thinking on how to tackle it.

Publicado en: Tecnología
  • @Chris Cooper Hi Chris, long time no speak I hope you are well. You are right that entropy score is needed and that is what I meant by the 'measure' aspect. After all you can't manage what you can't measure (or something like that). TCO is the clear message but as we know it can be very hard to get people to consider the longer term when it falls outside of the immediate budget cycle. I figured that by giving the problem a name and the start of an attempt to measure it then it might help people with the argument :-) Thanks for the comment. Cheers, Simon
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • I agree that Architecture Entropy is a reality however, because change is constant I expect you will require an 'Entropy Score'. This should be taken over time and then given a health indicator (improving or deteriorating). A strong aspect of the Entropy argument is the embracing of TCO, which will help focus those business leads demanding function to also balance this demand against run time cost. Overall a cracking concept and great advice.
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Architecture Entropy

  1. 1. Simon Greig, Executive IT Architect, IBM Global Business Services November 2015 Architecture Entropy A
  2. 2. About the Author  Simon is an experienced IBM Executive IT Architect with 20 years experience in designing and delivering complex projects  He has been working on complex systems integration projects since 1999 and over the years have been immersed in SOA, ESB and more recently cloud, mobile and agile technologies  Over his career he has delivered projects worth cumulatively about US$2Bn  Simon came up with the title term a few years ago and has finally decided to do something about it!  It is one person’s point of view on the subject…! 2 Simon Greig Executive IT Architect IBM Global Business Services Europe
  3. 3. Contents  What is Architecture Entropy  Example Architecture Entropy in Action  Architecture Entropy Consequences  What can we do about it? A
  4. 4. What is “Architecture Entropy”?
  5. 5. ar·chi·tec·ture (är′kĭ-tĕk′chər) noun. 1. The art and science of designing and erecting buildings. 2. Buildings and other large structures 3. A style and method of design and construction 4. Orderly arrangement of parts; structure 5. The overall design or structure of a computer system or microprocessor, including the hardware or software required to run it. 6. Any of various disciplines concerned with the design or organization of complex systems Source:
  6. 6. noun. 1. Symbol S For a closed thermodynamic system, a quantitative measure of the amount of thermal energy not available to do work. 2. A measure of the disorder or randomness in a closed system. 3. A measure of the loss of information in a transmitted message. 4. The tendency for all matter and energy in the universe to evolve toward a state of inert uniformity. 5. Inevitable and steady deterioration of a system or society. en·tro·py (ĕn′trə-pē) Source: (in other words, the universe tends towards disorder rather than order…)
  7. 7. compound noun. 1. A measure of the disorder in a computing system. 2. The inevitable and steady deterioration of a computing system toward a state of disorder. architecture entropy
  8. 8. A Architecture Entropy  Architecture Entropy is a term used to describe the slow design erosion away from the structured, governed and organised towards a more disordered state  Regardless of how well designed a computer system is, it will be subjected to the laws of Architecture Entropy  Typically a well designed system will initially have a low entropy due to the structure and architecture of the solution  Over time the system will be subjected to ‘entropy gain’ as the architectural and structural integrity of the system are eroded  All systems in a single organisation will eventually reach equilibrium at a similar level of entropy  Each organisation’s natural state of entropy will differ from organisation to organisation but it will always reflect the principles and attitudes of the overall organisation management  Architecture Entropy gain cannot be avoided but the levels of entropy gain can be minimised with appropriate governance and budgeting
  9. 9. Example Architecture Entropy in Action
  10. 10. A High Level Example This example is based on real experiences, it is not based on one single enterprise but the concepts and outcomes are real
  11. 11. As-Is Enterprise Components  A snapshot of part of a complex enterprise estate  Many connections between many components leads to complexity and change cost
  12. 12. To-Be Vision  An enterprise service bus component has been added to provide simplification of connectivity  Components D and G & H have been decommissioned  Structured, organised, tidy, clean…  …Expensive
  13. 13. Eventual Entropy State  During delivery it becomes hard to justify altering legacy systems that have been running for years without issue  Some connections are rationalised but others remain for operational reasons  There are short term pressures to deliver some benefit early  The ‘transition architecture’ is complex but a later release will ‘tidy things up’  Connections bypassing the ESB are re-established because they are quicker and cheaper in the short term
  14. 14. A Outcomes – any of this sound familiar? 1. The plan was to give the business what was needed as soon as possible and then tidy up the IT in the next release. The cost of later releases couldn’t be justified and so didn’t happen. 2. The additional IT complexity increased downstream costs and therefore “quicker” and “cheaper” alternatives to following the strategy were championed by the funding stakeholders. 3. The plan was based on rationalising and decommissioning legacy systems. However it was discovered late on that there were many more dependencies on the legacy systems and so it was determined to be too costly to decommission all of the legacy systems. 4. The short term “tactical solution” that was only intended to be live for a few months is now many years old and requires a lot of effort to keep it running. The result: The enterprise estate remained complex and expensive
  15. 15. Consequences of Entropy Grain
  16. 16. Entropy gain is directly linked to an increase in costs  The higher the entropy gain, the higher the overall architecture entropy and the higher the architecture’s relative operational costs  Typically entropy gain is caused by: Tactical bolt ons rather than engineered extensions Bypassing components in order to save time and then adding additional function to compensate Stovepiping Short Circuiting Duplication Avoiding flexibility in order to solve the problem of the day rather than the bigger picture Hardcoding Creating function in more than one place
  17. 17. Costs need to be balanced… Low Cost to Operate Low Cost to Change Low Cost to Build Enterprise dilemma: “Which two do you want as you can’t have all three?”
  18. 18. Consequences to Balance • Impact on operate costs: Risk of overall system fragility if “low cost” means “corners were cut” or elements of the system were left to be performed manually • Impact on change costs: Possibility of functional duplication as it was cheaper to ‘copy and paste’ function than it was to share and reuse existing. Therefore increases the cost to change • Impact on operate costs: An increase of overall system complexity to accommodate the flexibility features • Impact on build costs: Extra effort to design, build and (in particular) test the flexibility features • Impact on change costs: Potential inflexibility due to the run costs being optimised around the ‘go live’ state of the system • Impact on build costs: Increased levels of automation that requires additional design, build and test effort Low Cost to Build Low Cost to Change Low Cost to Operate
  19. 19. Costs Entropy Gain over Time Reaching Architectural Equilibrium  The Goal: Reaching a point where the architectural integrity of a system or enterprise is in balance with the costs  Achievement of this goal is incredibly hard and arguably one of the holy grails of IT  We should still try our best to balance as best as we can Architecture Integrity Costs Equilibrium point
  20. 20. What can we do about Architecuture Entropy?
  21. 21. The Level of “Entropy Gain” is Variable  Many factors determine the level of “entropy gain” of a system – Strength of technical governance – Size of the general investment budget – Business’s attitude to the complexities of enterprise IT – Organisational preference to ‘tactical’ vs ‘strategic’ – The ‘background level’ of complexity already inherent in the IT estate  An amount of gain is inevitable due to pressures on time and budget  A small amount of gain may be beneficial to allow a system to reach equilibrium  The amount of gain and downstream impact can be minimised with appropriate governance and management  Ultimately it is the IT department’s relationship with the business stakeholders that determines the entropy levels
  22. 22. Measure  Measure – The simplest way to measure entropy gain is to focus on the downstream costs of a particular cost – Don’t just focus the business case on the cost to implement; look also at a portfolio of common business change scenarios and the 5 year cost – Research the actual long term ‘lights on cost’ that the enterprise has accrued over time
  23. 23. Average Annual Cost  When comparing solution options and when ‘tactical’ vs ‘strategic’ consider the average annual cost rather than the upfront cost when comparing options  Where – A is the Average Annual Cost – C is the estimated number of system changes in a year (constant for all options) – T is the length of time the solution will be around for (constant for all options) A = Build Cost + C(Average Change Cost) + T(Annual Cost) T
  24. 24. Manage  Manage – Strengthen governance of system change to minimise the risk of short term changes causing long term costs – Create a change checklist to ensure that solution designers are considering the full life cycle changes – Keep focus on the cost case for the solution – Tightly manage deviations and exceptions from the solution architecture as if the system was being created from new
  25. 25. Minimise  Minimise – Make sure that each solution release provides value to the business and is not ‘just’ IT benefit – Use establish facts based on history and current costs – Use ‘tactical solutions’ with caution – Have a strong exit plan to get off the tactical solution – Calculate the full lifecycle costs of the tactical solution – Overall though, be pragmatic! – Every solution has an equilibrium point where the balance between the architecture purity and the overall costs is met
  26. 26. Conclusion
  27. 27. Architecture Entropy States  Strong business and technical governance  Full lifecycle design considerations  Managed exception processes so that exceptions to the standards can be achieved with managed consequences  Decisions based on the TCO Low Entropy  Medium to long term operational cost increases  Incrementally slower and more expensive to change systems  Risk of fragility in the enterprise  Progressively increasing operational costs High Entropy ! GOOD! BAD!
  28. 28. Be Aware!  Architecture Entropy will always exist  Nothing can be done to prevent entropy gain  Awareness of the existence of Architecture Entropy should help to minimise entropy gain  Invest effort to measure the impacts of decisions, especially in the longer term  Use the measurements to manage better outcomes  Minimise short term behaviours that can negatively impact an enterprise’s Architecture Entropy A
  29. 29. Further research needed…  Writing this document concluded that there are more questions to anwer: – Is it possible to consistently measure the relative entropy state of an architecture? – Is it possible to measure the “architecture half- life” to predict a either a point in time:  Where the costs of the architecture outweigh the benefits?  When the integrity of an architecture is compromised beyond a point where it is wasteful to apply full governance to it?