Archive for the ‘SaaS’ Category

From system integrator to service integrator

Tuesday, February 23rd, 2010

One of the themes we delve into in our free online framing a Cloud Computing strategy event is the emerging role of the Service Integrator. This is something I’ve been talking about for a while in discussions with clients but I thought I’d share it a bit more widely…

So what is a Service Integrator? Simply put, a Service Integrator relates to the SaaS/Cloud Computing world in the same way that a Systems Integrator relates to the on-premise computing world.

Right now we’re at a stage in Cloud computing development which is dominated by “early adopters”. Typically such companies are willing to go an extra mile to get the benefits of a new technology and technology model – things that many other companies would consider too complicated, risky or expensive.

Activities which fit into this category include integrating data and functionality (both between Cloud-based platforms and applications, and between Cloud-based and on-premise systems); encrypting sensitive data and securing communications; backing up and restoring data; replicating and managing resources to maximise reliability and availability; and so on and so on.

While today’s adopters of Cloud Computing may be quite happy to shoulder the technical burden of making remote resources “fit for purpose” within their enterprise, we should assume that most won’t. Particularly when you consider that a big part of the promise of Cloud Computing is that with this model, you’re delegating responsibility for managing technology. Why, if you’re so interested in a model of computing which is fundamentally tied to outsourcing – and particularly if you’re interested about using this model not just for one application but for a wide variety of purposes – would you choose to take responsibility for integration yourself?

If use of Cloud Computing is to move beyond tactical use in the early adopter community, there’s going to be a big opportunity out there for providers who can wrap multiple Cloud-based services and platforms up and deliver them as bundles of managed services.

So… duh… isn’t this the same thing as systems integration then? Well, maybe a little – but not completely. There are three distinct levels that a Service Integrator can work and add value at, which further blur the boundaries between “traditional” systems integration work and outsourcing/managed services provision work:

  • Technical integration. This is primarily “traditional” systems integration project work – delivering code to create and stitch custom and off-the-shelf application services together.
  • Management integration. This is managed services work that is focused on delivering seamless experiences to service consumers, to agreed levels of quality. Reliability, security, availability, break/fix, helpdesk services and disaster recovery all play here.
  • Contract integration. This level of integration work is about providing “one throat to choke”. The Service Integrator takes responsibility for all back-end contracts with resource and application service providers, and becomes the single integrated billing and payment point for the end customer, also creating a single point of liability for quality of service delivered.

Now of course many established Systems Integrators already combine work of different kinds (for example development/integration and application management) to create overall offerings for clients – but here, we see increased industrialisation of some the services provided (particularly as infrastructure providers like Informatica, Pervasive, and Cast Iron get in on the SaaS act at the technical integration layer), and also more focus on the economic benefits of the Cloud Computing model (rather than on “all-in” pricing for multi-year contracts). We’re already seeing a number of service providers stepping into this space, as well as new players springing up. Examples include (though there are many more):

Capgemini – which has created a specialised Cloud Computing centre of excellence and is providing advisory and integration services for its clients.

Accenture – which has created a set of services to help clients examine potential around Cloud Computing and SaaS.

CSC – which has launched two specific new offerings: Cloud Orchestration (principally operating in our technical integration layer) and Trusted Cloud (operating in our management integration layer).

Saaspoint – a specialist Cloud Computing/SaaS consultancy centred on delivering services based around Salesforce.com application service implementation, citing over 700 clients.

Bluewolf – which focuses on integrate a variety of services (often centred around Salesforce.com’s applications) for customers interested in driving change in marketing, sales and services processes.

For me, one of the most interesting things here will be to what degree the flexible pricing and billing models that have become expected in the Cloud Computing space are offered on to customers when these intermediaries become better established in this market. Will service integrators find ways to make margin out of Cloud Computing providers’ pricing and billing arrangements (for example by pooling a set of back-end application service licenses across multiple clients, and “soaking up” some of the variable demand for capacity that way) but not passing these efficiencies onto clients, instead preferring to drive clients towards fixed-price multi-year contracts? Or will they start to adopt more granular pricing and billing practices? Indeed, will this become an area of differentiation between the established SIs and the upstarts?

