RunOfTheMillBlog

Architects...Who? - Part II

ramkoth — Tue, 14 Mar 2006 02:00:00 GMT

Let’s talk about architects in Microsoft. The architects in Microsoft I know grew threw the ranks as Software Design Engineers and are extremely technical in nature. If a normal programmer knows 10 things about a thing, then an architect for the thing knows 500 different things about the thing. For instance, Christopher Brumme probably knows 500 different things about GC than a competent .NET Programmer. Roughly, architects in Microsoft product dev team do the following things

- They usually own a specific area of a product and come up with complete design (to the level of lowest granularity). Their tremendous experience in software engineering and their ship record helps them to look around corners, optimize things based on the underlying platform and provide guidance for developers to implement a particular strategy in a most optimal way.

- They work with other feature teams and architects to make sure that whatever they design seamlessly work with other components.

- They are extremely technical. This cannot be stressed enough.

- They write code – a lot of code actually.

- They communicate really well – one thing I have appreciated and trying to learn over a period of time is the clarity these guys bring to table. It is as though they speak the language of context-free grammar. You can’t interpret a sentence in two different ways.

They have huge credibility and it is due to their proven technology depth, engineering skills and their vast knowledge.

Let me digress and talk about the other types of architects I encounter (outside product teams) on a daily basis.

Beware of VNAs

I keep hearing this new term called Vendor Neutral Architects. First time, when I heard this, I spilled the NaaN that I was eating. (NaaN is not ‘Not a Number’, this is an Indian bread type J.) From what I hear, these guys are supposed to know all the technologies provided by all the vendors at the goriest level of detail for a particular problem domain to help customers make a knowledgeable decision. For example, if the domain is Messaging, then the VNA should know Exchange, SendMail, Lotus Notes etc in all their gory details and help customers choose the technology based on whatever the customer needs are. From what I see, you can count people with deep skills in all competing technologies in any domain. For example, it must be easy to count the people who can compare and contrast CLR and JVM at the minutest level of detail (for instance how the JIT optimization works in CLR and JVM or the GC heuristics used by different runtimes) or for that matter people who knows how to compare SQL Server Query Optimization vs Oracle’s query optimization. It is of course obvious that a person who has this knowledge will be of tremendous value to any team, but it is just that they are very hard to find.

From my experience, the VNAs I have met are definitely vendor neutral – in the sense they don’t know any vendor technologies at any level of detail. These people seem to have all the other ‘right’ attributes like socializing, playing politics, playing golf, nice dress sense etc. I am not generalizing, but this has been my experience so far. Some of these architects hold a view point that they only design at high level (i.e., UML and Visio) and leave the details to developers. Hello? You can’t write code, you are not an architect. Sorry – you didn’t pass the necessary condition (at least not in MTC).

So, I am going to use two variations of architects - Architect with capital A to denote MS Software Architects type; and an ‘architect’ with small caps to represent the solution architect and VNAs as defined (or loosely defined J) by world at large.

We want Architects not architects. If we come up short, I would settle for experienced software design engineers with good customer handling skills.

PS: These are all my personal view points and doesn't reflect view point of my employer.

Architect...Who? - Part I

ramkoth — Mon, 13 Mar 2006 09:33:00 GMT

It’s been an exciting job building a Microsoft Technology Center from the scratch – all right almost from scratch. The most important job of creating and selling the business value prop behind setting up a MTC is done by my boss – Sheila Gulati. From that point, I was tasked with setting up the MTC in Bangalore and this includes logistics, hiring, marketing (internal as well as external), partner management, lab set up and budget management – basically the whole nine yards of setting up and running a business. Given that I have been a techie all along, it’s been a wonderful experience for me to learn about business side of things and needless to say, I am learning a lot these days.

Let’s talk about hiring for a moment. I have to hire a set of technology architects and a bunch of contractors for managing logistics part of MTC. Needless to say, hiring right technology architects is essential to survival. Basically, the technology architects in MTC Bangalore should own a particular practice – a practice could be Connected Systems, BI, SQL, Collaborative solutions, Infrastructure Optimization, High performance computing etc. Owning a practice means the following things

