I love my new HTC because I can sit here in a lovely sunny place in Sydney and blog away.
So what does cafe blogging have to do with agile architecture?
You never know when you’ll have an inspiration about how to be agile as an architect. I find that hanging out with friends chatting about anything but work actually frees the mind to wander outside the box.
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.
I’ve launched The Agile Architect on it’s own site now.
The Agile Architect is a venture to help Architects become Agile. The inspiration came when the leaders on a very large project I was working on decided we were going Agile. My first reaction to this news was, “Great! we’re going Agile!” because for many years I have been studying Agile and applying Agile techniques to the teams and projects I had been working on. However, I had yet to be on a team where the management had totally bought in.
The Architect is typically the enemy of the Agile team. To make matters worse, I was also playing role of Enterprise Architect. In order for the project to continue to receive funding, they had to obtain Architecture Certification from me. This is similar to obtaining Development Approval (DA) from local Council. If you ever attempted to renovate or build, you will know, this is not an Agile Process.
The conflict between the Architecture and the Agile Team
The conflict between Agile and Architecture is well documented and discussed in the blogosphere. Traditionally, Enterprise Architects enforce a governance model which is based on the Waterfall Model – the antithesis of Agile. Architectures generally want a very well thought out end-state before anyone commits to coding. Agile on the other hand says, we need to make something that works and then refine it through refactoring.
Bringing peace to Agile Teams and Architects
What I truly love about being an Architect is that it generally puts me right in the middle of conflict – or what we call stakeholders with competing concerns. As the Architect, one of my key responsibilities is to perform Architecture Trade-off Analysis between these competing concerns. I always see this as a way to bring peace between these warring tribes.
When I found myself right in the middle of this brawl, it dawned on me that this is a golden opportunity. My being in the middle of this is not coincidental and I need to do something more than just survive it. I need to help others as well.
Visit The Agile Architect
So please go visit The Agile Architect. I really believe Agile will change the way we work and greatly improve the outcomes we achieve. I believe in this more than anything I’ve seen in my >20 years of experience in IT. That’s why I’m passionate about it, writing about it, doing something about it. Please visit: leave your feedback and encouragement; subscribe and engage. Help me make a big difference.
What happens to David Hall’s Blog?
I’ll continue blogging here on things that fascinate me. Sadly, that is mostly technology because that’s what I do. I subscribe to the axiom that, if you get a job you love, you never work a day in your life! If you’ve worked with me, you know I take never working a day in my life very seriously I’ll also try to mix in some writing about the Bronte sunrise, travel and fun with raising the M&Ms (the kids).
Ciao for now!
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:
Dialogue over Diagrams
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. Read more…
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.
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.
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.
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.