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.
I was really disappointed to read about Xobni. Bringing Gmail features to Outlook- and letting you 'pivot' your email by who it is from / to. I am disappointed because I have a great idea for an inbox assistant that I am conceptualizing, and this thing looks much better, if not really on the same track. The good side of it is that I will get a better sense of the market for Outlook plugins from watching their progress.
My idea is a little more focused on another aspect of email- the doing side of things, while Xobni is more on the analytical side. I still really want to try it, even though a few of the details are far from clear at this point...
I've also been checking out the trial for Sandy. It's another email type tool, except it's more of a command line using email. You send Sandy an email and she either updates your calendar, todos, sends a reminder or just remembers it. With the API support, you could think of it as a mail in interface to all of the tools you already use. I really wanted to like it, but it's not quite what I thought it was going to be.
Here's what my tool is going to do- help you get through your email faster and more effectively. I've been on the verge of declaring email bankruptcy a couple of times in the past months and I need this tool to stay at inbox zero (see below video for more on that).
Interesting thoughts on CS and Econ degrees on Marginal Revolution.
From the Comments:
I was a CS major at MIT and was heavily recruited by Wall Street firms. My friends who were studying economics did not do nearly as well right out of college. The CS major is a modern "liberal arts" degree; you can do almost anything with it. In my case, I am getting my PhD in economics. I think studying economics instead of CS as an undergrad just signals that you want a high-paying job without having to do any hard work.
Or maybe proving you can make it through one of the more challenging academic programs in the world means there is less risk in hiring you to do anything...Anyway, I don't have a CompSci degree, despite taking most of the 400 level courses, and I've never missed having one (that I know of).
I do really like the idea that CS is just a tool for getting involved in some other industry.
Another Comment:
This is all kind of funny to me. After graduating with a BBA Econ in 1999 I made a play at the CS world. Realizing I was not willing to learn any real programing I went to get my PhD in Econ. Now I sit all day... programing.
Funny world.
And you can now just follow along online...
"Wrote Visual Basic for Applications code in a consulting role to support a multi-user client/server time reporting application in Microsoft Excel"
I feel the need to add a line specifying that I was not the architect on this project who decided that doing hub-spoke replication in Excel was not only feasible, but a good idea. I was just called in when it was determined that the original team had made a big mess when they tried to "scale up" to 50 users. At least it was only a month seven years ago. I suppose what really would make it scary is revealing the customer...but I can't do that to them.
This was one of the first instances I had seen of a non IT department wanting to do something technical, but being shot down by a nascent CIO office in terms of being allowed to do IT projects. They thus went with what they had on their desktops as the development platform.
Anyway, I think that project is getting dropped from Resume 2.0.
Just checked out this interesting article from LukeW on secondary actions on web forms. The sum of it is that people don't complete forms faster when you make distinctions between primary (submit) and secondary (cancel) buttons. Still, as Luke points out- hitting cancel after filling in a long form really is not good. Do you really need a button for that in all cases?
I really enjoy the data driven approach of using eye tracking data to help make decisions on form elements. Unfortunately he missed my current preferred option: Bolder font-weight on the text on the primary action button, lighter or normal font-weight on the secondary actions. Since we have CSS classes for those button types on my project, I was all ready to make some changes...looks like I won't be making any, but it's still worth the quick read.
There are some people out there that believe there is one right way to build an application. The people that believe in best practices. The people that fall victim to Harwell's laws. (Particularly #1, "People always try to use their experience even if it doesn't apply to the current situation." and #3 "If a manager doesn't know how to improve an organization, then he/she will change it to look like the last organization that he/she remembers")
The particular issue I am dealing with has to do with web application security architecture, but it comes up again and again in architecture, particularly in web services. Where does authentication live and where does authorization live? And what trusts what. In particular, should a web application authenticate a user's x509 cert or Kerberos ticket, and then pass user information on to further systems, or should it pass the users security information on to further systems, such as databases. In other words, should authentication performed at each stage of a request that passes through multiple systems?
If you ask Oracle any question of the form "Should X be in the database?" the answer is yes. Apparently Microsoft is training their people to think the same way. It sure works great to induce vendor lock-in.
Somehow I am of the opinion that the first system a user comes in contact with should perform the authentication, that system should authenticate to other systems- as a system, not a user, and that their should be trust in the initial user authentication.
Having the database re-authenticate the user seems wasteful...and of no value.
I am completely sick of all of the processes that have to be constantly running on my Windows machines. The things that particularly annoy me are the "update check" software- I am looking at you menacingly iTunes, Java, Adobe and Windows Update. Why on earth do these programs have to run constantly? Can't they at least just have a scheduled task to run at a particular time? Or how about copying firefox and just checking for an update whenever I start your program. I think Quicktime asks for updates more often that I actually use the software. I don't need a background process running constantly to tell me a piece of software that I haven't run in two months needs to be updated.
Perhaps even more annoying are the "helpers" that run to make various software applications appear to start up faster. I suppose this is just keeping up with the various tricks that Microsoft employs to make their stuff startup faster, so it's fair to blame them for starting the arms race.
And the final annoyance is the difficulty in seeing which svchost.exe PID goes with which service. How hard could it be record the name of the service, so that I could in a glance see which one is sucking CPU or RAM? I suppose I could actually code a solution to that myself...but I shouldn't have to. In fact, someone already did:
Process Explorer- this is what task manager should have been...
