0
Frayed Edges Architecture in Practice        October 24, 2011   @akohli, www.linkedin.com/in/kohlia
Architecture is about categorisation, Separation of    Concerns and making decisions Explicit
Types of Architecture• Enterprise• Solution• Integration• Software• Business• Domain ...
Architecture
PrinciplesArchitecture
Principles               Target ArchitectureArchitecture
Principles               Target ArchitectureArchitecture   Roadmap
Principles               Target ArchitectureArchitecture   Roadmap               View Model
Principles               Target ArchitectureArchitecture   Roadmap               View Model               Patterns Used In...
Principles               Target ArchitectureArchitecture   Roadmap               View Model               Patterns Used In...
Principles               Target ArchitectureArchitecture   Roadmap               View Model               Patterns Used In...
As an Enabler
Part of The Solution• Metaphor  • Architecture + Domain Design• Ease Implementation  • Architectural Patterns  • Alignment...
Part of The Team• Project Plans/Sprint Plans/etc• Architecture• Domain Driven Design• UX• Development Teams• Deployment an...
Part of Larger Group• Solutions are part of a larger group• Conform to the idioms and Practice of  the group• Consistency ...
The Quality Attributes• Security• Performance• Scalability• Resilience• Recoverability• Address CAP
ArchitectureDeliverables
Principles•   Form the aims of the system•   Can be Business, Functional,    Technical or Deployment•   any technical deci...
Target Architecture and       Roadmaps‣   Impact of Architecture -            ‣   3-5 years in advance    Architecture as ...
Views       Why?                    How?                  What?                 Where?                               Imple...
Architectural Patterns‣   Identify the Common    patterns used in the    solution‣   Commonality can be    reused     Prin...
Peer Review• Technical review of  solution, roadmap• other architects, not  part of product• feedback to  technical soluti...
Governance•   Part of Enterprise Architecture Role•   Adhere to corporate and industry technical standards•   Application ...
Pitfalls
Avoid• Architecture becoming a book keeping  exercise - it’s not about box ticking• Ivory Tower architects - the architect...
References
Links•   Ambler Enterprise Architecture and     •   SOA Design Patterns, Thomas Erl -    Agile - http://www.agiledata.org/...
Frayed Edges - Architecture In Practice
Upcoming SlideShare
Loading in...5
×

Frayed Edges - Architecture In Practice

589

Published on

Architecture Overview Presentation given at TCD on 24/11/2011 to a group of MSc students.

The slides are used as talking points during the talk, with some supporting material in the links and speaker notes.

Overview of architecture, system architecture, software architecture, enterprise architecture and governance provided. We briefly touched on the different architecture frameworks.

Speaker notes are included.

Links can be found at:
http://pinboard.in/u:akohli/t:talks:tcd/t:talks:arch/

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

