Skip to content

architect? (jos)

April 26, 2008

This entry is written from an investment bank point of view.

Typical business responsibilities include:
* Understanding the business domain.
* Understanding the business data flows.
* Looking at the whole picture, not just individual bits.

Typical design responsibilities include:
* IT infrastructure, especially system coordination.
* Connectivity and middleware.
* Production reliability and resilience.
* Software development process.

Typical communication responsibilities include:
* Talking to just about everybody.
* Writing documents that people will actually read.
* Drawing pretty diagrams aimed at the specific audience.
* Software development coaching and mentoring.

Typical execution responsibilities include:
* Project management.
* Project execution.
* Vendor management.

I even do some coding – look, I can still do FizzBuzz 🙂

Basically, it really depends who you are talking to.  To a consulting firm, an architect is someone just technical enough to collaborate with the engineers and with enough sales skills to talk to the customer.  In other words, it is a technical liason role.  This is really not all that different than a sales-engineer, but the role is post-sale.  It’s also not much different than a requirements analyst, but the architect is expected to have the technical chops to say “It doesn’t work that way”.

I’m an architect for a very large project (you see TV commercials for this company’s product).

We do quite a bit of code development.  It’s true there are developers we work with that write a majority of the code however, Architects, at least from my experience, do a fair amount of code development:

–  Proof of Concepts code development.  Much of this code becomes the start code the developers use to implement with.

–  Protocol specification (sequence diagrams) and then developed the code.  Common theme when dealing with hardware devices and often the case for Architects who are not has highly focused as a developer role in same project tends to be.

–  Developers tend to be very focused.  For example, the .NET guys don’t do J2EE and vise-versa.  As an architect, I  have to know both.  Consequently, again in my experience, architects develop code in more languages than highly focused developers.  This has been the case on the 30 or so  enterprisey projects I’ve been on.

–  Architects are the go-to folks when problems come up during development.  If a developer finds they are having performance issues, then architects step in to review code to refactor, etc..  Mostly finding junk code being developed.

– Architects have more responsibilities and this comes with more $$.  If you fuck up the design, then it’s on you to fix or get fired.  Architects have to know more about the external systems, if any, that all must be integrated with.  If it’s a web application then chances are that you may be dealing with web service calls to other systems and if it’s external vendors, then maybe you trying to develop a single sign on system between the two entities.  In these cases I see architects also being product knowledgeable as well…  Knowing what, for example, IBM’s DataPower can and can not do, what MS-Exchange can and can not do, what Windows Communication Services is capable of and what Java timer beans can and can not handle on a WAS vs JBOSS platform.

No comments yet

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: