In Q2 2011, Apple had $5.0B revenue for desktops and laptops; in Q2 2012, $5.1B.  In that same time frame, iPhone revenue went from $12.3B to $22.7B, and iPad revenue from $2.8B to $6.6B.  Looking at the gross margin trends (and the huge gobs of cash the company is making), the margins are probably better on the iPhone/iPad deals (because of the kickbacks they’re getting from the phone carriers).  In a quarter where non-consumer purchases are at their strongest, Apple’s computer business is fading into irrelevancy for the company.  It’s down to 13% of revenues and a smaller portion of earnings.

It’s hard to know exactly what this means for the future of Apple computers, but it surely explains Apple’s cavalier attitude towards enterprise customers.  Why should they care about a possible piddling increase to a piddling business?

On the hopeful side, it could mean that the company’s long-standing resistance to OS licensing and virtualization could be softened.  After all, they’re not making any money on hardware now, why should they care if someone else does?  If it would help drive iPad sales it would make sense to push OS X out onto other vendors’ hardware.

On the less hopeful side, it could mean that the company will pare down its already severely pared down line of computers.  There are rumors that the Mac Pro is on the chopping block (and it hasn’t had an update in almost 2 years); Apple doesn’t have anything else to sell to people needing computing power, like scientists and graphic designers.  You can probably expect a touch-screen iMac at some point, but then what?

It’s Apple’s world; we’re just living in it.

Unlike Microsoft Windows, MacOS has not had 15 years of abuse at the hands of enterprising hackers.  This incident is likely to be the first of many for Mac users, and Apple’s lackadaisical security posture is going to cause problems for campus users.  This bug (which relies on a cross-platform hole in the Java libraries) was fixed by Oracle in February, and Apple only got around to releasing a patch in April, weeks after most other OS vendors.  And if you’re running OS X 10.5 (Leopard) or earlier, Apple isn’t planning to release a patch for you at all.

The campus has already announced that OS X 10.5 is in violation of the Minimum Security Standards (because Apple is not providing security patches), and now that there’s a known exploit in the wild, they are likely to move towards blocking 10.5 machines from network access unless they can be demonstrated to be secure.  If you have any 10.5 machines which can run 10.6 or 10.7, you should upgrade now.  If you have any 10.5 machines which cannot run 10.6 or higher (PowerPC), you should immediately begin planning to replace them with new hardware.

If you’re running 10.6 or 10.7, you should make sure that you’ve applied all security updates, and that Software Update is set to check for updates regularly.

LSCR has a very old FileMaker Pro Server (running FM Pro Server version 9) which needs to be replaced; we’ve been anticipating the release of FM12 for some time, and are now moving aggressively to get a new server up and running on an IST virtual machine.  Our plan will be to have the server installed and working by the end of the month, at which point we will work with departments to begin migrating their files to the new format and new server.  Our new server will be more reliable, and will allow us to provide better support for FileMaker web access, CalNet authentication, and other database-related functions.

Everyone who accesses files on our FileMaker Pro Server will need to purchase FM12; the cost through SHI is about $50/license.  If you’re one of the dozen departments using our FM Pro Server (boyce.LS.berkeley.edu), you should expect to make this purchase between now and the end of the summer.  If you’ve purchased FileMaker Pro 11 within the past 12 months, you probably have upgrade rights and won’t need to pay for another license; if your purchases are older than that, you’ll need new licenses.

Some departments are running their own FileMaker Pro Server instances, which will likely be updated on different timelines. At some point we will be unable to purchase new licenses for FileMaker Pro 11, so the migration cannot be delayed indefinitely; I recommend that everyone being preparing a plan for migration to FM12.

We will soon communicate directly with departments affected by our server migration.  We’re looking forward to retiring our old hardware and moving to a modern virtualized environment.

With Shared Services, it feels like things are really going to happen.  There is still a whole lot of stuff to be figured out.  The decision of the OE Executive Committee, while approving the proposal, also notes that the workforce transition plan and post-implementation funding plans will need further review, because neither of them is finished yet.  Workforce transition is close to ready; post-implementation funding has a lot more work to do.  Also still needed is a lot of work on the IT portfolio and support model.

