Thursday, September 2, 2010

My Time as an Application and eCommerce Architect - Why, What, How

A friend of mine asked an interesting question earlier:  Can you tell me about your experience as architect with Dell/Perot? How did you position yourself to be considered for the role? Did you enjoy the job? Was the role more technical/hands on in nature or more conceptual/framework oriented (Zachman/TOGAF)?

As far as the Dell architect gig goes, I loved the role of trusted adviser to the customer and CIO.   It was less technical and more conceptual.  I was one of several architect types focusing on their own experiential domain.  My domain was fairly wide, containing non-mainframe applications including web and client/server.  As you can guess, this also included various messaging architectures as well (MQ, WS, ESB, SOA).  I guess my knowledge and experience was part of the positioning that I relied on for this role, but I actively sought time with senior management before I was in this role, to recommend that I actually get this role.  I found myself selling the virtues of the role as well as my unique qualifications for it.  It took over a year of lobbying to get into it and get the autonomy that I needed to succeed.

As an architect, I got more face time with high level business folks, as well as the CIO and his VP of innovation.  I routinely found myself in the CIO’s office or in meetings with him, vetting his latest technology direction or decision.  Even if there was a full crowd in the meetings, the CIO and I would be the main two discussing the topic on hand.  Since I moved in to the role from a development team manager role, I had a perspective on development activities as well.  However, this also worked against me as directors and VPs would come to me directly for their needs and try to circumvent the change control process.  I got the reputation for getting things accomplished, but my management wasn’t always happy about that informal process path.

I spent considerable time writing architecture documents that described direction, or assessment of technology, or even documenting our position on a particular technology.  In those docs I used mostly the enterprise, technology, and systems model layers of Zachman.   I really had to understand to whom I was trying to communicate to craft my docs appropriately.  I wrote docs to guide the teams as well as to elaborate to senior management.  

I used TOGAF to help guide me toward a target architecture, though none of my peers used it.  I am no expert myself.  The TOGAF ADM was helpful in so much as it laid out a process for achieving a target architecture.  When I left Dell, I was in the middle of developing a “building permit” process for our technology projects.  As an architect I was cognizant of the lofty positions I could take on technology and tools.  I wanted to be an enabler to the business as well as to the development teams, and the last thing I wanted to do was introduce more process and obstacles to the technology delivery cycles.  The building permit process was going to be a contextual checklist that developers and leads would fill out, in order to proceed with a design.  Based on the answers on the checklist, architecture design reviewers would know how deep to dive into the design based on how pervasively the design affected the published enterprise architecture.  I never delivered this tool, but I still think it is a good idea.

My technology experience and knowledge was very important to my architect role, but more importantly was how I communicated.  I needed to know my topic well enough to remain confident when I delivered a decision or recommendation.  I tried to never be heavy-handed, but I also needed to be firm to exude confidence and decisiveness.  I was looked upon as a leader and I needed to function as one within my domain.  I also worked on my listening skills as well as adapting my non-verbal communication techniques.  I consciously tried to lessen the negative non-verbal communication; it was not easy.

No comments:

Post a Comment