IT architectures - the good, the bad and the ugly


Published on

Antipatterns and lessons learned on many failed and few successful architecture projects

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

IT architectures - the good, the bad and the ugly

  1. 1. Architectures: the Good, the Bad and the Ugly Miha Kralj Senior Architect Microsoft
  2. 2. 2
  3. 3. 3
  4. 4. 4
  5. 5. 5 • Structures and relationships, static and dynamic views, assumptions and rationale • Focus: decomposition and allocation of responsibility, interface design, assignment to processes and threads • Use model and guidelines; policies, mechanisms and design patterns; frameworks, infrastructure and standards • Focus: guide engineers in creating designs that maintain the integrity of the architecture Guides Developers • Architectural vision, principles, styles, concepts and mechanisms • Focus: high-level decisions that will strongly influence the structure of the system; rules certain structural choices out, and guides selection decisions and tradeoffs among others Guides Architects
  6. 6. 6 Process, Component, Deployment View Logical Architecture Detailed Diagrams, Functional Specs Conceptual Architecture Abstract View, Component Break-down Meta-Architecture Architectural vision, style and principles
  7. 7. 7 good stuff bad stuff
  8. 8. 8 Always compliment women. Nobody really cares if they are well-dressed or not.
  9. 9. 9 (What do we do?)
  10. 10. 10 Remember the preference
  11. 11. 11
  12. 12. 12
  13. 13. 13 User LAN User LAN Backup LAN Backup LAN Mgmt LAN Mgmt LAN iLO LAN Heartbeat LAN Heartbeat LAN iSCSI SAN iSCSI SAN User LAN User LAN
  14. 14. 14
  15. 15. 15
  16. 16. 16 Enterprise? Cloud??? OMG… Single user Peer net
  17. 17. 17
  18. 18. 18
  19. 19. 19
  20. 20. 20
  21. 21. 21
  22. 22. 22
  23. 23. 23
  24. 24. 24
  25. 25. 25 YetAnother Fine Layer Cream Sponge Custard Berries Sponge Custard Berries Sponge Custard Yum!
  26. 26. 26 SQL Server Project Server 2003 Project Professional 2003 PdsRequest.asp Username PasswordGo wild, grab data POST http://SERVER/projectserver/logon/pdsrequest.asp <Request> <GetInitializationData> <Release>1</Release> </GetInitializationData> </Request> <Reply> <HRESULT>0</HRESULT> <STATUS>0</STATUS> <UserName>mihak</UserName> <GetInitializationData> <GetLoginInformation> <DBType>0</DBType> <DVR>{SQLServer}</DVR> <DB>ProjectServer</DB> <SVR>SERVER</SVR> <ResGlobalID>1</ResGlobalID> <ResGlobalName>resglobal</ResGlobalName> <UserName>MSProjectUser</UserName> <Password>P@ssw0rd</Password> <UserNTAccount>SERVERUSER</UserNTAccount> </GetLoginInformation> </Reply>
  27. 27. 27 Man who eats many prunes gets good run for money.
  28. 28. 28 (degrees of freedom) Supported scenarios:
  29. 29. 29 (specific vs. generic) 1965 2010 100% 0% Function Assembler COBOL SQL Web Application-Specific General-Purpose Application Logic Business Process Logic Data Logic Data
  30. 30. 30 Build to grow Build to specifications
  31. 31. 31 Identifier Format Protocol IP Address IP packet IP ProtocolTCP/IP @ Address RFC 2822 SMTPE-mail URL HTML httpWeb URI SOAP envelope SOAP payload Ws-* Address Reference Name Document Message Container Method Operation Process
  32. 32. 32 Uncertainty Uncertainty Simple Interface (IFaP) Generic Solutions Federated Components Minimal Spec Wide range of implementations Wide range of uses
  33. 33. 33 MicrosoftMicrosoft AppModel AppModel AppModel AppModel AppModel AppModel Generic AppModel
  34. 34. 34 (Thin-waist design) RESTful operations 10mio calls per day Live API Live-aware apps AWS Thriving ecosystem
  35. 35. 35 Thin waist will make you pretty.
  36. 36. 36 Records Mgmt. Order Mgmt. Inv./ Shipping CRM Current Model Checkout Protocol Inventory Protocol Data Retention Protocol CRM Protocol Future Model Protocols are inherently stable. Applications are not.
  37. 37. 37 Data Code GeneralSpecific Unstable Stable Instance Data Metadata Class Instance Fold knowledge into data, so program logic can be stupid and robust What needs to be easy to understand and change goes into data What will be stable goes into code Data should depend on code. Code should not depend on data.
  38. 38. 38 "Service" Generic Rendering Engine Data Generic Process Engine Data Generic Rule Engine Data Generic Data Engine Data Parser Generator <Rules> e.g., BRML <Processes> e.g., BPEL <Views> e.g., XQuery <UI> e.g., XHTML "Service" DataDataData Data Parser Generator <Rules> <Processes> <Views> <UI> Update Edit Response Request SoftwareMetadata Generic Rule Engine Generic Process Engine Generic Data Engine Generic Rendering Engine
  39. 39. 39 Guest OS App B App A Guest OS app Owned by Company A Owned by Company B, executing on the host Owned by Company C, streamed to the host Owned by User, running in the Geoplex, streamed to the host Shared, temporary owned for contracting purposes
  40. 40. 40 Reaching human limits When process, platforms, technologies, workforc e and governance are defined in advance and rarely met. Quality Limited by human nature — you can enter code no faster than you can type. Limited multitasking. Speed Cheap (offshored) AD labor is limited by socioeconomic factors. Cost Manual Labor Machines' way of life — virtually unlimited When process, platforms, technologies, workforce and governance are measured and improved in real time Unlimited multitasking and variables handling Machines What could be cheaper than "software machine" with industrialized production?
  41. 41. 41 We always need strong hands on the plow.
  42. 42. 42