HostGator is Safe Harbour Certified

Image via CrunchBase

According to a recent HostGator May 2010 Newsletter, they are now Safe Harbor Certified.

Though this isn’t directly related to cloud computing.  It is interesting in that is shows hosting services in USA are becoming sensitive to the fact that overseas privacy regulation and concerns are more stringent than those imposed by USA.

In Australia, the Australian Prudential Regulation Authority (APRA) is apparently still not fully comfortable with the private information of customers of Prudential Wealth Management heading overseas.  You can read here about how the jury (APRA) is still out on whether or not they are comfortable with Prudential’s plans to use Salesforce.com which is hosted in the USA.

I am not aware of any agreement between Australia and USA or other country that is similar to the EU – USA Safe Harbour agreement.  The most likely place we need to establish such an agreement with is Singapore as that appears to be the target hosting site for the big clouds (Amazon, Azure) in Asia region.

Dialogue over Diagrams

In thinking how Agile changes the role of an Architect, I keep thinking about the Agile Manifesto Axioms or preferences.  For the Agile Architect, I think we need to add a new one:

As with the manifesto, we’re not saying that diagrams are  no longer required.   A diagram is still worth a thousand words.  Also, what would we do with our Visio and UML Tools?

The point of Dialogue over Diagrams is not to say we don’t need diagrams.  The point is that, as Architects, we need to remember that the Diagrams are not the final objective.  Working Software [products] is the final objective.  Working software comes when there is a common understanding between owners and builders of what needs to be built and how it needs to work in order to satisfy the vision of the owner.

I believe the best and fasted way to achieve common understanding is through dialogue.  The diagrams are still necessary, but they are no longer your primary focus.  They are enablers.

Starting The Agile Architect

What’s an architect to do when the team goes Agile?

The Agile Architect is a project I’ve started with with Peter Wennerstein of Icon Innovations.   The inspiration came when the leaders on the project I’m working on decided we were going Agile and sent everyone to Scrum training.   The Vision is to give guidance and encouragement to all the architects out there who want to be a valuable part of Agile projects.  I’m putting together my experience as a leader in Software Development and long time Solutions and Enterprise Architect.  I’m teaming up with Pete because of his passion and talent for communicating with images, icons and multi-media.  I think we’re going to have a lot of fun with this and hope it really helps you on your journey down the path of becoming an Agile Architect.

If you are interested in this topic, please leave a comment to encourage me in this projects.

Thanks!

Security in the Cloud

A while back I blogged on security in the cloud – whose data is it in the cloud.  I’ve recently been more interested in this topic and come across an article from the Application Development Trends.

Cryptographers Warn About Security Dangers in the Cloud at RSA

In the article there was –

predicted a “trust meltdown” for the security industry if that doesn’t change. “We have complex operations in place in tightly intertwined systems, and the processes are not well understood or analyzed, but they are widely used and trusted. That’s a recipe for disaster.”

But it did not proceed to explain what precisely these vulnerabilities are.  I cannot discern whether this is simple fear mongering or if indeed, we are all little “Alices with a key” hoping our data is secure in the cloudy wonderland.

Agile in a Waterfall Enterprise – Agile and PMP

If you’ve been working in software development and system implementation for large enterprises like I have, you can probably relate to the tension between knowing that Agile approaches really do have good results, but the governance processes of the enterprise are Waterfall.

I’ve recently been working with a team who have been trying to adopt Agile methods, but who rely funding from our central Project Approval Committee (PAC).  The PAC submissions and governance processes such as Information Security Certification and Architecture Certification are designed around Waterfall, not Agile.  So, we have something of an impedence mismatch.

Turnkey Grails

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.

Turnkey Virtual Appliance is Brilliant

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.

Moving the conversation from point-to-point to SOA

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.

 

Technical Debt Metaphor

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.

 

Culture of Communication vs a Culture of Fear

Does your organisation have a culture of communication or a culture of fear?

This thought came to mind while I was having a discussion with a System Owner recently.  He wanted to establish a forum in which like minded people could share their experience on how they had solved various technology problems they faced.  Examples of these include how they achieved SOX compliance or high availability.

At first blush, this seems like a great idea.  Surely there are people in the organisation who are facing problems that have already been solved.  This forum will be a good chance to encourage reuse and help people develop their presentation skills.

What about the culture of fear?

There is a dark side to this well intended idea that came to mind.  What if someone presents their solution and we find that their solution is contrary to one of the myriad standards or strategies in the organisation?

In a culture of fear organisation, I imagine there will be someone in the room who shouts out that the solution is not strategic or non compliant.  Now that it’s in the open, the sharing team will be lined up and shot and the organiser of the forum reprimanded for instigating proliferation of non-compliance.

Perhaps that’s a bit of an exaggeration.

Eliminate the Culture of Fear

If you want more reuse and communication in your organisation, you need to eliminate the culture of fear.  People need to feel free to tell the truth about what they are doing without fear of reprisal.

Standards and strategies are valuable and important.  But we should be careful about the organisational impact of fear.  What happens when people stop speaking freely?