Imagine cup- Architecture/Design talk

1,304 views
1,194 views

Published on

A presentation I did to support the Egyptian Imagine cup team, but anyone is welcome to use/download/comment

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,304
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
31
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Future proofing
  • Yasalam law nedeehashewayet inheritance
  • ”A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away”
  • Imagine cup- Architecture/Design talk

    1. 1. Designing your solution<br />Mohamed R. Samy<br />3 April 2010<br />
    2. 2. About the Speaker<br />Snr. Application Architect Right Solutions<br />Solutions Architect MVP 2008- 2009<br />MCP, MCSD Since 2001<br />Aiming for 2 communities <br />ALM<br />Dynamics AX<br />http://developmentmaster.spaces.live.com<br />@msamy<br />
    3. 3. Your Mission<br />Together you can make a difference. Create inventive software and service solutions that unleash the power of technology to benefit your community, country or region… or … the entire planet. <br />
    4. 4. Agenda<br />Problem domain<br />Solution domain<br />Conceptual view<br />Logical view<br />Physical view<br />Elements of a SOLID design<br />
    5. 5. Problem domain<br />So what is your problem?<br />
    6. 6. U.N. millennium goals<br /> Reduce child mortality<br />Eradicate extreme hunger and poverty<br />Promote gender equality and empower women<br />Achieve universal primary education <br />
    7. 7. U.N. millennium goals<br /> Improve maternal health<br /> Combat HIV/AIDS, malaria and other diseases <br />Ensure environmental sustainability <br /> Develop a global partnership for development<br />
    8. 8. Problem definition<br />What is the problem? <br />Who has the problem or who is the client/customer? This should explain who needs the solution and who will decide the problem has been solved.<br />What form can the resolution be? What is the scope and limitations (in time, money, resources, technologies) that can be used to solve the problem? <br />
    9. 9. Solution domain<br />Define your architecture<br />“Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability.”<br />
    10. 10. Define your architecture goals<br />
    11. 11. Architeture goals<br />Start with use cases and usage scenarios or “user stories”<br />Have a scenario for each feature in your system<br />How will your system be part of the scenario?<br />
    12. 12. Architecture principles<br />Build to change not to last<br />Model and analyze to reduce risk<br />Use the model as a collab. Tool<br />Identify key engineering decisions<br />
    13. 13. Build to change not to last<br />
    14. 14. Model to analyze and reduce risk<br />Yasalam law nedeehashewayetinheritance!<br />
    15. 15. Use models as a comm. & collab. tool<br />
    16. 16. Identify key engineering decisions<br />
    17. 17. Evaluating your architecture<br />What assumptions have I made in this architecture?<br />What explicit or implied requirements is this architecture meeting?<br />What are the key risks with this architectural approach?<br />What countermeasures are in place to mitigate key risks?<br />
    18. 18. Design principles<br />Separation of concerns<br />Single responsibility<br />Don’t repeat yourself (Dry)<br />Minimize BDUF<br />
    19. 19. Single responsibility<br />
    20. 20. Separation of concerns<br />
    21. 21. Don’t repeat yourself<br />
    22. 22. Don’t BDUF/YAGNI<br />Yagnibalash big design up front !<br />
    23. 23. So what do I do then?<br />There are some things you need to determine.<br />
    24. 24. What type of application is it?<br />Web, desktop, cloud service?<br />
    25. 25. How will it be deployed?<br />Mobile app, specialized hardware? Web inerface?<br />Don’t forget the physics!! Bandwidth, network latency, processor speeds?<br />
    26. 26. Choosing the appropriate technology<br />Shouldn’t we just use the buzzwords?<br />
    27. 27. Determine quality attributes<br />How good? How fast? How much is enough?<br />“Quality is not a goal, it’s a lifestyle.” Dubai one<br />Happy scenarios vs exceptions.<br />
    28. 28. Determine crosscutting concerns<br />Loggging<br />Exception handling<br />Caching<br />Security<br />Profile management … etc<br />
    29. 29. Architecture styles<br />Layered<br />Service bus<br />DDD<br />Client/Server<br />SOA<br />Which is better?<br />
    30. 30. Arch Styles<br />
    31. 31. So can I see a sample design document? <br />Use a wiki, or office live.<br />Forget templates, build your own.<br />
    32. 32. How can we support you?<br />Me evil idea… <br />How else may we help?<br />
    33. 33. Make us proud <br />
    34. 34. Thank You<br />m_raafat_samy@hotmail.com<br />@msamy<br />
    35. 35. Q&A<br />

    ×