locked
Software architecture... I'm stuck! RRS feed

  • Question

  • Hi all!

    I'm currently stuck in the design process of my next app. This is nothing new as I've been trying to get past this particular hurdle (over several projects) for the last 3-4 years without much success.

    Everything goes well until the end of the requirement gathering phase. I have a list of detailed , categorized requirements and I think the next logical step would be to work on the architecture of the project at a highest possible level of perspective. Well... I can't seem to be able to do it.

    The various elements of the my current application are relatively simple, but their sheer quantity is what I believe warrant a good overall design. The application is also using various internet protocols and is muti-threaded at its core, which doesn't make things any simpler.

    I have no problem designing at level closer to the code, and I believe I am fairly good at it. But in the past I had to jump from high-level design to this lower level because I just can't get it done. And the resulting software is not as good as it should.

    I have bought and borrowed a bunch of books including "Code Complete 2nd edition" from Steve McConnell (amazing book!). While Code Complete contains what seem to be adequate knowledge to get me going, I'm still stuck. I have tremendously improved other levels of the design/coding process, but the high-level architecture is still somewhat a mystery to me. I have yet to see/read any real-world information about how to proceed when you have a large software project.

    At this point I should mention that I have no formal education in computer programming and I learned by myself over the past 20 years. I'm currently using Visio and UML to plan things and I'm programming only in C++ and Pascal for this project using both Visual Studio 2005 and BDS 2006. I'm a freelance programmer and I personally know of no one that can help.

    So, any suggestion? Books? Web site? Any organization offering this type of training? Companies offering internship? Am I desperate to learn? yes!

    Thanks!

    --Eric



    Friday, March 10, 2006 5:15 AM