I’d love to hear what you think… this is a topic we’ll be digging into more over the course of this year.

If you’d like to check out our Cloud Computing event, it’s available free and on-demand… just go here. You’ll need a free Guest Pass ID to access the content, but signing up only takes a few seconds and you also get access to an extensive library of written research.

It’s time to start framing a Cloud Computing strategy. Are you ready?

Tuesday, February 16th, 2010

It’s easy to dismiss Cloud Computing as just another IT industry hype bubble that will one day burst, showering everyone in a slightly stale-smelling mist. Certainly, as with all waves of technology advancement, there’s been an *awful* lot of hype about the potential and – just like any other technology advancement – Cloud Computing offers no silver bullet for anyone’s IT investment or management woes.

Nevertheless our research (including a survey of 350+ IT architects in 9/09) shows that many organisations are dipping their toes in the Cloud (if that’s not a heinous non-sequitur) and they are seeing success. What’s also interesting is that some of the most eager proponents of Cloud Computing and Cloud-based application use aren’t in those industries which are typically at the leading edge of technology adoption (financial services, telecom); they’re in industries like media, retail, utilities, pharma which are more generally thought of as conservative investors in IT. This is because Cloud Computing is not a model of technology ownership – it’s a model of service delivery and consumption.

2010 will see every major IT vendor and service provider moving to offer or enable Cloud-based infrastructure and services. You need to be prepared to reap the potential benefits while managing the potential risks – and this means having a solid awareness of how Cloud Computing concepts fit into the rest of your existing IT investment portfolio. Only then can you chart a course that makes sense for you (and which won’t be driven by the proprietary interests of one or more IT suppliers).

Here’s some questions to think about that can help you frame a strategy:

  • What are the ways that Cloud Computing can deliver value, and in what kinds of scenario? How does the value of a “private Cloud” relate to the value of a “public Cloud”?
  • How is Cloud Computing really related to SaaS? What does this mean for me if I’m considering using the Cloud as a strategic source of IT services? Where does SaaS make most sense?
  • What are the tradeoffs that I’ll experience on choosing a Cloud Computing platform, and what will be the downstream effects?
  • What’s the real story with security in a Cloud Computing environment? Is the security issue a show-stopper?

With all this in mind, yesterday we launched a two-part online event designed to help enterprises frame a Cloud Computing strategy. It’s made up of two on-demand webinars which you can view at any time – and it’s completely free of charge (you just need to register for Guest Pass access to our site first – which also gives you access to a big chunk of our research library for free, too).

The event is sponsored by Google Enterprise – and we’re very grateful for their support. Nevertheless we designed and created the content without any input from Google – it’s a completely independent piece of work.

We’d love to hear what you think of this event. We’re currently exploring a number of options regarding holding future events like this, so your feedback is crucially important to us. Once you’ve viewed the content you can provide feedback right from the event home page – or alternatively leave us a comment below!

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.

Cloud computing, SaaS and SOA – the universal service network

Monday, February 23rd, 2009

Something that’s been sloshing gently around in my head for a little while came into focus the other day on reading a post by Brenda Michelson: Unintentional Cloud Watching >> Cloud Computing for Enterprise Architects. Namely, that the link between cloud computing and SOA has multiple angles.

It’s becoming clearer that, true to Tim O’Reilly’s initial Web 2.0 noodling, by providing open infrastructure services and APIs, the poster children of the Web 2.0 era – Amazon, Salesforce, Zoho, and so on – are now treading the path that companies like StrikeIron started out on in 2002.

