Moved to New Blog

I have begun blogging at a new group blog at Digital Business Strategy. I have moved most of the content from this blog over there, and am closing up shop here.

The Various Definitions of "Role"

I've been spending a lot of time lately on RBAC, specifically the technology-independent processes required to engineer and administer roles. As such, I was interested in a newsletter (not yet available online) by Dave Kearns pointing to a new RBAC glossary developed by the Modini-IDM Project in the EU. Here is their definition of a "role":

A role is a set of one or more authorisations related to a specific application or service.

I find this definition very interesting, since it echoes the operating definition we in Novell Consulting have been using for roles:

A set of permissions used to fulfill all or part of a job function.

Now there are some differences between these definitions, most notably an emphasis on "a specific application or service" versus "a job function". In this respect, I'll stick with our definition, since it provides a connection to the business, not just the technology. A definition of role that is so narrow that it obscures its ultimate purpose seems to be self-defeating.

But these definitions agree that a role is just a set of permissions. This is very different from the HR view of a role, which is defined by Merriam Webster as:

a function or part performed especially in a particular operation or process

This is why HR and the identity community are not communicating when we talk to each other about roles. Bridgestream even proposes making a distinction between "IT roles" and "business roles" to clarify this confusion. Some colleagues have argued that we should use some term other than "role", since we're talking about two different things.

But I think this approach is misguided, since HR and identity folks are talking about the same thing when we speak of roles, but are just approaching it from different places. Let's reword the HR definition of a role a bit:

a set of responsibilities required to perform a function or part in a particular operation or process

Of course each responsibility carries with it a required set of permissions, so this is virtually identical to our definition above.

For roles to be defined appropriately in the RBAC context, they must be the minimal set of roles, with a minimal set of permissions and memberships in each role, that still meet the needs of actors in the business processes. This will lead inexorably, I would argue, to a robust definition of roles for the HR context.

This doesn't mean that we have to get completely in synch with HR's set of defined roles before we implement RBAC. Sometimes this is an organizational, communications and political obstacle that it doesn't make sense to tackle up front, if ever. But let's not pretend that our roles are different things than their roles, or define our use of the word "role" so as to seem to be a completely different thing than what the rest of the business world means by "role".

Nicholas Carr: The End of Corporate Computing

Nicholas Carr, author of the much-contested article "IT Doesn't Matter", has written a new, equally debatable article titled "The End of Corporate Computing". In it, Carr shows the same blind spot demonstrated in his previous work by arguing that the corporate data center will be replaced entirely by utility computing providers delivering apps over the web.

Carr uses the analogy of the electric generating industry in the early 20th century. Companies initially were forced to run their own generating plant, but these were gradually replaced by centralized electric generating utilities. This centralization required the construction of the electric grid to distribute electricity, analogous to the internet of today.

But this is a poor analogy for two reasons. First, there are huge economies of scale for the generation of electricity, but these don't exist for the operation of a corporate data center. There are very few fixed costs to running a server farm. The servers themselves can be scaled in fairly small increments, unlike new electrical generators. Generators are designed to last many decades, while servers are often replaced in five years. The analogy doesn't work.

Carr talks about the low utilization rates of servers today to demonstrate the over-investment in computing capacity in corporate data centers. He later talks about virtualization as a driver towards utility computing. But virtualization will solve the problem of low server utilization without having to outsource the data center.

The second problem with Carr's analogy is his implication that applications are a commodity. The actual computing cycles are certainly a commodity, but that isn't where most of the costs, and the value-add, of corporate IT lies. The hard part is planning for, acquiring, implementing and integrating application software to support the business. There is no differentiation in computing cycles, but every corporate application layer is not only differentiated, but typically unique and a source of competitive advantage or disadvantage.

Utility computing delivered over the internet will certainly become more prevalent, just not in the way Carr envisions. The utility computing model will grow not because computing is a commodity, but because the corporate application layer will be most effectively assembled from multiple best-of-breed software services. Corporate data centers may find it useful to run some of their own servers and host their own databases, or not, as they see fit. But they will still have to plan for, acquire, implement and integrate application software into their business. This will be easier to do by subscribing to web services delivered over the web, and the application layer will be more flexible when it consists of remote web services. The business driver for this trend won't be data center economies of scale, but the flexibility and speed with which applications can be upgraded and integrated. Unfortunately, Carr has missed the boat once again.

Linux 40% cheaper than Windows, claims IBM

From Computerworld:

Linux's total cost of operation (TCO) is typically 40% lower than Windows, according to an IBM-sponsored report from Robert Frances Group, publicized by IBM this week.

[...]

Linux still may be cheaper than Solaris or Windows, but the study agreed with Unilever that the price difference is not what it once was. This is partly because Linux buyers are now treating the platform like any other commercial product, and are buying the same support offerings, management tools and other facilities as they would for another operating system, Robert Frances said. The other factor is that competitors have responded to pressure from Linux by lowering their prices, according to the study.

The high cost of IT complexity

Another from Computerworld:

IT organizations that keep a lid on complexity spend 15% less than their peers and operate with 36% fewer staffers while bringing in projects on time and under budget 25% more often, Hackett found. With data like this, Hebert says, CIOs will be able to educate business managers so they can make informed decisions about whether there's really a strong business case for deviating from the corporate standard.

ROI on clustered storage

From Computerworld:

Ron Rose, CIO at Priceline.com Inc. in Norwalk, Conn., used a clustered storage system to consolidate a storage-area network (SAN) made up of 100 arrays into a system with just five.

The clustered system, from 3Pardata Inc. in Fremont, Calif., also increased Priceline's back-end storage throughput to 20,000 I/Os per second. The system is used to support Priceline's production database for its Web site, e-commerce infrastructure and data warehouse.

...

Rose says using 3Pardata's S400 InServ Storage Servers offered the following advantages:

* Storage utilization rates jumped 30%.

* Administrative time was cut in half.

* Power, space and heat requirements dropped 66% by going from 15 racks of storage servers to five.

* Support costs were cut 70%.

* The number of SAN ports dropped 73%.

At $500 to $1,500 a port, dropping from 90 SAN ports to 24 SAN ports saved Rose tens of thousands of dollars.

Another savings came from using serial Advanced Technology Attachment drives in 3Pardata's storage servers instead of higher-performance and more-costly Fibre Channel drives.

ROI: Great Concept, Lousy Metric

Over the years, analysts have embraced ROI as a key topic for IT. While this emphasis on quantitative business cases for IT investments is definitely a good thing, it has also led to the spread of misinformation and bad advice.

The mechanics of evaluating the business value of a proposed capital project have been fairly well settled for quite a few years. Any Finance 101 course covers the basics of corporate finance, including capital budgeting and project valuation. Among the standard textbooks on the topic are McKinsey & Co's Valuation: Measuring and Managing the Value of Companies, or Eugene Brigham's Fundamentals of Financial Management. These textbooks may differ in the way the material is presented, but they all agree on the appropriate metrics for project valuation.

Interestingly, ROI is not one of them. Return on Investment is a great concept for CIOs: IT projects should be evaluated to ensure they return enough value to justify the capital investment. However, ROI has alot of problems when it is used as a metric for evaluating candidate IT projects.

First, there is no agreement on how to calculate ROI. Some analysts or consultants define ROI as the time it takes to recoup the original investment, what is more accurately called the payback period. Others define it as the sum of all benefits divided by the sum of all costs. This calculation ignores the "time value of money", or interest rate. This calculation also includes annually recurring costs such as hardware maintenance with the one-time up-front implementation cost. This mixes an ongoing operating expenses (what can be thought of as a "negative benefit") with the up-front capital investment.

To resolve these issues, some calculate ROI as the present value of the benefits and the recurring operating expenses divided by the present value of the one-time implementation costs. This metric has the benefit of giving the right answer regarding a go/no-go project decision because it is mathematically equivalent to net present value (NPV) or internal rate of return (IRR). But then, why not just use the metrics that are universally recognized as valid metrics for project valuation, NPV and IRR?

ROI is a made-up metric that at best redundant, and at worst erroneous. It seems to be propagated by analysts and consultants trying to appeal to CFOs, COOs and CEOs with their hard-nosed financial savvy. Instead, it only demonstrates a lack thereof.

City of LA and the True Impact of Open Source

A press release from the City of Los Angeles (dating back to February 2):

GARCETTI, GREUEL, WEISS: FREE OPEN SOURCE SOFTWARE MEANS MORE POLICE ON THE STREETS
COUNCIL BETS THAT OPEN SOURCE MOVEMENT CAN SAVE CITY MILLIONS

Councilmembers Eric Garcetti, Wendy Greuel and Jack Weiss introduced a motion today to divert millions of dollars spent on potentially unnecessary software expenditures into a fund dedicated to the long-sought-after expansion of Los Angeles' police force.

The motion asks the Information Technology Agency to report on how the city could forgo paying for proprietary software licenses and instead transition to open source platforms and programs. "Open source" means that any programmer can see the software code and propose changes; a community of users creates, supports, and freely distributes applications. Some users pay a fee for technical support, but free support is available on internet message boards. The city spent $5.8 million on proprietary software licenses in FY2003-4.

"For taxpayers, this is a no-brainer," said Councilmember Eric Garcetti, member of the Information Technology and General Services committee. "By engaging this online community, we can make our own communities safer. Free open source software can be as capable and more secure than products that cost the city millions."

"By rethinking the way we do business and taking advantage of new technologies, City Hall can save money * money that should be going to pay for ambulance service and police officers," said Wendy Greuel, Chair of the Audits and Governmental Efficiency committee.

