CQ2

I’ve recently moved into a new job at Novell, working on our strategy for worldwide services and planning for our next fiscal year is keeping me busy.  But I still, fortunately, deal with real clients and real problems too.  This one is classic: the client has several hundred old Unix and RHEL servers that they want to move to SLES.  Great!  We want to help.  So they negotiate the server deal and then want to know the cost to migrate.  How much is it going to cost, in total, to go from what they have today to what they want tomorrow?  They ask for estimates on a per-server basis; how many hours would it take to migrate a Solaris server to SLES?  Ten hours?  A thousand hours?  So they bring in the consultants, the dreaded consultants.  They’ve tried to avoid slowing down the deal but there’s no avoiding it now.

Well, you’ve done this before, they say, you’re grizzled veterans of the data center; is it two or ten hours for a server?  And the consultant — and I’ve been in this situation, believe me, it sucks — has to say, “Well, it depends.  It could be a thousand hours.”  Which is what everyone is expecting him to say because you can’t get a straight answer out of a consultant.  They’re always going to tell you “it depends.”  Right.

And even if there is all the time in the world, this particular answer needs to be in writing on the buyer’s desk by EOD today or the sales guy isn’t going to make his number for the quarter which means that he’s not going to make ‘club’ (his incentive travel event), which his wife is really looking forward to, so this damned consultant is not only not answering a simple, reasonable question from the beloved customer but they are also very directly making his wife mad at him, with the attendant consequences.

Perhaps you think I joke?  Or exaggerate?

Making matters worse, some nerd named Chad has downloaded OpenSUSE onto a machine in their testing lab and moved a couple of apps without incident (some directory changes, a few lines of code) and based on that experience has estimated that moving the three hundred servers will take approximately an hour each.  Seriously: we have clients who want us to tell them that moving unknown production workloads from one operating system to another will take less than two hours per server.

So the consultant sighs and starts to ask questions: What do the workloads on these servers actually do?  Online banking is different from warehouse management.  What platforms are they running?  (What version of J2EE?  What version of RHEL?  What version of Manugistics?)  Are they going to change anything else besides the operating system when they do this move?  Is the software custom or off-the-shelf?  What’s it written in?  If they say something like current Java apps running on a 2.6 kernel going to the same JVM on another distribution, that would be one thing.  If you are looking at non-ANSI C custom code on RHEL 3 on a complex multi-tiered app, that’s something else.  (Moving from the 2.4 kernel to the 2.6 kernel on any distribution is much harder than moving from one current distribution to another.)  What about storage, and backup, and disaster recovery?  Systems management?  There are a thousand more architectural details that you need to understand (one data center or many?  resource utilization?) but everyone is getting impatient with you and your endless questions.

Then you start getting into the enterprise-y aspects, which is where the real time and cost come in.  There’s a difference between Chad moving an app from one platform to another as a technical exercise and the actual time that it takes production applications to go from one to another.  What’s the testing regime?  I would expect that production code moving from one distribution to another would require real testing (stress/performance, UAT, etc.).  Would you include that in the estimate?  What about security?  Does the new OS have to go through a security audit at the company?  (Answer: yes, and it’s going to take a long time for the online banking app, believe me.)  Documentation?

This is all super-boring and bureaucratic and definitely not technical so the nerds aren’t interested and think it’s worthless and the sales guy is hearing his wife screaming at him and the buyer is saying, “Why is this so complicated?”

So, should we skip the backup part?

Really, the way to do this kind of thing is to do a quick assessment and figure out some kind of prioritization and rough sequencing, but that would require the client to spend time and money helping you to figure out how much to charge them and they are naturally leery of such a thing.  You desperately want to avoid getting locked into a fixed figure because you still have no real idea how complex the problem your being asked to solve is, but that is what the client and the others are asking for.

So you end up with a fudge; you commit to moving some edge servers and a cluster of supposedly simple apps and you sign up to do a security-approved core build and an assessment for the rest so that the project can get started and the customer can show progress to their boss and the sales guy can make his number.

Now you’re faced with months in the lab at the client site with Chad explaining to you how completely screwed up their environment is and how there’s no way that he’s going to give up his Solaris servers and anyway they’ve tried to do this themselves a bunch of times already and it never works because it’s not really a current release of Manugistics and they did some customization that they probably shouldn’t have…

Michael Nygard has his head in the computing clouds, suggesting that not only is cloud computing in our future, but that there’ll be many of them. He’s right.

