How to be an architect?

November 23, 2006

I have answered asked and deliberated this quite a few times, and I am trying to put together my thought on it. I hope this puts some sense into this loaded word.

IMHO, an architect brings to the table an ability to make or assist technology and platform choices which let business achieve its core objectives.

Apart from this, an architect is also expected to understand and communicate to different stakeholders ( be it ISP who you are supposed to chose the bandwidth package on behalf of the client, be it OOAD expert modeling the system, be it project sponsor who has to make choices and compromises).

Deliverable of an architect is a partitioned view of the system, with technologies / products and other basis or constraints of these partitions.

Let me elaborate these points by examples.

Sometime back, a manager at a forward looking financial institution got a brilliant idea for a new product / service the bank could sell. The management gave her a small budget and a time of 6 months to prove that the concept works, it sells and is profitable by doing a pilot. So when she approaches an architect, the architect needs to be able to understand ( possibly by questioning) that the application needs to be low budget/low time. Scalability and maintainability and other goodnesses could take a back seat here. The architect needs to explain to the Business owner that – in case the product is successful, the application will require to be re-built before it could be put to a bigger use. In this case a so called poorly designed application is the best architecture. The Architect also needs to be aware of ( or need to hunt for) any COTS ( commercial off the shelp product) which could fit the need and the budget, instead of proposing a custom development.

Now lets take a second scenario. Lets say a Startup approaches an Architect. One of the business objectives of the Startup is to maximize the capital value of its IT investment, as it is likely that they would like to be acquired. Now as an architect, you are expected to propose leading edge technology which creates a product better than what is out there in the market. which covers all the basic definition of a good software of scalability, maintainibility, security, availability and the works. It should possibly avoid product and components which restrict the sale of the same or make it prohibitively expensive to scale.

Now lets take a case of a product which operates as a software factory – having a common code base but certain client specific customizations which are also to be maintained. In this case, testability and maintainbility become important.

Now coming to HOW does one become an architect?

An architech needs to be able to do rough estimations – so that a proper granularity of partitions could be achieved.

An architect needs to be able to gather Non Functional Requirements  and apply them ( like the examples above)

An architect needs to have or to be able to get opinion on different technologies and product options (whether they are mature, whether they are used, is support available, which products are available, which are popular). This usually comes from networking, googling, experimenting and /or by sending out RFI to the vendors.

An architect needs to have a background of application design, so that he/she is able to convert the partitions and their responsibility definition into concrete specifications and interface contracts – possibly with the help of application design experts.

An architect needs to have some background on performance tuning and application load testing.

An architect needs to have understanding of different software and hardware ways to enable application scalability and availability, and cost / compromises required for each of the options.

So in short:

Get involved in “technical” and non functional requirements gathering.

Get involved in deployment planning and deployment (and possibly on-site application support) and figure out the concerns datacenter support teams have and their stake and interest in the applications.

Get involved in estimation and figure out how an application development is broken into individual tasks which can be expecuted.

Get involved in design.

Get involved in performance testing and testing of non functional requirements.

If you are reading this, its likely that you are already doing one or all of the above. If so, probably you already are an architech and all you need to do is to figure out nice document templates to put content in.

I recommend two places to look at: http://www.opengroup.org/togaf/ and http://www.rgoarchitects.com/saf/
The latte, being created by a single person , is more practical.

Advertisements

7 Responses to “How to be an architect?”

  1. Test Says:

    Hi all!

    G’night


  2. […] Pranshu Jain provides some insights into what you should expect from your architect: fundamentally the role is about picking the technologies that enable the business to meet its objectives. But this approach has led to some organisations having less technical architects who understand what various software packages do, but who don’t understand the in depth technical details of how the architectural components relate. This spells project disaster. […]

  3. Philippe Parker Says:

    Hi, I like your article and have referenced it here:
    http://contentedmanagement.net/blog/?p=6

  4. d Says:

    I actually am not an architect but I am looking to be one. However, this website was not helpful in the slightest between spelling and grammar mistakes. Also, the article did not illustrate how to become an architect, and even still the information that the sight did give was just a summary that just renamed the basics that are well known.

  5. HabeLetamut Says:

    Sounds like a very interesting concept! Sometimes I can’t help but surrender to my incredible tray Nice joke! What does a dog get when it finishes obedience school? A pet degree.


  6. […] Pranshu Jain provides some insights into what you should expect from your architect: fundamentally the role is about picking the technologies that enable the business to meet its objectives. But this approach has led to some organisations having less technical architects who understand what various software packages do, but who don’t understand the in depth technical details of how the architectural components relate. This spells project disaster. […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: