Archive for December, 2007

The Semantic Web

As with most of my posts, I will start discussing the Semantic Web at a very high level, geared towards gaining an overall understanding of what it means, why it’s relevant and what it’s implications are. Future posts will discuss the future and associated technologies.

In it’s simplest form, Semantic Web is about giving meaning to the vast amount of data that lies on the Internet and more importantly, making it machine readable so that all that data starts to make sense not only to humans (as is the case today), but also to machines such that machines can infer meaning from the data, associate it to other data to draw conclusions or provide new services. Imagine that you are about to take a vacation. What do you do today? You go to Google, type in “vacation packages”, click on a few links to see what these packages entail, sort and search though ones that fit your budget and then decide if any of the suggested packages is something that you’re interested in. Now imagine if there was an easy way to just tell the Internet – “find me the best vacation package under $3000” and somehow, the Internet knew enough information about you to do know where you’ve been recently (hence not to present those vacation destinations to you), what your general likes/dislikes are and given a budget of less than $3000, what current packages make the most sense for you. Now that would be something wouldn’t it? In essence, that is the power of the Semantic Web – drawing conclusions, forming relationships from given data sets and arriving at results.

Of course, this is a 10,000 ft view of the Semantic Web, so the above description is overly simplified. In reality, there are many issues associated with inferring relationships and arriving at conclusions. Take for example:

  • Suman Chaudhuri is the owner of this blog
  • The owner of this blog lives in Michigan

From these 2 statements, one can infer that Suman Chaudhuri (me) lives in Michigan. You (and machines) could not have known this by just processing each statement on it’s own, but combined, this conclusion can be reached. That is the power of the Semantic Web and the more that machines can process and infer, the more powerful the Web grows. However, as I mentioned, it’s not always that simple. Take for example:

  • Suman lives in New York.
  • People from New York speak with a New York accent.

This would mean that Suman speaks with a New York accent. But the truth is that I have been raised all over the world (England, States, etc) and although I do have an American accent, it is by no means close to a New York accent. The problem is that the 2nd statement is a generalization, but machines cannot understand that and that is where the problem lies.

But I digress. This article is about a high level discussion about the Semantic Web. So what is needed to get to the next generation of the web, the so called “Web 3.0”, where machines can understand and process data, make inferences and build on the idea of collaboration and social media (currently termed Web 2.0)? The data needs to be described, categorized and annotated. Meta-data is the key to the Semantic Web, as it is to SOA. As are ontologies. Ontologies are data models that describe concepts related to a domain, along with relationships that exist between those concepts.

Two specifications that are important in this space are the Resource Description Framework (RDF) and Web Ontology Language (OWL). RDF is an XML based language used to describe relationships. OWL is used to describe ontologies. However, in my opinion, both RDF and OWL are pretty complex and that is one of the reasons why adoption of the Semantic Web has been slow. To address these issues, people have come up with microformats. The idea is to embed meta-data directly into HTML and allow microformat aware browsers to deduce information about the concepts within a domain. For example, you might have come across the hCard microformat, that captures a person’s contact information (first name, last name, phone, etc) within XML tags. It is not as powerful as RDF or OWL, but it’s popularity lies in its simplicity. Having said that, there are a few drawbacks. Firstly, the onus is up to us to categorize data using the right format. Secondly, the number of existing microformats is nowhere close to capturing the myriad of different information that currently exists.

So we still have a long way to go before the world’s information is categorized and “Web 3.0” or whatever they call it then comes to life. But the promise of a semantic web is a very powerful concept and intriguing nonetheless.


December 31, 2007 at 12:41 am 1 comment

Understanding the CIO/VP of Technology

As part of my job, I routinely meet with people holding the title of CIO and/or VP of Technology to discuss business and technology strategy. I strongly feel that in order for me to do my job and deliver on the needs of my customer, I need to understand the role of my customer, what drives them, what keeps them up at night and what will make them successful. For me, it is not enough to know their business. I need to know their vision, their needs and their drivers in addition to sharing their domain knowledge.

A CIO is a complex position to be in, to say the least. A typical CIO has 2 tasks, one that is thankless, and one that is high risk. Geez! Can it get any better? 🙂 The thankless task is keeping the lights on. The high risk is developing and evolving the technology strategy in tandem with the business and in the area of innovation. Although many CIOs struggle with the former and that alone keeps them busy, the astute CIO realizes that their real value to the company lies in the latter.

