ASSIGNMENT II

EXPLAIN THE ROLE OF AN ARCHITECT AS A LEADER OF THE TEAM AND HIS RESPONSIBILITIES IN
COORDINATING A PROJECT.
WHY IS IT NECESSARY FOR THE ARCHITECT TO BE REGISTERED WITH THE COUNCIL OF ARCHITECTURE?

LAKSH MADAAN
FIFTH YEAR B

THE ARCHITECT'S ROLES, RESPONSIBILITIES AND SKILLS

The architect is responsible for defining and maintaining the structure of the
solution, and ensuring that it will meet the requirements. An architect must also
help the team to work together in an agile fashion, to jointly own the solution, and
to interface well with other parts of the organization.
There are five main parts to this:

Understanding the requirements - identifying the stakeholders, helping to

analyse the requirements and extracting those of architectural significance

Formulating the design - creating a solution structure which will meet the
various requirements, balancing the goals and constraints on the solution,

Communicating the architecture - making sure that everyone understands

the architecture. Different people have different viewpoints, so the
architect has to present various views of the system appropriate to different
audiences,

Supporting the developers making sure that the developers are able to
realise the architecture, by a combination of mentoring and direct
involvement,

Verifying the implementation ensuring the delivered system is consistent

with the agreed architecture, and will meet the requirements.

The architect defines the structure and organisation of the system. The
architecture describes the systems components, their responsibilities and
interactions. A complex system is more than the sum of its parts. It must have a
unifying, coherent structure. Therefore the architect must also define and

Metaphors, design principles and patterns on which the architecture is

based,

Page

describe:

The technology, tools and standards which will be used,

Key mechanisms, such as data access and error handling,

Specifications and interfaces of components to be bought or built.

In an agile development team many people will contribute to these things. The
architect will help all team members to contribute to the architecture, taking
good ideas from everyone and making them part of a coherent whole. The
architect may also adapt ideas originating elsewhere, but without losing the
teams ownership of the solution.
The architect will lead choosing the technology, and confirm that the choices are
viable. He or she must therefore be aware of the alternatives, and factors that
choose between them, and understand what technical issues are key to the
projects success.
The architect is frequently an evangelist for new or different technologies,
processes or solutions. However, he also has a responsibility to help manage
change, which may mean reining in his enthusiasm where risks and costs would
outweigh the benefits.
The solution must meet the users needs, but not necessarily every wish and
constraint. The architect should help to identify and resolve conflicting
requirements, helping to say No, or What do you really need? if the
requirements clash. The architect's objective is working solutions, and the best
solution for the enterprise may not even need new software to solve the
users' problems.
One of the architects main jobs is communicating the architecture. He or she
must become the solutions champion, selling the vision and keeping it alive in

Page

architecture meets their requirements. This requires multiple representations of the

the face of challenges. Each group of stakeholders needs to understand how the

architecture directed at different parties. Any architect must model to

communicate, but an architect will follow the principles of modelling, and help
the project to "travel light".
An expert visualiser, good at abstracting and modeling solutions, the architect
sees the big picture, and views a system and its context as a set of interacting
components. However, the architect must also be able to understand and discuss
the system in terms of functionality, hardware, project or financial considerations.
The architect helps the developers to understand the architecture, its value and
the reasons behind it. He may act as a mentor or consultant, assisting, training
and providing leadership to the developers. He may even work within the
development

team,

focussing

on

implementation

issues

of

particular

architectural significance.
A good architect will be insightful, pragmatic, and able to negotiate between
conflicting forces. He may act as a bridge between developers, managers and
other communities, and spends much of his time translating and mediating
between them. A true architect must not be parochial, and this means gaining
experience in different roles and fields. Having and using experience is more
about attitude than years.
The architect must recognise the wide range of stakeholders, and their needs and
concerns. The architecture has to serve well all the build and use processes
(both in their widest possible sense), not just a single phase such as coding or
deployment.
An architect models and documents: to understand, to create solutions and to
communicate. An agile architect will use informal methods and and promote

Page

agile documentation: good enough, but not excessive.

THE ARCHITECT IN AN AGILE DEVELOPMENT

In an agile development the architect has the main responsibility to consider
change and complexity while the other developers focus on the next delivery. In
any system of real-world complexity you can't allow anybody to change anything
at any time, any more than any member of a family can take down a wall of the
house. There are three dangers if "embrace change" is taken too literally:

"Thrashing" as things change rapidly backwards and forwards where the

requirements are unstable, or not understood, or not agreed by different
stakeholders,

Loss of stability for the system as a whole, and "the house falls down",

Development of complexity, where changes lead are made without

abstracting their common aspects or refactoring the design.

The architecture must support change but control complexity. The architect may
have to take the viewpoint of future users, developers and maintainers,
extrapolating the requirements from the short term into the future. The architect
may also have to identify which aspects of the design can be freely changed,
and which need control and planning.
An agile project will work in a different way, and at a different speed to less agile
parts of the enterprise. This is not necessarily a bad thing, just the reality of different
objectives and realities. In engineering terms, there may be an "impedance
mismatch" between the agile developers and the others. The architect may act
as the "transformer" between the different "impedances", more than just "keeping
people happy" or "blocking", the architect should help each party understand
the others' needs. The architect may make an important contribution to the agility

Page

bureaucracy.

of the project, by protecting the agile developers from unnecessary

HOW THE ARCHITECT'S ROLE CHANGES OVER TIME

The architect takes on many different roles over time. On a single project, the
focus will change as the system's architectural detail matures. The same person
may undertake different roles, changing his or her focus, or different people may
take on different architectural roles. The latter is typical if there's a large
architectural

