Services – latoga labs

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?

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…

How Much Infrastructure is To Much Infrastructure

SOA: Step 1 Isn’t Technology