In order for service providers like Patni to deliver, we need to better understand the challenges faced by our customers so that we become more than just merely an outsourcing vendor, but a true business partner focused on increasing our customer’s wallet share rather than just our own and helping them achieve success. In upcoming blogs, this section will outline some of the challenges and areas of focus for CIOs and how CIOs can harness IT to drive business strategy, institute portfolio management to get a deeper understanding of IT ROI, develop an IT performance management strategy and an IT outsourcing strategy and derive key metrics to measure IT performance and prove that IT is more than a cost center.

December 29, 2007 at 5:58 pm Leave a comment

We need “5 nines”

In the course of architecting systems for different verticals (health care, automotive, financial services, etc), my discussions with the customer eventually gets to availability and the customer’s expectations of how much downtime is permissible. The demand from the customer usually always starts off with “100% uptime”. That’s before they realize the cost of absolutely no downtime and that’s about when they start exploring the possibility of “the nines” (99.999 or 5 nines, or in some cases 99.9999 or 6 nines). The truth is that no system can hardly ever be up all the time every time. The cost is too prohibitive and the liability for the vendor is too high. What is usually negotiated is the hours of the day that 100% uptime is needed. This is usually very doable as long as those time frames are clearly defined. Consider a brokerage that does all it’s business between 9:30AM and 4PM. During those hours, it absolutely needs 100% uptime, otherwise the loss to the business is huge. This is a defined time frame that can be achieved with proper practices in place.

Most system vendors will market their “5 nines” or “6 nines” of availability. However, I try and make my customers aware of other important factors that they need to take into account when signing contracts. All downtime is not created equal. The consequence of downtime is very important. If my customers are driven away as a result of the downtime vs. the downtime just causing a minor inconvenience, those are two very different scenarios. Is the downtime spread out over days or does it all happen at once?

So what exactly is downtime? Definitions vary – some say that it’s when component in the chain is not functioning, others says they are experiencing downtime when the network is slow. In my mind, you are experiencing downtime when the system prevents you from getting your work done on time. What causes downtime? It could be different things:

  • human error
  • natural disasters
  • network issues
  • hardware issues
  • software issues
  • viruses
  • etc

So when people talk of 5 nines or 6 nines, what exactly does that mean. If you do the math, you’ll realize that achieving 6 nines (99.9999) means having 0.6 seconds of downtime a week (or 31.5 seconds a year!). This is very hard to achieve and quite often an unrealistic goal. To achieve a high degree of reliability and availability means looking at each link in your chain and strengthening the weak links and improving the strong links, because, at the end of the day, it takes just one weak link to bring down your system. So if you think about it, what are the links in your chain that need attention? The answer is everything from start to finish:

  • hardware
  • software
  • networks
  • file servers
  • printers
  • databases
  • applications – crashes, hangs, bugs
  • web servers
  • application servers
  • security
  • backups

As you can see, designing a system with an eye towards minimum downtime is not an easy task. A lot of practices come into play – clustering, load balancing, RAID disks, SANs, NAS, virtualization, redundant networks,  virus protection, proper documentation, application design geared towards monitoring and self healing, server farms and much more. In subsequent posts, we’ll explore some of these in greater detail.

December 29, 2007 at 5:15 pm Leave a comment

Web 2.0 – Intro

Bruce Lee once said:

“Knowing is not enough, we must apply.
Willing is not enough, we must do.”

I personally try and live by those statements as I think that it really hits the mark in both personal and professional lives of people…and if you look around you in the IT world, it seems that people are applying that statement as well.

At first, there was the days of mainframes. We then evolved to client-server programming, which has now evolved to service oriented applications. SOA has been the biggest buzzword in the past 3 years and it’s advantages are well talked about. Everyone knows that by developing loosely coupled services you increase re-usability and enable better integration amongst disparate systems, thereby allowing for increased data sharing. But as our friend Mr. Lee said, knowing that is not enough…show me the application of that concept.

Well Mr. Lee, the application is Web 2.0.

For those of you that might have heard of Web 2.0, but not really spent a whole lot of time bothering to find out what it is all about, in a nutshell, it’s about a new generation of web applications that:

– provide a more desktop like user experience (no long synchronous request/response cycles that involve page reloads)
– provide users with a collaboration type experience, where they can share and use data with/from other users
– in many instances, give users control over their own data, so that they can use it the way that they see fit

