Category Archives: architecture

Apache vs. IIS, round n

Posted on by

James Governor of Redmonk has an interesting analysis of the supposed decline of Apache in the latest Netcraft survey. Infoworld first reported the story, and their headline was “Microsoft’s IIS may catch Apache in Web server market.” The lede is no less provocative: “Microsoft’s Internet Information Services (IIS) continues to narrow the gap with the open source Apache Web server, with a survey firm suggesting that the longtime second banana could surpass Apache as early as next year.” (Matt Asay calls it “The unthinkable.”)

Governor and his friend go to the Netcraft data, though, and find that it’s really a reporting anomaly. Netcraft just began breaking out Google’s web server — which is probably of Apache ancestry in any event — in May, accounting for most of the drop in Apache’s market share. Check out that pink line in the lower right-hand corner:
Active web servers total

But wait, Governor says, that’s not all: while Apache may still rule in absolute numbers, Microsoft has long controlled the corporate market. Here‘s some less quantitative, more anecdotal information that points in that direction:

large company web servers

Based on my experience (and here’s a survey from Port 80 if that isn’t good enough), this rings true; this is just one among the many ways that enterprise computing is different from the rest of the world.

Enterprise identity strategy: 1. Establish core infrastructure

Posted on by

Strategy

Okay, so you’ve conducted some kind of identity strategy project to figure out what you want to do with an identity management system for your company. You have an overall idea of the sequencing of work, of the technical architecture, the business case, the goals and requirements, and the people who are going to be responsible to do the work.

Congratulations! Sit back, relax, have a homebrew.

Connect primary identity repositories

Next, assuming that it’s a company with thousands of employees, you’re going to be dealing with a lot of existing infrastructure so one of the first decisions you’re going to have to make is the sources of authority for the initial deployment. There probably are already multiple identity stores in your organization; the HR department, the file & print directory, the badging system, the PBX, and so forth. Technically, you need to figure out how to connect them (may I suggest Novell Identity Manager?), but you’re also going to have to make some business decisions about the ownership of the data and decide on authoritative sources.

For instance, I might have a phone number listed in the corporate PeopleSoft HR system and another one in the PBX. If we connect both of those to the identity infrastructure, which has precedence? If the number changes in the PBX, should that change propagate to the HR system? What is the business rule in that situation? You might say, “PBX,” which seems like the right answer, except that the Personnel department might not like the idea of giving up control of their records like that. So it bears saying and repeating and repeating: HR must be involved from the beginning of any successful enterprise identity project.

Of course, it would be especially nice if I followed my own damned advice; I’m working on a project right now for a mid-sized government agency that is struggling with HR issues precisely because they have not included HR representation from the beginning. So we now have to integrate not only the HR system, but a separate database that the department maintains of pending changes, contractors, and temporary employees. All of which can be handled, and gracefully, by PeopleSoft, if only we had the HR department involved.

So maybe I should amend the rule to say: It makes things much easier to involve HR from the beginning of any successful enterprise identity project. We even have a white paper on this very topic.

Tip: A nice quick way to demonstrate success, always a problem with IT infrastructure projects, is to deploy a white pages applications. This is actually useful to end users and is relatively easy to do (YMMV) once you’ve got the core pieces in place.

Establish an Identity Vault

When we do these first phase deployments, we almost always set up an “identity vault” (IDV) as the centerpiece directory. The IDV is itself not authoritative, which is initially counter-intuitive. In fact, it ought not to hold any unique information at all but simply replicate information held elsewhere (such as, in the example earlier, a person’s telephone number from the PBX.) The connectors, in Novell’s architecture, hold the business rules about the flow of information in and out of the IDV. The IDV needs to be highly available but you don’t necessarily want to be hitting the IDV with a lot of requests, at least not directly. Instead, we usually build out “service directories” that are tailored for particular situations; they may vary by geography or application type and so forth. The service directories can be placed physically close to the users, to improve performance, and the service directories communicate back to the IDV.

Enterprise LAMP?

Posted on by

Linux continues its relentless march across the enterprise IT landscape; there are now few places in the corporate data center where Linux doesn’t make sense. And Linux has been the default choice for start-ups, especially SaaS start-ups, for a while now. Zack Urlocker illustrates the point with the example of iLike, a music sharing site (the kids are all into it), which scaled from 1m to 6m users in a few weeks on the back of a LAMP stack.

So what happened to ActiveGrid, which was supposed to bring LAMP to the enterprise? Peter Yared’s gone onto other things, and has this to say about LAMP’s supposed lack of penetration into the enterprise market. Essentially, he’s arguing that it’s Java’s fault; Java’s gotten easier to use and taken the wind out of the sails of the scripting languages (PHP, Perl, Python, etc.) in the LAMP stack. I don’t know that I buy that explanation — Linux and Apache seem to be doing quite well, thank you, and I haven’t heard any complaints from MySQL either — but it explains, I suppose, ActiveGrid’s shift in focus to Java.

Enterprise identity strategy

Posted on by

What are the components of an enterprise identity strategy? What do I mean when I talk about ‘direction setting’ for identity management systems in corporate IT? Here are some of those components:

Current state assessment: where are we today? What are the IT systems that will impact the identity infrastructure? What are the requirements for the proposed system? I’m a big fan of simply writing these things down so that people can see them in black and white, because too often there is a shared fuzzy sense of what the proposed system will be doing. Lack of clarity around that shared fuzzy sense is a major risk factor for the success of any technology deployment, especially something as intricate as systems integration, which is what enterprise identity systems are. A good current state assessment looks at technology and business issues together and requires some kind of checkpoint to agree or disagree with the finding before proceeding.

Business process analysis will vary by the type of identity management system you’re implementing and the goals you’re trying to achieve. If you’re simply deploying a core infrastructure capability it might not be as important to do detailed process analysis. Putting in a employee provisioning system that handles not only full-time employees, but also contractors, part-timers, and so forth is going to require more business process documentation. And you have to look at whether you’re paving cow paths or trying to redesign workflows. If you’re not doing at least some process work you’re making a mistake.

Financial analysis: what are the quantifiable benefits of doing the work, what are the costs, and where is the payback? If strategy is a set of allocation decisions, then financial analysis is one of the key tools to making good decisions. But it’s not always done; sometimes, companies are compelled by Sarbanes-Oxley audit findings to build out an identity infrastructure for authentication and authorization to key systems, for example, or they might want to simplify log-in for their employees (the holy grail of Single Sign On). In these cases, they might not bother doing financial analysis.

In general, the bigger the company, the easier it is to justify infrastructure elements such as identity management. But the thing to look out for in any technology business case is the underlying analysis; can you compare this case to another case outside of the IT department? Can a financial analyst without any knowledge of the technology compare the identity management business case to, say, a business case for investment in new machinery or an investment in a growth area of their business? Project finance is a known good, although too rarely known in IT.

Prioritization: For me, this is the core of doing IT strategy and it lends itself especially well to identity strategy which requires Big Design Up Front. Prioritization is simply the process of creating criteria and evaluating options (you can call them initiatives or opportunities or recommendations or whatever) based on those criteria. In its most rigorous form, the criteria are largely financial with technical constraints but in practice they are always a blend of complexity vs. payback vs. political realities. Well-run prioritization sessions, with the proper assessment and buy-in from the people making the decisions, are a lot of fun. It’s where the rubber hits the road.

Technical architecture: typically, we design an identity vault as the centerpiece of an enterprise identity system. This vault draws on authoratitive source systems (e.g., HR, PBX, physical badging, email, file & print, etc.) for user attributes and then delivers these via service directories to consuming applications. But building out this system, and all the interconnections, is complex and requires involvement from both technical and business perspectives — especially the HR department.

Governance: I hope to write more about this in another post but suffice to say that you need to figure out the policies and procedures for managing your identity infrastructure, including the organization that’s going to do the work. This is far too often overlooked.

Roadmap: I think it’s absolutely required to have a plan of where you’re planning to go in phases or milestones or tracks or whatever. At a high level, the plan needs to communicate to the business and technical leadership what the timings and outcomes are going to be. At a more detailed level, you also need to have, consistent with the high level view, some kind of detailed work plan with resources and specific activities and milestones. The point is not to have an inviolable document that everyone slavishly follows; rather, you need to have a central point of coordination so that work proceeds in the right direction. The plan is going to change over time. To be fancy, it’s an emergent strategy. Or, as Eisenhower supposedly said, “Planning is everything. Plans are worthless.”

It’s important to recognize the level at which identity strategy ought to take place. It’s not at the level of designing requirements for a directory. That is too detailed, although that will certainly be one of the elements on the roadmap. And it’s not at the level of designing architectural first principles (security is valued more highly than cost, but cost more highly than agility, say); that is too abstract.

Instead, identity strategy ought to evaluate options at the project level. Recommendations should describe a series of activities each at the level of a discrete project, each with goals and milestones and project owners. The roadmap sequences these into a precedence of execution based on the requirements and the technical architecture and the business case and all the rest.

Rich Internet Applications

Posted on by

Microsoft’s “Silverlight” announcement a few days ago has gotten a lot of positive early attention (see here and here and especially here for examples) and focused attention on the category of Rich Internet Applications. The Mono folks have announced that they’re going to do a Linux version, tentatively codenamed “Moonlight.” OpenLazlo, a pioneer RIA, has been discussed as a Google acquisition target, if AJAX and the persistence engine planned for Firefox 3.0 aren’t enough. And Silverlight, uh, overshadowed Adobe’s recent Flex announcement.

All the initial reports suggest that Microsoft, presumably under the watchful eye of Ray Ozzie, got this one right; it’s fast, small, beautiful, and reclaims space for Microsoft on the desktop. Can Office on Silverlight be far behind?

I’ve used the New York Times Reader (free trial, $15/mo., included with paper subscription) which is based on Silverlight and it is a great experience. You don’t need to be online to use it; in fact, it sort of blurs the distinction between being on and off line to the extent that you don’t really care so much. And it has rich controls for viewing, much better, because it’s customized for reading a newspaper, than a plain old browser, even with all the cool Javascript and prefetching tricks.

Lazlo claims some corporate customers, but from what I’ve seen Rich Internet Applications are in their infancy in the enterprise. Silverlight’s got an advantage there, of course, because of all the armies of VB and .Net developers who now have another tool at their disposal; it will be interesting to see what they build.