As a result, as other commentators have noted, it looks like the bulk of the service-oriented IT that many organisations will interact with will be “stuff from outside” (commercially provided services) rather than “stuff from inside” (internally developed services). And it’s not just hosted SaaS providers who are playing here of course: there’s the issue of newer versions of on-premise commercial packaged application software products and integrations between them – SOA is coming in by the back door there, too (see SAP’s ESOA, Oracle’s Fusion Architecture). In fact, perhaps unsurprisingly, there are strong parallels here with the component-based development (CBD) hype-wave of the 1990s – a lot of the initial hype was around tools and development for enterprise IT groups, but ultimately the vast bulk of development was actually carried out by commercial software vendors, for consumption by enterprise IT teams. What we’re seeing here is a repeat of “componentware” market development, with a 21st Century twist.

Regardless of where services come from (and indeed because they will come from multiple places, creating cross-enterprise service networks), it’s increasingly the case that in order to deliver effective IT capabilities in the 21st Century, you need to understand SOA principles and build technology and management structures that really support the principles of service orientation. Much has been written about the “consumerisation of IT” and how new generations of people entering the workplace are asking difficult questions about why enterprise IT applications are so unintuitive to use. But what happens when business teams that are using SaaS-based offerings learn about the infrastructure side of the story – how easy they can be to customise, extend, and integrate with – and ask why internally-developed systems don’t exhibit the same qualities? Another slab of SOA pressure, that’s what.

Back in 2006 I was doing some research for an event that we were considering running on “IT Sourcing in the 21st Century”. As part of trying to work out what might be in scope and what might be out of scope, I drew this picture:

As the picture attempts to show, from a technology architecture point of view, the software-as-a-service (SaaS) model relates to the prior Application Service Provider (ASP) model in much the same way as SOA relates to monolithic on-premise applications – to deliver value, both SaaS and SOA need to “crack the box open” and enable IT capabilities to be customised, composed and remixed while also being shareable/reusable. There’s much I disagreed with about Anne Thomas Manes’ recent “SOA is dead” post (see Schrodinger’s SOA), but she nailed this parallel between SaaS and SOA pretty well I think.

With the increasing visibility of cloud-based infrastructure and application services in mind, anyone seriously pursuing SOA should be looking to the world of SaaS for insight, or at least inspiration. In the IT industry’s rush to SOA, many of the nuances and implications of SOA have often been condensed into simplistic advice targeted at software developers (something that’s been written about a great deal, not least by us). One of the themes we’ve returned to again and again in our SOA advice is that the concept of a “service” isn’t primarily about something you build – it’s about something you experience. If you’re going to deliver business value from your SOA efforts, you have to grasp the implications of this and make the necessary changes – not only in terms of tools and technologies, but also (crucially) in terms of your governance approach. One of the most popular posts from arch-architect Todd Biske, on ITIL and SOA, digs nicely into how it’s crucial to consider the full service lifecycle when you do SOA, and drive governance to ensure that you can deliver “real service” – not just code wrapped in XML-based interfaces.

The providers of cloud-based services should have this idea etched on their brains – and there are plenty of examples of this principle in action for any eager student of SOA. Witness the grumbles that echo when Twitter barfs, for example, or see the grumpy users trying to get to grips with Zoho’s CRM API in the face of almost non-existent documentation. These are great examples of situations where the provider’s idea of service doesn’t match the consumer’s expectation.

The rise of cloud computing and SaaS should entice us to revisit our development-centred assumptions about SOA and search for a “bigger picture” that focuses on consumer expectation and value first. The pressure to deliver business value from IT capabilities, and the increasingly diverse mix of IT capability sources, demands that we do so.

Software Delivery InFocus podcast – Developing in the cloud

Friday, January 30th, 2009

This is the third in our Software Delivery InFocus series of podcast episodes, starring Bola Rotibi – the Principal Analyst of MWD’s Software Delivery competency area. In this episode, she discusses the opportunities and challenges associated with using cloud-based software development services. Bola’s guest is Debbie Ashton, Product Director for CODA – a provider of both on-premise and SaaS-hosted financial management applications.

