Archive for the ‘business value’ Category

IASA: making architecture work

Monday, October 19th, 2009

Last week I spent three days in Manhattan, attending the International Association of Software Architects (IASA)’s IT Architecture Regional Conference (ITARC) in NY. That’s a long time for me to be anywhere – so why did I do it?

The first answer is the speaker lineup – there were keynotes from Len Bass of Carnegie-Mellon’s SEI; Grady Booch (IBM Fellow and self-styled “Free Radical”); John Zachman (yes, that one); Eric Evans (the champion of Domain Driven Design); and Angela Yochem (one of IASA’s Fellows – perhaps not as widely-known, but certainly just as important as the others – see here). I thought I might pick up some interesting tidbits..

The second answer is that I was scheduled to present the findings of MWD’s recent survey conducted in partnership with the IASA – looking at how IT architects are approaching the subject of Cloud Computing (we’ll publish a report detailing the findings in November). Here, I thought I might be able to share some interesting tidbits…

Having let what I heard and saw at the ITARC event sink in for a few days, I have a lot I want to write – much of it will have to wait for future blog posts. Here, I’d like to concentrate on my overall feelings about IASA, after spending 3 days pretty deeply “embedded” with many of its leaders.

1. IASA has a big ambition – to create a global professional body for IT architects. There’s still a lot of work to do, but the level of drive and momentum within the body is very very impressive. Being able to get the above people to hang around a conference for 3 days is a difficult task: the fact they did so is a fantastic validation of IASA’s vision and passion.

2. The issue that kept popping up in hallway conversations and during breaks, as well as in many of the sessions, was how to demonstrate the value of IT architecture to other stakeholders (business sponsors of IT investments, other parts of IT organisations, and so on). What was interesting to me was that although a number of the speakers touched on various aspects of this issue and how to address it, there’s no “place to go” to find a coherent body of advice to those struggling with it. Or if there is, no-one seemed to know about it. There obviously is an answer (or at least, a set of working principles) – I saw a lot of good advice being presented – but curating this body of knowledge and crystallising it is something that IASA needs to make a priority.

3. There’s still a lot of uncertainty in architecture circles about the “right” relationship between enterprise architecture and software/solutions/system architecture. Are the two disciplines actually two parts of the same discipline? Are there any connections between them? Where do they overlap? What can each group learn from the other? Despite very definite views from some of the IASA leaders, it’s clear that other senior figures have other views – my feeling is that this one still isn’t resolved.

I always suspected that IASA was an important industry organisation – and following the event, I feel doubly sure about that. It’s easy to malign IT architecture as a discipline that’s overly introspective and navel-gazing, and to deride IT architects as uber-geeks with more interest in tools and techniques than delivering business value. There are certainly examples of this behaviour that we can all probably recount. But it’s clear to me that IASA is determined to help IT architecture professionalise, and maximise the value that architects deliver to internal and external customers.

I heard a lot of really great stories at ITARC NY about how IT architecture, done right, can deliver real value. Now more than ever, as organisations become saturated with IT, architecture practice is vital if organisations are to minimise the cost and risk associated with change, and maximise business flexibility. Nevertheless, as IASA’s CEO Paul Preiss pointed out in his update talk focusing on the IASA’s new certification programme, “today, my hairdresser needs to have more in the way of certification than an IT architect typically does”. That’s a sobering thought.

IASA is on a journey and there’s a way to go – but if you’re an IT or enterprise architect, or would like to find out more about what they think and do, then I would urge you to explore what they’re up to.

Notes from CloudCamp London #5 – what would stop you from using Cloud?

Saturday, September 26th, 2009

On the fifth attempt, I finally managed to attend CloudCamp London earlier in the week. I’m glad I went – the “camp” format isn’t for everyone, but it works well for topics like Cloud Computing where most of the value is in networking and hashing out ideas/arguments.

The latter part of the evening was given over to sponsor talks and side discussions, and I proposed a session on “what might stop people from using Cloud Computing?”. I thought it was only fair that I also stuck my hand up as a volunteer to moderate the session, and hey presto.

