Deciding the framework

[Chiranjeevi Kanthraj]

Hi all

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

regards
Chiru

[Ulf Dittmer]

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.

[Gregg Bolinger]

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.

[Hong Anderson]

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.

[Ulf Dittmer]

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]

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).