Everyone who runs a large data center is today faced with the same set of interconnected environmental problems; space, power, and heating/cooling. And these are environmental not just in the sense of tree-hugging but also in a straightforward practical sense: there is no more space, there is no more power, there is too much heat and not enough cooling. These problems were the domain of junior people a few years ago, worrying about where, physically, to locate all the new Windows boxes. Then it was middle managers trying to sort out power and HVAC issues: “If we deploy a new phone system in our building we won’t have enough power to do any upgrades in the data center,” that sort of thing. Now environmental issues are front-and-center for senior IT management and if you’re a “red-shift” kind of company, for senior corporate leadership too.

You can cloak it if you want to in green terms but businesses are faced with real operational issues that they need to address regardless of their perspective on global warming or riverine dolphins.

Alongside these environmental issues, data centers are also facing a crisis of manageability. A large enterprise data center is a staggeringly complex thing, too complicated. Also, if the truth be told, most of them are not that well run; would you expect, for example, that an auto parts distributor would have great technology management skills? No, of course not, and the fact is that they probably wouldn’t want to spend the money to acquire that talent and technology even in they could; their differentiation, the competitive advantage of their business, lies elsewhere. So they have a complicated, and sub-optimized, technology infrastructure.

The answer to all of these problems — Monday edition — supposedly lies in virtualization. Novell gets brought into these conversations because inevitably data center managers have a roadmap that looks something like this:

(more…)

At Brainshare, Novell’s annual user conference in Salt Lake City, our CTO, Jeff Jaffe, announced a new technology vision, code-named “Project Fossa,” [pdf] intended to enable computing and collaborating with agility. The fossa is a cat-like mammal from Madagascar, sort of related to raccoons, weasels, and palm civits. (Fossas may be viverrids like civits or the falanouc, another Madagascar endemic; the taxonomy seems to be contested.) Fossas are supposed to be very agile, and if you have little kids you know them as the villains in the animated movie Madagascar. The project’s name is also a play on Free and Open Source Software (FOSS).

Here’s some press coverage including the priceless hed “Novell focuses future strategy around endangered mongoose” from the UK edition of ZDNet.

A year ago now, I wrote:

For the Indology nerds: there are a set of clay tablets at the Guimet, I think on the second floor, which have as their provenance a Buddhist monastery in Kashmir. The panels have raised images on them which are clearly not Buddhist. I suspect they’re Ajivika and I seem to remember an article, which of course I can’t track down now, describing how the Buddhists reused the materials from an Ajivika complex as the flooring in their monastery, as an insult. But I can’t pinpoint the source and it’s driving me nuts.

Since then, I figured out that they were from Harwan, a site outside of Srinigar, next to the Shalimar Gardens. But I still couldn’t find the article I was thinking of or, really, any good information on the deeply enigmatic tablets.

This past fall, the Asia Society in New York sponsored an exhibit entitled The Arts of Kashmir, which — despite my best intentions — I never got to visit. (Here’s a review by the great New York Times Asian art critic Holland Cotter.) Consoled with the catalog to the exhibit by Pratapaditya Pal, I found some helpful references.

The beautiful catalog itself is much more substantial than a typical exhibit catalog — it’s really a collection of art historical survey articles about Kashmir, including architecture, sculpture, painting, calligraphy, and crafts.

The Harwan tiles appear in John Siudmak’s piece on religious architecture, which seems to summarize what we know about the site:

The earliest surviving Buddhist site is at Harwan, near the Mughal Shalimar Gardens, probably dating from the fifth century and of Hephthalite patronage, and mostly known for its terra-cotta tiles impressed with figural and floral designs used to decorate a large circular terrace on the hillside, which was destroyed by an earthquake. [...] Similar terraces have been found elsewhere in the valley; the most extensive at the site of Hutamura, in the Lidder valley. Their religious affiliation still remains a mystery. However, excavations of a rectangular courtyard in a lower terrace uncovered the triple basement of a stupa, a number of cells, and several terra-cotta figural fragments and three plaques impressed with stupa images (fig. 37.) [...] The stupas on the Harwan plaques compare closely with three Gandhara bronze examples, one also with columns at the corners, and confirm a Gandhara influence. (pp. 55-56)

So there are more of these sites, besides Harwan, although “their religious affiliation remains a mystery.” And nothing about the Ājīvikas. The second half of this redacted excerpt is on firmer ground, unraveling the Buddhist elements of the site; the complex symbolism of the stupa is a favorite topic of study and Siudmak’s comments helpfully locate early Kashmiri, presumably wooden, examples in the timeline between Greco-Bactrian Gandhara and later versions, especially Tibetan. (Tibetan and Central Asian religion and art is deeply indebted to Kashmir.) Note, by the way, that the tiles or plaques with clearly Buddhist stupa images are different — made differently and different in appearance and style — than the rest of the Harwan tiles.

