At their PDC 2009 edition, Microsoft outlined a strong vision which might boost them in the Cloud
I watched Microsoft PDC keynotes yesterday and it left me quite an impression: Microsoft firmly intends to be a strong force in this Cloud markets, no doubt.
Ironically, Microsoft might become a big winner here. Thinking about it, Cloud turns the clock on vendor-independence mantra: businesses would rely more than ever on their cloud provider. This works for Microsoft too: it no longer matters what platform runs your business, so long as it performs and you get the expected value from it. Naturally there remain issues around security, governance and such, issues that are open for all vendors the same way.
By delivering quality tools and performing Cloud solutions, Microsoft is in the game. If you can depend on Google of Salesforce to run your business, what other reasons can there be for snubbing Microsoft? Can anyone credibly speak of vendor lock-in as a valid argument? The other important questions to ask are then around pricing and service terms.
The vision outlined by Microsoft appears sound to me, they also appear to be engaging customers in this effort. The tooling seems to be coming along nicely too, and Microsoft is wooing celebrity developers. It seems that a larger chunk of Microsoft technology is being made available in the Clouds, that is something I didn’t expect so soon – could still be just a teaser with no real intention to deliver much, we’ll see. But my impression at the moment is: game on for Microsoft, when they start shipping Azure.
As Microsoft starts to deliver Cloud services, the playing field becomes square and they can leverage their massive momentum to gain a significant market share once again. They might actually end up dominating the Cloud in the process!
I’m loving this epic battle in the Clouds. Will it be a winner takes all?
The most prevalent practices of Software Architecture tend to undertate the importance of user experience design
I think the title states quite the obvious, User Experience practitioners would agree with me. But in the context of your ICT activities, do you find that Software Architects take the same view? It is not so clear cut in practice, in fact tensions or misunderstandings can be easily found. The situation I am discussing here mostly applies to large IT organisations, where design and development and rollout activities and responsibilities are split across multiple groups. This is not the case for small organisation or tiny start-ups.
In my experience, software architecture tends to be the discipline or at least the responsibility given to people with an Sofware Architect profile. In this text, I am referring to Software Architect as the profile that is often contrasted to UI Architect in some ways. The former is the title given to the guy who knows the inner workings of the software, the person who can perform back-end coding and is intimate with it. Whereas, the latter doesn’t get credited for his/her technical skills beyond pure front-end coding considerations. Then there is also the IT Architect, the role given to the persons that build or look after machines. Incidentally, when the Software Architect and the IT Architect roles are not working closely together, problems arise at the time of deployment where organisations find that many production staging aspects where not tackled properly. But that is a subject for another talk.
Recently I tweeted a link to an old posting by Richard Monson-Haefel about 97 things every software architect should know. @multifarious remarked that he found it interesting that (experience) design was not one of the 97 things mentioned in the article. This blog entry is an attempt to expand on my thought a little bit.
As I understand it, R. Monson-Haefel polled a few people whom he deemed authoritative in his quest. A quick reading of the entries will support @multifarious’ suspicions. There was probably no intention to exclude UI experts. Whatever R. M-H’s intentions, @multifarious might have just singled out one of the shortcomings of software architecture practice. You can get the impression that designing user interface code is taken for granted, if the “back-end” stuff is sorted out that is. Often case, discussions on usability is really bogged down to response-time in a context of request/response. If the actual interaction proves unworkable, blame is easily laid on business analysts or business owners for not clearly indicating their intentions.
In my opinion, the Total Experience should really be the focus of usability at any point of a software architecture crafting process. I think Google got this right when they launched google.com all these years back. It is no a flashy web site, but everyone agree that you get precisely what you are looking for without hassle. And that is a fundamental point. Perhaps the current maturity level still focuses too much on the inner workings of the underlying software, but is little cogent of the user interaction issues.
I give it to @multifarious, R. M-H’s article ought to mention user experience design. Maybe it does in the book, which I haven’t read yet. Maybe they’d cover it in a future iteration.