Saturday, December 30, 2006


Not having blogged for sometime it feels a bit strange to do so again. Last few months has been hectic between the birth of our second son, and a few projects coming off the boil simultaneously (one of sensitive nature restricting what I can blog about).

Someone recently asked me what do I look for if I am hiring architect, the question caught me off guard as I had never given it much thought. In the past I have interviewed lots of Solution Architects, hired a few good ones and a few not ok ones. The problem with interviews is it is such a luck of the draw, despite the best intentions there are no guarantee of outcomes. Having said that I wanted to pen down what I thought made a good enterprise/solution/software/architect.

Architects in our information age have a unique position they sit between the business and technology acting as a bridge between competing domains. This role has become even more important as role of IT has changed from being Automating Business to Information Management and finally Business Transforming (Information Paradox). The other paradox with architects role is even though they play such a crucial role very often they have no power to direct things, other than to influence from the sidelines. Often when IT projects turn bad CIO have been know to turn to their Architects (Enterprise or Solution) and ask them where were you when the rot started (on the sidelines watching the project go downhill).

From my personal experience and what I have seen in others to be successfully architects one need to have equal parts of following professional traits.

Salesman: to be able to sell the concept to other members of the team and stakeholders. Basic sales skills are important to firstly empathize with others and understanding what they are truly looking for.

Preacher: As an architect one needs to believe in something and have the ability to appeal to others emotional core. When things don't go as planned every one in a software project team have a tendency to turn to the architect who had initially articulated the vision. During such trying times faith in ones ability should be unfaltering. The down side of being too much of a preacher are the flame wars we are so often familiar with "Linux is better than Windows", "RUP is better than SCRUM", "UML is the only modeling language the world needs".

Thinker: This is perhaps the most important ability of an architect, the ability to solve complex problems either by abstraction or separation of concern. This is the trait which gets discussed the most when talking about architects so I wont waste any more time or space.

Dana Bredemeyer and Ruth Malan in their article "What It Takes to Be a Great Enterprise Architect" describe US Constitution as a form of Enterprise Architecture and James Madison the first Enterprise Architect. They outline similar skills I have outlined above and include a few more (domain expertise, political acuity, strategic ability, and leadership skills).

Having said all this an architects job is never easy they have to often juggle multiple dimensions and competing priorities with the responsibility to articulate a solution which balances all these dimensions and then communicate it to diverse group of stakeholders. James M Butler in his book Technology Blueprints: Technology Foundations for High Performance Companies defines a form of psychosis that afflicts architects when these forces goes out of balance. Following are his list.

"Dimensional Myopia: Focusing too tightly on resolving certain dimensions of the problem space while being unaware of or choosing to ignore others

Evolutionary Vertigo: Refusing to ever commit to an approach, tactical or strategic, based on a perception that the solution spaces are changing too rapidly, thus resulting in a lack of traction

Molecular Paranoia: Working 23 hours a day to mentally maintain for real-time access all details along all dimensions and scanning all news sources for any external influence for fear of missing any single detail, relevant or not

Reverse Acrophobia: Clinging only to the highest levels of abstraction and avoiding reality-based grounding while apathetically assuming that the engineers can and will do all the heavy lifting"

I have seen Dimensional Myopia especially among architects who come from a specific stream background (I.e. Data Architects tend to see the whole world as a database). As an software architect it is important to have well rounded experience, preferably some in non IT space (manufacturing, finance and so on). Recently reviewing someone's architecture I came across Reverse Acrophobia; in this particular case solution was at a level of abstraction where reality was a problem. I am not going to comment on Molecular Paranoia as sometimes I suffer from that affliction :-).

Recently I came across a beautifully quote from Chris Bangle Chief Designer at BMW where he says "Engineers make the world happen. The role of the designer is to give them focus." In the world of IT Architects play the role of designers and software developers, hardware engineers, network engineers make it happen.

As a final word have a look at this article

Sunday, October 08, 2006

VS2005 and SOAPExtensions

