Architect Vendor or Platform independence with care

Vendor independence or Platform independence should be carefully considered, weighted against the organisation strategy. Vendor and/or Platform Independence often won’t make sense if architecture is to deliver true value efficiently.

When designing Software Architecture, it is easy to confuse Vendor independence with Platform independence, or think that it is absolutely necessary. If your organisation already has a strategic platform, or that it has strategic alliance with a particular vendor, then this should be core to your architecture design processes. Ignoring this aspect, you might design a perfect solution for a non-existent problem. This is the software architecture equivalent to overcapacity, it could be costly.

There is always a temptation to come up with an architecture that is pure, scalable, flexible, and so on. But to what end? As we know, beauty is in the eyes of the beholder, and beauty for its own sake will often not make business sense. Why pursue it then?

One of the benefits of the software architecture practice is in delaying implementation decisions until after the business issues have been properly understood and captured, in fact it should be separating implementation decisions (and not delaying). But that thinking amounts to assuming that implementation is not a business concern at all, which could be wrong. There is a risk of designing a perfect architecture that simply cannot be implemented without significant performance or delivery penalty.

My point can be summarised as follows:

  • A perfectly valid process can yield perfect disasters when it is short sighted in any significant way.
  • Business domain semantics should be analysed in context, not based on a theoretical ground far remote from the specific business reality.
  • Consider the complete lifecycle of the solution being designed: if the vendor or platform lifecyle is likely to survive your solution, duly include such vendor or platform considerations in your key drivers.

In large enterprise architecture endeavours, usually there are sufficient resources to tackle all aspects of an Enterprise Architecture requirements. This is often not the case for SMEs and start-ups, the largest group operating with tight resource constraints.

It might be tempting or even self gratifying to think that you’re designing a vendor or platform independent solution, but that might not be the best way to deliver value to your stakeholders. In practice, it is always better to take sides when designing business technology solutions. This is the main reason that large businesses often enter strategic alliance with a prominent vendor and thus commit to its solutions and products. There is nothing wrong with such practices, obviously. Carefully managing the vendor relationship is another issue altogether, which cannot be discussed in this post. What could always be counter-productive however, is when software architecture practitioners would try to downplay the role of such strategic vendor products and solutions at the design stage.

With Azure, it might be game-on for Microsoft!

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?

User Experience Design is part of Software Architecture

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.