It probably makes me way uncool to admit this, but this was my first ever “camp” – so I wasn’t really sure what to expect in these sessions. What kind of moderation do people want/expect? At the end of the sessions, does everyone just disperse and forget what was discussed? So I decided to just play it old-skool – write notes and promise to write them down so that everyone could read them afterward and comment if they like.

Hence this post – a record of what was discussed in the session. It’s a bit sketchy – reflecting the state of my notes!

If you were at the session and think I’ve missed or misrepresented anything or have any fun insights to add that you’ve noodled on since, please comment! Also, it would be great to get feedback from other readers who weren’t there – are there any other points you’d add?

Thanks to all those who came – I thought it was a really enjoyable session.

General discussion of barriers

We pretty quickly decided that it only made sense to discuss “barriers to use” in the context of perspectives – IT practitioners are likely to have different concerns than business decision-makers, for example. These are the main points we discussed:

  • IT practitioners – They’re likely to have concerns about the ultimate impact on their jobs and the potential of Cloud to take power away from the IT department. Uncertainties regarding processes around platform change management and dependencies. Concerns about security. Concerns about integration, latency and lockin.
  • Business decision-makers – Is Cloud really just a cost-cutting proposition or is there more business value there? Can Cloud help us make money as well as save it? [The point was made that when new opportunities arise that are to an extent poorly understood, people tend to want potential benefits to outweigh potential risks by a significant margin - say 10x]. It’s still too early to say what ROI looks like for particular scenarios. Regulatory compliance risk and legal uncertainties rear their heads.

Other factors relating to potential for Cloud adoption

We quickly moved on to talking more broadly about IT and business environments and how particular factors might affect the attraction of Cloud Computing.

Something that came up pretty quickly was that the “barriers” at the forefront of people’s minds would be very different depending on whether an organisation was looking at a tactical entry into Cloud use, or making a strategic entry. The type of entry point will drive significantly different perspectives.

One discussion that was particularly interesting to me was around the cultural dynamics within organisations – competition and power struggles between different IT functions, between different business functions, and between IT and business functions – and how Cloud Computing and Cloud-based applications could easily exacerbate these turf wars. Without clear leadership and governance structures in place the turf wars that invariably exist will prevent effective strategic entry into Cloud use, and will also likely severely hobble the value that can be obtained from tactical entry.

We also noodled on the potential value of sector or community-specific Cloud propositions – whether delivering specialised Cloud environments would make potential customers’ objections easier to identify and deal with and the value of Cloud clearer. We didn’t really come to a clear agreement – the overall feeling seemed to be that the potential advantages might be offset by economy-of-scale disadvantages (for example).

Other observations and talking points

“Cloud Computing is the new Microsoft Access”. Will it lead to IT chaos, fragmentation? What do we need to do to prevent this? [See the governance discussion above]. Is there a danger that Cloud could be like crack – highly addictive, easy and cheap to explore and dangerous? It seems that certainly for strategic entry into Cloud use, solid enterprise architecture and IT governance practices will be important pre-requisites.

“All the benefits relate to processing; all the risks relate to data”. This was a fascinating thought that bubbled up (sorry, I didn’t note who mentioned it – let me know in the comments!). I’m not sure I entirely agree (some use cases for Cloud are more around collaborative information and knowledge work, and these are very different from the “Cloud as Grid Computing 2.0″ use case which is definitely about processing).

This quickly led to a discussion around regulation and how it typically drives a focus on the stewardship/protection of data – but how it also lags behind actual risks present in the environment. We talked about how – if regulation was of no concern – there would be real merit in considering that a large Cloud platform provider is likely to be able to manage data security risks better than your average IT department – because the existence of their business depends on it. Regulation, however, has the power to curtail that train of thought pretty quickly.

Seven elements of Cloud value: public vs private

Friday, July 3rd, 2009

