Sunday, April 05, 2009

Chief Architect...huh?

So about a year back I took up a job where my title is 'Chief Architect'. The job is with a financial services company. So you ask - what does a Chief Architect do at a Financial Services company? Good question - I wondered about it too. My job profile as explained by my hiring manager was to provide architectural governance, help with technology roadmaps, mentor junior folks and provide expertise on key projects. So that doesn't sound too outrageous. However, after about a year in the job, I still wonder if the title of 'Chief' Architect is a bit misplaced. To me, the Chief Architect would be a suitable title for someone who was the mastermind behind the flagship product of a product company. A more suitable title could be that of 'Enterprise Architect'..I guess.
So after a few stints at small companies, I am now at this 'big' company with close to 50,000 employees overall. My division alone has close to 1000 employees within IT. Its startling how the politics plays out as such large companies. Everyone is more worried about protecting their turf, making sure that the respective 'asses' are covered and that the individual bosses are happy. There aren't many who are thinking about the overall good of the organization. And I don't for a second pretend that this is a problem with my workplace. Its the same story I hear about most large companies. So must be something to do with our human nature. However, I truly believe that I am here to make a difference...to be a team member and contribute towards creating value for the company.
The economy and especially the financial services industry is going through some tough times right now. Recently I attended a meeting where there were questions raised regarding the need for having a separate architecture representation. My translation - time to look for another job!
Architecture to me is truly about the strategic vision, a plan, a roadmap for aligning the IT systems with the business strategy. In times like these, most companies look at architecture as an overhead. Which is kinda sad. In fact, in such times is when companies should challenge the architecture team to find efficiencies, reuse leverage etc. Some companies decide to make strategic investments during lean times to position their organizations for taking the lead when the economy does turn around.
So regardless of what happens with me, its been a very interesting experience to work as a Chief Architect of a sizeable company. Have learned a lot in the process and hopefully contributed a lot to the job too. At some point, I will definitely share my experiences here for others.
Boy, each time I decide to keep the blog short, it never happens as the thoughts and ideas pour out. But I think its more important to chronicle the true feelings than to artificially truncate thoughts to keep things precise.
Adios for now!

Tuesday, January 08, 2008

And employees are important??

So I learn yesterday that one of my good friends and a great developer quits from my company. And of course, I am not thrilled! I decided to blog about it to express some of my frustrations. It so happens, although the topic is not itself related to architecture, more often than not, architects or people in that role are generally put into leadership positions and expected to deliver in a team environment.
I got this important lesson from my Dad a long time ago (he retired as an executive in a manufacturing company) about how the most important thing as a manager is to make sure you hire and nurture good people. Although I had largely ignored that statement, it started to resurface when I started facing situations where I had to compensate for the lack of experience or skills on the team. I spent countless hours trying to explain the problem domain, trying to ramp people up on the frameworks being used etc., at the same time keeping an eye on delivery dates. It helped, but not to the degree I had expected.
My current company has the philosophy of lean and mean operations, with very little cost overheads. And there are definitely pros and cons of this approach. A lot of us (including two of the founders) came from my previous company where exactly the opposite was true (excesive spending! But then again it was the dot-com era! Who cared!) So I do understand the drive to keep the costs low. But what happens is because of such an approach is that there isn't enough investment internally.
  • Managers (or lack of thereof) are busy trying to grow the topline.
  • There is hardly ever any bench and if there is, there is no active management of it
  • Lack of structure ensuring delivery quality
  • Always hiring on-demand doesnt allow teams to gel, putting pressure on delivery leadership
  • And I could go on and on...
Of course, on the positive side, and its definitely a *huge* positive, is that we have never had a single layoff. We are always short on resources (not intended to be a pun!) to delivery on the pipeline and so, we don't have to really worry whether we will stay in business.
I did try and communicate this out to the decision makers within the company, and it did seem like at least a few of them acknowledged the fact. But I have yet to see follow-up or any changes on the ground with regards to the issue.
There probably is a middle ground where there is fiscally conservative policy but at the same time, adequate investment back into the company. I would love to hear others experiences in this matter and any pointers on how to go about improving the situation.