Although there is a lot of hype surrounding the concept of "cloud computing", there also appears to be real value to be gained in some usage scenarios. The obvious financial benefit of renting software service (being able to remove up-front capital expenditure and instead account for software as an operating expense) is coupled with the scalability that’s possible (you can pay as you go, and pay as you grow) and together it looks like cloud-based offerings will be especially attractive in the tougher economic climate that nearly all of us look likely to be experiencing for quite a while. Many organisations today are tempted to think only of the quick advantages of Cloud – partly as a result of the hype coming from the vendor community. However, whilst the potential and advantages are well documented and clear for people to see, the disadvantages or the challenges of use are not. In this podcast we look specifically at the challenges of developing applications for delivery from cloud-based software platforms. What practices if any should organisations take on board in developing applications and solutions using cloud-based development services? What processes and methods should organisations be putting into practice to get the most out of cloud development services?

CODA developed its SaaS-based offering, CODA2go, on Salesforce.com’s Force.com platform – and in this podcast episode we hear what Debbie and her team learned about developing in the cloud along the way. Thanks to Debbie for some great insights. You can download the audio here or alternatively you can subscribe to the podcast feed to make sure you catch this and all future podcasts!

As with all the episodes in this podcast series, we’ve also published a companion report which summarises the discussion and "key takeaways". You can find it here, and it’s free to download for all MWD’s Guest Pass research subscribers (joining is free).

SaaS takes centre stage at Lotusphere

Friday, January 23rd, 2009

One year on from the launch of IBM Lotus’s first home-grown effort in the world of software-as-a-service, codenamed project “Bluehouse”, SaaS is again top of the news agenda at Lotusphere 2009, and shows up as an underlying theme across the event’s big stories.

The main headline was the launch of LotusLive, a new brand for the company’s cloud-based services, which will incorporate Bluehouse, Sametime Unyte Meetings, Sametime Unyte Events and Lotus Notes Hosted Messaging, as well as a all future offerings in this space, one of which I’ll come to in a moment. In line with the new branding, each of the above products will be renamed, with the aforementioned products becoming “LotusLive Engage”, “LotusLive Meetings”, “LotusLive Events” and “LotusLive Notes” respectively.

Alongside this was more detail about last week’s announcement of IBM’s intent to acquire the assets of Outblaze, a Hong Kong-based provider of white-label, SaaS-based webmail services. Upon completion, IBM plans to offer the Outblaze technology as part of LotusLive, under the name LotusLive iNotes. In addition to adding breadth to the LotusLive portfolio which it is selling direct, IBM sees the Outblaze acquisition as providing a new business model, helping the company to develop the SaaS reseller channel through value-added services.

Other major news from Lotusphere centred on partnering activities at IBM, and again SaaS played a central role – Salesforce.com integration with LotusLive Engage and Lotus Notes, integration between the LinkedIn business social network and contacts within LotusLive Engage, and between LotusLive Engage and Skype for VoIP calls.

IBM is clearly determined to show it has a credible story in SaaS, and is working hard to deliver a portfolio which mirrors its breadth in the on-premise software space. The biggest opportunity for IBM in SaaS – particularly with the Engage offering – is clearly the SMB market, and it will be interesting to see whether it is successful here, or whether LotusLive simply becomes an extension of its established enterprise portfolio. In any case, these announcements demonstrate that it is prepared to square up to Microsoft in the battle for supremacy in the cloud.

Keep your eyes open for a new report on Collaboration-as-a-Service which we’ll be publishing within the MWD Collaboration advisory service over the next couple of weeks.

More acquisition activity in the identity space

Wednesday, March 12th, 2008
Hot on the heels of last week’s acquisition of Credentica by Microsoft, Ping Identity (who I covered here in an On The Radar report) announced yesterday that it has acquired the Sxip Access business unit from Sxip Identity.