Biological Sciences will be an interesting use case for the last of these.  End user support for administrative staff is definitely included, but how faculty support will be included is not at all clear.  BSDS currently has 3.5 positions centrally, and those folks provide admin staff support, instructional support, application development, some faculty/research support, and strategic assistance for the department.  It’s clear that some portion of the 3.5 positions will remain in the department, but exactly what portion, and what support those positions will be providing, still needs to be developed.  The other academic units in the early adopter cohort (CED and CNR) have similar questions.

Shel’s departure comes only shortly after he announced a major IT reorganization; the details aren’t fully published yet, but the plan includes dual reporting lines to the CIO for some IT units currently outside of IST, including Student Affairs and ETS; the other reporting line will be to their functional leader (Harry Legrande and Cathy Koshland, in those cases).  It’s at least a nominal increase in the role of the CIO, and I think part of the idea is to tie the technical work more closely with the functional leaders.  More will be fleshed out in this realm in the next couple of months until Shel leaves.  Lyle Nevels should be a good choice as interim CIO; he understands the academic side of the house, and while Haas faces much different problems than L&S does, Lyle always acknowledges the ways that Haas is unique on campus.  He led the OE-IT initiative, so he will be in a good position to keep things moving on the Productivity Suite and Shared Services-IT.

Birgeneau’s departure was anticipated, it was only a question of when.  His timing seems to be selected to allow him to finish the implementation of the bulk of the OE proposals; certainly by the end of the year most things will be past the point of no return.

Crazy week, even before the tournament started.

The topics of the meeting were IT governance, and departmental IT once Shared Services is up and running: what’s left in the departments, and what will they need to make the arrangement successful?

Should you find yourself in a chronically leaking boat, energy devoted to changing vessels is likely to be more productive than energy devoted to patching leaks.  –Warren Buffett

There’s an interesting bit of strategy going on here.  Brad Wheeler, CIO at Indiana University, talks about pursuing a “philosophy of abundance“:

Members of the IU community should be able to conduct their work without thought of IT constraints. While financial resources must always shape reality and some policies provide essential protections, the university should consider all possible approaches that develop IT services in unmetered and unrestricted ways that approximate a philosophy of abundance.

Berkeley IT exists in a culture of scarcity. Users expect that IT services will be expensive, poorly run, or be discontinued without warning.  Departments try to retain local funding and local control of IT because they doubt that central or shared services will meet their needs, or even take them into account.  Hoarding of resources increases the total cost of providing IT and reduces the overall quality of the results, but it is the natural and expected outcome when shared services are not trusted.

The campus is trying to shift the culture.  By entering into these license agreements, they are saying, “Here.  We know that you need these things, and we are going to provide them for you.  In exchange, we are going to ask you to participate in a common good funding model once we’ve gained your trust that the funds will be used to address things you consider important.”

When the details of the common good funding model come out, there is going to be push-back from departments, fueled by the expectation of scarcity.  These licensing agreements exist to help build trust, which I hope will facilitate the adoption of the fundamental changes required to improve the success of IT operations at Berkeley.

A major difference relative to the Adobe deal is that a large percentage of our customers will be affected by this change in licensing.  We have huge numbers of down-rev Office versions out there, and a whole bunch of good machines running Windows XP or Vista which we will consider upgrading to Windows 7.  Upgrading from Office 2003/2004 to Office 2010/2011 also presents training issues; the interface is different enough that many users are confused when they first try the new versions.  For training, Microsoft has decent online tutorials, we have access to web-based training through the UC Learning Center, and there are often MS Office classes taught through CalPACT (though I wasn’t able to find any scheduled right now).

We have the ability to push out Office through Active Directory for Windows machines connected to AD, but the training issue will require us to be careful about how we do that; we don’t want to give everyone a new interface without warning.

For most other configurations, we’ll have to SneakerNet around for Office installs, although we will also be looking to pilot BigFix, the campus’ new patch management system.  It may make more sense for us to install BigFix, then use BigFix to install Office, rather than installing Office directly; we’ll be testing that in at least one department.  We think that BigFix will reduce our long-term support costs by making this kind of deployment easier in the future.

We’ll be approaching Office upgrades on a department-by-department basis; you’ll be contacted by your LSCR partner to schedule any upgrades needed in your department.  If you have immediate needs, feel free to submit a ticket.

We will be recommending upgrading to Windows 7 for some machines currently running XP, and all machines currently running Vista.  Those upgrades need to be considered on a case-by-case basis, and they will take some time.  We’ll be rolling out a plan to address them over the next few months.