For the last couple of days I have been concentrating on creating some SOAP extensions that will allow me to Log messages, validate messages and monitor performance counters in my web services. I got stumped the other day when I was trying to debug the extension by adding them to a dummy web service. It turns out in VS 2005 when using the default documentation page to send soap to the web service I could not get the SOAPExtension to load. After spending a day researching I discover the problem is IE when sending the message uses HTTP GET and this does not get intercepted by the SOAP Pipleline. Finaly I had to use Altova XML SPy to send test message to the service in order to debug. Finally it is working now; just got to finish my Logging, Validating, Authenticate, Timing and Exception throwing SOAPExtension library.

Thursday, September 07, 2006

Companies get the systems they deserve

Over the past couple of years working with various clients in Australia, Eurpoe and US I often came accross organisations whose applications were siloed and in total mess. During these times I did often wonder how did they get there, understanding that is partly the way to help them get out of it. Recently I came accross following quote and I think in few lines it aptly sums up the issue. Challenge is how do you fix something as fundamental as this.

Jim Crookes, Chief Architect at BT has observed,
“Companies get the systems they deserve. A company's systems estate is a result of its culture, organizational history, and its funding structures. Coherent, well integrated systems will only ever exist in companies that value coherence and integrated service.”

Tuesday, August 29, 2006

Just when you thought VB6 was dead

I recently came across this while reading Australian IT and could not resist the urge to blog about it. Sun and Microsoft have teamed together and released Semplice. You might be wondering what is Semplice. Project Semplice - Visual Basic for the Java Platform, yes indeed. It will allow you to compile your program to Java platform and run it on any platform that JVM supports. You never thought that it would be possible to run VB6 on mainframes did you. Well here is your chance :-)

More details here, have fun. Would be interesting to see how this technology is received and pans out.

Sunday, August 06, 2006

Business architecture

When doing Enterprise Architecture for any organisation, most people tend to start from bottom up. They would map out the infrastructure architecture (more or less what assets they have), application architecture and may be their information architecture. What often gets left behind is the business architecture, fundamentally what is the organisation trying to achieve and does all its assets support that objective. The key to achieving this is to have a solid understanding of what business motivations are what are its strategy and then map it back to its applications and infrastructure, while maintaining all the relationships that exist between all the entities.

Just trying to visualise (Business Strategy to Function to Application and finally to Infrastructure) the scenario will send most people into a head spin, often we try to visualise the complexity using Visio or PowerPoint. These are good presentation tools but lack the depth when it comes to modelling dynamic relationships. This then leads to simplifications and the risk of abstracting the reality away just so we can fit it into the modelling tool of choice.

In next couple of weeks I will try and blog around this concept and how it then translates into SOA (Business Services vs. Web Services).

Another blog from inside Microsoft Word 2007 Beta as you can see I am loving this.

My first Word 2007 Blog post

This is a test blog to see if I can publish from right inside Word 2007 Beta.

Monday, July 03, 2006

Excellent Enterprise Architecture Books

For past few weeks I have had the pleasure of working with Adrian (he is a Principle in Architecture and Strategy Team), during this time we have had numerous discussions about what should make an Enterprise Architecture. Surprisingly we have been in violent agreement all the time. He shares the same view as me EA is more that IT it should encompass all aspects of an organisation including manual tasks. Often when we focus too much on IT aspect is when we miss the flow on effects manual tasks have on IT dependent processes.

Adrian being more experienced than I am (having been Chief Architect for 3G at Vodafone in UK), has written a simple book on the EA framework that he has developed during his career. I would recommend it to anyone considering some light reading on the topic.

Book Details:
"An Enterprise Architecture Development Framework: The Business Case, Framework and Best Practices for Building Your Enterprise Architecture" : by Adrian Grigoriu

Sunday, July 02, 2006

Some changes for good in my life

I have been silent for a long time on this blog and it has been due to some personal reasons. Most of you who knew me professionally were aware that I was working as National Lead Architect for Volante Software Solutions in Sydney. Volante became target of a hostile takeover by Commander Communications and they won after a protracted period. At this point I thought it may not be a bad idea to explore greener pastures.

Couple of months back I got a firm offer from Oakton to join their Enterprise Strategy and Architecture team as an Enterprise Architect. I did accept the offer and for past one month have been working with them. Having said that I am still passionate about technology and Microsoft .NET so will continue to blog about that including SOA, and some new areas around Business Architecture, Application Architecture, Information Architecture and what ever else that catches my fancy :-) .

Monday, February 13, 2006

Agile dev end of life, Waterfall is back