Sxip was early to spot the potential opportunity in providing organisations with a simple, easy-to-deploy single sign-on (SSO) solution for software-as-a-service (SaaS). Sxip Access was its response to that opportunity, combining provisioning capabilities with some Sxip hosted services and an appliance. The company had also cultivated relationships with the likes of Salesforce.com and Google (for Google Apps).

The acquisition of Sxip Access is a smart move by Ping Identity. Although it can be used to provide SSO for SaaS, PingFederate (the company’s flagship multi-protocol federated identity offering) lacks some of the rapid implementation and deployment capabilities of Sxip Access. Part of the SaaS proposition is that organisations can get up-to-speed much more rapidly. Authentication and authorisation shouldn’t hold you back: something that Sxip Access should help to prevent. Back in September Ping began to actively target the SaaS opportunity, allowing providers to sell PingFederate-based SSO to their customers and share the revenue with Ping. Yesterdays announcement should accelerate this.

(As an aside, I do wonder whether we might see Ping’s SignOn.com user-centric identity offering heading in the other direction, given that Sxip is now fairly-and-squarely focused there).

Ping and Sxip, whilst they are comparatively small, punch above their weight when it comes to identity mindshare. I wonder whether this announcement might shake the much larger incumbent identity management vendors, none of whom have really articulated a credible SaaS proposition, into action. It should. SaaS buying decisions often bypass the IT organisation and the business buyers aren’t (and in fact shouldn’t be) interested in identity management: they want access. If a Salesforce.com recommends that the customer just needs to get their IT department to deploy this box and hook it up to the existing identity management solution so be it. Job done. With SaaS increasing in popularity, particularly in the SME segment where they have struggled to gain a foothold, the incumbents need a strong proposition or lose out to the likes of Ping.

Time to be honest about SaaS

Wednesday, October 3rd, 2007

I thought that those of you who aren’t recipients of our monthly newsletter might be interested in this commentary (penned by the other Neil) dissecting some of the problems with the definition (or lack thereof) of software-as-a-service.

Over the past few days we’ve been having an interesting debate here at MWD, in conjunction with the analysts at our close partner Freeform Dynamics. The question came from Dale Vile at Freeform: what’s a good definition of software-as-a-service (SaaS)? The reason for asking the question was that SaaS is a hot topic, and it’s something that’s considered as a major growth opportunity for a lot of technology suppliers; but although there are a fair few forecasts of growth in demand, it’s difficult to get a clear idea of what’s actually included in these forecasts. Of course, if there isn’t a consistent view of what does and doesn’t actually constitute SaaS then that’s not really helping anyone. The approach we took to try and provide that consistent view was to look at a long list of things (ranging from Google Search, Google Maps and hosted wikis to Skype’s VOIP and messaging services, hosted voice PBXs, online travel agency services and remote backup services), and say whether we thought they “counted” as SaaS offerings.

What came to the fore very quickly was that there was no crisp set of attributes that we could agree characterised SaaS offerings. SaaS isn’t defined (as some would tell you) by a particular type of distribution or access technology, a particular technology architecture, or a particular approach to charging for usage.

Yes, SaaS offerings do commonly exhibit particular choices in these areas (use of the web for distribution and access; a “multi-tenant” architecture to efficiently separate the data and customisations of each customer from those of others; and some kind of subscription license). But crucially, these choices aren’t unique to what most people would call SaaS offerings. Google’s services, and countless millions of other online dynamic websites, have made those same technology choices for distribution and access – and they’re commonly lumped into that whole other can of slippery worms, “Web 2.0″. Countless online portals (some hosted within organisations, others available to the public) allow users to personalise their experiences and use a multi-tenant architecture to store personalisation data efficiently and effectively. Lastly, all sorts of information- or IT-based capabilities are delivered on a subscription basis (not least, mainframe capacity, and analyst research ;-).

So what is it that marks something out as SaaS (or not)? The only answer that seems to tick all the boxes is that SaaS offerings are those which deliver online, hosted alternatives to things that we have historically experienced through the in-house purchase (or development) and deployment of software systems.

