addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1light-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Software Architecture Decomposition

  • May 1, 2014 · 6:00 PM
  • This location is shown only to members

IDesign's approach to large system analysis design is by using volatility to decompose a system into its comprising services,  contrasting it with the most common mistake done in architecture, using functionality to identify services. You will also see how to overcome the real hurdles architects face perusing volatility-based decomposing, simple and practical techniques for identifying areas of volatility, common telltale signs or "smells" when your design is still functional when using the Method, IDesign's approach for system architecture.

Join or login to comment.

  • Hao L.

    A very nice meetup covered the core of The Method. With the previous knowledge learned from the Architect Master Class, this meet up joins all the dots together. Now I can sense what is an architect.

    Here is my understanding: as an archetect (powered by the method), one should first engage the business and get the core use case. After that, collect use case that matters to the business. Decompose the system based on volatility, and then generate component chart.

    Iterate the decomposition a few times based on the collected use case. If not all use case is covered, then make modification by break down components further or abstract from a different angle.

    And then apply the rest of methodology provided by the method to fine tune the architecture. Thank you for bring this meetup, looking forward for the next one :)

    May 12, 2016

  • Asim S.

    Thank you very much Ally. The presentation was an eye opener. I knew the problem exists in the Functional Design and yet went working over and over on it just hoping it will get stable at some phase of the project. Volatility-based decomposition does makes sense. I'll try implementing it in my next project.

    May 2, 2014

  • Anne

    This really very interesting. Thanks, Ally for the presentation, it was well delivered. Volatility-based decompostion is a different perspective but but makes sense as it allows for less time and effort when requirements change. I see great value in this.

    1 · May 1, 2014

11 went

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy