Downloaded 25 times
Uploaded byAman Kohli
Frayed Edges - Architecture In Practice
This document discusses various types of architecture including enterprise, solution, integration, software, business, and domain architecture. It also outlines key architecture principles and deliverables. The principles include target architecture, roadmap, view models, patterns used in the solution, peer review, and governance. Key deliverables include documentation of these principles, various views of the system, and references. Maintaining architecture is important to enable the solution, ease implementation through patterns and alignment, and support the system post-deployment through quality attributes.
More Related Content
Similar to Frayed Edges - Architecture In Practice
Frayed Edges - Architecture In Practice
- 1. Frayed Edges Architecturein Practice October 24, 2011 @akohli, www.linkedin.com/in/kohlia
- 2. Architecture is aboutcategorisation, Separation of Concerns and making decisions Explicit
- 3. Types of Architecture •Enterprise • Solution • Integration • Software • Business • Domain ...
- 5.
- 6.
- 7. Principles Target Architecture Architecture
- 8. Principles Target Architecture Architecture Roadmap
- 9. Principles Target Architecture Architecture Roadmap View Model
- 10. Principles Target Architecture Architecture Roadmap View Model Patterns Used In Solution
- 11. Principles Target Architecture Architecture Roadmap View Model Patterns Used In Solution Peer Review
- 12. Principles Target Architecture Architecture Roadmap View Model Patterns Used In Solution Peer Review Governance
- 13.
- 14. Part of TheSolution • Metaphor • Architecture + Domain Design • Ease Implementation • Architectural Patterns • Alignment • Better After-Life • Quality Attributes, SLAs
- 15. Part of TheTeam • Project Plans/Sprint Plans/etc • Architecture • Domain Driven Design • UX • Development Teams • Deployment and Support Teams
- 16. Part of LargerGroup • 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
- 17. The Quality Attributes •Security • Performance • Scalability • Resilience • Recoverability • Address CAP
- 18.
- 19. 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
- 20. 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
- 21. Views Why? How? What? Where? Implementation Deployment Business View Functional View View View •Work with Business •Identify main The software (or • The physical to support their components and process) realisation of business Level interactions components will be The Solution Architecture •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
- 22. Architectural Patterns ‣ Identify the Common patterns used in the solution ‣ Commonality can be reused Principle of Orthoganality ‣ Ease implementation
- 23. Peer Review • Technicalreview of solution, roadmap • other architects, not part of product • feedback to technical solution • part of governance and alignment
- 24. Governance • Part of Enterprise Architecture Role • Adhere to corporate and industry technical standards • Application Rationalisation • Ball of Mud to Clarity!
- 25.
- 26. Avoid • Architecture becominga 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
- 27.
- 28. 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
Editor's Notes
- #2 IntRO - me and my role\n what does an architect do?\n what value?\n do you need one?\n your experience?\n
- #3 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
- #4 \n
- #5 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
- #6 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
- #7 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
- #8 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
- #9 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
- #10 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
- #11 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
- #12 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
- #13 Differentiate with Technology\nthink amazon services rant\npercolator \nevolution and roadmaps\nhelp tackle technical parts of solutions in bitesized chunks\n\n
- #14 Agile/XP Metaphor\nRole of Conceptual/Target Architecture\nFitting together\nBetter Afterlife\n- \n\n
- #15 \n
- #16 This is Enterprise Architecture\n\n
- #17 \n
- #18 \n
- #19 \n
- #20 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
- #21 \n
- #22 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
- #23 \n
- #24 Explain ball of mud -\n- architecture by accident, no decoupling\n- hodgepodge\n
- #25 \n
- #26 \n
- #27 \n
- #28 \n