Why Web 2.0? Think of it this way – the web has been around now for a number of years, and if you are used to the request/response style usage of the web, then these new applications will provide you with a different experience – where you will hardly have to wait for page refreshes and will, in many cases, be able to leverage not only your own data, but that from others to enhance your user experience. This new experience has been tagged with a new version – 2.0.

Having said that, I must add the disclaimer that this is my take on Web 2.0. Others will tell you their own version which might vary slightly from mine, and the prevailing truth is that there is no standard definition for Web 2.0.

Almost all Web 2.0 apps make use of AJAX at some level, with many making use of AJAX heavily to provide that desktop like user experience. Look around you on Google and you will see just how many Web 2.0 apps are coming out every week. Some good examples of such apps are Google Maps,, flickr and Writely. Rest assured that there are very many bad apps out there as well.

But that is not the point. The point is that there are many creative minds out there that are applying what they know – that SOA is slowly, but surely, leading to breaking down of information silos and allowing these minds to develop apps that leverage existing apps and services to “mash together” apps that are presenting information to users from disparate sources in a unified fashion. In other words, they are trying to make SOA’s goals a reality, and we are at the very early stages, but it’s a good start.

Vendors like Amazon and Yahoo are making APIs for their services available to the people and the people are using these APIs to transform the idea of reuse and information sharing into a reality with Web 2.0.

Also, in my opinion, AJAX is hard to code in. There are some major drawbacks with using AJAX, and not just on the browser side (no bookmarking, etc) but more to do with AJAX programming itself (due the limitations in OO in JavaScript). JavaScript 2.0 is in the works and is getting a lot press because of the popularity of AJAX. What do you think of JavaScript 2.0? Will it become a reality? If so, what does it mean for us and the developer community?

Until next time…

December 29, 2007 at 5:58 am Leave a comment

The 4 Pillars of SOA

I thought that I’d start my first technical post on a buzzword that has already been overused (and abused) quite a bit – SOA. Many books have been written about SOA and this post is not about going deep into SOA, but more so, an introduction into what SOA is at a very high level. Over the next few posts, I will get deeper into SOA, what it entails, what the best practices are, how companies can build out a road map to get started on their SOA journey, why governance is important and much more.

SOA stands for Service Oriented Architecture. Over the years, there has been a transition from mainframes to client server to the web. As a result, many companies have a hodge podge of applications, technologies and infrastructure in their IT environment. Disparate languages (COBOL, Java, Perl, .NET, etc), different platforms (Microsoft, Linux, IBM, etc) and different databases and data sources (EDI, flat files, XML, relational, object oriented, etc) means that often one application cannot talk to and access data from other applications within a company. Customer data might be spread out over 2 or 3 data sources. Business processes exist only on paper and hence there is no automation. Multiple applications need to be accessed to gain insight into customer information. Business logic is strewn all across the place, making it hard to keep track of and maintain duplicate logic. The business folks keep churning out new requirements while the technical folks can’t keep up with the requests and instead keep building non-reusable, highly monolithic applications that take up time, energy and money and produce little in terms of future benefits to the business. The list goes on…

SOA is an architectural approach that tackles these problems head on, aimed at breaking down these siloed applications and data sources and creating the potential to share processes, logic and data amongst applications within and outside the corporate walls. At it’s very core, it is concerned with building services out of existing and new applications such that they can be composed together to quickly build newer applications. This should result in a more adaptive business, shorter development cycles, more maintainable code, faster time to market, centralized business logic that is easier to debug and test, etc.

When people think of SOA, they think of web services – how to build them, how to test them, deploy them and monitor them. But that is only but a part of the bigger SOA picture. When companies think of embarking on SOA, they need to approach it from a much broader perspective, otherwise their SOA initiatives will fail (and a lot of them have). So what the are the areas that make up an SOA implementation? In my opinion, any SOA architect needs to tackle SOA from 4 angles. I call them my 4 pillars of SOA:

1) Architecture
This aspect deals with the “A” in SOA. What do we have in place? What can we harvest? Where are we today and where to do we need to be? How does the architecture reflect the business needs (this is very important because at the end of the day, you are not doing SOA because it’s cool – you are doing it to make your business more agile), what are the gaps in the current and future state and how do we bridge that gap? What standards and protocols should be leveraged to build open, extensible systems? What are the entry points into SOA and where/how do you start? These are the issues that need to be addressed as part of an overall SOA strategy.