But most interestingly to me is a footnote at the end of this excerpt, to a 1989 article by Fisher. Unfortunately, the scholarly apparatus of the catalog is shoddy and there’s no further reference to Fisher in the bibliography.

The curator of the exhibit, Pal, has a long useful essay (the metal sculpture section alone is fantastic) entitled “Faith and Form” in the catalog which also refers several times to the Harwan tiles:

The earliest sites that have yielded terra-cotta objects, which, according to tradition, go back to the Kushan period, are Semthan, Harwan, Hutmora, Ushkur, and recently Kutbal. These sites are particularly noteworthy because of the large, stamped tiles with figural and symbolic forms that represent an independent local artistic tradition. Although tiles for paving floors and walls of monasteries were used in Gandhara, they are not as richly and diversely decorated as those from Kashmir. The figures in the Harwan tiles further show both Indian and foreign ethnic types, strange crouching ascetics unique in the Indian plastic tradition and convincingly rendered flora and fauna. Both the Harwan and the Kutbal finds reflext a mature and confident state of artistic skill but, strangely, the tradition did not continue. There is no certainty about the exact dates of these sites, although the consensus is between the third and the fifth century. (p. 66)

So now we have a whole set of sites related to Harwan, including Siudmak’s afore-mentioned Hutamura — presumably the same as Pal’s “Hutmora” — plus Semthan, Ushkur, and Kutbal! Again, though, the scholarly apparatus of the catalog fails us, since the endnotes in this passage aren’t correctly referenced; #9 appears twice in the excerpt above and only once in the notes; the only usable reference (a pers. comm.) is to the recent Kutbal find. And still no Ājīvikas.

Even though I couldn’t get an exact citation, some heavy duty googling yielded reference to a 1982 article by a Robert E. Fisher in Art International, a now-defunct (I think) journal. For the record, it’s:

Fisher, Robert E. The enigma of Harwan, Art International, 1982, XXV(9)33-4

There may be a later, 1989, Harwan article by Fisher, too, as Siudmak suggests, but I haven’t been able to find it. (Fisher’s early 1980’s Ph.D. dissertation at USC was on the Buddhist architecture of Kashmir.)

I think that Fisher’s article, the one that I was looking for and finally tracked down, thanks to my wife and the wonders of inter-library loan, more or less definitively addresses the enigma of Harwan. Fisher proves — at least to my satisfaction — that the tiles are part of an Ājīvika religious site, later reused in a nearby Buddhist monastery. (Thus Siudmak’s reference to [monastic] cells adjoining the stupa.)

Fisher, although not cited in the 2007 Kashmir catalog, acknowledges Pal in his endnotes: “It was his belief that there is more to Harwan than has been published as well as his careful screening of my evidence that inspired this essay.”  And, although I haven’t yet had a chance to read it, Pal discusses (pp. 223-224) a tile in the LACMA collection, described as “Tile with Ajivaka (?) Ascetics” in vol. 1 of his Indian Sculpture (Los Angeles: Los Angeles County Museum of Art, University of California Press, 1986) book.

Alright, if you’re still with me, some quick background on our suspects:

We really don’t know much about the Ājīvikas, except from what we read about them from their successful rivals, including Buddhists and Jains. It’s a similar situation to, say, gnosticism in late antiquity in the eastern Mediterranean: most of what we knew, up until the Nag Hammadi finds, about gnosticism was hearsay, and the hearsay treated the tradition as heretical.

The founder of the Ājīvika tradition, Gosala, supposedly was a contemporary of Mahavira, the founder of Jainism and thus a near-contemporary of the Buddha and possibly from the same north-central region of India. (Fisher points to a 1951 book by A.L. Basham, History and Doctrine of the Ājīvikas, which I haven’t read yet. There’s also a workmanlike Wikipedia article.) They were famously ascetic, and one story that really left an impression in my mind was that they supposedly meditated (or committed slow suicide) inside of clay pots. This is such a disturbingly powerful idea that just thinking about it makes me start to physically panic. Whether or not this has any basis in reality, of course, is another matter, but Ājīvikas are closely associated with pots, pottery, and the like. Thus, as you might have guessed, all the clay tiles. And look again at the ascetic figures in the tiles; don’t they seem like they could be crouching in pots?