For all the SCRUM and Agile people out there, Waterfall is back have a look at this conf and meet all like minded people.

One of the guys at work sent me the link after I had been pestering everyone why Agile is so cool....


I found the following really funny and will resonate with all Architects.

"If designs are ruined by execution details, then we should divorce designs from execution. Implementation is harmful to designs! Implementation ruins the elegance, beauty, and symmetry of designs. The problem is execution; and so it is execution that must be eliminated. As a community of designers we need to insist that our designs remain unexecutable!"

Saturday, January 28, 2006

Every thought what would happen if Amazon and Google were to merge

This is an old movie but a classic it looks at how we bloggers are changing the world, what would happen if Google and Amazon were to merge and become one company how will Microsoft respond. What will happen to all of us the 2014.

Have a look at this might change your perspective at things.

I remember at the last Code Camp in Wagga Wagga someone (an un-named person :-) ) said, "I don't buy books any more, prefer to read blogs instead" think about that after seeing this movie....I am already seeing in my profession what I call Bloggitechture (Software Architecture by blogs ).

By now I think I have pissed of quite a few people so let me stop now.

Wednesday, January 25, 2006

Ever wondered how much your blog is worth

This one is worth B$1,297.49 there is a web site which calculates what blogs are worth. Mine is way lower than Frank's which is worth a princely amount of B$19,216.04. You can check your blog rating out on this page . This is the trading history of Franks blog

Sunday, January 15, 2006

Future Shock and our daily lives

For those who know me, will know my fascination for the book Future Shock written by Alvin Toffler. He was recently in Sydney Australia and said the following in his interview with Australian Financial Review.
"The issue is not jobs but creating value, creating something that someone else needs," he says. "Whether you get that through a regular, paid job, whether you do that as a freelancer, or whether you do that as a group that forms itself for a purpose and then folds up its tent."

Everyday we worry about the fact where our next job is going to come from, how will Indian outsourcing engine will effect us. Yet we continue along creating value for our customers and employers hence remaining employed. Fundamentaly I think the day we stop creating value will be the day we slowly start moveing towards unemployment.

His other thought that interested me the most was "It a period in which wealth is now mobile and we can reverse the tyranny of distance because value is so often based on intangibles and weightless products. ". Which is so true did I write a kilo of code today :-) or how many kilos of software did Microsoft ship this month.

Anyway I am eagerly waiting for his new book "Next May, Toffler publishes his latest book, Revolutionary Wealth (Alfred A. Knopf), about the way we are making money and will continue to make money in the knowledge economy. " April 25th to be precise.

Saturday, January 14, 2006

Chatty or Chunky Interfaces

I came across this article sometime back and thought to share it around. I have often discussed this during interviews and architectural reviews and was really surprised to find how many developers and solutions architects fail to comprehend the performance hits between chatty interfaces and chunky interfaces. This is especially true for web services, I can give more examples of bad Web Services implementations with 100's of method calls running over internet or WAN's resulting is slow or badly performing applications. Some of the classic implementations are where the developer decides to decorate every function call in their business logic layer with attribute and rest is history.

One such Architecture that I had the privilege of working with was Oracle Forms running over internet. Forms sends every user click back to the server for processing, this results in very bad user experience over slow connections and sometimes database corruptions. Let me just say I don't work for that organization anymore and all the issues I had predicted at design time are croping up now. Oh well all you do is say if your boss does not listen and you know it is going to be a disaster polish up your resume :-).

Ingo in the following article really sums up the issues involved with chatty interfaces. Fundamentally if you have an application in production using chatty interface, better start working on improving the speed of light :-).

Pasted from <>

Latency vs. Bandwidth – Developers vs. Einstein