The software is supposed to be available as of January 9.  We will start Office installs that week, probably rolling them out over a period of 6-8 weeks.

Feel free to contact me or your support team if you have any questions.

From the abstract:

Mac users are drinking furniture polish in back hallways, getting their fix from fellow bootleggers who have blazed the trails around IT’s prohibition. End user computing professionals steeped in two decades of Microsoft management traditions are either prohibiting Macs on the company network or limiting their support to executives only. It’s time to repeal prohibition and take decisive action. This document is the first in a collection in which we’ll introduce you to a new class of Mac users, explain why they matter to the business, and share how other firms successfully managing Macs are doing it.

We’ve seen the trend towards Apple hardware in the devices people are using on campus, not only among the faculty but at the director and executive level.  At the same time, many of our campus-level initiatives are being implemented with software which provides little or no support for Macs.  I have been at meetings where campus IT leaders talk about standardizing on an application which only runs under Windows, while every person at the table is using a mobile device from Apple.

Enterprise vendors (Oracle in particular) are very slow to react to changes in technology, so it may be many years before they’ve caught up.  But in some cases, these enterprise vendors are the only ones providing software that meets a specific need, so we may have to select one that doesn’t fit well with our actual population of devices.

I will make two assertions:

1. If we’re considering a vendor who does not have cross-platform support, we need to seriously think about accepting different or lesser functionality from a vendor who does.
2. Web-based products which fail to work cross-platform on modern browsers are broken and should not pass acceptance testing.

As previously mentioned, the campus has decided to outsource our calendar and email systems; from what I’m hearing, a vendor announcement to be made very soon.  That decision led (directly or indirectly) to the departure of the two guys who’d designed and built the CalMail system, James and Paul.  I am willing to assert that yesterday’s outage would have been diagnosed and fixed sooner if James and Paul were still around, since they know the system inside and out.  So one tangible short-term result of the decision to outsource is that we had one outage of greater length and scope than would otherwise have been the case.

On the other hand, the risk of this kind of outage is exactly the driving force behind the move to outsource.  When one or two people with specialized knowledge are instrumental to the function of a critical system, at some point there will be an outage that they’re not available to manage, whether due to vacation, sick leave, or those individuals finding other opportunities.  Without the subject matter experts on hand, you’re stuck trying to figure out the system’s interdependencies at the same time that you’re trying to fix an operational problem with users pounding at your door.

I don’t think that outsourcing email and calendaring is going to save money.  It might cost more than what we’re doing now.  But it will change our risk profile.

The risk with outsourcing is that you have no control over the vendor response to an outage.  The assumption being made is that large vendors have less dependence on individual contributors, and more ability to build redundancy into their infrastructure.  I think that’s a reasonable assumption, and on average we should see less full-site downtime with a vendor solution than an in-house solution.  Major service providers have strong incentives to keep their core systems up and running.

I see two tradeoffs: One, we will give up some functionality.  Vendors only provide what they provide; when we outsource, there will be things that CalMail and CalAgenda currently do that will not be supported in the new system.  And two, while vendors have strong incentives to keep their core systems up and running, they don’t have strong incentives to keep edge functionality up and running.  Outages which affect only a portion of their population, or only groups using a specific type of functionality (say, IMAP with TLS) may not be considered critical response situations.  And some of that edge functionality may be removed in future versions; we are small potatoes in the commoditized service world, so if our needs are not aligned with their core service, we have little leverage to demand them from the vendor.

We wound up with eight folks in the room, who between them are supporting 12 different departments.  One thing that was quickly obvious is how little opportunity Unix sysadmins have had to share information recently.  There is no active community on campus, so everyone’s on their own, which is one reason why we were able to catalog eight different OSes or distributions being run in production on desktops among the group. We had good discussions on the history of each unit’s efforts in this area, and pros and cons of the various options.

Time was too short to come to firm conclusions, but it was clear that people enjoyed getting the chance to discuss the issue, and brought up a number of other topics for future discussion.  We decided that the group will get together on a monthly basis going forward.

This is an informal group, with membership open to anyone interested.  It was conceived as within L&S, but I don’t mind if someone from outside wants to join us.  Contact me if you’d like to be added to the mailing list.

After the success of this meeting, I am going to try to get develop similar groups for L&S web developers and desktop support folks.  Those populations are quite a bit larger, so I’ll have to figure out some logistical issues.