Turnkey Grails

December 20, 2009 Leave a comment

When I discovered Turnkey Linux, which I think is awesome, an light bulb came on about how virtual machines can be extremely useful for me.  In my work, I may switch frequently from one activity to another.  Each of these activities require a different software tool set.  In the past I would accommodate this by installing all the different tools I need onto my desktop at work.  Then, if I wanted to do some work on my home laptop, I’d find myself reinstalling the same set of tools.  Obviously this isn’t the most effective way to work.

I have never spent much time working with virtual machines because I really thought they were most useful to vendor or pre-sales guys who need to demo a complete stack of technologies without having to install them at a given site.

Read more…

Categories: Cloud Tags: , ,

Turnkey Virtual Appliance is Brilliant

December 20, 2009 2 comments

I have just come into the opportunity to buy a small business that, among other things, will immediately need a new web site.  From my other posts you’ll gather I’m an IT guy.  But lately I’ve not been so hands on.  I’m working in Strategy and Architecture.  I have in the past setup the LAMP stack on a spare home PC, one step at a time.  Now I’m thinking more like a user than a techie.  I don’t want the thrill of understanding every little config file under /etc and what it does.  I also don’t want to mess with an old PC.  I have my Macbook Pro and I certainly don’t want to mess it up.

Categories: Uncategorized Tags: ,

What I love about Australia

December 1, 2009 Leave a comment

I’m an American living in Australia now for just over 10 years.  I first came here because I fell in love with Sydney and the amazing beaches.  But I’ve remained for a deeper reason that I have felt, but couldn’t really put my finger on it.

I’ve had trouble explaining what it was about Australia that makes me stay.  But a recent newspaper article about a famous cartoonist has really helped to clear it up for me.

Interestingly enough, the article is about a famous political cartoonist named Pat Oliphant. Anyone who’s ever read the Washington Post would know Oliphant.   Having grown up in Washington DC, I always thought Oliphant, was an American.  Well guess what, he was born in Australia!

So, the revelation about why I love Australia is not just that Oliphant is really an Aussie.  It is what Mike Steketee, of The Australian, wrote in his 14/11 article in the Weekend Australian about Oliphant.  In there he explains it is perhaps [Oliphant’s] Australia attitudes… why Australia turns out so many world-class cartoonists: a natural inclination to challenge authority, a larrikin streak, a preference for plain speaking and not taking yourself too seriously.

When I read this I thought, wow, that’s it!  It’s the Australian Attitude. That is what I love about being here.  That is what I see in my best friends in Australia and to a large extent, it describes me.  Must be why I feel at home here.

Thanks Mike!  Thanks Australia!


Categories: Uncategorized Tags:

In the Cloud, whose data is it?

November 17, 2009 2 comments

I just attended a promotional event by NetSuite in Sydney.

When I got back to the office and started speaking with a colleague about how interesting the NetSuite proposition is, he conveyed to me a horror story he had recently heard about a Cloud or SaaS Customer.  It was a small business who had all there business records / erp / gl in the SaaS application and for some reason decided it was time to move on to another solution.  Trouble came when they requested their data and the supplier said, “it’s not your data, it’s mine.”

Shock horror I thought.  This is supposed to simplify the world for SME’s but now they’re going to need a crack legal team to protect them from the evil cloud. I was a bit shocked at this prospect, so decided to do a little research – kind of a snopes or myth busters act on this loss of ownership of one’s vital business data in the Cloud.  Here’s what I found.

You cannot delegate responsibility

Read more…

Moving the conversation from point-to-point to SOA

November 3, 2009 1 comment

I’m currently working as the Architect on a large Calypso implementation. Integration with the surrounding systems is clearly critical to our success. As usual, we are under very tight time constraints  I am participating in recurring working groups where we are reviewing all the interfaces that currently exist and determining how we should replace them or reproduce them.

My continuous reminder of thinking in terms of Services is probably very frustrating for the Business Analysts in the room.  They of course are concerned that their task in the project plan says, “Write the Business Requirements Doc (BRD) for the Systems X to System Y interface by next week.”  They really do not want to consider the possibilities and try to think about this a little differently


It’s not about the SOA Stack

No offense to my friends at Tibco and WebMethods who sell the technologies in the SOA stack, but it’s not about your stack.  We bought the stack and we’re still not SOA.  Until we start people thinking about the interactions of systems as one providing a Service and the other Consuming it, we are still going to be implementing specialized point-to-point interactions on top of some very cool and expensive technology.

Stop thinking like an Architect!

I’m sure many of you’ve been in these same type of conversations where you go though the list of existing interfaces and ask, “do we still need this one?”  As we go through these, I keep trying to drive the conversation away from interfaces and towards looking at what Service does a given legacy interface provide for whom rather than say, “this interface must be built.”

“If we look at what’s going on in this interface and build it as a Service, then we can reuse it,” I tend to say.

Half way through one of the above sessions, one BA whom I’ve known a long time half jokingly grumbled, stop thinking like an architect! Because he did not want to re-scope or revise his BRD’s just for the sake of what to him appears to be technical purity or unnecessary elegance.

I persist though in my doggedly determined manner.  Ask them to humor me a little longer, “…bare with me, be patient, you’ll see,” I say.  The people in the team are willing, so we entertain my way of thinking a little longer.  Finally there comes the moment, where the lights come one.  We’ve moved on to another interface.  As we dig in, we discover that this other interface is performing nearly identical function as a previous one.  I can see the result almost immediately.  Very quickly rather than having two more interfaces, we start having one more Consumer of an existing Service.  When that reduces time required to finish the project, finally the project manager smiles and is glad someone recommended he add an Architect to his project.  Keep thinking like an Architect, he says.  As a matter of fact, can you teach my whole team to think like an architect?

Now I’m happy!  We’re on the way to SOA and we haven’t hat to boil the ocean.


Youth with a Mission

October 30, 2009 Leave a comment

Here’s an idea – fund your mission with Amazon Links

Categories: Uncategorized

Technical Debt Metaphor

October 27, 2009 Leave a comment

As an architect in financial markets, I love the Debt metaphor described in Martin Fowler’s Blog as attributes to Ward Cunningham.  A simpler version the metaphor is pay me now or pay me later.

The essence of the metaphor is, when you are faced with a design choice with a quick and dirty solution as one option and a more appropriate, but perhaps more expensive alternative, picking the former option is like borrowing money.  As with financial debt, you will likely pay interest along the way and ultimately pay the prinicple in the future.  The interest is the pain the team feals each time a change must be made to the quick and dirty solution.  The principle is paid when a proper solution is finally implemented.

I think most people clearly understand this trade-off.  Where I find the problem lies is in valuing the debt. So, how many times will we have to change this thing?  How much difference will it make?  How frequently will it fail as a result?  Is your proper solution really better than the quick and dirty one?

In order to make an informed decision about the trade-off between higher up front cost and the technical debt, we really do need to know the valuation.  The up front cost is generally well know and expressed in dollars and time to market.  The debt is expressed in qualitative terms like, error prone, hard to maintain, etc…

Applying the metaphor to Enterprise Archtiecture

Here Charles Edwards applies the technical debt metaphor to enterprise level as the Enterprise Technical Debt.   He goes on to say that if you could explain this to a business executive in these terms, you’ll be well on your way to justifying investment in enterprise architecture.