One piece of The Ultimate Wisdom which is quoted quite often is that "chatty interfaces kill the performance of a distributed application". But actually, it's not the chatty interface which kills it - the really limiting factor is instead one of the handful of unchallenged physical constants of this universe: the speed of light. But let me come back to this later.
Whenever something - and this can be something non-physical like a stream of bytes or a huge chunk of extremely physical rocks - needs to move, you can choose between a set of different alternatives in the way you transport it: You can transfer as much as possible in one go, or alternatively, you could take multiple round trips with smaller amounts of your payload. When you're a teenager moving out of your parent's house, you will quite likely just pack your stuff into your and your friend's cars and just hit the road, going back and forth a few times just to get out as quickly as possible. Years later, after you bought and sold the right stock at the right time, you might instead hire someone to move everything from your 8 bedroom home in one state to your new mansion in a different state using just one big truck and trailer. (Unless of course, you had special help with your choice of stocks, in which case somebody will move you with a rather small car to a rather small room in your final roundtrip for the next 15 years.)
Is Bigger Better?
Despite the fact that reducing the number of roundtrips usually decreases the complete processing time, the usage of smaller units of transportation also has a few advantages: you can for example unpack the first boxes and start using their contents while the rest of your flat is still being sent in smaller packages. That’s what we ended up calling streaming. (My wife would now point out the fact that somebody in our family always managed to be out of the country whenever the two of us moved. That’s what we ended up calling slipping away. Unless you are my wife, in which case you would have use a slightly more explicit term.)
You also get the benefit of being able to use the smaller self-contained packages which might arrive out of sequence. In computer systems, this is sometimes implemented by only returning a small response (let’s say only the header information) as the answer of a synchronous request while returning the detailed information asynchronously using a message queuing system. In real life, I tend to implement this during my regular commuter flights: no matter whether or not my checked bags are delayed or re-routed, I will always have my computer, a power adapter, a toothbrush, and clothes for the next day in my carry on luggage. Especially when traveling via CDG or LHR.
The Speed Of Light – Or: In Doubt, Assume Bandwidth
But in any case: the general recommendation is that chunky interfaces are better than chatty ones. This suggestion is based on the belief that, in doubt, you should assume high bandwidth but not low latency. And this belief in turn is grounded in one ultimate fact: the former can be bought with money – the latter can’t.
I’ve been online since 94. At that time I used a 1200 baud modem to connect to the Internet via terminal dial-in to a Unix box. For me the WWW was Lynx, but that’s a completely different story. At that time, I could send a ping from Europe to the US in about 1200 milliseconds. Today, I can roundtrip the same ping in about 120 milliseconds. But today, I can download the full 3629.6 MB of Visual Studio 2005 Team Suite in approximately 6 hours from a random hotel room. This is coincidentally what I’m doing right now which triggered the writing of this article.
The Long Walk
If I would have done the same thing back in ’94, it would have taken roughly 367 days to transfer the 3,805,911,450 bytes with approximately 120 bytes per second, including start/stop bits and hardware compression. Just to put this into perspective: let’s assume that your hotel room is at the point on this earth which is the farthest away from Redmond. (The fact that penguins will be the only neighbors on this small island might make you think again about the likely roots of the Linux mascot.) If you would have received divine help to walk over water towards the Microsoft HQ, something interesting would have happened: With a swift pace of 5 kilometers (3.1 miles) per hour for 12 hours a day, you would have finished the roughly 20,000 kilometers (12,427 miles) on the earth’s surface in 333 days (23.7 fortnights) which means that you would have had your hands on Visual Studio about a month earlier than your friend who started the download at the same time when you left the island.
Now, of course, this would not have helped you too much as you would have had to wait two more years for a DVD player to become available 1997.
But I think that it’s really interesting to see that the end-to-end bandwidth increased by 1468 times within the last 11 years while the latency (the time a single ping takes) has only been improved tenfold. If this wouldn’t be enough, there is even a natural cap on latency. The minimum round-trip time between two points of this earth is determined by the maximum speed of information transmission: the speed of light. At roughly 300,000 kilometers per second (3.6 * 10E12 teraangstrom per fortnight), it will always take at least 30 milliseconds to send a ping from Europe to the US and back, even if the processing would be done in real time.
That’s why most people recommend chunky interfaces instead of chatty ones to optimize for higher latency instead of smaller bandwidths: The latter will be solved automatically; the former only if you prove Einstein wrong.

posted on Tuesday, November 08, 2005 8:38 PM

Saturday, January 07, 2006

Found a solution architect

Remember sometime back I had blogged about the fact I was looking for a Solutions Architect, well after a long and hard search finally found someone, it came as a pleasant surprise to find out he blogs as well ( Out of personal experience I can tell you this it is quite hard to find the right person you just have to keep your standards up and persevere). Check out Arons blog he is cool and passionate about .NET, in some respects I think a bit more than me.

Welcome aboard Aaron.