The Councilmembers include a very interesting quote in their motion:

For governments, Open Source raises an important question: why should taxpayers continue to pay for licenses when equally powerful and often more secure versions are available online at no cost, supported by a community of users? This conundrum has been posed eloquently by national governments in the Third World, where conversion to open source has been underway for years. As one Brazilian official told the magazine Wired:

Every license for Office plus Windows in Brazil - a country in which 22 million people are starving - means we have to export 60 sacks of soybeans. For the right to use one copy of Office plus Windows for one year or a year and a half, until the next upgrade, we have to till the earth, plant, harvest and export to the international markets that much soy. When I explain this to farmers, they go nuts.

Here are two ways of making the dry open source ROI debate a bit more compelling: open source savings = more police officers, or open source savings = 60 sacks of soybeans. Beats debates about appropriate DCF time horizons or server admin labor rates!

UK Schools: Open Source Has Lower TCO

eGov Monitor reports on a study on open source TCO in UK schools:

UK schools should "seriously consider" switching from proprietary software to open source alternatives because of the "obvious" cost savings on offer, says the Government's lead agency for ICT in schools.

Research published by Becta on 13 May concludes that in nearly all cases, schools moving to open source software reduced the total cost of ownership per PC significantly.

The highly-anticipated report, based on a study of 15 schools, shows that by using OSS, primary schools halved their costs. The relative cost per PC at secondary school level was 20 per cent less than that of schools running commercial software.

Also, support costs in schools using open source were on average 50 to 60 per cent of those of their non-OSS counterparts.

...

"This report underlines the massive opportunity that exists for all schools to get the best value for money from their IT budgets. The advent of Open Source Software solutions in education opens up the whole UK Education market for the first time in a decade to competitive choice, removing the inevitability of lock-in." Mike Banahan, Director of OpenForum Europe

I find this particularly interesting since, at least in the US, schools get software at a significant discount (software vendors, like tobacco companies, want to get future consumers hooked early.) Open source still comes out with a lower TCO. This is not surprising...we've seen similar interest in the K-12 market in the US for the same reasons.

(Hat tip to Martin Reilly.)

Open Source = Choice, Not Just Lower Cost

Computer Economics magazine published the results from a poll taken on their website regarding respondents' reasons for moving to open source. Since it's a web poll, the results are unscientic. Still, they're interesting. The top reason of the five by a wide margin was "reduced dependence on software vendors".



So why is reducing dependence on vendors more important than a very tangible economic outcome such as lowering cost? Are IT managers being irrational, ready to lash out at their vendors instead of taking care of their own shareholders by improving profitability?

Not at all. The flexibility provided by reducing vendor lock-in has a tangible economic value, even if actually calculating the value is problematic. Optaros describes the economic value of software in terms of financial derivatives. The elimination of vendor lock-in reduces the cost of switching vendors, and this option to switch, even if an IT shop never does, has real economic value. This poll, unscientific as it is, says that these IT managers believe the value of the option to switch vendors is more important to them than the reduction in software license costs from open source.

It would be interesting to see a more scientific poll confirming this conclusion, but if it holds up, this says that open source is about choice, not about cost.

More on Optaros

While digging around a bit on Optaros' website, I noticed its CEO is Bob Gett, formerly of Viant, an ebusiness consulting highflyer that crashed along with the rest of us in the ebusiness bubble. Before that, he was the number 2 guy at Cambridge Technology Partners, a very successful client-server consulting firm, where we briefly overlapped.

Gett has ridden the successive technology waves of client-server and ebusiness, and is now hoping to ride the open source services wave. I see this as validation of the pure-play open source services business model. At Novell, we are also pursuing the open source services market, while also selling our SUSE Linux distribution. Red Hat is doing the same

I'm sure there will be plenty of room in this marketspace for both integrated plays like Novell and Red Hat, and pure-plays like Optaros. Nice to see that Gett agrees.

Open Source as Financial Derivatives

Optaros, an open source services company, has an interesting slide deck titled The Paradox of Choice (pdf) with some comparisons bt financial derivatives and open source vs. proprietary software. The text is sparse, so it takes a lot of reading between the lines to get where they're going, but it's a very interesting take on the economics of open source.

Some intriguing quotes:

The promise of open source is to eliminate the choice of products and increase the choice of vendors.

...

The search for "one throat to choke" is the manufacture of "vendor lock-in"...the "one throat" you are choking is the "vendor locking you in".

The slide deck goes on to argue (or so I infer, given that I'm missing the voice-over) that IT managers should diversify their software portfolio, not standardize. This diversification represents the creation of options to switch software at a future date, and according to Black-Scholes, such an option has a concrete value.

I'm not sure I'm sold on the concept, at least not on the basis of this slide deck, but it is certainly food for thought.