Posts Tagged ‘architecture’

Leverage the best of community and agile approaches for results

Tuesday, December 1st, 2009

It seems to me that Microsoft is applying some valuable lessons from open-source and community driven software processes: get user buy-in as early as possible, deliver early and frequently incomplete or partially flawed products. People will happily participate, you would get a more accurate feel for the reception when the product finally ships. I don’t know what the pundits are saying, but to me (as a software architect and user), this strategy pays off handsomely.

Every new Microsoft product I laid my hands on over last half-year has been nicely thought out and clearly user-oriented by design. You can almost feel that product development received a lot of attention, and that is good news for the 90% of us who use Microsoft software.

I’ve started using Microsoft Office 2010 Beta on my Windows 7 box. You immediately see the impact of some of the lessons they’ve learned with the previous major release, the ribbon concept has been tweaked, the experience feels more natural yet innovative. I’ve not had to spend any time reading documentation (though that would be a mistake for a final product, reading the documentation is always for the best), I had no troubles working just like before.

Similarly, when I first learned about the early Microsoft Azure visions, I was having a strange feeling of “lipstick on a pig” treatment. After PDC2009, I saw lots of improvements and change of heart on some early ideas that seem to be, without a doubt, the result of extensive community participation.

The early concepts and beta releases of SharePoint 2010 and Office 2010 have stunned me in their clarity of vision, for the first time I’m getting excited about Microsoft’s web-based software. Having spent the best part of last decade delivering non-Microsoft solutions, albeit I’ve never lost sight of what they were doing, I am seeing a lot of good vibes coming from Redmont these days.

Another potential idea that can be read here, would be that Microsoft is directly engaging users and hence doing away with their former approach where their partners supplied the bulk of feature requirements (I’ve read a lot of Michael Cusumano and Mary Jo Foley throughout the years, any misreading would be mine).

To me, these are all signs that Microsoft’s products are improving, they are increasingly addressing unmet user needs. This would be a software delivery equivalent of a “growth business”, I buy it.

I see a parallel with the practice of software architecture, whether its Enterprise Architecture or Solution Architecture on a smaller scoped project. Software Architects can achieve much success by adopting some of the same recipes hinted at earlier, by no means a complete list:

  • don’t seek completeness on any significant topic before getting stakeholder communities fully engaged (no, they won’t think you’re daft)
  • don’t think you have all the answers (many thought leaders are saying this), actively seek and incorporate ideas from the receiving parties – they’d have a hard-time to reject their own input, wouldn’t they?
  • delegate major chunks to smaller and dedicated groups, see to it that the inter-group communication is fluid and sustained (I don’t know if Microsoft does this, it seems many of their products are still large silos).

With this type of approach, the outcome tend to feel much more natural and the acceptance will probably be easier. You see it for example when, using the product, you guess how something might work and could verify that the feature was implemented almost exactly as you guessed. This happens a lot when I use Apple products. I used to think that Microsoft would never be able to match such feat, but I now see that they are changing their approach for the better.

Architect Vendor or Platform independence with care

Friday, November 20th, 2009

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.