2) Infrastructure
So you want to build services to get your applications talking. But in order for your architecture to be robust and scalable, you need the right infrastructure in place. By infrastructure, I mean things like an Enterprise Service Bus (ESB) to mediate message formats and protocols, a portal to tie in disparate web applications, a repository to house your reusable assets, a registry to enable users to discover your assets at runtime, security infrastructure, monitoring infrastructure to manage service level agreements (SLAs), virtualization infrastructure, etc. Without infrastructure, you’ll soon go from a hodge podge of siloed applications to a hodge podge of services developed by different teams without appropriate documentation on who has developed what, what’s available for reuse, which projects are consuming what, how much ROI are you getting from SOA, and a whole slew of other problems. This is not to imply that everything needs to be in place right away, but it is important to note the need for infrastructure and to have an incremental roadmap in place to ramp up on infrastructure gradually.

3) Service Engineering
Many consulting companies say that they do SOA. They might have accidentally done SOA for their customers in the past by building out a few web services for them and touting that as their foray into SOA. However, that is far from being experienced in SOA. As I mentioned earlier, SOA is not just web services. But being able to servicize assets is core to SOA and building out services willy nilly is a recipe for disaster. Service Engineering is a well planned and thought out framework that lays out in great detail how to go about analyzing assets to harvest services, how to identify ideal candidates that can be servicized (service portfolio planning), release planning, how to build these services, how to test them, how to deploy them, monitor and manage them. Think of service engineering as start to finish best practices for planning out your service portfolio.

4) Governance
Another overused word in the world of SOA. Hopefully, you can see from this post that SOA is more than just about web services. I have worked on many complex SOA projects with customers and from those experiences, I can tell you that it takes more than just service implementation for a SOA project to succeed. From the onset, a customer needs to be made aware of the costs of doing a SOA project. Proper teams need to be in place to manage SOA architecture and infrastructure decisions. Policies need to be created and enacted, both at the enterprise, project and service level to track progress and monitor metrics. All this is dealt with using proper governance frameworks. Governance means different things to different people – to a developer it means conforming to project requirements and guidelines set forth by the architect and reusing components that already exist. To an architect it means ensuring that developers are complying to development standards, leveraging reusable assets, tying services to policies, etc. To a business person, it means something different – they are more concerned with SLAs and making sure that IT is delivering what it promised. So IT governance frameworks such as ITIL, and more specifically, SOA governance frameworks need to be put in place to make SOA a success. But make no mistake, governance takes a lot of work and that is why a lot of companies shy away from it. The trick is to not jump neck deep into governance, but as with SOA, do it piece meal – do what is relevant today and leave room to grow into tomorrow’s requirements…but start SOA with governance, instead of making it an afterthought.

This hopefully gives you some insight into SOA and what it entails. The message here is not that you need all this in place right away before starting on your SOA journey, but that along the way, these 4 areas need equal amounts of attention if your SOA projects are to be deemed successful. In subsequent posts, I will dig deeper into these areas, along with best practices, roadmaps, etc.

December 29, 2007 at 3:15 am Leave a comment

New to Patni

I recently joined Patni Computers as Sr. Director of Solutions. One of the main reasons I took the job was because the position offers me an exciting blend of technology and business – not only do I get to shape the technology strategy by creating and marketing the service offerings around key emerging technologies such as SaaS, Open Source, Web 2.0, Virtualization, etc, I also get the chance to be involved with running the ISV business unit – creating off-shore teams, participating in the procurement, training and mentoring efforts, identifying key customers to go after to grow revenues, working cohesively with sales and pre-sales to formulate strategies and help with sales cycles, initiate marketing efforts such public speaking, publishing articles and much more. In addition, I get to work in new verticals such as ISVs, medical devices and health care, consumer electronics and others which will be a nice addition to my background in financial services, retail and automotive.

Coming from a hard core technology consulting background, this will be a welcome change and I look forward to taking on a more business focused, yet highly technical role. I will use this blog to share my thoughts with you on both technology and business related issues. Each topic that I write about will start off at a high level introduction and in subsequent topics, I’ll drill down to the details, best practices, etc.

To learn more about my background, please click here.

December 29, 2007 at 1:35 am Leave a comment

Add to Technorati Favorites
December 2007
    Jan »

Recent Posts