Let’s take Customer Relationship Management (CRM) as an example. Historically, CRM capabilities were provided by software that was installed on premise, was managed on premise, supported one organisation, and was paid for through a perpetual license. When Salesforce.com delivers those CRM capabilities from a remote installation, manages them on behalf of multiple organisations, and is paid to do so on the basis of a monthly subscription, it needs a different name: that’s “Software-as-a-Service”. Following that example, remote backup/restore services, online word processing applications like Google Docs, the Zoho suite and (now Adobe’s) Buzzword, and SAP’s BusinessByDesign (formerly A1S) all count as SaaS offerings. Google Search and Facebook don’t, because they’re not delivering capabilities that you would ever have associated with on-premise, perpetually licensed software.

This helps us clarify SaaS’ place in the IT industry, but we think it’s a problematic conclusion, for three reasons. Firstly, most people use the label without really understanding how context-dependent it is (what you think of as SaaS is primarily defined by your own experience); secondly, if we continue down this road, there can never really be a consistent definition of SaaS that will work for everyone; and thirdly, this is a very IT industry- and supplier-centric way of looking at the world that is only likely to alienate or confuse a very important community – “users” (the people who pay all our salaries).

Perhaps we need to call time on SaaS, and think of some clearer terms and definitions that can really help IT organisations and IT buyers work out how everything fits together. At the very least, as an industry we need to be honest about SaaS – and explain that it’s an industry-driven marketing and positioning term that’s primarily about separating “funky new stuff” from “boring old stuff”.

Real-world Enterprise Architecture part II: conversation, federation, road trips and tools

Tuesday, May 15th, 2007

In my previous post I explained how in order to get real value out of Enterprise Architecture (EA) work, it’s critical to focus not only on the outputs of EA work, but also on the process/practice of EA – and moreover that the process/practice has to focus on *conversations*.

What does this mean for tools, technologies and methodologies which purport to aid architecture work of different flavours? To get to the bottom of this, it’s important to add another thought into the mix, which concerns the nature of IT work in large organisations.

What we found in our research for our book is that in large organisations (which are of course the organisations most likely to be pursuing EA activities) IT work is only very rarely truly centralised. Even where there is “officially” one central IT department, the reality is most often that there are other pockets of IT activity that happen elsewhere – perhaps in subsidiaries, remote offices, or within particular business departments. What we also found is that it’s pointless trying to centralise IT work and force all IT activity to happen in one place. A top-down, centrally enforced IT mode of production might work for a short while, but soon enough entropy will work its slippery spell and projects will start springing up elsewhere (this is just one reason why the book is called the Technology Garden).

In reality, then, there’s little point in planning and executing high-level architecture work in a highly centralised fashion, when IT work is actually federated. At least part of successful and value-adding architecture practice is going to be conducted on corporate road trips, not in bunkers or ivory towers.

So I’m starting to realise that a lot of architecture theory and method is not always very helpful.

At best the focus of the theory and method work can only be one part of a much wider picture, and it needs to be hidden from that main piece of the action – the business-IT conversations. We need new techniques, technologies and new skills to drive the conversations. We need tools and approaches that promote lightweight, collaborative and iterative work – tools and approaches which we can use to share ideas and edge towards agreements as we make those road trips.

There are lots of tools and approaches on the market that help people “do things right” in bunkers or ivory towers. But let’s not forget that there’s something that’s at least as important as “doing things right”, and that’s “doing the right thing”. Figuring out *that* part of the equation is where road trips come in. Where are the tools?

I really hesitate to use the terms “Web 2.0″ or “Enterprise 2.0″, but what’s needed is an approach which builds off the kinds of capabilities you’ll be familiar with if you’re a student of those two-dot-oh-isms. Hosted platforms with universal remote access; and collaborative editing and sharing of information.

Embarcadero is planning on supporting this kind of scenario in future releases of its EA/Studio modelling tools, and Lombardi is already testing the market, from a process architecture perspective, with Blueprint.