Official Gmail Blog: Code changes to prepare Gmail for the future
How sad is it that I get excited about a mostly invisible update to a web based email program? Nonetheless, I am "stoked" for the gmail updates, and only slightly concerned about potentially losing some GreaseMonkey awesomeness.
Read this SOA definition from Pete Lacey this morning and it almost makes sense...too bad it's not what most people mean.
So, then, what is SOA? For one thing, SOA is misnamed. It’s not an architecture in any sense of the word. It is, to use a Burton Group phrase, a mind set. It is the generally held belief that when implementing systems one should expose system functionality for general consumption directly from the network, as well as or instead of burying it behind a user interface. It is, as well, the belief that there is a great deal of value to be generated by retrofitting network accessibility into most existing systems. And it is the belief that this can only work if the means of doing so aren’t locked to a particular language, framework, operating system, vendor, or network architecture.
It's a bit hard to disagree with that as a good policy. However, having a bit of a linguistic bent, it makes me wonder if there isn't something fundamentally wrong with an acronym that is "misnamed". Mr. Lacey does suggest an alternative term for what he is describing: Network Oriented Computing. However doesn't that make it a worse definition of SOA (since the definition better fits another term)? It does. His final definition of SOA is "a technical approach to NOC that has a non-uniform service interface as its principle abstraction. Today, SOAP/WS-* is the chief implementation approach.". This is a better definition because it actually is an architecture. It also sits well next to ROA (Resource Oriented Architecture).
The killer final definition he offers is: "Business Service Architecture (BSA): An unnecessary term (also not an architecture) that tries to make the obvious something special. Aka, business analysis. Aka, requirements gathering." Reading this crystallized something important about why phrases like IT-Business alignment always bothered me- you align the IT systems with the business via requirements gathering. Now, maybe you are doing it at high level and want to give it a special name, but the dangers of abstract terms are that people can look like they are agreeing about how to do something, but really have completely different ideas about what they are concretely going to do.
Hmm, that might be a topic for another post.
I've been an extreme skeptic when it comes to virtual worlds for a while now. I really can't understand how people can get excited about things like Second Life. None of the arguments for it as a great business seem to make much sense. The false scarcity markets for real estate seem quite misguided. I really enjoyed working with Forterra the other day- it's definitely richer than chat rooms and teleconferences in terms of communication- but is it richer than video telecon? In one way it is, because you can walk around and such, but that also imposes the limitations of the real world upon communication: you can't hear someone if you walk too far away.
I left a highly skeptical comment on James Au's post on 7 reasons why business execs should care about second life. There needs to be an Internet of sorts, so that the virtual worlds can, well, internetwork. You can't say Second Life is that important, because investing so much in something owned by another company is putting all of your eggs in one basket. It's like starting a company that builds Facebook applications- when (not if) Facebook gets acquired, your whole business model is in jeopardy. Better make a quick buck.
The world isn't just about open platforms. It's about interoperable platforms. One thing that makes adoption of new GIS systems possible is that the data can be transitioned from one to another because all of the stuff is connected to real world coordinates, and it is possible to translate from one coordinate system to another because the both refer to a place on the real earth. I am not sure what the virtual coordinate system is. With the Internet, it's the unified addressing and naming schemes. There can only be one 220.231.23.123 on the public internet.
In this light, the iPhone looks really dumb. You can't install apps on it. Okay, WiFi works and the phone bit actually connects with the real phone network, but it's not an open platform. Few cell phones are unlocked to connect to multiple networks, but Apple seems to be actively discouraging this. To me, that's a sign of a bad business model- easily defeated. Just make the money on the device- not the lock-in.
It seems like the right business model is have an open and interoperable platform. It cuts off competitors, but allows you to benefit from the network effects of others innovations.
Lots of good articles in the Fall Sloan Review of Management which I am just getting around to reading...
Avoiding the Alignment Trap in IT
One of the big ideas in IT Enterprise Architecture lately is Business / IT alignment. This is generally defined as the concept that the shape of the services offered by IT should reflect the offerings of the business. At the very least, it makes it easier for the CIO to justify why they are spending money on project X- because it is directly tied to a business need. To some degree it's a communication convenience.
In reality, the biggest benefits seem to come from simplifying the infrastructure and putting an emphasis on integration. A second article in the SMR by Cynthia Rettig really hits it on the head: The trouble with enterprise software:
...enterprise software may be just too complex to deliver on its promises. She also suggests that the next new thing — service-oriented architecture (SOA) — is not likely to fare much better, for many of the same reasons. There are no easy fixes, cautions Rettig, save a large dose of sobriety, clear-eyed analysis and emphasis on simplicity and efficiency.
If you want to read one of the best advocates for the odd beast known as SOA, I suggest following Bobby Woolf's blog or reading his new ebook. His old book is has had a solid slot on my shelf for a couple of years, but I still haven't felt the need to install an Enterprise Service Bus. (Despite the fact that I more or less use it as a design pattern for integration architectures, just without the overhead of actually having it be a running piece of software)
In any case, I am not writing myself out of a job here- the message is simple though: don't try to do everything at the expense of ending up with complexity. Keeping things simple and hitting the "Pareto important" requirements is the winning strategy.
