aspose file tools*
The moose likes Other Application Frameworks and the fly likes Deciding the framework Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Deciding the framework" Watch "Deciding the framework" New topic
Author

Deciding the framework

Chiranjeevi Kanthraj
Ranch Hand

Joined: Feb 18, 2008
Posts: 289

Hi all

I need to Know how the software architect decides the Framework for the application?

regards
Chiru


-Chiru
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41574
    
  54
I'd argue that deciding on a particular framework is not a question of architecture, but of implementation. The decision depends on many factors, just a few of which are:
  • Are the framework's capabilities a good match for the requirements?
  • Are the framework's capabilities a good match for the application's architecture?
  • Are the developers already familiar with it? If not, how steep is the learning curve? If it is steep, do the benefits justify mastering it?
  • Do people have confidence in the framework's future? That is to say, will bugs be fixed, will new technologies be supported where it makes sense, etc.

  • The list goes on.


    Ping & DNS - my free Android networking tools app
    Gregg Bolinger
    GenRocket Founder
    Ranch Hand

    Joined: Jul 11, 2001
    Posts: 15299
        
        6

    I agree with Ulf. At the architect level, it shouldn't matter what framework is used, so long as it implements the architect's design decisions.


    GenRocket - Experts at Building Test Data
    Hong Anderson
    Ranch Hand

    Joined: Jul 05, 2005
    Posts: 1936
    I agree with Ulf, but I think software architects should also be responsible for choosing development frameworks .
    IMO, software architects are not merely responsible for "software architecture". They must do many things like requirements management/scope management, team building, schedule management (work with project manager), risk management (work with project manager), get involved in implementation, plan for testing, etc.

    For me, I will consider using several criteria like features, architecture & design of the frameworks, extensibility, documentation.


    SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
    Ulf Dittmer
    Marshal

    Joined: Mar 22, 2005
    Posts: 41574
        
      54
    Kengkaj Sathianpantarit wrote:I think software architects should also be responsible for choosing development frameworks .
    IMO, software architects are not merely responsible for "software architecture". They must do many things like requirements management/scope management, team building, schedule management (work with project manager), risk management (work with project manager), get involved in implementation, plan for testing, etc.

    I don't want to derail the discussion of frameworks, but just point out that there is a difference between the function of software architecture and the person of the software architect. Many of the functions you list above have nothing to do with architecture, but with team management and project management. Those functions *may* be exercised by the same person who is responsible for the architecture (especially in small teams), but they may just as well be separated, and generally will be, once the team and/or the project reaches a certain size. So I think that's an important distinction.
    Hong Anderson
    Ranch Hand

    Joined: Jul 05, 2005
    Posts: 1936
    In practice, I don't think most of software architects can do *only* software architecture, the same goes for developers and other roles as well.

    From IBM's opinion the software architects must have skills about experience, leadership (work closely with project manager), communication (motivate, mentor, etc.), goal-orientation and pro-activity.

    I cannot copy-and-paste because there is Copyright, but IBM's opinion is quite similar to my post above.

    You can read Microsoft's opinion about architect job roles on http://www.microsoft.com/learning/mcp/architect/specialties/default.mspx.
    Right now, there is no MCA in software architect, but I think solution architect is the closest.
    Solutions architects: Communicate mainly with business owners within a company and with the technical staff that delivers the solution. The projects they work on affect the enterprise and they design the solution to take advantage of the existing assets, integrate them into the existing environment, follow the enterprise architecture, and solve the business problems of the business owner or unit. They are primarily responsible for taking a project through envisioning and design, and are more consultative to the project manager during the development and deployment phases, ensuring the project stays true to the architecture, timelines, and budgets. If problems occur, they are escalated to the solutions architect.

    They work with one or more business owner at a time to create line of business-based solutions that integrate with the existing infrastructure and can be supported by the operations group. They typically do not manage the technical staff that is delivering the solution, therefore, solutions architects must demonstrate their skills as a technologist and persuade the staff regarding the validity and approach to the solution. The approach they take to creating architecture is to gather business requirements, select the technologies that provide the best solution, and then identify the products available that will best fit the solution they are proposing, based on the details of the project.

    Key areas of focus include integration, workflow, and applications (purchased, developed, and business).
     
     
    subject: Deciding the framework