Frayed Edges - Architecture In Practice

  • 550 views
Uploaded on

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

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/

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
550
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
23
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

  • 1. Frayed Edges Architecture in Practice October 24, 2011 @akohli, www.linkedin.com/in/kohlia
  • 2. Architecture is about categorisation, Separation of Concerns and making decisions Explicit
  • 3. Types of Architecture• Enterprise• Solution• Integration• Software• Business• Domain ...
  • 4. Architecture
  • 5. PrinciplesArchitecture
  • 6. Principles Target ArchitectureArchitecture
  • 7. Principles Target ArchitectureArchitecture Roadmap
  • 8. Principles Target ArchitectureArchitecture Roadmap View Model
  • 9. Principles Target ArchitectureArchitecture Roadmap View Model Patterns Used In Solution
  • 10. Principles Target ArchitectureArchitecture Roadmap View Model Patterns Used In Solution Peer Review
  • 11. Principles Target ArchitectureArchitecture Roadmap View Model Patterns Used In Solution Peer Review Governance
  • 12. As an Enabler
  • 13. Part of The Solution• Metaphor • Architecture + Domain Design• Ease Implementation • Architectural Patterns • Alignment• Better After-Life • Quality Attributes, SLAs
  • 14. Part of The Team• Project Plans/Sprint Plans/etc• Architecture• Domain Driven Design• UX• Development Teams• Deployment and Support Teams
  • 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. The Quality Attributes• Security• Performance• Scalability• Resilience• Recoverability• Address CAP
  • 17. ArchitectureDeliverables
  • 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. 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. 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. Architectural Patterns‣ Identify the Common patterns used in the solution‣ Commonality can be reused Principle of Orthoganality‣ Ease implementation
  • 22. Peer Review• Technical review of solution, roadmap• other architects, not part of product• feedback to technical solution• part of governance and alignment
  • 23. Governance• Part of Enterprise Architecture Role• Adhere to corporate and industry technical standards• Application Rationalisation• Ball of Mud to Clarity!
  • 24. Pitfalls
  • 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. References
  • 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