team,

or

responsibilities

are

split

between

architectural,

development and technology support groups.

For a portfolio of projects, the focus may be different for different projects at the
same time, simply because each project is at a different point in the life cycle.
Again, a single person can change focus and role, or different people fill the
different roles.

Finally, people change over time. As a person's interests and skills develop, he or
she may feel happier concentrating on different parts of a system's life-cycle. If
an architect has particular skill explaining concepts to business people, he will
naturally focus at the strategic end. Another with deep technical skills will focus

Page

at greater levels of detail.

The diagram shows how all the "architectural" roles relate to a typical system:

In fact, the picture is even more complicated, because as the system matures a
team of people become involved, each with a different role and focus. so at the
right-hand end of the picture we should show several overlapping roles. The total
breadth of architectural knowledge increases so no one person can hold it all,
and architectural responsibility is typically split, at least between hardware,
software and data.
Each architect has a different "range of vision", and that may change depending
on his role within the project. The "gaps" between the different ranges of vision
may also be important, because these represent potential areas for failure in
communication, where one person cannot "get down to the level" of another

Page

and vice-versa.

There's no "progession", "seniority" or natural reporting hierarchy between different

architecture roles. These things do exist, but they are independent of the varying
roles that architects naturally have.

SO HOW WIDE IS THE AGILE ARCHITECT'S ROLE?

The architect may be any combination of client, project overseer, inspector,
trouble-shooter and builder as well as some combination of visionary, designer,
problem solver and mentor. No single body of knowledge or expertise defines the
architect. There is no single role: some architects spend time getting their hands
dirty, and others spend most of their time drawing big picture views of an
enterprises whole IT portfolio.
Architecture is certainly not defined by job title. Some organisations or projects
have no named architects but a good architecture, others have many people
called "architects", but few with the right attitude and mindset.
The architect may deal with either architecture or design. Architectural
attitudes and approach are equally important inside a components interface as
outside it this is just a different stage in the same process.
Ask a building user or owner about architecture, and they are interested in two
main things: the "grand design" (i.e. the big ideas, the overall form of the solution),
and the "visible design" (how it looks, and how it actually works in day to day
interaction with its users and the environment). The architect's primary concern is
to deliver a solution on these two levels which firstly meets the objectives of the
various stakeholders, and secondly provides sufficient guidance so that it can be
built in line with "the architecture".

Page

how plumbing contributes to the overall set of requirements and constraints.

It's not actually the architect's job to know about plumbing, except to understand

Likewise IT architecture is about a lot more than "plumbing". It has three major
aspects:

The "grand design" and how it (the solution) meets the various stakeholder
objectives,

The structure which underlies the "grand design", and how it will meet the
quality requirements (adaptability, performance etc.),

The "visible design", and how its users will understand it. Different aspects of
"visible design" matter to different people. For an end user, it's the user
interface. For programmers, it's the design patterns and overall class
structure. For both the architect delivers a vision, and a clear set of
consistent metaphors and guidelines.

All architects, and especially agile ones, must embrace this visionary role, focusing
on how the solution delivers real value to the users, and how the system's structure
meets the needs of all the stakeholders.

COUNCIL OF ARCHITECTURE (COA)

The Council of Architecture (COA) has been constituted by the Government of
India under the provisions of the Architects Act, 1972, enacted by Parliament,
which came into force on September 1, 1972. The Act provides for registration of
Architects and matters connected therewith. The COA, besides maintaining a
Register of Architects, oversees the maintenance of standards, periodically of
recognized qualifications under the Act by way of conducting inspection through
Committees of Experts. Based on the inspections, the COA can make
representation to appropriate Governments with regard to inadequacy of
standards maintained by the institutions. The Central Government after further

regarding notifying de-recognition of the architectural qualification. The

Page

Governments and the architecture institutions is required to take decision

inquiry as deemed fit and keeping in view the comments of the appropriate

recommendations of the COA are taken before any architectural qualification is

notified as recognized under the Act by the Central Government.

REGISTRATION OF ARCHITECTS
Only a registered Architect or a registered firm of Architects can use the title
and style of Architect. Every time an Architect signs an agreement with the
client, he is supposed to quote his Registration Number. If any person misuses the
title and style of Architect, such acts tantamount to committing a criminal
offence, which is punishable under section 36 or 37 (2) of the Architects Act, 1972,
on first conviction with fine of five hundred rupees, and on any subsequent
conviction with imprisonment which may extend to six months or with a fine not
exceeding one thousand rupees.
WHY IS IT NECESSARY THAT AN ARCHITECT BE REGISTERED WITH THE COA?
It is very important that every qualified Architect, desirous of carrying on the
profession of Architect, be registered with the Council of Architecture because
any reference in law to an Architect, shall be deemed to be a reference to an
Architect registered under the Act.

WHAT DOES THE REGISTRATION WITH COA ENTITLE?

The registration with the Council of Architecture entitles:
1. A person to practice the profession of Architecture, provided he holds a
Certificate of Registration with up-to-date renewals;
2. A person to use the title and style of Architect. The title and style of Architect
can also be used by a firm of Architects, of which all partners are registered

Page

with COA.

3. Limited Companies, Private/Public Companies, societies and other juridical

persons are not entitled to use the title and style of Architect nor are they
entitled to practice the profession of Architecture.

REGISTRATION STATISTICS

Age group of architects

Cities having more than five hundred architects

Placement of architects

Placement of women architects

Qualification wise registration

Ratio of Male/Female architects

Yearwise registration of Architects

Defaulter Architect

Page

10

Registration of Architect helps in determining the following statics:

Page

11

CERTIFICATE OF REGESTRATION