- Ability to map customer business problems and pain points to technical solutions. TA is not expected to be a domain expert and it is expected that Account Manager and field folks who are associated with that particular opportunity has to help our TA to understand business context. But, TA should be able to take the business problem and map it to MS technology/solution platform.

- Ability to design a solution (widely called as solution architecture) using Microsoft Platform. Oh, by the way, when I say Solution Architecture, I don’t just mean the routine ceremonial, hand-waving high level visio/UML type architecture, but the low level design that includes how exactly the solution be built with MS with focus on performance, security and extensibility.

- TA is considered the GOD of the practice. She is expected to be omniscient about the technology area that belongs to her practice that she owns. For example, if you are a TA for HPC, you are expected to know anything and everything about Beowulf cluster, MPI programming, HPC management, RIS etc. Customers expect you to know everything; we expect you to know everything about the area that you own.

- Needless to say, TA should have great communication skills and more importantly, great listening skills.

So, you can say it is all about technology depth, great design skills, great communication skills and customer empathy – and oh yes, little bit of experience is required (minimum 10 years).

With this idea, I set about to hire technology architects for MTC. The experience has been illuminating.

Architect…Who

We did receive whole bunch of resumes. The resumes roughly fall under following categories.

A) Project manager. Typically has been handling a mid-large sized team (25-100). The resume is all about how he/she built a practice, enabled his/her reports to do whatever they are set out to do..blah blah. They don’t have any hands-on experience of late (that means 2-5 years). Majority of the resumes belong to this category. These ends up being paper rejects because of wrong fit.

B) Developers with a difference – and the difference being that they have been developing similar apps for 10 years. They typically build in-house apps for IT dept for large customers for quite sometime. Typically (not always), they wouldn’t have designed large scale apps and hence doesn’t know some of the fundamentals related to scalability, transactions (yes sir, it is true), basic algorithms etc. Their title is architect, simply because of their experience. Most of them are paper rejects because of lack of designing large scale apps, some of them get rejected in the first round after stumbling upon cursive questions on transactions and scalability.

C) Individual contributors – These people have been designing and developing large scale apps for quite sometime. They like being individual contributors (good fit) and they want to remain technical (good fit). In this case, people with good communication and consulting skills (apart from technical skills) proceed to next round. We’ve had some success here. But, unfortunately, we don’t get a lot of these.

Here is an interesting statistics about the source of resumes. Usually, type A and type B come from System Integrators and Customer IS departments. Type C typically comes from ISVs and some SIs. So, you may wonder why we are getting type A (project management folks) when it is very clear what we want is some one with deep technical, hands-on and consulting skills. The problem is because of the nebulous definition of the word ‘Architect’ in the context of IT industry.

Let’s look at the definition of an Architect from the following sites

http://www.bredemeyer.com/pdf_files/role.pdf

http://www.agilearchitect.org/agile/role.htm

http://www.artima.com/intv/architect.html

http://www.certmag.com/articles/templates/CM_gen_Article_template.asp?articleid=1406&zoneid=225

If you look at the definition of ‘Solution Architect’ in many of these sites, they go beyond the role of solution architect (i.e., to build a solution architecture) and cross over into many of the project management functions (like political handling (for god’s sake how is this part of architect’s job. Actually every role has some politics associated with it. What’s new here), little bit of project management like managing budget, ROI calculation etc). The agile folks seem to have a much more pragmatic view of Solution architects as opposed to others. I think the problem seems to be more like the confusion of different roles such as architects, project management, portfolio management etc. It is entirely possible a single person may be doing all the roles, but it is important to cleave them apart.