Saturday, January 05, 2008

My recent trip to India

So I am back from a month long trip to to India. What a blast! Each time I visit India, there is a slew of change that greets me, right from the time I land at the airport. This time around, I was visiting after only a couple of years, and yet, I couldn't believe how much had changed in that relatively short duration of time.
The landscape - new buildings coming up next to where my parents live in Pune, the traffic going from bad to worse (both in Mumbai where my in-laws are) and in Pune, new coffee houses everywhere (a change I do welcome!), new swanky cars (I barely saw any Ambassadors or Fiats on the road other than the taxi cabs that are still reminiscent of the not so distant past), . We even had a chance to visit a brand new mall that opened in Pune. Of course, everyone now has a cellphone, including my little cousin sisters, one who is in junior college and one in high school.
The other very interesting trend I noticed was the kind of career opportunities that are now available to kids growing up. Language translations, transcription, media, journalism, finance... there's demand for all kinds of work. Growing up, if you were not an engineer or a doctor at least, it was a struggle to land a job that could earn enough money to live a decent life.

Pay scales in India are phenomenal!!! I couldn't believe how much some of my buddies were making in India. The middle class is becoming quite wealthy and people are spending money like there's no tomorrow, some loading up on as much debt as they can. Hmmm, I wonder where I have seen this before?? ;)

There are those that are argue that the rapid liberalization of the economy and opening up of the marketplace is good for the country and then those that say that recent policies are increasing the gap between the rich and the poor, that only a fraction of the country's population is benefiting from the change. I believe both are right and its only a matter of time before the wealth percolates down to the lower rungs of the economic ladder. I think this is the price that the country is paying for the transformation. I think its all good! I like change. India has gone through much tougher times in the past, and I believe it has the capacity to assimilate this change too.

Anyways, what has all this got to do with architecture, nothing! Just felt like sharing my experience with fellow netizens out there.

Peace out!

Labels:

Thursday, November 01, 2007

Role of an architect

I have struggled a lot with what it means to be a good architect in the technology space. I have been involved with IT for a good 13 years now. Although an engineer by training, I have had this title for a good 5-6 years now.
So what have I been doing? Many things - filling in for project management, writing code when needed, providing design guidance using the experience gained working in this field, collaborating with user interface designers to express functionality that they can visualize. At times, I have also had to manage the client relationship to shield the project team and let them be productive. So have I been playing 'Architect' on these projects? I am not sure! The one common thread in all these roles has been leadership. On each of these engagements, I have been playing the lead role in terms of taking the proverbial bull by the horn and doing what is necessary to get the project over the line. Thus, from what I have seen, the architect or someone who carries a title of an architect, is more often than not a senior team member who has been through the grind of executing projects over and over again and has uses his/her experience or gut feel to make effective decisions that more often than not, prove right.
Of course, most of my career has been in the consulting space. So any first hand experience is definitely from this perspective. However, I have interacted with architects on the client side, who are employees and not consultants. I have often wondered what decisions I would make if I were on the other side.
In my opinion, in such a scenario, my first priority would be to understand the direction that the organization is moving in, the business goals, the culture, the delivery processes. All of these factors would certainly figure into what kind of architecture needs to be put in place to support the business. For someone to know the above, I think it is important that the person be acclimitized with the environment and have worked there for some time. Additionally, a natural curiousity for understanding the business would definitely be an added bonus. After all, the architect is a key position that translates technology to business and vice versa (I can cite countless examples of how I have seen this lacking in many clients I have consulted for..maybe another entry some other time).
Last but not least, what constitutes an effective architecture? I dont know if there is a good definition around this. At some organizations I have worked for, architecture to them really is just the hardware, deployment configuration, software stack etc. In other words, specifications that a data center would be concerned with. At others, architecture is extremely detailed and intimately connected with the technical design of the applications and products, going into the patterns of data movement, integration methodologies, protocols etc. Is one more right than the other? I dont know!
Anyways, if anyone reads this blog, I would love to hear opinions and thoughts.

