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.
14. Part of The Solution
• Metaphor
• Architecture + Domain Design
• Ease Implementation
• Architectural Patterns
• Alignment
• Better After-Life
• Quality Attributes, SLAs
15. Part of The Team
• Project Plans/Sprint Plans/etc
• Architecture
• Domain Driven Design
• UX
• Development Teams
• Deployment and Support Teams
16. 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
17. The Quality Attributes
• Security
• Performance
• Scalability
• Resilience
• Recoverability
• Address CAP
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
• Technical review 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!
26. 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
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
Notas del editor
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