• Like
  • Save
Role of an architect
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Role of an architect



Published in Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    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


  • 1. Hasith Yaggahavita
  • 2. Why BigDUF is difficult?30.10.2012 99X TECHNOLOGY | PRODUCT ENGINEERING 2
  • 3. Why BigDUF is difficult?30.10.2012 99X TECHNOLOGY | PRODUCT ENGINEERING 3
  • 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. Why BigDUF is difficult?30.10.2012 99X TECHNOLOGY | PRODUCT ENGINEERING 5
  • 6. Why BigDUF is difficult?30.10.2012 99X TECHNOLOGY | PRODUCT ENGINEERING 6
  • 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. Role of an Architect? Minimize the architecture! Convert Architecture to Design!30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 8
  • 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. 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. 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. What about Brownfield Projects?You are the accountant of technical debts!30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 12
  • 13. What about Brownfield Projects? Be the miner & planter of patterns!30.10.2012 CONSULTING | OUTSOURCING | PRODUCT ENGINEERING 13
  • 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