What or Who's Driving Architecture ?

All too often I'm hired by the IT Department. First thing I usually have to do then is argue my way into the 'business side' of the company that hired me. After all, Architecture should be a business issue, not to condone IT strategy. Usually IT management grudgingly agrees.

But, when architecture is initiated by IT management, your work is a lot harder. I find it is really one of the hardest part in doing architecture: business often doesn't really care, and IT cannot sell the idea of architecture. You will have to overcome the suspicion of the business. That will take some doing, as nobody is really waiting for you. Make sure you're not on a mission to sell the IT strategy to a business that is a) not interested and b) doing a whole lot of other - more interesting - stuff.

So you really need to make clear to the business that what you're trying to achieve is aimed at achieving (long term) business goals. At the same time you need to stay on good terms with IT management, as they're picking up the bill for your hours. Another kind of trade-off than we're usually used to. The hard - but fun - part lies then in finding the balance between business and IT goals.

Sometimes you're in luck. Business is so pressured into change that it will welcome anyone who can assist them in realizing that change. But don't get used to it....

Architecture and Agility

Last night I had an inspiring dinner with one of my old colleagues, Ronald Doelen. We both see more and more companies changing their project methodology from waterfall to agile. We're both very enthusiastic about that, even though there are some hurdles to take, like architecture for example.

All and good to go Agile, but if you're stuck in an analysis-paralysis situation with your architecture, you will not reap the benefits that Agile brings. You might get away with ignoring the architecting issue - at least for the short term - but it will catch up with you in due course.

So, the answer: Agile Architecture. That got a nice ring to it, but what and how? It all depends on how you look upon architecture and the role of the architect in the company. At the end of our meal - not quite as good as our discussion, tbh - we came up with a number of statements that we'll take with us to work on in the near future. Let me share a few of our thoughts:

The role of the architect in your organization is often determined by the culture of your organization. The architectural style (ivory tower, magician, counsellor, architectus reloadus) determines how you need to adapt your agile projects to align with architecture. The more agile the architect, the less impact.

Architecture is nothing more (or less) than a (limited!) set of choices and the accompanying motivations. Often architects worry about making the best choice. In case you didn't know it yet: there IS NO BEST CHOICE! There's just choices, all with consequences. Use risk-analysis to determine short and long term implications of your choices and base your trade-offs on them. But limit the choices to those you really need NOW.

I'll spend some more time thinking about Agile architecture and especially how to align Enterprise Architecture with Agile projects. I still see some challenges, but will take about those later.

Architecture: Burden or Blessing?

I'm a big fan of architecture. I really think it makes a big difference whether or not you have an architecture in place to build upon. However, I get into discussions with program- and projectmanagers, who think that architecture is nothing more than a burden for the project. Often I try to explain to them what the benefit is from architecture, even teaching them that architecture and programmanagement have the same goals: realizing business goals (by implementing software).

What does seem to help, is to approach it from a different perspective: what if .... you do not use architecture to guide your development? Lessons learned from the past show us that this will lead to:
* applications with loads of peer-to-peer connections (building a convoluted network of interapplication dependencies)
* unpredictability of IT projects due to the coupled nature of the application landscape. One never knows which application will fall over when a change is applied.
* costly projects due to the unpredictability. Project risks increase, costly measures (extreme testing) have to be implemented. Changes will take longer and longer at higher cost.
* diverse landscape of different applications, tools, languages, hardware etc.
* increased IT costs due to maintaining this diverse landscape and keeping knowledge up-to-date.
* overlapping functionality, multiple implementations of the same business functionality (like customer registration etc)
* loss of insight into the entire IT landscape.

Need I go on? I daresay that architecture can tackle all these issues and deliver a clean and feasible solution. However, it does mean for (some) architects that they will have to come down from their ivory tower and participate in building the new application landscape. They have to be the missionaries to spread the word ....

Podcast on SOA Governance

A while ago I was at Oracle HQ talking to Dave Berry, product team manager of Oracle Fusion Middleware, about governance. We started out a discussion on our blogs and we felt it would be a nice idea to convert our discussion into an article.

Somehow Bob Rhubart, manager of the Architect Community within Oracle, got wind of our discussion and invited us to give our take on Governance in general. The result is two podcasts on Governance:

* OTN Arch2Arch Podcast: SOA Governance: It's Cultural
* OTN Arch2Arch Podcast: SOA Governance Perspectives.

Let me know what you think of it!