In last week’s post on the seven elements of Cloud computing’s value, I said that the simple model I put forward looked like being a nice way to compare different Cloud approaches and offerings and see what’s really being offered. There’s a lot of people jumping on this particular bandwagon, and a lot of the time it’s not easy to see what’s really going on.

In this blog entry I want to use that model I introduced last week to try and clearly demonstrate the difference between “public” cloud offerings (third party owned and managed, remote installations that you rent capacity from) and “private” cloud offerings (infrastructure that you install and own, but that implements many of the technology platform features found in large “scale-out” server farms run by public cloud providers). I’m not diving into the technology detail here, but rather showing how the value you get from each type of offering is different.

In the diagram I’ve drawn lines around each of the “cloud value element”. Thicker lines mean that more emphasis is placed on that value element; where the value element appears fainter, the value element is de-emphasised or missing.

So, in a nutshell: public cloud offerings typically major on the strategic and economic value elements, and quite often – although the architectural value elements can be there – they’re not talked about quite so much. Private cloud offerings, on the other hand, are *all* about the architectural value elements – virtualised resources, management automation, and (in some cases) self-service capacity provisioning.

Another slightly simplistic way to think about private cloud offerings is that they’re basically like 21st Century mainframe computers. Built using commodity hardware, yes – but layered with virtualisation, sophisticated SLA-driven management, capacity management, billing/chargeback… this looks awfully like a mainframe (again, from a value perspective, not from a deep technology perspective).

So: public and private cloud offerings: “like chalk and cheese” (as we say here in the UK). That’s not to say that one is better than the other: just that they’re different, and it pays to understand the kind of value you’ll receive from each.

Just like I said in my last post: I don’t pretend to have all the answers here, and I’d love to hear your thoughts on this. Please let me know what you think!

The seven elements of Cloud computing's value

Thursday, June 25th, 2009

Last week I was invited to speak as part of the London leg of TIBCO’s NOW roadshow, which focused primarily on Cloud computing and TIBCO’s new Silver offering (you can see what we think about that specifically in this report).

My job was to talk about “articulating the value of Cloud computing”. This was a fun challenge: so much of the talk about Cloud today starts by arm-waving at the 30,000ft level – and then zooms right down to the level of “virtualised compute resources” and “dynamic scalability”. What I hadn’t seen so much of was an attempt to map out more of a big picture of the value that Cloud computing can potentially deliver in the context of other approaches to consuming IT infrastructure resources.

So after reading countless blogs, conference proceedings, customer stories and news articles, I sat and stared at a blank piece of paper for a while, thinking about how I could pull all the different perspectives together to show one picture that captures all the different ways in which Cloud computing can potentially deliver value. This is what I ended up drawing and presenting in my talk:

You can see that there are seven elements of value I’ve highlighted, and they fall into three “value types”: economic, architectural and strategic.

  • The economic value of Cloud is largely about being able to align the timing and size of the investments you make with the value you receive – variously referred to as “pay as you go”, “pay as you grow”. You don’t pay $millions for infrastructure that only delivers value months or years later; you pay for what you actually need, when (or soon after) you use it. And you don’t purchase an asset that then depreciates (like crazy).
  • The architectural value of Cloud is about having an simple, consistent abstract environment presented to developers and operations folks that hides a lot of complexity, making it much quicker and easier to develop and deploy applications.
  • The strategic value of Cloud might be easily conflated with the economic value, but I think it’s different. It’s this: Cloud platforms help you focus on what makes your organisation more effective and different, and leave all the other stuff to a third party that is dedicated to doing a great job for a competitive price. This is about focus and it’s also about avoiding having to train people to do things that fundamentally don’t add value to your organisation (think “Lean IT” if you like.)

Have I captured all the potential elements of Cloud computing value? I’m 90% sure I have – but if I’ve missed something please let me know! Either way, the discussions I’ve had around this picture so far make me think that it’s a useful model for exploring different Cloud propositions as stated today and comparing them. What do you think?

Next up: I’ll post another version of this picture that contrasts the value of “private” and “public” Cloud propositions. Both types of propositions have value – but it’s important to be clear about what that value actually looks like in each case.