Uncategorized – Page 5

How Much Infrastructure is To Much Infrastructure

November 19, 2006 Leave a Comment

Lately, I have been doing some advising for a friend of mine on a new technology business. They are in the early stages of building out a new SaaS offering and they are planning out their technology infrastructure. The discussions that we have been having would be all to familiar to those of us who sold through the “bubble years”. How big do you plan your infrastructure?

The enthusiastic ones talk about the thousands upon thousands of possible customers and millions of visitors per day (at least that part is different from the bubble…back then it was millions of customers and 100’s of Millions of visitors…at least I was fortunate enough to work with a couple of the companies who actually did that type of volume). The cautious ones talk about minimizing the number of moving parts and not make it too complicated. The pragmatic ones (I consider myself part of this group) try to strike a balance between the two.

During the bubble you needed to spend literally millions on infrastructure to run an Internet company. Today, open source packages enable you to do this for close to nothing. You can build out a very robust, flexible, and scalable infrastructure based on open source (can you say Google?). But the question still exist, how much do you need and at what point.

The specific question comes down to a single source for user information (most specifically their authentication) for the customers and visitors to the web based service. One thought is to implement an LDAP system right away for future grown and flexibility. Another thought is to just build it into the web site.

For the record, I’m part of the LDAP camp. I think it will provide the flexibility of a single source of truth for users right now and is standard enough that most open source packages can hook into it for authentication. The plan includes adding multiple services that are either free or for charge, and a users set of services could belong to both groups. The thought of trying to synchronize user authentication information between multiple systems across each service just adds too much complexity.

If anyone has any opinions to share on this topic, I look forward to hearing them. How are others out there implementing their infrastructure for similar situations?

SOA: Step 1 Isn’t Technology

October 28, 2006 Leave a Comment

For the past few months, I have been working with two well know Financial Services firms around “SOA” initiatives. I put quotes around SOA because different terms describing services are used in each firm for various reasons (usually politically in nature). At the core, each firm is looking at how to use services to facilitate greater levels of reuse within their development organizations. One interesting fact to note is each firm’s primary driver: one is doing this to reduce the rate of increase in IT spend, the other is hoping to increase the velocity of their application development cycles (shorten the cycles to get products out faster).

One of the most interesting aspects that has come out of this work is the acute awareness of the social aspects of SOA and how important that is for the success of any initiative. (Steve Vinoski has written a wonderful article about the Social Side of Services).

Firm A has invested considerably in socializing the concepts of SOA and reuse through out their organization (up to the highest levels of management). They have a very clear plan on how to implement services across their organization; understanding of new positions that will need to be added to ensure services succeed; functional technical areas that will need to be addressed to enable services; mechanisms to measure the amount of reuse in order to track their progress; programs to educate the developers on services and reuse. All this work was done by the Office of the CTO and took time and effort to put in place, but Firm A realized the need for this and made this investment.

Firm B decided over a year ago that they needed to do SOA based on all the hype in the market place. This decision was made by the business side of the house versus the technology side. Services were soon showing up in project requirements the business side was sending over to the IT Development groups. There was no real centralized planning or coordination with regards to services. Now IT is playing catchup and trying to make sense of all services currently out there. One of the big problems they have is that most of the services that are available are not really reusable by most others, just services internal functionally from applications.

Doing a postmortem on Firm B’s services, you see a number of number of mis-steps that has been taken with their SOA initiative. One issue is the fact that the business side of the house needs to provide functional requirements, not technical requirements. A second, more important, issues is that fact that Firm B totally ignored the social side of SOA…they never took into account the political, organization, and cultural changes that need to be implemented to make SOA really work for them. They never did an analysis of how services could benefit their application environment.

While on paper Firm B has been doing SOA much long than Firm A, Firm A will see value from SOA much sooner than FirmB. In this case, a little investment will go a long way for Firm A.

It’s still amazes me how much technology development or implementation (even at large companies) occurs without taking into consider the social impact of the technology. Even when it’s the social impact of technology on techies (i.e., developers or managers of technology).

I’m curious to hear from others with regards to the social techniques in use within their organizations when it comes to SOA or technology in general…

Project Blackbox: Great Name, Bad Color…

October 17, 2006 Leave a Comment

I just happened to surf over to the Sun website today and ran across Proejct Blackbox. a quote from the website: “Project Blackbox is a prototype of the world’s first virtualized data center–built into a shipping container and optimized to deliver extreme energy, space, and performance efficiencies.”

I didn’t spend more than 10 seconds thinking about this before I thought…that doesn’t make sense. The whole concept of a ‘portable’ data center for quick capacity addition make sense. Take a shipping container, insert a cooling system, power system (with one huge plug!), and 1U servers and presto…instant portable mini-data center.

The problem…why in the world would you paint the thing black? (I’ll get to the logos in a bit)

Let me see if I remember back to my high school physics courses….black absorbs light, white reflects it….got it. Big steel container with hot computers running inside of it. The container is designed to just be dropped off in the parking lot next to your data center…most likely in the direct sun. Let’s paint it black so it get even hotter and paint a big Sun Log on it so everyone knows what it is (psst: guys…ever wonder why most of your customer’s data centers don’t have big signs out front that says “XYZ Corp. Data Center”?)

This seems to be a great example of Marketing taking over a technology project and making bad decisions based on the need to add value (note: I have worked in marketing, and have great friends who are marketing wizards…). Let’s hope that common and business sense takes over for Sun on this project before this prototype goes into production.