While we’d all like to know whether your door is open or closed this holiday season and you’d welcome us for a pop-in visit, what we’re referring to here is architecture. In his recent Advisor, Ken Orr, Fellow, Cutter Business Technology Council, discusses some of the benefits and drawbacks to open and closed approaches to architecture. His comments are reproduced below, and we’d very much like to know your thoughts.
Should architectures be closed? Or open? Or some combination?
Are there certain types of architecture that should be one or the other?
What do you think of Apple’s developer environment for the iPhone? Does this mark a change for Apple?
Do you agree with the contrast Ken makes between Steve Jobs’s closed approach to architecture and Tim Berners-Lee’s open approach to the Internet?
How should user interfaces be defined and augmented? Are they/should they be dynamic?
Steve Jobs: Architecture, Platforms, and the Big Picture, Part 2
In my last Advisor (see “Steve Jobs: Architecture, Platforms, and the Big Picture,” 25 October 2007), I talked about Steve Jobs and “closed architectures.” A number of things have transpired in just two weeks. The first is Apple’s announcement of its developer environment for the iPhone. Also, the developer community has been hard at work opening up (aka hacking) other Apple crown jewels. The most recent example of this activity is the announcement that some developers had found a way to run Apple’s latest operating system release, code-named Leopard, on a plain old PC.
I received a couple of very thoughtful replies to my last Advisor. For example, John Schmidt from Wells Fargo wrote:
In theory it should be possible to have an elegant architecture with a consistent and simple user interface that is also open — but in practice it’s really hard to do. This is one of the reasons we have all become so accepting of the Microsoft windows idiosyncrasies — we “expect” PCs to hang and crash. One of the underlying reasons is that the idea of plug-and-play components for software systems (i.e., dynamic systems) just isn’t as deterministic as for other kinds of physical structures and we will as a result always have some measure of chaotic behavior.
I for one admire Steve Jobs for keeping a tight control of the architecture and for maintaining its integrity. It’s a beautiful architecture and is a lot more predictable than most other computer systems. If that means it needs to be more closed than we might ideally like, then I’m prepared to accept that trade off.
My response to Schmidt went something like this:
Like yourself, I am a great admirer of Steve Jobs and his architecture. Like you, I also took away a lot of lessons from Fred Brooks and his writing on architecture from his experiences developing IBM’s OS/360. Being really old, I actually saw some tragic architectural failures play out at IBM during that period when people took shortcuts that actually invalidated the basic hardware/software architecture that Brooks and Amdahl and their teams had put together.
What I wanted to do in this series of opinions was not to criticize Steve Jobs’s contribution to architecture but rather to contrast his approach to that of Tim Brenners-Lee and others in developing the architecture of the Internet. Closed architectures, for which Jobs is the poster boy, make it possible for the internal folks to guarantee performance, reliability, and security. Everything just works together. Jobs and Apple have shown how well that works. Clearly, Jobs is a master of user interfaces as well.
Open architectures are a clearly articulated set of well-defined interfaces that allow large numbers — and in the case of the Internet, millions of people and organizations — to (independently) build things that “bolt on” an evolving framework. (By the way, I argue that the reason that the PC architecture, even with an inferior hardware/software architecture, became dominant, was IBM opened up the PC architecture.)
The lesson to be drawn from these two approaches is that that they are both very, very valuable. Some architectures need to be closed and some ought to be open. Our core (mission-critical) systems need to be closed (reliable, secure, accurate, auditable, etc.), while our interfaces with our users ought to be open. The central IT groups have to be able to deal with both.
In the next Trends Advisor, I will further explore the concept of architecture as a mechanism of providing a framework for development, maintenance, and, most importantly, communication.