Monday, October 01, 2007

Read-only role

It is funny how this functionality is always an after-thought. After getting off a call where we were just about finalizing the design and getting ready for the sign-off this issue came up. I don't know how many times this issue has been raised at the last moment.
Why this is a tiny bit important is because it, more often than not, does have a *very* significant impact on user the time and effort needed to deliver the project. And then, there are always the hacks that we as developers/designers come up with "Oh...for now, lets just have hidden or disable action buttons" sort of a solution.
An elegant solution, as we all know is to present a read-only view (a separate page) of only the specific information that a read only user might be interested in and not build a read only view of every form within the application. Although, I am not sure if this is something that the plethora of application frameworks out there can provide as a feature. But, creating this view does require some thought and some user interactions ot figure out what might be the right set of things.

So there you go, an interesting situation that we in the technology field face often times.

Anyways, instead of planning to blog, I have decided to experiment and create entries in here as soon as a thought hits my head. Of course, this means, these entries have to be short, otherwise I would probably end up blogging all day about all sorts of things.

Friday, May 19, 2006

The ESB .. Thoughts - Part 1

So here I am after a*very* long time writing about some of the things that have been going on in my mind. Like I mentioned before, I work for a niche consulting company focused around Financial Services sector in the Boston area.

Time and again, this question of the service bus pops up when consulting for my clients. I still havent formed my opinion on whether this is a new concept, evolution vs revolution, nirvana, panacea .. etc etc. The developer within me keeps screaming - "Yea right! Another broker based integration technology..so whats the news?" However, the architect side says - "wait..there definitely is some value in this component".

I do think that it is important to weigh the pros/cons, architectural requirements and capabilities needed for the particular problem domain to figure out if this component is a right fit. Some of the capabilities that I found useful was

- Applying security outside of the application logic
At one of the pharma clients that I worked at, I created an SOA security architecture where we implemented the WS-Security standards outside of the actual application. Although we were not using a traditional service bus component, I understand that this function can be easily embedded into the service bus.
- Reliability of messages (and here I refer to messaging based service bus components)
At the same client, we implemented a store and forward type pattern where persisting the message was greatly important in case the reciever was temporarily incapable of receiving the message
- Message transformation to canonical formats
At another client, there was a scenario where incoming requests were of various formats (due to legacy reasons) and we developed a custom component (based on XSLT transformations) which normalized the various requests into canonical formats. We leveraged the same component to do the same with responses. Sometimes the responses were generated by different endpoints in different business units with different standards! Ultimately, the clients made a service out of this component, much like a translator/mediator between the consumers and providers.
- Avoiding point to point connections
From the CORBA days, a message broker architecture is infinitely more scalable than point to point connections..which is sort of back to the previous bullet. Having a level of indirection is extremely useful, especially over a period of time when new endpoints are added on both consumer and provider ends.

I am sure there are other capabilities that people have found useful from an integration perspective. So if all such capabilities were bundled into one component, it would probably be quite useful.

In the interest of keeping the post small - I will stop here and continue the discussion later. Specifically I do have thoughts on questions that clients have asked me:

How much time does it take to implement a bus?
Can I start without a service bus and then add it later? What would I need to change?
Do I need to have an organization/governance change around the bus?

I would love to hear from others on these thoughts too..

Tuesday, December 13, 2005

Hello and welcome to all readers! This is my first of the many more entries to come. Actually, today I am going to be on the road and hence keeping this short. I am contemplating blogging on the 'Enterprise Service Bus' as a component within the architecture. So look forward to dumping some of my thoughts and experiences from the latest project that I have been working on which is a 3 year IT strategy for CRM services within a large (read one of the largest) banks.

So long for now..