Get executed queries history Sql

SELECT  deqs.last_execution_time,dest.text
FROM    sys.dm_exec_query_stats AS deqs
        CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE   deqs.last_execution_time > '05/11/2017 11:00' -- check date
        AND dest.text LIKE '%querytomatch%' -- optional
        AND dest.dbid = DB_ID('dbname')
        order by deqs.last_execution_time desc

Difference between J2EE,J2SE & J2ME

J2SE stands for Java 2 standard edition and is normally for developing desktop applications, forms the core/base API.

J2EE stands for Java 2 enterprise edition for applications which run on servers, for example web sites.

J2ME stands for Java 2 micro edition for applications which run on resource constrained devices (small scale devices) like cell phones, for example games.

Netbeans is an IDE (Integrated development environment) developed in Java which eases your job of application development.

Centralized Asynchronous Auditing with Service Broker

Service Broker is a new feature in SQL Server 2005. It is an integrated part of the database engine and it provides queuing and reliable direct asynchronous messaging between SQL Server 2005 instances only. In the future this is planned to be extended to non-SQL Server instances. This article shows how to use Service Broker and triggers to capture data changes.

How Service Broker works

What Service Broker does is it talks or converses with other service brokers. It does that by exchanging messages in a dialog conversation between two service brokers. Imagine two people talking to each other. The words they exchange are messages and their conversation is a dialog. To fully understand the basics we must become familiar with the terminology and what does what. I will show only basic commands. More info can be found in SQL Server Help better known as Books Online.

Commands are explained in the order of needed object creation for Service Broker conversations.

The basis of everything is a message type. A message type defines the validation of the XML message that will be performed.

The general syntax is:

CREATE MESSAGE TYPE message_type_name
 [ AUTHORIZATION owner_name ]
 [ VALIDATION = { 
NONE | EMPTY | WELL_FORMED_XML | 
VALID_XML WITH SCHEMA COLLECTION 
schema_collection_name 
} ]

This is how to create a simple message type with validation that conforms to well formed XML:

CREATE MESSAGE TYPE [//Audit/Message] VALIDATION = WELL_FORMED_XML

Next step is to create a message type contract. This contract defines which message types are allowed in a conversation. For example, if we take our two people talking from before, a contract means that they are only allowed to talk about sports. Anything else is rejected by both persons as garbage.

The general syntax is:

CREATE CONTRACT contract_name
 [ AUTHORIZATION owner_name ]
 ( { { message_type_name | [ DEFAULT ] }
 SENT BY { INITIATOR | TARGET | ANY } 
} [ ,...n] ) 

In the SENT BY part we specify which message is allowed to be sent from each point of the conversation. So we can specify that the initiator can talk about sports and women, while the target can only talk about sports.

This is how to create a simple contract type with previously created message type that can be only sent by the initiator:

CREATE CONTRACT [//Audit/Contract] ([//Audit/Message] SENT BY INITIATOR)

Next comes a queue. A queue holds every message received by each point in the conversation. Each point of conversation has it's own queue in which the received messages are waiting for processing

The general syntax is:

CREATE QUEUE [ database_name. [ schema_name ] . | schema_name. ] queue_name

This is how to create a simple queue which takes:

• a stored procedure name to execute when a new message arrives in the queue
• maximum number of concurrently running stored procedures (for very busy queues)
• and user under whose context the procedure will be run

CREATE QUEUE dbo.TargetAuditQueue 
 WITH STATUS=ON, 
 ACTIVATION ( 
 PROCEDURE_NAME = usp_WriteAuditData, -- sproc to run when the queue receives a message
 MAX_QUEUE_READERS = 50, -- max concurrently executing instances of sproc
 EXECUTE AS 'dbo' );

Every queue is associated with a service. A service exposes the functionality of contracts associated with the service to other contracts. It defines which message types the associated queue will receive. Other types are rejected. If no contract is specified then that service can only be an initiator of the conversation so we have to specify which queue it will use and which contrats are allowed.

The general syntax is:

CREATE SERVICE service_name
 [ AUTHORIZATION owner_name ]
 ON QUEUE [ schema_name. ]queue_name
 [ ( contract_name | [DEFAULT] [ ,...n ] ) ]

This is how to create a simple service with previously created contract on our previously created queue with dbo authorization:

CREATE SERVICE [//Audit/DataWriter] 
 AUTHORIZATION dbo 
 ON QUEUE dbo.TargetAuditQueue ([//Audit/Contract])

Building the Centralized Asynchronous Auditing System

Now that we're familiar with the basics of Service Broker we can go on with building our auditing system. Auditing is the means of tracking changes of your data. It provides you with a log of who did what when. In the US and EU it is also required by law for sensitive data.

Auditing is usually done by inserting changed data into the accompanying audit table in the trigger of the source table. Or it can be a part of the Update, Delete and Insert stored procedures in which case we don't need triggers. Simplest way to implement auditing is for every table to have another audit table with the same structure. The downside is that these audit tables grow very fast. This increases the database size and backup/restore times which is a negative side effect. With a lot of tables this becomes cumbersome an hard to maintain. Imagine the work you have to do if you have 10 databases with each having 40 tables. That's 10 x 40 x 2 = 800 tables you have to create. And those are small databases table-wise.

Another option is to use third-party Log Readers but they aren't fun, are they? :)

I went about it differently. I wanted to have only one database that will hold all my audited data from every database I have on the server. This way my other databases would be free of bloated audited data. If i wanted to query the audited data i ccould simply select from one table that holds everything. I also wouldn't want this scenario to impact my performance. How to implement this? Service Broker to the rescue.

Service Broker's reliable asynchronous messaging was the perfect solution. I still used triggers but the technique can be easily used in stored procedures and OUTPUT clause. I created two databases each with its own Service Broker. The auditing database is called MasterAuditDatabase and the database to be audited is called TestDb1. Both databases have SET TRUSTWORTHY ON which enables us to use cross-database service broker communication without the use of certificates. Each database has its own error table that holds errors that happen in Service Broker communication. Yes, they may happen :)

When an insert, update or delete happens our audit trigger simply takes appropriate data from the inserted and deleted pseudo tables, turns it into our well formed XML message and uses Service Broker to send it to another Service Broker in the Master Audit Database which then saves it to our auditing table. Every time a new message arrives to our target queue, a stored procedure is executed that inserts the queued message into the audit table.

For busy systems only one stored procedure couldn't possibly cope with all incoming messages. That is why we set the MAX_QUEUE_READERS = 50. To allow 50 concurrent (parallel) queue readers. Because this is a completely asynchronous operation there's no impact on performance on the initiator end. The triggers return immediately.

The code can be downloaded and is well documented so I hope it speaks for itself. The code is broken into two scripts.

• The Master Audit Database (the database that holds all audited information) and its Service Broker infrastructure
• Sample audited database and its Service Broker infrastructure

Note: You will need to copy the GUID returned by the first script and use it in the second script.

This method of auditing proved to be very good with no noticeable impact on performance. Of course the master audit database grows fast and horizontal partitioning will be surely needed. It can also be used with multiple servers where one server serves as keeper of audited data from other servers. To do this we'd have to create TCP/IP endpoints and create users, certificates and other security measures which I will show how to do in the next article.

Conclusion

Service Broker is a great addition to SQL Server and it's use has just barely scratched the surface. The future is leaning to service oriented architecture (SOA) and loosly coupled applications. With the coming of .Net 3.5 and adoption of Windows Communication and Workflow Foundations, Service Broker will fit in nicely. So learn it.

Ref:

http://www.sqlteam.com/article/centralized-asynchronous-auditing-with-service-broker

Interview Questions

.Net Framework :

1. CLR 
2. MSIL
3. CTS
4. CLS
5. Garbage Collector its Types
6. How to Programmatically Invoke GC 

C# Interview Questions : 

1. Explain OOPS Concepts & Why to use them.
2. Can we use abstract class instead of interface? If yes then give example of each where to use interface and where to use abstract class. 
3. How Exceptions handled in C# and its types
4. Why do we not simply use delegates and scrap events?
5. What is Private Constructor? 
6. What is use of yield operator in C#?
7. Difference between ref and out
8. Diff.between constant and read only.
9. Explain new features in c# 4.0 dynamic, Co and Contra Variance?
10. Difference between Var and dynamics
11. Explain Reflection concept why to use .

C# Architecture Level :

1. Design Patterns Why to Use and Explain  its types.
2. Solid Principles

Asp.Net Questions:

1. Difference between HTTP Module and HTTP Handler? Asp.net page Life cycle? In which event we can modify session data initially?
2. Session Management

Linq Questions:

1. What is difference between IQueryable and IEnumerable?
2. Difference between Func, Action and predicate? They are delegate
3. How you debug LINQ query

Jquery/Javascript:

1. How you will debug JQuery request? If javascript disable then JQuery will work?
2. How you will create asynchronous request in JQuery? Syntax?
3. Give me scenario where you will use MVC rather than asp.net and MVVM or MVP?

MVC :

Unit Testing:

WCF Questions : 

1. How to do exception handling in WCF?
2. What is WCF throttling?

Web API:

1. What is Web Api & Why to Use.
2. WCF vs Web Api

SQL Questions:

1. What is Merge statement in SQL server? Sparse column? CTC feature?
2. Difference between RANK and DENS Rank? 
3. Which are isolation levels in SQL? Difference between snapshot and serializable?
4. Agile and scrum methodology? 

A brief understanding of pointers in C

The computer’s memory is a sequential collection of storage cells. Each cell, commonly known as a byte, has a number called address associated with it. Typically, the addresses are numbered consecutively, starting from zero. The last address depends on the memory size. A computer system having 64k memory will have its last address as 65,535.

Whenever we declare a variable in our programs, the system allocates somewhere in the memory, an appropriate location to hold the value of the variable. This location will have its own address number. Consider the following example:

The above statement int var creates a location in the memory to hold integer value. That location will have an address for example assume it is 5000. The statement var = 200 stores the value 200 at the location whose address is 5000. So, in our example, var is the variable name, 200 is the value stored in var and 5000 is the address of the memory location containing the variable var.

So, we can access the value 200 either by using the variable name var or by using the address of the memory location which is 5000. We can access using the second method by storing the address in another variable. This concept of storing memory address in a variable and accessing the value available at that address is known as a pointer variable. Since the pointer is also variable, it will also have a memory address just like any other variable.

Pointer Constants

The memory addresses within a computer are referred to as pointer constants.

Pointer Values

We cannot assign the memory addresses directly to a variable. We can only get the address of a variable by using the address operator (&). The value thus obtained is known as pointer value.

Pointer Variables

Once we obtain the pointer value, we can store it in a variable. Such variable which stores the memory address is known as a pointer variable.

Accessing the Address of a Variable

The actual location of a variable in memory is system dependent. A programmer cannot know the address of a variable immediately. We can retrieve the address of a variable by using the address of(&) operator. Let’s look at the following example:

1 2 3

int a = 10; int *p; p = &a;

In the above example, let the variable a is stored at memory address 5000. This can be retrieved by using the address of operator as &a. So the value stored in variable p is 5000 which is the memory address of variable a. So, both the variable a, and p point to the same memory location.

Declaring and Initializing Pointer Variables

Declaration

In C, every variable must be declared for its type. Since pointer variables contain addresses that belong to a specific data type, they must be declared as pointers before we use them. The syntax for declaring a pointer is as shown below:

1	datatype   *pointer–name;

This tells the compiler three things about the variable pointer-name. They are:

1. The asterisk (*) tells that the variable pointer-name is a pointer variable.
2. pointer-name needs a memory location.
3. pointer-name points to a variable of type datatype. 

Consider the following example for declaring pointers:

1 2	int  *p; float  *p;

Initialization

After declaring a pointer variable we can store the memory address into it. This process is known as initialization. All uninitialized pointers will have some unknown values that will be interpreted as memory addresses. Since compilers do not detect these errors, the programs with uninitialized pointers will produce erroneous results.

Once the pointer variable has been declared, we can use the assignment operator to initialize the variable. Consider the following example:

1 2 3

int  var = 20; int *p; p = &var;

In the above example, we are assigning the address of variable var to the pointer variable p by using the assignment operator. We can also combine the declaration and initialization into a single line as shown below:

1 2	int  var = 20; int *p = &var;

Accessing a Variable Using Pointer

After declaring and initializing a pointer variable, we can access the value of the variable pointed by the pointer variable using the * operator. The * operator is also known as indirection operator ordereferencing operator. Consider the following example:

1 2 3

int var = 20; int *p = &var; printf(”Var = %d”, *p);

In the above example, we are printing the value of the variable var by using the pointer variable palong with the * operator.

Duties, Skills, & Knowledge of a Software Architect Background

SEI work in architecture-centric engineering exploits the relationship between a system's architecture and its quality attributes, and leverages architecture as the key means for ensuring that systems will support their business and mission goals.

Learn More

• Explore our architecture-related training opportunities.
• Learn about our research in architecture-centric engineering.
• Network with other software, systems, and enterprise architects.

Duties, Skills, and Knowledge of a Software Architect

Crafting the right architecture to solve the problem at hand is only part of architects' responsibilities. They must also

• define, document, and communicate it
• make sure everyone is using it, and using it correctly
• make sure that it comes out in stages in a timely way so that the overall organization can make progress before it's complete
• make sure the software and system architectures are in synchronization
• act as the emissary of the architecture
• make sure management understands it (to the detail necessary)
• make sure the right modeling is being done, to know that qualities like performance are going to be met
• give input as needed to issues like tool and environment selection
• identify and interact with stakeholders to make sure their needs are being met
• make sure that the architecture is not only the right one for operations, but also for deployment and sustainment
• resolve disputes and make tradeoffs
• resolve technical problems
• maintain morale, both within the architecture group, and externally as well. The latter is done by providing a sound design, when needed, and providing good presentations and materials to let everyone know the organization is on the right track.
• understand and plan for evolutionary paths
• plan for new technology insertion
• manage risk identification and risk mitigation strategies associated with the architecture

Information Contributed by Readers

The SEI gathered the following input from readers after June, 2006 about the primary duties of a chief software architect, including

• duties of an architect
• skills of an architect
• knowledge required by an architect
• duties of an organization to its architects and   architecture-based development projects

Christopher Brandt (Systems Architect, Moneris Solutions, Burnaby, BC, Canada)

Duties: In my experience, an architect brings together the pieces of an architecture for all aspects of the system and then communicates the architecture to the stakeholders. By aspects of the system I mean everything from software development tools to the high level design to the "off-the-shelf" components and services required for the system to function. A good architect provides a development team with all of the tools they need to put together a great system.

Skills: An architect must be technically competent and a strong communicator (written, verbal, presentation...).

Knowledge: An architect should be competent in the core frameworks used or to be used, however they need not be an expert programmer in that framework. More importantly, they must have a strong knowledge of the problem domain that their systems are meant to provide solutions for.

Organizational Support: Architects need time and leeway to experiment and learn. Software methods are continually changing, thus an architect must be given time to learn, communicate with peers and try out new stuff.

David Cornish (Technical Architect, JPMorgan, London, UK)

Duties: Ensure that new systems are built in a way that best ensures that functional requirements are met whilst also ensure that service qualities (Performance, scalability, extensibility etc) for now and for the future are achievable. Review and improve on existing systems, making use of new technologies and methodologies to seek continual improvement for existing systems. Provide high level guidance and direction on project work, making sure tha new projects fit in with an overall strategic vision.

Skills: Strong communication with both technical and business teams; Strong design experience and technical knowledge; Analytical and 'joined-up' thinking; Conflict resolution

Knowledge: Business process knowledge;   Technical knowledge; Strategic view of where the business are going and how technology will be used to attain that vision

Organizational Support: Provide clear guidance on project requirements: Provide a clear business strategy; Provide training to allow architects to stay up to speed with new technology developments

Huub van Dijk (Quality Manager, Independent, Amsterdam, Netherlands)

Duties: Now: same as system designer. Architecture is generally so loosely defined that it is virtually indistinguishable from design. This situation has been deteriorating for many years. Should be:

• Defining a prescriptive architecture based on ubiquitous standards. However, appropriate models are still scarce. An example of an excellent model is OSI. Its layers cater to the needs of many stakeholders and are completely transparent (it surpassed ubiquity and reached the status of user oblivion). Like OSI, architectural models should be layered. Any telescopic or hierarchic model is disastrous. Hence the relentless SE crisis.  
• Staying absolutely clear of anything that reeks of implementation.
• Conforming to IEEE 1471 I.e. starting with stakeholders! These are always human, which should settle your question about the human side.

Skills: Too many. I am afraid that a SA must be detected rather than selected.

Knowledge: Equivalent to: MSc Computer Science and MBA. Applicable standards (IT and domain specific). 
Available solutions and models for re-use.

George Fankhauser (Head SW, MT, Columbus, OH, USA)

Duties: Software PLM Platform Management, often including hardware resolving design decisions harmonizing design portfolio analysis (SW metrics, project metrics)

Skills: experienced designer experienced coder (yes!) communicator ambassador (sometimes)

Knowledge: sound theoretical skills (e.g. complexity measures) algorithm & data structures 101

Organizational Support: management backup veto right in projects

Theo Gantos (Consultant, TEKA, Flint, MI, USA)

Duties: A software architect must manage a constellation of issues, ranging from:

• Consulting; gathering artifacts, conducting interviews, communicating with stakeholders, selling the NEED for architecture
• Systems analysis; understanding and representing the various disparate views of information, documenting actual or probable structural issues; reverse-engineering architectures from existing structures
• Data modeling; representing the various views and representations of information in their various layers...conceptual,logical,physical; abstracting elements of information and relations to develop alternative unified database models; working with application developers to understand physical IDE limitations
• Architect-foreman-"Sage/mentor" or "cantankerous crackpot"; work hard to stay involved during the development process to modify the architecture to make adjustments for various outside forces; communicate and articulate the architectural vision in terms that each person can comprehend  

Skills: A renaissance person. Consulting, diplomacy, organization, conceptualization, abstract thinking, logical reasoning, data modeling skills in several methodologies, ability to self-evaluate and adapt quickly, presentation and communication skills, programming expertise, writing skills, sales skills, charisma, finance and return on investment calculation skills, dealing with difficult and change-resistant people, sense of humor.

Knowledge: The knowledge requirement is so staggering and extensive that there are very few persons capable of performing in an above average capacity. I cannot envision how one could possibly through strictly academic coursework, acquire this knowledge without perilous and untiring pursuit. There is much mis-information, vendor ax-grinding, self-serving, and uncritically reviewed published material that the chances of building a thorough understanding of the fundamentals is daunting.

Organizational Support: Appreciate the value of the contributions they can make , especially not in the short run, but over time. Build a recognition that architecture is vital to the life cycle of the information, does not exist solely to serve the application, and may well surpass several generations of application development. Recognize that like building a solid bridge, the value is not in how quickly and cheaply it can be built, but how ultimately useful, flexible, and durable it is over it's expected life.

Stefan Grasmann (Manager Competence Center Microsoft, Zühlke, Eschborn, Germany)

Duties: Create a common technical vision, which fulfills quality requirements. Maintain and explain this vision to anybody interested in it or those who are not, but should be. Technical quality assurance (before, during and after development). Create partnership with project manager to give him technical assistance regarding important decisions. Elaborate quality requirements and urge to test them early. Drive technical evaluation of brilliant ideas.

Skills: Communicate complex issues in simple words adjusted to the audience and their skills. 
Endurance in repeating the same idea again and again and again. 
Creativity to find simple solutions to complex issues. 
Ability to feel like a developer.

Knowledge: Experienced development know-how in different areas. Architectural styles and design patterns - from a practical point of view. Deep understanding of underlying technologies and future trends. Software Factories and productivity aspects. Domain knowledge. Understanding of potential customer base.

Organizational Support: Trust him, but control results.

Durga Srinivas Gudimetla (Associate Consultant, Tata Consultancy Services, Hyderabad, AP, India)

Duties:

• Create an organizational IT roadmap, closely interact with CXOs in defining the IT objectives
• Understand the business processes, Create a visionary roadmap to align business vision to IT vision,
• Create a robust IT architecture framework and enforce across IT systems,
• Decision authority/signoff authority on application architecture
• Ambassador between Business organization and IT organization  
• Oversee platform selection, HW, SW selection processes, Pilot studies across all IT

Skills:

• Should have extremely good knowledge on SDLC processes
• Should posses sound knowledge on IT Application architecture, Design methodologies across multiple platforms
• Should have good grip on non-functional areas like performance, scalability studies, human interaction, software ergonomics
• Commitment to quality
• Should have clarity on what business wants and ability to transform wants to results
• Thought provocative leader
• Critical reasoning skills, Decision making skills
• ROI calculation skills

Knowledge:

• Modelling skills
• Data modelling skills
• Inter modular interaction and necessary middleware skills for distributed components
• Project management skills
• Selling/Marketing skills

Organizational Support:

• Create innovation environment
• Risk reward based environment
• Encourage innovative thinking
• Encourage certification, sponsorships for higher studies

Moonesh Kachroo (Technical Manager, WNS, Gurgaon, Haryana, India)

Duties: Undermentioned are some points (other than already mentioned) which are also important duties of an Architect:

• Should know how to   strike a right balance between the "major four" -time, scope, cost and quality.
• To enforce and monitor the "agreed upon" policies and best practices   through out the organization. 
• To manage the perception of various   stakeholders (parties) and try to bring them on the same page and under the   same thought umbrella. 
• Needs to keep himself updated on all the   relevant subjects.

Skills: Should have an ability to switch between "macro" and "micro" visions effectively and efficiently, as time demands; Should have an excellent analytical skills for obvious reasons; Decision making is also one of the "must haves"; Should have an ability to foresee, plan and mitigate any type of "risk".

Rajesh Kanna (Development Manager, PT. 1rstWAP, Jakarta, Indonesia)

Duties:

• Strong Communication Skills
• Should be able to understand the BRDs(Business Requirement Document)
• Stick on to simpler, cost effective and less error prone frameworks
• Need to understand the right framework/software components and use them in right place.
• Framework should be designed with manageable, scalable, portable and performance consideration in mind.
• Should have a deep workable knowledge in OOAD and implement the same in terms of standards and policies within the architecture.
• Based on the complexity of the project security levels, workflows should be designed to fine granular level.
• Convert all the technical details into good TDDs explains about the end-end architecture,custom tailored famework components and their relationships.
• Performance considerations, profiling techniques

Skills:

• Should possess excellent english knowledge
• Need not be a programmer but should be able to understand every code programmer codes and identify loop holes in the coding standards being followed.
• Should monitor the code written very closely.
• Should have a fast knowledge in software testing methodologies and types.
• Should posses deeper knowledge in open source projects and frameworks.
• Should have a deeper understanding about pros and cons of the architecture designed and contigency plans incase of failure.
• Should understand to the team member inputs

Knowledge:

• Frameworks Spring, Struts
• Knowledge in Industrial Standard Profiling Tools
• Knowledge in Unit Testing
• Knowledge in Mobile Technology and frameworks being used.
• Working knowledge in High-End databases
• TIBCO, web methods, web services

Organizational Support:

• Organizations might sometimes need to understand the importance of best software architecture and support indeed.
• Should encourage architects to attend conferences, certifications if necessary and self update on the latest frameworks and products either in open source or commercial community.
• Encouraging architects to certify in Project Management will be an added advantage for the company.

Venkatesh Krishnamurthy (Technical Architect, Valtech India, Bangalore, KA, India)

Duties:

• Understand the business requirements from the customer and convert them to technical design.
• Be available to the team members, stake holders
• Drive the product development
• Provide design and architecture and explain this in detail to the team members
• Be hands on with programming. The architect with no programming skills cannot make a good decision
• Keep updating knowledge with latest and greatest tools and technologies
• Bring the best tools and his past experience into the organization
• Create a low coupled-extensible architecture
• Be aware of the process in place
• Make quick decisions and stand by it
• Be open for suggestions from all the team members
• He should provide good configuration plan
• Review the test cases
• Make decisions to reduce waste in software development.
• Keep a close watch on developer’s code, and review it to ensure there are no extra features added to the code.
• Develop a good coding practice
• Mentor and coach the team on latest tools and technology
• Not try to become a PowerPoint architect
• Ability to extract the non-functional requirements from the user. He needs to keep an eye on this all the time
• Performance optimization

Skills: Architect needs to be

• Creative
• An Artist
• Politician
• Strong willed
• Excellent communication skills
• Excellent presentation skills
• People person
• Matured
• Articulative
• Courageous to make decisions and stand by it
• Risk taker
• Good observer
• Negotiator

Knowledge:

• He is supposed to know "end to end" design. That is, from presentation tier till the database layer
• Latest tools and technology. It could be Java/J2EE, .NET, Eclipse, Visual Studio, CVS/Subversion, TIBCO, Security related like encryption, decryption, and session management
• Strong in OOAD/OOP/UML
• Domain knowledge is required but not mandatory
• Principles of TDD, Refactoring

Organizational Support:

• An organization should provide resources (tools, technology and human resource) as and when needed. The organization should not sacrifice the code quality by cutting costs and not listening to architects
• It is becoming a de-facto standard that, an architect is highly necessary for each and every project. No project can be executed without a proper architecture. It is like building a house. Whether it is a small house or big house, one needs to build a good plan, good foundation and then construct it.
• Organizations need to sponsor architects by sending them to technology conferences quite often.

Other thoughts: see http://agilearchitect.blogspot.com

Donna Maskell (Principal Software Engineer, Raytheon, Fort Wayne, IN, USA)

Duties: The SA is responsible for defining the overall structure of the system based on the forces driving the system (e.g. "ilities"). It has to be robust, effective, and maintainable. It does not have to be optimal, much less perfect, or there would be very few software projects. The SA has to decide what the most important drivers are in order to justify his approach, because there will be questions. The SA has to be able to communicate the architecture intelligibly to the stakeholders at a level of detail that becomes progressively more refined as the comprehension of the audience becomes more sophisticated. An architecture created by one person will be limited to what one person can think of, so the SA has to be open-minded about criticism and treat it as constructive. The SA should seek buy-in from the stakeholders, including the people who have to implement it all the way down to the code.

Skills: An SA needs a thick skin and an open mind; communication skills to articulate the architecture and respond instructively to questions about the architecture; the ability to recognize that the architecture quality is more important than the architect's ego; leadership qualities, because software engineers are an independent lot who cannot be herded; courtesy, since you can't give everyone everything they want, but you can listen fairly and be courteous in saying no.

Knowledge: Patterns of analysis and design; architectural archetypes; available tools and notations for representing architecture artifacts; presentation skills to convey information with clarity and conciseness.

Organizational Support: Document all the requirements, including the corporate business goals to be supported. See the architect gets the training he/she requests. Provide opportunities for the architect to flowdown the current state of the architecture to lower-level stakeholders (e.g. implementers). Have multiple architects, with one lead POC, and decisions by consensus.

Mayank Sugandhi (Sr. Software Engineer, Pyxis System, Pune, MH, India)

Duties: I usually confuse between duties of Project Manager. Some duties are common between them only difference is about orientation. In which Project Manager aligned more toward Client interaction, People, Time & cost management. An architect can be of any type based on organization structure and its hierarchy.

• Solution Architect
• System Architect
• Technical Architect

According to me following are duties of Architect but one thing I am sure A System can exist without architect but now without project manager.

• Show right path to team
• Decide bit and pieces and communication channel between them
• Decide technology, tools and process guidelines
• Design high level view of System
• Focus on scalability, maintainability, performance and modularity
• Adopt, understand new technology to apply in business 
  In some organization  .Contact CXO to suggest new path for creating business by use of technology
• Negotiate with clients
• Lead team under his vision and aligned team in that direction
• Apply right process, design and technology based on project to accomplish task
• Guide Team to solve challenges during development

Skills:                   

• Politically sound to resist internal issues  
• Good Presentation and Communication skills along with convincing power  
• Good vision and experience to handle conflicts  
• Good technical and process exposure as depth and breadth  
• Good learner to adopt new technology quickly  
• Good problem solver and initiator  
• Good listner for team to understand their problem and ideas 

Knowledge: An Architect must be good learner as Software Industry changing trands frequently. He must have sound knowledge of programing and it's concept. 

He must has solid approach to figure out solution and creative for new ideas. He should posses skil to communicate and convince that properly.

Peter Pavlovic (Global Senior Architect - Rates & Credit Markets, JPMorgan, New York, NY, USA)

Duties: Provide guidance to others on how software should be built. Oversee development in build mgmt role to ensure successful delivery. Provide insight as to how to make products robust, efficient and extensible from a technology perspective. Be accountable for what is going on in the firm.

Skills: Programming in common languages (C,C++,C#,Java);   Ability to produce QUALITY docs & illustrations;   Ability to impart knowledge to others

Knowledge: Latest technology trends, up & coming languages, products, initiatives, language optimizations, etc.

Organizational Support: Trust their architects to deliver quality product (not just opine on how things should be done). Provide enough authority to ensure their accountability is warranted and able to be supported.

Victor Alejandro Baez Puente (Chief Technology Officer, Grupo Nacional Provincial, Mexico City, DF, Mexico)

Duties: Chief Architect will be responsible for all aspects of technology including the high-level architectural designing, construction, reconstruction and refactoring, technology standardization and modernization. The Chief Architect will establish the strategic technical direction for the enterprise products. They will also serve as the evangelist of the architectural vision, strategy, and principles to internal staff, customers, industry analysts, and throughout their peer groups.

The main areas of responsibility include the following:

• Technology Oversight: Maintain an ongoing awareness of emerging developments and trends in technology that could impact current projects and influence new projects
• Industry Participation: Participate in external standards organizations, industry groups, panels etc. that could enhance company's image and reputation as well as provide vital information on technology trends and best practices
• Vendor / Tool Analysis: Lead the evaluation of software vendors targeted for possible integration into the systems or environment, including strategic applications, tools and utilities
• Evangelism of architectural vision, strategy, and principles
• Creation and delivery of detailed technical presentations
• Leadership of architectural alignment implementation efforts
• High-level technical consultation and developer mentoring
• Plan and implement the technical Enterprise Architecture, including both short and long term strategies for retiring certain legacy systems, integrating existing systems and new systems implementation recommendations
• Refinement, documentation and communication of architectural principles
• Oversight and guidance of new product initiatives ensuring adherence to architectural principles
• Customer Technical Resource: Serve as the chief technical resource and reference for the new product, and help define appropriate customer support responses, as well as dealing directly with customers on high-level issues

Skills:

• Experience designing an enterprise application with financial auditing, contract management, enterprise workflow, business process integration, and perhaps asset management components
• Experience with Service Oriented Architecture (SOA).
• Experience as a chief architect on inception-to-delivery of J2EE projects.
• Experience with deploying J2EE rich and/or web client applications in a high-availability, clustered environment
• Expertise in the Unified Modeling Language (UML) for constructing, and documenting the artifacts of software systems
• Exemplary general IT knowledge (applications development, testing, deployment, operations, documentation, standards, best practices, security, hardware, networking, OS, DBMS, middleware, etc.)
• Expertise and experience in lightweight, rapid development, agile methodologies.
• Experience in estimating and measuring project velocity
• Experience with interaction with legacy systems and phased application integration
• Exquisite attention to detail
• Written, verbal, and diagrammatic communication skills

Required Technologies Experience:

• Operating Systems example: Windows NT, Windows Server 2000, Windows Server 2003, Linux and other unix flavors, z/Os
• Java (core), J2EE (Servlets,JSP,EJB,JMS,and related), JavaBeans, Enterprise JavaBeans, J2EEXML(DOM, SAX, XSL, XSLT, DTD, Schema), COBOL
• Web Services: SOAP, XML, WSDL
• Middleware examples: JMS, Apache/Tomcat, BEA Weblogic, JBoss, Webshpere, MQ series CICS
• Databases examples: MS SQL Server, Oracle, MySQL, DB2
• Business Intelligence
• Business Process Integration: Java based rules engines and workflow engines
• EAI/Legacy extension: experience with common tools
• ETL Tools: experience with common tools

Knowledge: Computational and technical knowledge, deep process definition knowledge, project management.

Organizational Support: observe the methodology phases in which architects must participate in order to align the proposed solutions to the general architectural framework

Murugesan R. (Lead Analyst, Saksoft Limited, Chennai State, TN, India)

Duties:

• Identifying stakeholders
• Communicate with stakeholders and understand what each wants
• Understand business requirements
• Creating architecture and validate it
• Consulting and educating on the use of Architecture

Skills: MUST have the following qualities:

• Innovative & Creative
• Analyzes
• Leadership
• Excellent business communication

Knowledge:

• Aware of different technologies & tools up-to-date
• Knowledge on Architectural patterns Knowledge on Design patterns

Organizational Support: Learn! Think!! Create!!!

Poornachandra Sarang (Practicing Solution Architect, ABCOM Information Systems Pvt Ltd, Mumbai, India)

Duties: An architect role should not be restricted to creating an architecture document, but should be extended to cover the various responsibilities until the project is delivered and deployed. An architect must be well versed on various technologies and should have zest for learning emerging technologies at all times. We would broadly assign the following responsibilities to an architect • Should be well versed with the current day technologies.

• Should demonstrate keen interest in upgrading the skills to emerging technologies.
• Should be prepared to do some hands-on coding for understanding the intricacies of new and emerging technologies.
• Should make presentations on emerging technologies and his/her own project experiences to user groups and conferences. Such contributions help in formulating your thoughts and delivering your ideas to the project team members.
• Should assist the domain expert in creating the business case.
• Should overlook the process of requirements gathering.
• Should assist analysts and designers to create design artifacts
• Should be familiar to the various tools available in the market for creating design artifacts and give recommendations on this to the project team.
• Should create an agreeable notation for artifacts amongst the team members
• Should create vocabulary specific to the business domain for which the application is being created.
• Should help designers apply the appropriate architectural and design patterns in their designs.
• Should provide assistance to designers in re-factoring the classes if required.
• Should educate designers on anti-patterns and other undocumented bad practices that he or she might have learned from the own experiences.
• Should perform random code reviews to ensure that the developers adhere to the specified guidelines.
• Should provide test points in the software being developed and assist testers in creating test cases for evaluating the software.
• Should assist developers in creating prototypes.
• Should be able to create and demonstrate proof-of-concepts (POC) on newer technologies.
• Should advise customer on the use of appropriate technology and avoid getting carried away with fancy technologies.
• Should accept the onus of success/failure of the system.
• Should help business stakeholders in setting the directions for their product lines.

Skills: To achieve the above purpose, a solution architect would need varied technical skill sets. These may be broadly stated as follows:

• Should possess a sound technical knowledge of the various current technologies such as J2EE, .NET, Open Source, Messaging infrastructures and so on.
• Should have a good understanding of various technological architectures such as CORBA, J2EE, .NET, JMS, MSMQ, MQ series and so on.
• Should be well acquainted to several EAI integration technologies such as J2EE connectors, COM-TI components, TIBCO and so on.
• Should possess good knowledge of several database products available in the market.
• Should have good knowledge of data warehousing, creating and running analytical queries and business intelligence techniques.
• Should be able to compare and contrast several tools and products available on the various technologies mentioned above. • Should be able to create artifacts using available tools.
• Should be able to re-factor the code to apply design patterns and also ensuring appropriate applicability of anti-patterns.
• Should be able to do a code walk-through on sample code selected at random.
• Should possess good knowledge of various testing tools.
• Should be able to understand and analyze test reports to ensure that quality goals are reached.
• Should be able to assist developers in resolving the technical issues and providing proof-of-concepts on newer technologies.
• Should provide advice on selection of appropriate hardware and deployment architectures.
• Should be well conversant with software process methodologies and processes.
• Should be good in team building.
• Should be able to create architectural documentation.
• Should possess good communication skills.

Knowledge: The above technical skills requirements can easily deter anyone from aspiring to become a solution architect. Though a deep technical knowledge in each of the above areas is not expected, architect should possess a good conceptual clarity on each. Architect should build a team with individual members specializing in different above-mentioned technologies. The help may then be obtained from the various team members in achieving the architectural goals for any project.

Organizational Support: The organization that is creating and maintaining an architectural team should provide support to the chief architect in building and retaining the team. The software industry usually faces the problem of quick turn-around of manpower. The organization should provide enough incentives and facilities to retain the trained manpower. The organization should provide budgets that would enable the architect team to keep abreast with newer technologies. The organization should be willing to budget Research and Development (R&D) expenditures for experimentation, learning technologies, obtaining software licenses and acquiring test hardware platforms. Organization may opt for CMMI certifications to ensure quality processes and building customer confidence in the architectural processes deployed on the customers’ projects.

Ramakrishnan Subramanian (Technical Specialist, Cybernet Software, Chennai, TN, India)

Duties:

• Keep it Simple.
• Architect to Scale by feature and for change.
• Mentoring Dev team
• Keeping all stake holders happy with an excellent balance.

Skills:

• Performance Improvement Skills.
• Refactoring  Skills.
• Mentoring.
• Excellent Communication.
• Understanding Organisation need.  

Knowledge:

• Technical knowledge.
• Domain knowledge.

Organizational Support:

• Keep politics away
• Freedom to   the Architects
• Encourage Arch-based development
• Provide a play   area to play / tryout and fail with no threat of consequences!

Mayank Sugandhi (Sr. Software Engineer, Pyxis System, Pune, MH, India) Duties: I usually confuse between duties of Project Manager. Some duties are   common between them only difference is about orientation. In which   Project Manager aligned more toward Client interaction, People, Time & cost management. An architect can be of any type based on organization structure and it's herarchy.

• Solution Architect
• System Architect
• Technical Architect

According to me following are duties of Architect but one thing I am   sure A System can exist without architect but now without project   manager.

• Show right path to team
• Decide bit and pieces and communication channel between them
• Decide technology, tools and process guidelines
• Design high level view of System
• Focus on scalability, maintainability, performance and modularity
• Adopt, understand new technology to apply in business

In some organization .Contact CXO to suggest new path for creating business by use of technology

 
• Negotiate with clients  
• Lead team under his vision and aligned team in that direction  
• Apply right process, design and technology based on project to accomplish task  
• Guide Team to solve challenges during development

 

Skills:

 
• Politically sound to resist internal issues
• Good Presentation and Communication skills along with convincing power
• Good vision and experience to handle conflicts
• Good technical and process exposure as depth and breadth
• Good learner to adopt new technology quickly
• Good problem solver and initiator
• Good listner for team to understand their problem and ideas

Knowledge: An Architect must be good learner as Software Industry changing trands  frequently. He must have sound knowledge of programing and it's  concept. He must has solid approach to figure out solution and creative for new ideas. He should posses skil to communicate and convince that properly.

Information Submitted Before June, 2006

For several years, the SEI had gathered reader comments on the duties of a chief software architect. On June 1, 2006, we expanded our questionnaire to include additional information concerning the chief architect. The following entries were submitted prior to the June change.

The previously submitted duties of a chief software architect are alphabetized by submitter's last name.

Ammad Amjad (Software Architect, Lahore Stock Exchange (G) Ltd., Lahore, Pakistan)

In my opinion, a systems architect should possess the following qualities and features relevant to his/her duties. He should

• be innovative and creative
• have good analysis skills
• know BEST PRACTICES of the industry
• be aware of technologies and available solutions
• be experienced with all the phases of software engineering
• understand the business objectives
• be able to gather business requirements and map them to objects in problem solving manners
• foresee changes and take measures to accommodate them while architecting the system
• have problem domain knowledge
• have good communication skills and able to express his ideas
• be able to follow process

Ezhil Arasan Babaraj (Technical Architect, Cybernet Software System, TN, India)

Should provide appropriate technical solutions for the given requirement. Should effectively communicate the proposed solution. Should be a quick learner to learn new technologies. Need to be a good mentor. Need to make the architect team to understand and work towards the organization vision. Should be able to think beyond expectations.

Srihari Boregowda (Technology Director, Canarys Automations (P) Ltd., Bangalore, KA, India)

• Extends on that of any Engineer. "dealing with the practical application of scientific knowledge to the safe and cost-effective solution of Human Problems."
• The Architect is adept at use of heuristics to cause the best change in a poorly understood situation within the available resources and reduce risk in imminent implementation
• "Everything is created twice" . First is the Mental creation followed by a physical cration later. Architect is part of the first creation. He must be able to selectively switch between Abstract and Concrete as required throughout the project.
• Architect in leadership role, using the right brain, Architect part of business development and pre sales, Professional responsibilities of architect

Mallik Bulusu (Sr. Software Engineer, Intel, DuPont, WA)

I have a 2 step recipe. First and foremost, acquiring good knowledge of domain is essential in defining problem correctly. Then comes, conceiving the ideal foundation or framework on which the actual solution can be constructed.

Shahid Farid (Student, PUCIT, Lahore, Punjab, Pakistan)

In big organizations (Enterprises), architect is not a single person--- it is a team. This team led by an experienced architect, called “Chief Architect”.

Hierarchy of the Team: Often (at medium level organizations) this team is divided into two groups. They are:

• Functional architects, who optimize business processes, and have a very good knowledge about analysis methods;
• Technical architects, who design long-term, reliable and adaptive technical architectures, and constitute a technical gateway between the project manager and the developers.

But in big organizations, this team is divided into a number of roles:

• Software Architect
• Hardware Architect
• Data/Communication Architect
• Information Architect
• Internet Architect
• Network Architect
• Systems Architect
• Security Architect
• Process Architect
• Project Architects

Now we discuss the responsibilities/duties of each of these one by one.

Software Architect: A software architect is responsible for creating or selecting the most appropriate architecture for a system (or systems), such that it suits the:

• business needs,
• satisfies user requirements, and
• achieves the desired results under given constraints.

Responsibilities of a Software Architect:

• A software architect analyses an organization’s overall business and establish how their software is used
• A software architect assess new software applications to see if they are suitable for an organization and if the current hardware will support them
• A software architect provide detailed information about costs and benefits of software to ensure that it will serve the client over a long period
• A software architect abstracts the complexity of a system into a manageable model that describes the essence of a system by exposing important details and significant constraints.
• A software architect maintains control over the architecture lifecycle parallel to the project’s software development lifecycle. Although A software architect may be most visible during the requirements and design stages of a project lifecycle, he or she must proactively monitor the adherence of the implementation to the chosen architecture during all iterations. Architecture on paper is fruitless unless implemented proficiently.
• A software architect stays on course in line with the long term vision when projects’ scope creep attempts to manipulate software architecture in a certain way in order to satisfy the desires of myriad stakeholders. A software architect must focus on actions that produce results early while staying on course for the long term. When project variables outside of one’s control change the architect must adjust the strategy given the resource available while maintaining the long term goal.
• A software architect progressively makes critical decisions that define a specific direction for a system in terms of implementation, operations, and maintenance. The critical decisions must be faithfully made and backed up by understanding and evaluation of alternative options. These decisions usually result in tradeoffs that principally define characteristics of a system. Additionally these decisions must be well documented in a manner understood by others.
• A software architect sets quantifiable objectives that encapsulate quality attributes of a system. The fitness of the architecture is measured against set marks.
• A software architect works closely with executives to explain the benefits and justify the investment in software architectures. This may be done by participating in business process re-engineering activities, by using Cost Benefit Analysis Method, or by measuring the level of component / architecture re-use between projects with the help from the software process improvement team. Software architect must be effective in order to deliver results that are meaningful to the projects that have an impact on the bottom line that result in greater profits.
• A software architect inspires, mentors, and encourages colleagues to apply intelligently customized industry’s best practices. Educating the recipients and participants of system architecture is essential to successfully selling the chosen architectural path. Specifically the stakeholders must be able to understand, evaluate, and reason about software architecture. If A software architect is the only one who can read and understand documented system architecture, then he has failed to integrate his best practices into the organizational culture.
• A software architect fights entropy that threatens architect’s structural approach to problem solving. It’s A software architect’s job to keep the inertia going once the project is in progress. He or she must convince all relevant stakeholders that the chosen approach is sound – moreover the chosen architectural solution must be well explained and justified. The benefits of implementing a system in a particular way must be explained not only in terms of “that’s the right pattern for this problem,” but also to demonstrate the measurable benefits - such as easier integration. For example, in a product line approach A software architect must be able to demonstrate how the subsequent projects will be easier to implement due to the presence of a common base from which subsequent work can be done.
• A software architect creates and distributes tailored views of software architectures to appropriate stakeholders at appropriate intervals. For example, a customer may demand to become more involved with a project and they may need to know an abstract view of a system on the level understood by them. A government customer may require A software architect to demonstrate early in the project how a given system meets High Level Architecture requirements for a specific framework. It’s the architect’s responsibility to identify and present a sufficient level of information that a customer needs.
• A software architect acts as an agent of change in organizations where process maturity is not sufficient for creating and maintaining architecture centric development. If the concept of software architecture is not well recognized in an organization it may be a “tough” sell to formally recognize the role of software architecture in a SDLC. Without senior management commitment and without mature software development process, architecture of the system on paper may not reflect the actual architecture of a system.
• A software architect should be familiar with compilers and other language translators and can determine costs for converting computer programs from one language or machine to another, so he selects the language and the environment.
• A software architect leads a team of programmers or negotiates outsourcing contracts to develop and build new software.
• A software architect builds prototypes of the software and tests them.
• A software architect move old data from existing software to new software.
• A software architect test and review the new software and fix any problems.
• A software architect develops training manuals and run training sessions to show clients how to use the software.
• It is seldom possible to define an architecture which satisfies all the ideal architectural parameters. For example, in the telecom software industry, availability, scalability and performance of the system is most important where as when developing desktop applications, usability and responsiveness becomes critical for the software system. This problem is resolved by the architect.

Hardware Architect: “A hardware architect is responsible for the design of hardware architecture, peripherals and display bodies.”

Responsibilities of a Hardware Architect:

• A hardware architect reviews computer software systems and data requirements as well as communications and response needs and devises computer hardware configurations to support them.
• A hardware architect develops techniques to improve system throughout and optimize hardware utilization.
• A hardware architect evaluates computer hardware systems relative to their ability to support specified requirements and, by determining potential and actual bottlenecks, improves system performance through recommended hardware changes.
• A hardware architect should be well versed in hardware compatibility, and has participated in the design of real-time or remote access systems and has a working knowledge of process control and/or large timesharing hardware systems.

Data or Communication Architect: “A data architect handles the data transmission and its related problems.”

Responsibilities of a Data or Communication Architect:

• The Data/Communications architect is technically competent in the area of data communications and transmissions and analyses computer software systems, data requirements, response times and computer hardware configurations relative to the communication and data transmission requirements.
• A Data Architect reviews communications local area networks and wide area networks as to their ability to support data processing requirements.
• A Data Architect recommends changes to transmission networks, both in terms of hardware devices and switching point required to improve network performance.
• A Data Architect has a working knowledge of coding and error detection methodologies;
• A Data Architect has participated in the analysis, design, and implementation of communication networks including data processing transmissions.

The Personality of an Architect: The main characteristics of the personality of an architect are:

• An architect is often an ex-developer who has accumulated such experience as to reach a good level in expertise. This experience must cover ideally a variety of platforms and products, and knowledge about the lifecycle of an application, or even of an information system.
• Communication skills are required.
• Diplomacy and pedagogy skills are also required to be able to explain architectures, debate about them and have them adopted.
• An architect must be able to step back and take a higher-level look, which is often difficult for developers and projects managers because they are often too focused on a specific project and so on immediate need. This means raising from the application level to the information system level. This also means that the architect has to perform a continuous technological survey; one that goes further than the context a specific project.
• An architect is a negotiator. The method of principled negotiation should be the tactic of choice for an architect. This method is most suitable in contrast to soft or hard negotiation method, because it seeks mutual cooperation between an architect and project stakeholders. An architect will be expected to deliver better, faster, and cheaper, but since only two-way combo can be selected an architect must negotiate to decide which aspects of a system will be considered first and under what conditions.
• An architect must convey a sense of credibility and trust; an architect must be perceived as successful. An architect can attain such status with his prior successful experience, formal training in the field (certifications in the future), and by his or her ability to deliver successful and relevant architectural artifacts through every stage of the SDLC.
• An architect believes in his ability to perform well. In a leadership position attitude is everything – if the passion for success is absent, then an architect must step down from the leadership pedestal.
• An architect must be patient and resilient, as the only thing constant is the change itself. Since software architecture has direct influence on the quality characteristics of a system, an architect will interact with a great number of people with a full spectrum of personalities. He or she must quickly adapt to the way stakeholders operate, as it’s not possible or feasible to expect them to speak the language of an architect.
• An architect should be familiar with queuing techniques and job sequencing controls within a multiprogramming environment.
• An architect should be familiar with Artificial Intelligence, Expert Systems and Neural Networks. The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.

In simple, n architect bears a multi-personality. He may have to wear multiple hats - as a "manager" to co-ordinate with all stakeholders, as a salesman to "sell" the idea behind his solution, as a "developer" to develop POC or pilot to prove that his solution will work, as an "executive" to drive through the implementation.

Elan Govan (Manager - Software Engineering, Solectron Centum, Bangalore, India)

The Software Architecture determines the design of the system. Hence prior to design:

• System requirements shall be evaluated to meet the essential requirements, consistency and design constraints.
• Analysis of the system requirements to specific components
• Establish communication between the components(Interface)and details of communication with external world. 
• Define software components(objects) their attributes and properties 
• Arrive at a highly cohesive, lowly couple optimal architecture.

Amit Kawalkar (Engineer, Honeywell, Bangalore, KA, India)

• To understand the system high-level system requirements.
• To understand the scope of the system.
• The system design goals should be solidly understood.
• Must understand the deployment scenarios.
• Must design the system with extensiblility.
• Must design the system by isolating the functional areas.
• Should layer the system according to different responsibilities.

Constantin Kostenko (Software Architect, SoftwareArchitectures.com, Washington, D.C.)

An architect

• abstracts the complexity of a system into a manageable model
• maintains control over the architecture lifecycle
• stays on course in line with the long term vision
• progressively makes critical decisions that define a specific direction for a system
• sets quantifiable objectives that encapsulate quality attributes of a system
• works closely with executives to explain the benefits and justify the investment in software architectures
• inspires, mentors, and encourages colleagues to apply intelligently customized industry’s best practices
• fights entropy that threatens architect’s structural approach to problem solving.
• creates and distributes tailored views of software architectures to appropriate stakeholders at appropriate intervals
• acts as an agent of change in organizations where process maturity is not sufficient for creating and maintaining architecture centric development

Anant Kuslekar (SAE, Qwest, Bangalore, India)

Design the skeleton for building blocks of software application.

Ken MacBean (Architect-Destination Design Software for Entertainment Developments, IDAD, Cincinnati, OH, USA)

(DDSA) - Definitive Definition for Software Architecture: Software architects are professionals responsible for the planning and development of all aspects of user/system interfaces in software product development, including the design of hardware architecture, peripherals and display bodies. This young evolving polyspecialized field is concerned with human/technology interactions, education, sustainable design, communications and engineering. Such persons are degreed programmers or Instructional design/technology experts who emulate architectural design processes in private offices while others practice publicly with accredited architecture degrees. Industry or degreed architects working in computer science as software architects both use image, graphic, entertainment and architectural design knowledge together with legal, scientific, business and programming requirements to assess prudent planning and design decisions. Software architects may be involved in software engineering supervision, design and product management, user research, market studies and testing. They may apply their skills to the development of new technology products, programs or services and combine systems logic, hardware environment, human needs or anthropometrics, and innovation for the benefit, safety and welfare of society while promoting value for the industry through quality design.

Source: (2001)Institute of Destination Architects and Designers

Amit Midha (Research Scholar, Carnegie Mellon University-West Coast Campus, Mountain View, CA)

A software architect's job is to ensure that the architecture he is responsible should suffice to initial customer requirements and when implemented, will fulfill the system as envisioned by the customer.

Muthuramalingam Nagarathinam (Product Architect, London Bridge Phoenix Software, Heathrow, FL)

• Understand Business Goals
• Understand Customer expectation 3. Understand Technology solutions
• Understand Current Technology in use
• Create/maintain the Company strategies in line with the Business Goal & Customer expectations with the current/new technology.

Ashwin Palaparthi (Principal Architect, AppLabs Technologies, Philadelphia, PA, USA)

• Make sure "not" to become a top-notch developer in the company
• Advocate company politics, technological or otherwise
• Act as a consultant-strategist for everyone
• Think outside software and communicate that view to the inside (or sometimes vice-versa)
• Be an adherent of technocracy and provide thought leadership
• Ensure to be trusted by others though they hate (As you know, hating and liking have got nothing to do with whether you are trusted)
• Mentor, mentor and mentor (him and then others)
• Develop and foster all the positive adjectives prefixed-- proactive, aggressive and xxxxive
• Always live in the ideal world and pretend that the pragmatic world is an unknown thing

Sathyanarayana Panduranga (Solution Architect, Hughes Software Systems, Bangalore, India)

Chief Software Architect who is responsible for the creation and evolution of an organization's product line has the following responsibilities

• Choose the right tools, technologies and platforms for the development, testing and deployment of each product in the product-line
• Identify architectural differentiators for the product line 
  It is seldom possible to define an architecture which satisfies all the ideal architectural parameters. For example, in the telecom software industry, availability, scalability and performance of the system is most important where as when developing desktop applications, usability and responsiveness becomes critical for the software system. Create an architectural vision. 
• Sell the architectural vision to all stake holders
• Define patterns, frameworks and best practices to achieve the architectural vision
• Identify and mitigate risks during the development of products
• Closely watch competing products and strategize for the continuous evolution of the product line
• Feel the pulse of the market, management, and development team at all times
• Build good architects and designers in the organization 8) Frequently evaluate new tools and technologies to be incorporated in the organization
• Build knowledge base

Narayana Peesapati (Vice President Technical, NuNet Technologies Pvt Ltd, Visakhapatnam, AP, India)

• Understanding the customer requirements in right perspective - in terms of functional & non functional, financial & future growth.
• Envisage the architecture (technology, security, scalability, functional meeting, etc) to meet all the above.
• Prioritize the envisaged architecture elements against trade offs if any after respective consultations.
• Translation & communication of Critical areas & impact of those to the respective stake holders.
• Documenting the architecture with all the pros and cons & communicating the same.
• Make the implementation & review plan.
• Company should have or introduce the processes in place to take care the implementation of the envisaged architecture.
• Collection of User Feedback.
• Transforming the Feedback into preventive actions of the processes if any.

Tao Nguyen Phu (Accounting, Truong Xuan Co., Ltd, Ho Chi Minh, Vietnam)

Constructing databases.

Alan Nuytten (Sytems Programmer, ITC, Indian Rocks Beach, Fl, USA)

Define software development lifecycle and tools to include, hardware/ configuration management, software change management tools, bug tracking and analysis process.

Rajendra Prasad (Java Solution Architect, RaminfoLtd, Hyderabad, India)

Creating application and system architecture, analysis of use cases and drawing the detail design, sequence and collaboration diagrams.

Rushton Prince (Chief Architect, X-tier SAE Inc., Shawnee Mission, KS)

"The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations." – Vitruvius, circa 25 BC

In summary, the software architect must be well-rounded, posses maturity, vision, and a depth of experience that allows for grasping issues quickly and making educated, critical judgment in the absence of complete information. More specifically, the software architect, or members of the architecture team, must combine these skills:

• Experience in both the problem domain, through a thorough understanding of the requirements, and the software engineering domain. If there is a team, these qualities can be spread across the team members, but at least one software architect must provide the global vision for the project.
• Leadership in order to drive the technical effort across the various teams, and to make critical decisions under pressure and make those decisions stick. To be effective, the software architect and the project manager must work closely together, with the software architect leading the technical issues and the project manager leading the administrative issues. The software architect must have the authority to make technical decisions.
• Communication to earn trust, to persuade, to motivate, and to mentor. The software architect cannot lead by decree, only by the consent of the rest of the project. In order to be effective, the software architect must earn the respect of the project team, the project manager, the customer, and the user community, as well as the management team.
• Goal-orientation and Pro-activity with a relentless focus on results. The software architect is the technical driving force behind the project, not a visionary or dreamer. The career of a successful software architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can focus on doing what needs to be done will be successful in this environment of the project.

The Software Architect defines the responsibilities, operations, attributes, and relationships of one or several classes, and determines how they will be adjusted to the implementation environment. In addition, the architecture role may have responsibility for one or more design packages, or design subsystems, including any classes owned by the packages or subsystems.

Citation: Rational Unified Process - Software Architect Role

Murugesan R (Technical Architect, Genisys Software, Bangalore, KN, India)

• Identifying stakeholders
• Communicate with stakeholders and understand what each wants
• Understand business requirements
• Creating Architecture and Validate it
• Consulting and educating on the use of Architecture
• He MUST have the following qualities:
  • Innovative & Creative
  • Analyzes
  • Leadership
  • Excellent Business Communication
  • Aware of Technologies & Tools

Thanigai Ranganathan (Software Architect, Infosys Technologies Ltd., Plano, TX, USA)

Identify the business goals & drivers, all the stakeholders of the system/solution being built, and understand their requirements and expectations (in a quantifiable and measurable form), and before proceding with the definition of the solution. He should ensure that the solution is defined such that it addresses all the expectations/concerns of all the stake holders, as well as is directly influenced by one or more business driver/goal. It is his duty to communicate his decision to all the stakeholders in the languages they understand on how the system will behave (meet their requirements & expectations) when subjected to various stress factors. In this process, he may have to wear multiple hats - as a "manager" to co-ordinate with all stakeholders, as a salesman to "sell" the idea behind his solution, as a "developer" to develop POC or pilot to prove that his solution will work, as an "executive" to drive through the implementation.

Conrad Roche (Applications Architect, Cognizant, Manchester, CT, USA)

Ensure Architectural consistency in the various company divisions. Provide a future architectural direction and transition plan. Ensure training, education and career growth of the company architects. Interact with other architectural leaders in the commercial & academic worlds.

Terro Sage (Director of Enterprise Architecture, CTB/McGraw-Hill, Monterey, CA)

Identify architecturally significant use cases, provide design blueprint for these uses cases to build on.

Sewell, M. and Sewell, L. "The Software Architect's Profession." Prentice Hall PTR; 1st edition, 2001. ISBN: 0130607967.

Dr. Zakir Syeed (President, Symbions Software, London, UK)

In my opinion, a architect should possess the following qualities.

• Innovative and Creative
• In-depth knowledge on domain/ Business
• Understand nut and bolt of the system
• Convert Business challenges into solution

Amir Ali Tayyab (CEO, ZEN Corporation, Lahore, PK, Pakistan)

It was quite interesting to read other's feedback and almost everything that they said, is needed. However, due to problems in comprehending CLEAR, yet brief duties of a project's chief software architect, I had to come up with my own version as

• identify goals of the software by discussing with end-users or management
• write a plan and update it based upon progress
• establish a seamless communication with developers and end-users
• have disaster recovery backup plans in place
• ensure standardization in all aspects
• deploy it successfully and diplomatically via easy training and documentation
• keep it up-to-date with the new technologies' availability before-hand

Nicole Tedesco (Software architect-engineer, Ware-Squared Software Development, Shoreline, WA, USA)

Let me paraphrase Marc and Laura Sewell:

• Understand the worldview, problems and issues of your client, employer and end-users
• Design solutions to solve those problems
• Communicate these solutions to all stakeholders, implementors and consumers
• Ensure the quality of the solutions through delivery

Jan Willem van den Beukel (Manager Architecture & Technology, Philips Medical Systems, Best, Netherlands)

Within PMS / Medical IT the duties are as follows:

Within context of a release project:

• writing / overseeing the System Requirements Specification
• technically overseeing product hazard analysis
• organising the design meetings for global design
• writing the (global) System Design Specification
• directing performance specifications, measurements and their analysis + follow up during development phase
• overseeing the overall test strategy
• member of project kernel team / technical peer to project leader
• day-to-day technical support / troubleshooting to other designers / software engineers

Across projects / mid-to-long term

• proving input to commercial roadmap of the product
• defining technical roadmap of the product
• identifying and performing/overseeing feasibility activities
• providing input to development (technology) strategy

Rob van Ommering, principal researcher at Philips Research Laboratories, Eindhoven, the Netherlands, and a thought leader in software architecture, has written a wonderful essay titled "Things to Do in Denver When You're an Architect" about the duties of a software architect. 

Aravind Venkat (AVP, Satyam, Bangalore, India)

A software architect is one who constructs and articulates technology solution to a business problem. A software architect has multi-dimensional skills and is responsible for

• Technical Solution for business problem
• Provide Value addition to the process
• Create a blueprint upon which applications and systems can be build
• Big Picture Baby Steps
• Evaluate and mitigate Technical Risks
• Create architecture that works under the boundary of Cost, Time and Feature Set

Craig Walters (Master Architect, Monsanto, St Louis, MO, USA)

• Develop long range technical direction and planning.
• Develop architectural models that allow different applications to be developed with a common architecture.
• Mentor project teams.
• Develop best practices.
• Train tech leads.

Daniel Wang (software architect , project manager, CCIT, Beijing, China)

Decompose the overall system to make sure it can be worked on by all teams and team-members together.

David Weiss, Director of Software Technology Research at Avaya Laboratories and co-author ofSoftware Product-Line Engineering, writes that a chief architect should have the following responsibilities (not in priority order).

a.	Create and enforce architectural standards that enable the company's products to interoperate.
b.	Create and enforce architectural standards that make the same features appear and behave the same in all of the company's products.
c.	Create a company product line (responsibilities a and b preceding are part of this).
d.	Define the responsibilities of an architect in the company, including what architecture means in the company.
e.	Create a community of architects within the company.
f.	Create training and education for the company's architects.
g.	Identify and recruit potential architects.
h.	Explain the architecture of the company's products to customers.

Bob Wilmes (Enterprise Architect, Large Financial Services Company, Phoenix, AZ, USA): Software is the living codification of ideas, brought together to achieve economic benefits for society and ultimately to bring enjoyment to individuals. Similar to living entities, software is subject to the forces of evolution and change, and ultimately has a mortality unless adaptation and growth is maintained. The role of the chief software architect is understand, codify and communicate the forces of adaptation and change while maintaining the organizational balance between economic drivers and technical capabilities.

Steve Wright (Consultant - Sr. Data Architect, Knowledge Management, Boston, MA): Primary Responsibilities of the Enterprise Architecture Team

• Responsible for translating business requirements into systems qualities and thence into repeatable design strategies and patterns that enable those qualities (e.g. adaptability, scalability, availability, non-repudiation, reusability, etc.).
• Responsible for enterprise application integration (EAI). This includes defining the opportunities for integration, selecting the tools, specifying the shared data & code resources, defining the interfaces and data-flows, and monitoring the success of said integration.
• Compiles or designs architectural models of current and proposed systems across the enterprise for use internally and in conjunction with Technology Partners. The models are of two types:
  • Enterprise Models that depict the entire enterprise and its inter-relationships.
  • Reference Models that depict recommended & approved technologies & designs, which can serve as a template for future projects.
• Establishes the Design Repository and Metadata Repository for integrating all aspects of these models, and provides oversight of its use in conjunction with integrated Tool sets.
• Perform design reviews across the organization. (Note: not code reviews.)
• Leads the evaluation of vendor software targeted for possible integration into the systems or environment, including strategic applications, tools, and utilities.
• Defines the IT design methodology, development process methodology and best practices.
• Surveys external emerging developments, and evangelizes new technologies, standards and methodologies that will have a positive impact on the company's bottom-line and quality of service.
• Participates in external standards body work that defines IT standards in the health community.

The Architecture team is divided into a number of roles based on an orthogonal “separation of concerns”:

• Chief Architect
• Applications Architect
• Data Architect
• Information Architect
• Internet Architect
• Network Architect
• Systems Architect
• Security Architect
• Process Architect
• Project Architects

Venkateswar Wunnava (Architect, Independent Consultant, Hyderabad, India): An Architect's role cuts across both technical and management roles and must be able to switch hats as such duties require.

The first and foremost requirement of a chief architect is to gain commitment and trust of the management for his work-products a.k.a architecture, design, guidance and decisions. This is important because "fire-fighting" managers is a fact of the real-life and most often they veto critical architectural decisions which potentially compromise architectural effectiveness and efficiencies per real-life practical scenarios. Hence

An Architect should assist managers by taking active part in estimation and project planning and tracking process so that the project can realize a concrete manifestation of the architecture a.k.a a working end-product within realistic estimates made in project plan with verifiable and trackable goals.

An Architect must be a compulsory participant of all the life-cycle processes right from Requirements through Deployment and support. Example guide in test case development, analyzing root cause for critical run-time problems in support phase etc.

Gain a complete conceptual understanding of the domain being modeled its actors, entitles and their relationships along with the scope of the solution that is being focus of the current project.

Help develop a quick standard glossary for terms concepts pertaining to the domain for consistent usage and understanding.

Help create and insist concrete, consistent and signed-off baseline requirements and control their changes.

Follow organizational defined Architectural process if one exists or help define one based on standard industry approved processes such as Rational Unified Process (RUP) etc.

Develop an architectural development plan that identifies an iterative development of Architecture with identified deliverable workproducts their time line etc., which helps both management and technical staff.

Substantiate architectural and design decisions with available alternatives pro's -con's of each and reason for choosing a particular alternative. This avoids arguments amongst senior staff and reduce conflicts and saves valuable project time, since often there are multiple ways to solve the same problem and one needs to choose one amongst them based on project constraints (cost, time, skills, availability etc.,) rather than hunt for the best alternative always. This requires establishing a design decision process to identify the same.

Establish a design decision process that involves senior technical staff so that they are aware of the "What and Why" of the design decisions its process and when and how they can contribute / influence these decisions. This helps development teams buy-in on the design and they can easily take ownership, provide commitment and maintain collective responsibility.

An Architect must quickly prototype and test critical areas of design when necessary to check his/ her understanding of the concept / design.

Oversee the development and coding process, by participating and verification and validation processes of the development artifacts and workproducts.

Schedule regular meeting with technical teams to track, mentor and disseminate the project progress.

Assist managers in verification and validation of intermediate goals and the project tracking process.

Create and make presentations for senior management on progress of the project to gain their confidence and help them track the progress.