Answers

  • Hi

    I am not sure what are the hurdles you see that make you feel "stuck". You might need to look at some points here 

    1. Get to know the intent of the architecture, what are the key business drivers. Identify these drivers.

    2. Divide it to simplify.

    3. User various architectural approaches to get different perspectives into the system.

    4. See how each approach achieves the business goals, system goals you have identified.

    5. Use the best technique in your current context.

    But yet again practise it to learn it.

     

    Friday, March 10, 2006 7:23 AM
  • Hi Eric,

    I know of couple of book resources that i thought you would be interested in.

    1. Domain Driven Design by Eric Evans. Addison Wesley 2003 (http://www.amazon.com/exec/obidos/tg/detail/-/0321125215/ref=pd_sim_b_4/104-3756240-1938363?%5Fencoding=UTF8&v=glance)

    2. Patterns of Enterprise Application Architecture by Martin Fowler. Addison Wesley (http://www.amazon.com/gp/product/0321127420/104-3756240-1938363?n=283155)

    3. UML Distilled by Martin Fowler. Addison Wesley (http://www.amazon.com/exec/obidos/tg/detail/-/0321193687/qid=1142014625/sr=1-1/ref=sr_1_1/104-3756240-1938363?v=glance&s=books)

    I would also suggest you to keep a tap on http://www.martinfowler.com/. Its worth it.

    Regards

     

    Friday, March 10, 2006 6:19 PM
  • Eric,

    I would say the first step is recognizing that there is a better way (which you obviously seem to).  The profession of "architect" often has a number of different meanings.  In fact you could probably bring 5 architects from 5 different companies together and they would describe their daily tasks completely differently.

    What is common though is something you started to hit on in one of your responses.  Architects need to work at a higher level of abstraction and help guide designers through the process of refinement.  So where then do you start?  Well it should be something that aligns with the business in which you are delivering systems. 

    Most likely any large company (which would demand a large application like the one you are talking about here) will have multiple lines of business.  Those lines of business have assets or systems that they "own" (for example your HR LOB owns the corporate user information).  So when you start to architect a new system the first process is determining how to leverage what you already have.

    The second part of that is what constraints or existing patterns are documented within your organization that should be adhered to in an effort to conform to some archietcture road map.  The architects typically have a vision for where the technology industry is heading and they will use every opportunity to put in place steps to bring an organization toward that end.

    So you ask what level of abstraction do you start at ... well in my opinion you start by addressing an overall plan or vision for where you want to be in 5 years and start to design and deliver systems that show how you are taking steps toward that vision.  So if you want to move an enterprise toward SOA you will start to define architecture documenation that delivers reusable enterprise services.  New systems will attempt to aggregate existing artifacts and always avoid reinventing the wheel.

    This is where frameworks for delivering applications come in handy.  If you look at MSF 4.0 you'll see how architects are involved in the process.  MSF will also explain the deliverables produced by archtitects to ensure the right level of governance takes place in any organization.

    I also have found during my days as a developer that the best way to learn is from other peers that do the same type of work day in and day out.  I am a HUGE proponent of communities like the .NET User Groups and now as an architect I've become a huge fan of IASA (http://www.iasahome.org) International Association of Software Architects.  If there is one in your area that is the best place to start learning from other people that are practicing architects.

    I could go on and on and on but I'll leave you with this.  Architecture is all about starting at a high level vision and using the process of refinement to get to an application architecture that makes sense to developers, architects, planners, and your business areas.  This can't be done in one step ... business people will never want to see a class diagram .... developers rarely want to see a business strategy document.  Delivering iterations from the highest level to the lowest level is the only way to get everyone on board and keep them moving toward a unified goal.

     

    Friday, March 10, 2006 8:03 PM

All replies

  • Hi

    I am not sure what are the hurdles you see that make you feel "stuck". You might need to look at some points here 

    1. Get to know the intent of the architecture, what are the key business drivers. Identify these drivers.

    2. Divide it to simplify.

    3. User various architectural approaches to get different perspectives into the system.

    4. See how each approach achieves the business goals, system goals you have identified.

    5. Use the best technique in your current context.

    But yet again practise it to learn it.

     

    Friday, March 10, 2006 7:23 AM
  • Hello Sandeep, thanks a lot for taking the time to reply.

    After reading your message I realize that one of the problems I have is that since I have no experience with architecturing at a high level of abstraction I have no idea what is the meaning of most of the suggestions you made.

    #2 is pretty clear and #5 sounds like good common sense, but aside from what seem like good advice to someone that already knows how to proceed I have no idea what it means and what I should actually be doing once in front of my screen...

    I know it's not time to build classes and functions, but I can't seem to be able to find out what I really should be doing.

    Thanks,

    --Eric




    Friday, March 10, 2006 8:44 AM
  • Hi Eric,

    I know of couple of book resources that i thought you would be interested in.

    1. Domain Driven Design by Eric Evans. Addison Wesley 2003 (http://www.amazon.com/exec/obidos/tg/detail/-/0321125215/ref=pd_sim_b_4/104-3756240-1938363?%5Fencoding=UTF8&v=glance)

    2. Patterns of Enterprise Application Architecture by Martin Fowler. Addison Wesley (http://www.amazon.com/gp/product/0321127420/104-3756240-1938363?n=283155)

    3. UML Distilled by Martin Fowler. Addison Wesley (http://www.amazon.com/exec/obidos/tg/detail/-/0321193687/qid=1142014625/sr=1-1/ref=sr_1_1/104-3756240-1938363?v=glance&s=books)

    I would also suggest you to keep a tap on http://www.martinfowler.com/. Its worth it.

    Regards

     

    Friday, March 10, 2006 6:19 PM
  • Hi Badri, thanks for replying.

    I will indeed look up these resources. The site of Fowler seems really interesting.

    In case someone else reads this post, I'd like to add an older book that I just got hold of that have a few interesting bits (I just skimmed a couple of chapters):

    Software Project Survivial Guide, by Steve McConnell. Published in 1997.
    http://www.amazon.com/gp/product/1572316217/104-3470243-7793509

    It's not really up-to-date since it's 9 years old, but still seems like a good read. Anyone read it?

    Thanks!

    --Eric

    Friday, March 10, 2006 7:42 PM
  • Eric,

    I would say the first step is recognizing that there is a better way (which you obviously seem to).  The profession of "architect" often has a number of different meanings.  In fact you could probably bring 5 architects from 5 different companies together and they would describe their daily tasks completely differently.

    What is common though is something you started to hit on in one of your responses.  Architects need to work at a higher level of abstraction and help guide designers through the process of refinement.  So where then do you start?  Well it should be something that aligns with the business in which you are delivering systems. 

    Most likely any large company (which would demand a large application like the one you are talking about here) will have multiple lines of business.  Those lines of business have assets or systems that they "own" (for example your HR LOB owns the corporate user information).  So when you start to architect a new system the first process is determining how to leverage what you already have.

    The second part of that is what constraints or existing patterns are documented within your organization that should be adhered to in an effort to conform to some archietcture road map.  The architects typically have a vision for where the technology industry is heading and they will use every opportunity to put in place steps to bring an organization toward that end.

    So you ask what level of abstraction do you start at ... well in my opinion you start by addressing an overall plan or vision for where you want to be in 5 years and start to design and deliver systems that show how you are taking steps toward that vision.  So if you want to move an enterprise toward SOA you will start to define architecture documenation that delivers reusable enterprise services.  New systems will attempt to aggregate existing artifacts and always avoid reinventing the wheel.

    This is where frameworks for delivering applications come in handy.  If you look at MSF 4.0 you'll see how architects are involved in the process.  MSF will also explain the deliverables produced by archtitects to ensure the right level of governance takes place in any organization.

    I also have found during my days as a developer that the best way to learn is from other peers that do the same type of work day in and day out.  I am a HUGE proponent of communities like the .NET User Groups and now as an architect I've become a huge fan of IASA (http://www.iasahome.org) International Association of Software Architects.  If there is one in your area that is the best place to start learning from other people that are practicing architects.

    I could go on and on and on but I'll leave you with this.  Architecture is all about starting at a high level vision and using the process of refinement to get to an application architecture that makes sense to developers, architects, planners, and your business areas.  This can't be done in one step ... business people will never want to see a class diagram .... developers rarely want to see a business strategy document.  Delivering iterations from the highest level to the lowest level is the only way to get everyone on board and keep them moving toward a unified goal.

     

    Friday, March 10, 2006 8:03 PM
  • I'd like to chime in here with a few suggestions.

    I have found Use Case driven design to be very productive for me. First you get a collection of the tasks that a user of your application will want to perform (Use Cases). Be careful not to get too fine grained with the use case.

    For instance a good use case for a Project Management application would be "Add task to project". "Give project task a name" would be too fine grained as a Use Case. Sometimes the line between making a task a separate Use case vs. making it a step within a Use Case. A good rule of thumb is that a Use Case performs an action on an entity. Again using the Project Management example: "Update project task" is a good use case "Edit task estimate" is too fine grained.

    Some of the issues that you mentioned such as multithreading, underlying protocols, and the like don't belong in your high level architecture. Your high-level design should show things like how your application will be composed and how the different components will interrelate.

    A standard breakdown I use has presentation, business objects, business logic (although sometimes people embed the logic within the business objects, I generally use dumb objects that just hold the data), data access, and commons. At the high level you should design your components in such a way that they only rely on each other, not on an external library. The high level architecture is all about what needs to be done (e.g. add a task to a project) and logically dividing those tasks among various components. How it's done (protocols, O/RM layer, concurrency) should be left for low-level design decisions.

    I agree with earlier respondents that you should look at Martin Fowler's Patterns of Enterprise Application Architecture and his website, both of them can really provide an eye-opening experience.

    Friday, March 10, 2006 11:05 PM
  •  Arnon Rotem Gal Oz wrote:

    Plus, I hope, you will also find my site (www.rgoarchitects.com/saf ) interesting

     

    Arnon

    Just spend a few days there and you can skip most of everything else we have posted.  Arnon has an awesome site.

    Saturday, March 11, 2006 2:18 PM
  • Wow guys, thanks a lot for all the great replies! I'll spend some time, probably days checkging it all out and let you know.

    --Eric

    Saturday, March 11, 2006 5:32 PM
  • Great job guys,

    I'm going to sticky this post and give answers to everyone who contributed (except myself).

    Michael

    Sunday, March 12, 2006 7:16 AM
  • Hi, I'd like to recommend a book that i recently discovered and am using on almost a daily basis.

    It's titled Software Systems Architecture : Working With Stakeholders Using Viewpoints and Perspectives

    Its a really cool handbook and very practical. Full of checklists and dos and donts. It helped me get off to a pretty good start when i was stuck earlier trying to express the architecture for my current integration project.

    HTH,

    Benjy

    Monday, March 13, 2006 9:14 AM
  •  Benjy wrote:

    Hi, I'd like to recommend a book that i recently discovered and am using on almost a daily basis.

    It's titled Software Systems Architecture : Working With Stakeholders Using Viewpoints and Perspectives

    Its a really cool handbook and very practical. Full of checklists and dos and donts. It helped me get off to a pretty good start when i was stuck earlier trying to express the architecture for my current integration project.

    HTH,

    Benjy

    If you fill out this form, you get a good overview of what the book covers in detail in a quick reference document.

    Monday, March 13, 2006 11:33 AM