Role of an architect

847 views

Published on

Published in: Education
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
847
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide
  • Plan driven vs. change driven
  • Plan driven vs. change driven
  • -There a constraint on deployment environment - Technology is going to be out dated - Two selected technologies conflict with each other - Competition has moved to a different platform
  • Predicting future is difficult. We software developers are a set of lazy guys.- Build technical flexibility- It is the your architecture that enables you to be agile.
  • - Being agile is not just about ‘daily standups’ and ‘scrum masters’- It is the cohesive connected technical and management approach, that makes you agile
  • Things that are of high cost of change: - data schema - authorization - addressing - ModularizationLow coupling and high-cohesionComponent based architecture - independently evolving - loosely coupled,corse grained, with own life cycle - independently test - layeringIt is not true everything can be emerging - But architecture should not be emergent. You need something to build upon - Design can be emergent, make architecture evolutionary
  • Architecture is the constraints – things that are hard to changeThere should be little as much as possible of the constraintsExamples: - Data schema: ORM - Authorization: Facades for evolving areas - ModularizationLow coupling and high-cohesionComponent based architecture - independently evolving - loosely coupled,corse grained, with own life cycle - independently test
  • Now you know theory.. Sounds pretty easy to do… - Spring context files - Plugin architecture for JS - Hyper generic utility methods
  • Decisions made too late in a project are hugely riskyDecisions made too early in a project are arguably even moreriskyEvolutionary architecture often ends up in a disaster - aggregation of bunch of adhoc tactics - perception of no design - developers act like kidsLast responsible moment - knowledge and context - the longer you wait, the better the decisionArchitecture is requested when least amount of information is availableDo not delay too long.. And things will be difficult to change
  • Technical debt is accumulated future work that resulted by decisions made during the development of softwareWhy? - schedule pressure - bought systems - unknown unknowns - better knowledgeReduce marginal cost of a new feature
  • Find patternsWho talk to whomConstraintsMessages between componentsStyles/design patternsData structuresHarvest patternsReverse engineer the architectureWhere to Refactor?- Reduce cyclomatic complexity (edges –nodes + 2)- Afferent coupling – measure of importance
  • Role of an architect

    1. 1. Hasith Yaggahavita
    2. 2. Why BigDUF is difficult?30.10.2012 99X TECHNOLOGY | PRODUCT ENGINEERING 2
    3. 3. Why BigDUF is difficult?30.10.2012 99X TECHNOLOGY | PRODUCT ENGINEERING 3
    4. 4. Why BigDUF is difficult? “There are known unknowns, but there are also unknown unknowns” – Donald Rumsfeld30.10.2012 99X TECHNOLOGY | PRODUCT ENGINEERING 4
    5. 5. Why BigDUF is difficult?30.10.2012 99X TECHNOLOGY | PRODUCT ENGINEERING 5
    6. 6. Why BigDUF is difficult?30.10.2012 99X TECHNOLOGY | PRODUCT ENGINEERING 6
    7. 7. What is Architecture? “All architecture is design, but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significance is measured by cost of change. - Grady Booch”30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 7
    8. 8. Role of an Architect? Minimize the architecture! Convert Architecture to Design!30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 8
    9. 9. Role of an Architect? Making things easy to change Is a complex task… It’s the complexity that makes things difficult to change!30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 9
    10. 10. In addition, successful Architects do> Understand end-to-end process> Understand the vision and context> Derive solutions from real customer needs> Pragmatic on technology usage> Influence the requirements> Communicate with stakeholders30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 10
    11. 11. BigDUF or LittleDUF?Make decisions at a point at which you have the most contextand knowledge on which to base the decision.Make the commitment the moment at which failing to make adecision eliminates an important alternative30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 11
    12. 12. What about Brownfield Projects?You are the accountant of technical debts!30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 12
    13. 13. What about Brownfield Projects? Be the miner & planter of patterns!30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 13
    14. 14. Questions?30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 14
    15. 15. Further Readings> http://martinfowler.com/articles/designDead.html> http://www.in-ag.eu/uploads/media/whoNeedsArchitect.pdf> http://www.youtube.com/watch?v=K905mAKDFj0> http://www.codinghorror.com/blog/2006/10/the-last-responsible-moment.html> http://www.youtube.com/watch?v=p5Qj75nJPEs 30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 15

    ×