Fisher, citing Basham, notes that caves in Bihar, with Ājīvika inscriptions from the 3rd century BC, had three foot deep deposits of clay fragments in them when excavated by Alexander Cunningham in the 19th century. These caves, it’s important to note, had what Fisher calls “an unusual shape”:

apsidal in plan with a circular construction at the far end. If Buddhist, this arrangement would indicate the presence of a circular stupa. According to Basham, these caves may originally have been stone replicas of the earliest Ājīvika meeting-place, a circular thatched hut at the end of a courtyard. (p. 43)

If, like me, your vocabulary doesn’t include “apsidal,” Wikipedia comes to the rescue. It’s a form of “apse“:

In architecture, the apse (Latin absis “arch, vault”; sometimes written apsis; plural apses) is a semicircular recess covered with a hemispherical vault. In Romanesque, Byzantine and Gothic Christian abbey, cathedral and church architecture, the term is applied to the semi-circular or polygonal section of the sanctuary at the liturgical east end beyond the altar. Geometrically speaking, an apse is either a half-cone or half-dome.

And, you may have guessed correctly already, that is the same plan as the Harwan site.

Furthermore, other images — especially flowers, elephants, and swans –common in the tiles have Ājīvika associations, based on our very limited knowledge of their beliefs.

In his article, Fisher goes to great lengths to disprove other associations: that Harwan is not exclusively Buddhist, that the images have connections to but are different than other traditions, and so on. So he surveys Hindu and Buddhist images for ascetics, and crouching figures, and floor tiles, and looks at Parthian evidence for the horse rider images and the potential architectural connections between Parthain fire temples and the Harwan site. But he concludes this section with the following comment (p. 39):

Amidst all these images, be they foreign or Indian, one stands apart with compelling force. The repeated portrayal of a crouching ascetic forms a dramatic border to the variety of lively forms of the floor and provides the most enigmatic problem for the entire site.

And this, to me, is the central issue; a really enigmatic problem. These figures look like nothing else: in Pal’s words, the “strange crouching ascetics [are] unique in the Indian plastic tradition.” I can still remember the surprise I felt seeing the tiles at the Guimet, how odd and otherworldly they seemed.

I think that Fisher’s solution, the Ājīvika attribution, is a brilliant contribution, one that’s unfortunately not been widely accepted. (This, I suspect, is due to issues of distribution not disagreement.) If we add in the comments from the Kashmir catalog that Harwan is one in a set of similar finds, including Hutamura/Hutmora, Semthan, Ushkur, and the supposedly spectacular Kutbal site, we have suggestive evidence for a large Kashmiri Ājīvika movement in the early centuries of our era, ca. 300 - 500 C.E..

Via BoingBoing, fascinating photos of Burma’s new capital from, literally, the first tourists there. It seems to me from these pictures that the government wanted a new city that was more like Singapore or southern California and less like, well, Burma.

Check out these houses:

Note that each of them has a garage – in a country that is essentially without roads. Garages make sense (well, as far as it goes) in Orange County but not so much in a country like Burma. The oddness of these houses in that context cannot be overstated.

My guess is that these houses are inspired by similar-looking developments in suburban Bangkok or perhaps Singapore or Shanghai.  Those housing developments — in their overall master plan and in the particulars of the architecture — in turn draw directly on American suburban housing, especially in southern California. All of that seems reasonable to me: Burmese generals visit Bangkok and see new housing developments which are influenced by Thais returning from, say, Irvine. As much as Burma has any contact with the outside world, it’s with Bangkok and Singapore.

The southern California gated community with attached housing, in turn, draws directly on the experience of the mass-produced single family houses of the new suburbias created after World War II for returning veterans and their growing families: Levittown and all that. These communities, in an oft-told tale (see, among others, Anthony King’s history, The Bungalow) mass-produced the idealized American house, derived from the popular craftsman bungalow style of the turn of the century. This style was influenced by the British arts & crafts movement — itself a response to industrialization — and the houses, which they called bungalows, built by returning colonial administrators, especially from India.

In India, these colonists lived in grand houses called “bungalows,” a word whose etymology is disputed but probably derives from Gujarati via the Hindi for “Bengali” (”bangla” thus “Bangladesh”, “land of the Bengalis”) since Calcutta was where the British first built their private houses.

Thus, I think you can draw a line, not too straight, but a connection nonetheless, from these bizarre new Burmese houses to neighboring Bangladesh, via Bangkok and Irvine Ranch and Long Island and Surrey and Simla.

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:

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:

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.

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.

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.

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.

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.