And I am not sure why we take these definitions as god’s gospel. Where are the proof points that this model has worked? Given that overwhelming of the software projects are failure (http://www.agilefactor.com/stats.aspx), what you have, in fact, is the counter-proofs that these models never worked. I personally feel closer to agile approach.

There is an interesting aside. In India, most of the IT population works for system integrators. In the Indian Sis, it is (at least it used to be) very difficult for a techie to have a career as software engineer. This is not because the SIs don’t want to promote individual contributor role with technical focus, but because of the ‘time and material’ business model they all follow. In this model, ROI of a ‘resource’ is directly proportional to how much they can be billed in a specific time. If you remain as an engineer for quite sometime, the ROI (of you) will be diminished over time as your pay increases over time, while your billable amount remain constant (or near constant). I guess this is changing now as the customers also recognize the word ‘architect’ and willing to pay a little bit more. Also, there are few companies in Pune that truly value Software engineers and have built career plan for them as individual contributor role.

In the next blog entry, I will talk about architects in Microsoft and how different they are from the architects as understood by outside world.

PS: These are all my personal opinions based on my observations and it doesn't reflect my employer's view point.

2005 Cyber security bulletin by CERT

ramkoth — Tue, 10 Jan 2006 07:52:00 GMT

CERT has published an Cyber security bulletin for Year 2005. Here is the snippet

This bulletin provides a year-end summary of software vulnerabilities that were identified between January 2005 and December 2005. The information is presented only as a index with links to the US-CERT Cyber Security Bulletin the information was published in. There were 5198 reported vulnerabilities: 812 Windows operating system vulnerabilities; 2328 Unix/Linux operating vulnerabilities; and 2058 Multiple operating system vulnerabilities.

Here is the link - http://www.us-cert.gov/cas/bulletins/SB2005.html

They do have a disclaimer that states that the result is aggregation of reports from various sources.

Building Colloborative Solutions Content released

ramkoth — Fri, 02 Dec 2005 16:46:00 GMT

We have been running a series of Architecture Workshop under the theme of 'Solution Architecture Series'. The idea behind the SA series is to create a workshop that is focused on building a specific type of applications - for example, apps like typical web based OLTP application or a Business Intelligence App or High performance App or Service enablement etc.

For the first workshop, we chose Colloborative applications as the theme and you can find the content and presentations here in the GotDotNet workspace. Your comments are appreciated.

Microsoft Technology Center in Bangalore

ramkoth — Thu, 28 Jul 2005 10:27:00 GMT

I am happy to announce that we are building a Microsoft Technology Center (MTC) in Bangalore. MTC is a world class facility that offers several services to customers and partners (ISVs and SIs) to architect and build high quality, world class, robust applications using our technologies. The services offered are free of charge and the main motivation here is to help customers and partners build high quality apps and infrastructure using our technologies.

We offer whole suite of things ranging from a quick 2-4 hours strategy briefing to 2 days architecture design sessions to 2 weeks POC.

We provide world class facilities for doing a POC (proof of concept) in our MTC. As a customer/partner, you can bring in your development team and technical architect from MS will work closely with that team on the architecture, design, development and testing the POC. We will provide a dedicated work spaces and lab resources for developers and architects from our customers.

We are expecting the MTC Bangalore to become operational by November 2005. We are looking for solution architects who can survive in an high-octane intellectual environment. We are interested in folks who can button up and do strategy briefings for CIOs and at the same time, can also roll up your sleeves to design and build (meaning writing code) a solution. We are looking for both IT architects and solution architects. What we are looking for is passion to help customers, passion for MS technologies and passion to learn and lead. If you think you are the right person, please feel free to contact me through the contact form. Looking forward to hear from you.

SQL Server Architecture Workshop content posted

ramkoth — Thu, 28 Jul 2005 10:06:00 GMT

The content for the SQL Server Architecture Workshop (decks + samples) have been posted in a Gotdotnet workspace called .NET Architecture Workshops. Please follow the link to register yourself with the workspace to download the content.

I will post the CLR Architecture workshop content soon.

I am also looking forward to hear from you regarding the future workshops and the subject areas of interest to solution architects. Please use the 'Contact Form' to directly send an email to me. Thanks.

Performance Clinic Content posted

ramkoth — Mon, 30 May 2005 01:57:00 GMT

I and my colleague Govind Kanshi have been going around India talking about performance tuning as part of the Performance Clinic Workshop. The content for the workshop (decks + samples) have been posted in a Gotdotnet workspace called .NET Architecture Workshops. Please follow the link to register yourself with the workspace to download the content.

BTW, we also did SQL Server 2005 internals workshop and CLR internals workshop earlier. We will be posting the content for those workshops in the same workspace in the near future. Govind maintains an excellent blog that contains tons of pointer to interesting database related articles that formed the basis for our SQL workshop.

An Ode to interop

ramkoth — Sat, 12 Jun 2004 00:20:00 GMT

Pat’s obsession has caught up with me as well…My daughter was singing this all the time after we visited Disneyland... I nspired by 'Small World' song of Disneyland It's a small world after all Hence we should Inter...op It's a small world...(read more)

EVMs and Indian Elections

ramkoth — Tue, 01 Jun 2004 05:02:00 GMT

India, world's largest democracy, just recently successfully completed the general election for its parliament. For the first time in its history, India has successfully used EVM (Electronic Voting Machines) for the polls in all the constituencies.

Obviously, usage of EVMs have been the highlight of the election. Obviously, it didn't get the attention it deserves, because media doesn't care about things that work. Here are some of the requirements for EVM system.

600 Million possible voters (380 million actually voted in this election)
Million election booths.
Each constituency will have different set of candidates. Some constituency may have up to 100s of candidates standing in the election - which is an unlikely thing in west (of course, California is the exception.)
EVM should support 18 different official languages. For example, I hail from a state called Tamil Nadu and voters belonging to this state understand only Tamil.
~15-20% of the voters are illiterate - can't read and write. It adds an interesting perspective to the usability aspect of EVM.

Here are few facts.

One million EVMs have been manufactured for this election.
There was virtually no complaint about usability of EVMs. In my opinion, this is the greatest achievement. If you ask why, just think about all the hoopla around Florida episode during last USA presidential election.
Each EVM is shipped to the local booth via appropriate transport mechanisms. I am sure you have seen photos of elephants carrying EVMs to the remotest corners of India. This is a logistical nightmare at the best of times. This is one of the reasons (apart from security) as to why the election was conducted over a period of three weeks.
All votes were counted. (sorry mate, couldn't avoid taking a pot shot :) Honestly though, I have a huge respect for US electoral process. IMO, contrary to popular opinion, it is really efficient. It could be made better, by buying EVMs from India. :))
Here is the counting process: All the EVMs are brought to a centralized place and they were connected to the network. Counting is a matter of just summing up the votes for individual candidates from different EVMs. All said and done, the whole process takes up to 2 hours. Before the usage of EVMs, the whole process takes up to 2 days and is error prone as the votes were counted manually.
Millions of trees were sparred from extermination.

The cool thing about this election is this: If EVMs work for India, it should work for every democratic country for conducting polls (and it will work for china too, if and when china becomes democratic.) When it comes to polls, India should be the benchmark, just by its sheer size and the population. Folks who designed this system should be really proud about what they have achieved.

So, next time when you think of India, please think about the EVMs and not call centers and snake charmers. :)

Entity Aggregation white paper released

ramkoth — Wed, 26 May 2004 08:24:00 GMT

In my earlier posts, I was talking some of the real world challenges that an architect face while trying to implement SOA in their enterprise. Entity Aggregation is one of those problems. You can read more about entity aggregation here.

Integration Patterns preview released

ramkoth — Sat, 15 May 2004 18:38:00 GMT

PAG has released the preview of integration patterns which can be found here. I contributed/co-author of the Entity Aggregation pattern which can be found here. My solo paper on Entity Aggregation will be released in MSDN sometime soon.

Moving to India DPE

ramkoth — Sat, 15 May 2004 18:36:00 GMT

I haven't been able to post for a long time as I was involved in too many things - one of the things happen to be my move to India DPE as an Architect Evangelist.

I am really excited about the opportunity to interact with developers and architects in India. Every Indian professional in USA has this dream of going back to India and work there and I am really glad that this is becoming true in my case. I am starting my new job on May 24th of this month and like I said earlier I am super excited to be transferred to the 'front-line'. (Actually, I see that more of a love front rather than a war front. Not sure why people characterise field as a 'war front'.)

I will continue to post my views on SOA, Data and other such things in my blog.

SOA - Real World Challenges reposted

ramkoth — Tue, 16 Mar 2004 16:18:00 GMT

I guess I shouldn't post a blog during mid-night. Here is my second try. My views on real-world challenges can be found here

BTS 2004

ramkoth — Mon, 15 Mar 2004 13:44:00 GMT

IMHO, Biztalk Server is the only team in Microsoft that understands integration issues. They have delivered a product that in my opinion provides complete solution for the B2B as well as EAI scenarios. The two things I love about the product are - Orchestration and Business Rules Engine. BTS architecture is really elegant and it is built for customization from the ground up. It is possible mainly because, various components like (Pipeline components, Adapters, Ports, Message Bus etc) are loosely coupled. I could have done certain things differently - like keeping orchestratin little bit loosely coupled from the messaging etc. But, I was the first one to bitch about loose integration between orchestration and messaging in the previous version.

They really worked their tail off to deliver a quality product; their perseverance and hard-work deserves a round of applause.

While we are it, please bookmark Scott Woodgate's blog. I am sure he is interested in your feedback.

SOA Real-World challenges

ramkoth — Mon, 15 Mar 2004 13:30:00 GMT

This post discusses some of the challenges architects/designers face while trying to implement SOA in their Enterprise. Our team has been working with customers for the past two and half years to implement SOA. This post reflects collective experience of our team.

Most of the discussions around SOA revolves around basic issues as RPC vs Doc/Lit, Remoting vs Web Services, usage of WS-* protocols etc. These are relevant issues and has to be discussed in detail. But, there are other important issues that needs to tackled in order to implement SOA in an enterprise. In my opinion, WS-* is necessary, but not sufficient. So far we have been talking about the necessary part. This post will cover the sufficient part.

Today, SOA is mainly used in connecting applications. In other words, the sweet spot for SOA is primarily in the integration space. If you look at the solutions that are built in a typical enterprise today, they fall into two classes of solutions - Service Delivery and Information Analysis. Service delivery - as its name suggests - is about delivering services offered by business systems (like ERP) to end-users directly. Self-Service solutions such as Employee Self-Service portal falls into this category. Primary motivation for self-service type solutions is to reduce the cost by dis-intermediating the interaction between user and system.

Let's take Employee Self-service portal as an example. Building this portal involves integrating multiple systems - HR System, Payroll system and Benefits system. Usually, these are separate systems and are autonomous in nature. Some of these systems may even be outsourced. For example, Payroll capability is usually outsourced.

Now, let's look at the challenges involved in building a self-delivery application.

Identity management - Usually, every business system maintains their own identity profile. They also define their own authorization realms - they define roles specific to the business functionality they expose. So, managing identity across multiple systems is a major challenge. Some of the issues you have to resolve are

Single Sign-On (both web-based SSO and system level SSO)
Federation - For example, Payroll systems and benefits systems may be managed by a different enterprise. How do I federate identities across organization boundaries.
Provisioning - When a new identity is created (during hiring for example), what is the process involved in creating appropriate identities in other systems.
Synchronization - Usually Single-Sign on solution requires some sort of credential mapping. How do we make sure when password changes occur in a business system and how do we synchronize that SSO credential mapping store.
Authorization - How do I authorize in this world?

EII (Enterprise Information Integration)

Every system maintain its own view of employee. For example, payroll system defines the payroll specific view for the employee entity, benefits system defines benefits specific view for the employee entity etc. But, building a service-delivery application requires a unified view of employee. A better example would be 'Single view of customer' issue that every enterprise faces.
Horizontal partition - There are cases where entity instances are partitioned across multiple services. How do we present an aggregated view.
There are cases where your solution requires cross join of entities encapsulated by different systems. In that case, you have no choice but to bring those entities to a central store. Cross-join scenarios are so devastating that your mind set will shift from service-orientation to data-orientation. I have gone through that experience :)

Schema Harmonization - Every service maintains its own view of an entity. How do we harmonize the schematic differences between services? Canonical schema is one practical way to harmonize the differences. But, the real challenge is to get all the stake-holders to agree on the schema. This is where a strong enterprise architecture team can make a difference. Another challenge is - would you go for a big-bang approach with enterprise modeling or would you go for incremental approach. Current thinking is to go with incremental approach. Start with few commonly used entities such as Customer, Product etc and then add more stuff later on.

Service Management - How do I manage, bill, meter, provision, de-provision services?

There are more issues. But, these are the primary challenges one would face while trying to design a solution based on services. In my future posts, I will spend some time on each of these issues and share with you some of our experiences and key learnings.

I would love to hear your opinions on this subject. I am sure some of you may have implemented SOA in your IT and faced similar challenges. I am also sure that you may have come up with better solutions and have a better insight into this problem. Please, please share your learnings. We can all learn from each other.