No Downloads
Views
Total Views
589
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
23
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • IntRO - me and my role\n what does an architect do?\n what value?\n do you need one?\n your experience?\n
  • Going to talk about\n- what is architecture?\n- what part of the team is the arch?\n- what does an arch do?\n- how?\n- Pitfalls\n
  • \n
  • Talk about each:\n\nPrinciples\n- intention of system, the boundaries of what it does \nTarget Architecture\n- end state of how it should be - but this is evolving\n- never really reached\nRoadmap\n- using delivery cycles (eg in IT orgs, 6-12 months) how to get to target\nView Model\n- all the views:business, functional, implementation, deployment\nPatterns used \n- interaction and integration mechanisms, types of resources, and services, and interaction modes\nPeer Review\n- other arch and tech in broader group\nGovernance\n- adhering to technology standards, corporate standards\n
  • Talk about each:\n\nPrinciples\n- intention of system, the boundaries of what it does \nTarget Architecture\n- end state of how it should be - but this is evolving\n- never really reached\nRoadmap\n- using delivery cycles (eg in IT orgs, 6-12 months) how to get to target\nView Model\n- all the views:business, functional, implementation, deployment\nPatterns used \n- interaction and integration mechanisms, types of resources, and services, and interaction modes\nPeer Review\n- other arch and tech in broader group\nGovernance\n- adhering to technology standards, corporate standards\n
  • Talk about each:\n\nPrinciples\n- intention of system, the boundaries of what it does \nTarget Architecture\n- end state of how it should be - but this is evolving\n- never really reached\nRoadmap\n- using delivery cycles (eg in IT orgs, 6-12 months) how to get to target\nView Model\n- all the views:business, functional, implementation, deployment\nPatterns used \n- interaction and integration mechanisms, types of resources, and services, and interaction modes\nPeer Review\n- other arch and tech in broader group\nGovernance\n- adhering to technology standards, corporate standards\n
  • Talk about each:\n\nPrinciples\n- intention of system, the boundaries of what it does \nTarget Architecture\n- end state of how it should be - but this is evolving\n- never really reached\nRoadmap\n- using delivery cycles (eg in IT orgs, 6-12 months) how to get to target\nView Model\n- all the views:business, functional, implementation, deployment\nPatterns used \n- interaction and integration mechanisms, types of resources, and services, and interaction modes\nPeer Review\n- other arch and tech in broader group\nGovernance\n- adhering to technology standards, corporate standards\n
  • Talk about each:\n\nPrinciples\n- intention of system, the boundaries of what it does \nTarget Architecture\n- end state of how it should be - but this is evolving\n- never really reached\nRoadmap\n- using delivery cycles (eg in IT orgs, 6-12 months) how to get to target\nView Model\n- all the views:business, functional, implementation, deployment\nPatterns used \n- interaction and integration mechanisms, types of resources, and services, and interaction modes\nPeer Review\n- other arch and tech in broader group\nGovernance\n- adhering to technology standards, corporate standards\n
  • Talk about each:\n\nPrinciples\n- intention of system, the boundaries of what it does \nTarget Architecture\n- end state of how it should be - but this is evolving\n- never really reached\nRoadmap\n- using delivery cycles (eg in IT orgs, 6-12 months) how to get to target\nView Model\n- all the views:business, functional, implementation, deployment\nPatterns used \n- interaction and integration mechanisms, types of resources, and services, and interaction modes\nPeer Review\n- other arch and tech in broader group\nGovernance\n- adhering to technology standards, corporate standards\n
  • Talk about each:\n\nPrinciples\n- intention of system, the boundaries of what it does \nTarget Architecture\n- end state of how it should be - but this is evolving\n- never really reached\nRoadmap\n- using delivery cycles (eg in IT orgs, 6-12 months) how to get to target\nView Model\n- all the views:business, functional, implementation, deployment\nPatterns used \n- interaction and integration mechanisms, types of resources, and services, and interaction modes\nPeer Review\n- other arch and tech in broader group\nGovernance\n- adhering to technology standards, corporate standards\n
  • Talk about each:\n\nPrinciples\n- intention of system, the boundaries of what it does \nTarget Architecture\n- end state of how it should be - but this is evolving\n- never really reached\nRoadmap\n- using delivery cycles (eg in IT orgs, 6-12 months) how to get to target\nView Model\n- all the views:business, functional, implementation, deployment\nPatterns used \n- interaction and integration mechanisms, types of resources, and services, and interaction modes\nPeer Review\n- other arch and tech in broader group\nGovernance\n- adhering to technology standards, corporate standards\n
  • Differentiate with Technology\nthink amazon services rant\npercolator \nevolution and roadmaps\nhelp tackle technical parts of solutions in bitesized chunks\n\n
  • Agile/XP Metaphor\nRole of Conceptual/Target Architecture\nFitting together\nBetter Afterlife\n- \n\n
  • \n
  • This is Enterprise Architecture\n\n
  • \n
  • \n
  • \n
  • Architecture as an enabler\n- Percolator at google: \n* big change to core architecture and offering, \n* addressed a quality attribute: time to update \n* enable more features - eg previews\n- Amazon and services\n- by adopting a services based approach, allows amazon to offer it’s services to en users/customers\n\nReal world Use:\n different Frameworks\n- TOGAF\n- Zachman\n- UML\n- etc \n
  • \n
  • Use software frameworks to enforce architecture\n- eg MVC \n- Spring WebFlow\n- frameworks can maintain the principles \n* eg a principle could be to allow addition of new functionality without bringing the system down. In implementation, use OSGi\n
  • \n
  • Explain ball of mud -\n- architecture by accident, no decoupling\n- hodgepodge\n
  • \n
  • \n
  • \n
  • \n
  • Transcript of "Frayed Edges - Architecture In Practice"

    1. 1. Frayed Edges Architecture in Practice October 24, 2011 @akohli, www.linkedin.com/in/kohlia
    2. 2. Architecture is about categorisation, Separation of Concerns and making decisions Explicit
    3. 3. Types of Architecture• Enterprise• Solution• Integration• Software• Business• Domain ...
    4. 4. Architecture
    5. 5. PrinciplesArchitecture
    6. 6. Principles Target ArchitectureArchitecture
    7. 7. Principles Target ArchitectureArchitecture Roadmap
    8. 8. Principles Target ArchitectureArchitecture Roadmap View Model
    9. 9. Principles Target ArchitectureArchitecture Roadmap View Model Patterns Used In Solution
    10. 10. Principles Target ArchitectureArchitecture Roadmap View Model Patterns Used In Solution Peer Review
    11. 11. Principles Target ArchitectureArchitecture Roadmap View Model Patterns Used In Solution Peer Review Governance
    12. 12. As an Enabler
    13. 13. Part of The Solution• Metaphor • Architecture + Domain Design• Ease Implementation • Architectural Patterns • Alignment• Better After-Life • Quality Attributes, SLAs
    14. 14. Part of The Team• Project Plans/Sprint Plans/etc• Architecture• Domain Driven Design• UX• Development Teams• Deployment and Support Teams
    15. 15. Part of Larger Group• Solutions are part of a larger group• Conform to the idioms and Practice of the group• Consistency across a Portfolio • Economies of scale for delivery, support, maintenance
    16. 16. The Quality Attributes• Security• Performance• Scalability• Resilience• Recoverability• Address CAP
    17. 17. ArchitectureDeliverables
    18. 18. Principles• Form the aims of the system• Can be Business, Functional, Technical or Deployment• any technical decision must conform to them• If any decision deviates, change the principle or note why the deviation
    19. 19. Target Architecture and Roadmaps‣ Impact of Architecture - ‣ 3-5 years in advance Architecture as an enabler ‣ Roadmap aligned to‣ Technical boundary, forms Delivery cycles part of principles and solution approach ‣ 6-12 month duration, typically ‣ Each decision is made as part of context of target architecture ‣ Target architecture is desired state, never achieved
    20. 20. Views Why? How? What? Where? Implementation Deployment Business View Functional View View View•Work with Business •Identify main The software (or • The physicalto support their components and process) realisation ofbusiness Level interactions components will be The SolutionArchitecture •Services can be used to meet the•In practice Business derived from here functional • Machines,Architects work in the •not focused on requirements networks,Tech organisation implementation aspects software installations
    21. 21. Architectural Patterns‣ Identify the Common patterns used in the solution‣ Commonality can be reused Principle of Orthoganality‣ Ease implementation
    22. 22. Peer Review• Technical review of solution, roadmap• other architects, not part of product• feedback to technical solution• part of governance and alignment
    23. 23. Governance• Part of Enterprise Architecture Role• Adhere to corporate and industry technical standards• Application Rationalisation• Ball of Mud to Clarity!
    24. 24. Pitfalls
    25. 25. Avoid• Architecture becoming a book keeping exercise - it’s not about box ticking• Ivory Tower architects - the architect is part of the team• Polishing door knobs • Architecture for Architecture’s sake • too many components, too finely granular services
    26. 26. References
    27. 27. Links• Ambler Enterprise Architecture and • SOA Design Patterns, Thomas Erl - Agile - http://www.agiledata.org/ http://www.amazon.com/Design- essays/enterpriseArchitecture.html Patterns-Prentice-Service-Oriented- Computing/dp/0136135161/• SEI Software Architecture Overview - ref=ntt_at_ep_dpt_2 http://www.sei.cmu.edu/architecture/ • Twitter rearchitecture to Scala - http://• Enterprise Integration Patterns: www.infoq.com/interviews/kallen- Designing, Building, and Deploying scala-twitter Messaging Solutions, Hohpe, Woolf - http://www.amazon.com/Enterprise- • Guardian rearchitecture - http:// Integration-Patterns-Designing- www.guardian.co.uk/info/developer- Deploying/dp/0321200683/ref=sr_1_1? blog/2011/apr/18/scala ie=UTF8&qid=1319462905&sr=8-1 • Large-scale Incremental Processing• Amazon Vs Google - Services centric Using Distributed Transactions and approach https://plus.google.com/ Notifications - http:// 112678702228711889851/posts/ research.google.com/pubs/ eVeouesvaVX pub36726.html
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×