Over the years I’ve been part of many conversations that revolve around how ‘BPM’ is not the same as ‘BPMN’ (in the context of process automation). The point consistently made is that even when you’re tackling work improvement scenarios that are suitable for modelling with BPMN (i.e. scenarios where the structure of work can be largely designed upfront), there are lots and lots of other important considerations you need to address before you can create a deployable process application that will automate all or part of a business process and help people work more effectively.

At the risk of repeating what you may already know, the design elements commonly needed within a process application but not addressed at all by BPMN include:

• Logic associated with providing integration links to back-end systems and data sources
• Task form and other user interface definitions
• Logic to define task management (task assignment, delegation, escalation)
• Specifics of calculations and other important rules and algorithms that are separate from the conditions you specify in BPMN gateways
• Definitions of performance monitoring models, KPIs, reports and dashboards.

This isn’t an exhaustive list, but even the items above add up to a pretty comprehensive set of things you need to deal with to get to a deployable process application.

Most of what I’ve heard in discussion around this point focuses primarily on implications for the time to deliver projects: in other words, don’t think that once you’ve created a BPM and model your even close to finished application for real-world deployment. However there is a bigger issue at stake here, which is: exactly what kind of provision a given BPM technology platform makes for the specification of those items in the list above – and specifically, to what degree you’re encouraged to design and (when necessary) code these items so that each kind of concern is kept separate from all the others.

The quality of this “separation of concerns” in design might not make a huge amount of difference when you first start in implementation, but it can become incredibly important over time. And support for it turns out to be one of the most important (to my mind) differentiating points between BPM technology platforms.

Of course, because almost all BPM technology platforms centre implementation work around a graphical process model there is always likely to be a clean separation between definition of process and all of the other important design elements I’ve listed. But whereas some platforms provide a rich, well structured asset repository and clean design tools that implement the principle of “a place for everything, and everything in its place”, other platforms really provide quite weak facilities of this kind. With this latter group of platforms, it’s still theoretically possible to create process applications that are relatively easy to maintain; but designers and developers are going to be pushing against the tools available rather than working with them.

Easy process application maintainability is of course one of the key parts of the BPM technology value proposition! Without the right tools, the cost and risk of managing and improving business processes in an operational environment just aren’t as easy to control as they should be.

It’s interesting to me that there’s very little attention paid to this issue in BPM technology vendors’ marketing literature; instead, vendors prefer to focus on sexy things like support for mobile devices, integration with social collaboration capabilities, cloud-based deployments and so on. When we examine BPM technology offerings in our detailed assessment reports, though, the architecture and philosophy of the of the toolset and platform in relation to application maintainability is one of the main things we dig into.

If you’re interested in finding out more about our assessment approach, you can get access to our assessment guide reports for free here and here. You can also see overviews of our most recent versions of our in-depth reports here.

What’s your view – how important do you think the principle of “a place for everything, and everything in its place” is in BPM implementation?

Of all the conversations and discussions held at Salesforce’s customer day in Egham this week, one in particular struck a chord with me. Cloudapps, an ISV and partner of Salesforce, spoke briefly about the challenges of capturing, storing and analysing Big Data, in particular telecom mast sensor data, on the Force.com platform.  Although there wasn’t time to drill into detail about Force.com’s Big Data support – it got me thinking generally about the wider options for exploiting vast amounts of digital data within the cloud.

As a lot of the Big Data that people are interested in analysing – such as sensor data, social media data or weblog file data – already lives in the cloud, it makes sense to also use it as a platform for hosting and analysing this data too. Rather than the often more inefficient method of pushing it to an on-premise enterprise data warehouse for example.  At the same time one set of technologies in particular – Hadoop – is also becoming synonymous as a lower cost approach for storing and processing these large-scale datasets in the cloud.

Given the proliferation of digital data and the desire to harness it for better business effect, it’s not surprising that Big Data and the Cloud are on a natural collision course. With its elastic processing capacity, lower cost and lower risk approach, the cloud provides a powerful platform for storing, processing and crunching this data – whether using Hadoop or not. Similarly the emergence of cloud based offerings that mix analytics and Big Data in the public cloud are also helping to circumnavigate some of the skills shortage issues relating to advanced analytics techniques and Big Data technologies.

However that’s not to say that the cloud should be seen as the answer to all your Big Data needs. On-premise data warehouses that employ technologies such as MPP analytic databases, in-memory computing, columnar databases or packaged appliances provide equally valid alternatives. In fact in many cases these Big Data approaches should be seen as complementary to each other, as each brings different strengths to the table.  The challenge however for organisations that haven’t put their eggs in any one particular Big Data basket, is how to mesh these approaches together and equally how to do this across the on-premise and cloud divide.  The benefits of  integrating data to support a more consolidated, complete and accurate view of your business are well known after all.

As we outlined in our recent report on Analytics in the Cloud, a hybrid cloud is one plausible approach to using both public clouds and private or on-premise IT to deliver a more integrated Big Data analytic system. This can provide a more pragmatic and blended approach for balancing the strengths and pitfalls of both cloud and on-premise implementations but it also comes with its own set of challenges. Apart from managing the environment there are also factors relating to the immaturity of certain Big Data technologies, lack of best practice and interoperability across platforms.  For example, of those looking at Big Data Hadoop projects a significant proportion are still in experimentation (rather than production) mode, testing out the concepts, design and technology -although we do expect this to change over the next 12-18 months as the market evolves.

Given the great many opportunities for leveraging Big Data in the cloud, it’s surprising to see that aside from its social media monitoring platform Radian6, Salesforce doesn’t have a stronger message or story about its Big Data hosting capabilities. It appears from the conversations at the customer event the company still has something to prove when it comes to supporting and helping ISVs and developers work with Big Data especially on the Force.com platform. But as a company used to pioneering cloud based offerings we don’t expect this to be the situation for very long.

Ever since I read Geoffrey Moore’s Future of IT paper introducing the concept of systems of engagement (published last year), I’ve had a slight uneasiness about the ongoing discourse. For a long time it was nothing I could put my finger on, but in some recent conversations about how technology can improve business agility, I finally realised what had been niggling me. In this blog I’m going to explain what I think is missing.

Systems of engagement vs. systems of record: a summary

If you’re not familiar with the narrative around systems of engagement, in brief it goes like this:

‘Systems of record’ – systems which manage core business information types and provide facilities for processing the information in place (think financial management, logistics, billing, CRM, and so on) – are no longer a source of competitive differentiation: they are a necessary condition of doing business, but because their capabilities are so commonplace their presence is merely table stakes. Increasingly, globalisation is forcing companies to focus more strongly on their core capabilities, and work more broadly and deeply with other companies and agencies to deliver value to customers. This means that communication and collaboration are more important than ever before. And this is where the concept of ‘systems of engagement’ comes in: the idea is that in this more distributed and  collaborative business environment, the ability to adopt the advanced communication and collaboration tools that people are familiar with in their home lives will become the new focus for competitive differentiation through technology in business environments.

Something’s missing

Before I go any further, I should be clear: I have nothing at all against the assertion that the business value of technology is shifting away from how well information is managed in place (by ‘systems of record’), towards how well information is communicated – between systems, people and organisations. I’m also absolutely in agreement with the assertion that social collaboration technologies have some really exciting roles to play in driving business improvement.

But based on my research and industry experience I think there’s something really important that’s omitted from the narrative that I’ve seen: and that’s to do with how the changing nature of value chains, combined with changing customer expectations, regulatory pressures and so on, is forcing a new kind of appraisal of how work needs to be supported by technology. Specifically, the key part of the ‘how’ here that we need to concentrate on is to do with the co-ordination of work.

It’s no longer enough (and in fact it hasn’t been enough for some years) to give people standalone tools (including those ‘systems of record’) and expect them to just get on with it and produce great work. The pressures highlighted above mean that to deliver great business performance, optimising work at the level of an individual’s contribution is a long way from enough; businesses need to be able to optimise how work gets done at a much larger scale.

However I’m not talking here about changes like the outcomes of the BPR programmes of the 1980s and 1990s – rigid process ‘improvements’ that ushered in massive changes to administration and operations through top-down diktat and only offered crude transactional ‘solutions’ that attempted to control information, the focus of work and change in a highly centralised fashion.

Instead we need to invest in systems and cultures that allow technology to be woven more closely into a broad range of types of work, where that work naturally happens, to help actively coordinate how work gets done between people, departments, and companies – and also, crucially, to gather intelligence and metrics that organisations can use to improve coordination and drive better business results.

Introducing ‘systems of co-ordination‘

Of course, anyone who’s been following my ramblings for a while will know that what I’m talking about is the application of Business Process Management (BPM) technologies and techniques*. These technologies and techniques, when used properly, create systems of co-ordination that enable businesses to systematically manage and improve their knowledge about ‘what works in work’ for them, and apply that knowledge directly in an operational context across people, departments and even corporate boundaries.

In his Future of IT analysis, Moore mentions co-ordination as a responsibility of systems engagement in passing, but I think that a mention in passing just isn’t enough. Given the length of time I’ve spent talking to companies that have implemented process improvement programmes and projects I might have too much bias colouring my view, but I think the value of these systems of co-ordination is just as crucial an element of business-technology strategy and investment as are systems of record and systems of engagement.

In an enterprise people don’t collaborate just for the fun of it – people collaborate to “get work done”. But how does knowledge about the best way to do work, and get the best results from work, get encoded, applied, managed and improved? Neither systems of record nor systems of engagement (at least, in terms of how the latter are painted in the discourse I’ve seen so far) have anything to offer in this respect.

Greasing the wheels between systems of engagement and systems of record

To my mind, then, the narrative needs to be refined. Businesses need to start to figure about the roles that systems of engagement should play in helping them maximise the effectiveness of business interactions, and consider how systems of engagement should play alongside systems of record: but crucially, the interface between systems of engagement and systems of record should not be a direct one. Between these two system layers – the grease between the wheels – should be systems of co-ordination.

What do you think? Am I the only one who thinks we need to look at this more closely? I’d love to hear your comments.

*There’s been a lot of debate about the limits of the applicability of some BPM technology in the face of different types of work – structured vs. unstructured, planned vs. unplanned, goal-oriented, collaborative, and so on – but I’m explicitly avoiding those details here and talking at a general level for the purposes of this piece.

At a recent analyst day in Hursley Labs, IBM outlined its current and future plans for Big Data. The company clearly sees a huge business opportunity in this market by helping customers extract value from new, complex and voluminous data sources to uncover deeper and richer insights that have previously not been possible before. However, embarking on a Big Data journey is a far from straightforward proposition not least because it requires organisations to consider new technology and architectural approaches to information management and analytics. While IBM’s extensive research expertise is being brought to bear successfully on the Big Data challenge through Infosphere BigInsights and InfoSphere Streams, the early stage of market development means the move towards an integrated technology stack and common developer tooling environment is still a work in progress. One that IBM clearly sees as its next Big Data challenge.

Leveraging Big Data requires a different information management approach

Big Data is one of the hottest trends in IT industry circles. Although overused as a buzzword it is generally characterised by the large, complex and rapidly growing volume of information that often remains untapped by existing analytical applications and data warehousing systems. Examples of this data include web traffic, high volume sensor data and social media information from web sites such as Twitter and Facebook. Managing and exploiting this data however provides significant added value to organisations by enabling them to discover and act on new and deeper insights.

IBM is no stranger to managing data having fleshed out an information management portfolio – mainly through acquisition – for data warehousing, ETL, data quality, data federation and master data management. However, Big Data is posing a different set of information management challenges, as its volume, variety and complexity continue to push the performance and scalability boundaries of current data warehousing and BI architectures.

As a result, IBM has tailored two product offerings to address this Big Data challenge: Infosphere BigInsights and Infosphere Streams. The former is used to ingest, process and analyse vast volumes of data for solving large scale business problems such as anti money laundering, customer sentiment analysis and weather impact analysis. The platform is based on open source Apache Hadoop, a distributed computing framework that supports parallel processing of large-scale unstructured data. In addition it is augmented with advanced text analytic capabilities and tools for provisioning, security, workflow and fault tolerance – designed to make BigInsights more of an enterprise-ready consideration. Infosphere Streams, on the other hand, provides a development platform for building and deploying applications using the Stream Processing Language (SPL). These applications enable the continual analysis of massive volumes of streaming data at ultra low latency levels such as those used for traffic management, fraud prevention or financial trading systems.

No one technology or platform can solve the Big Data challenge

Organisations leveraging next-generation technology and languages such as Hadoop and SPL are effectively managing and exploiting Big Data today. However their application also demonstrates that – at least in IBM’s view – Big Data challenges cannot be solved by a single platform or engine but instead need to employ a variety of technologies, components and architectures. While IBM’s vast Services organisation can help customers navigate this maze, the longer term aim for the company is to bring more commonality and integration across its existing Big Data portfolio. BigInsights and Streams have grown out of separate development projects and use different engines, UIs and tooling for Big Data applications. By bringing these together on a common platform will help reduce the cost of ownership and streamline the development process, but can simultaneously broaden the opportunities for mining all forms of Big Data.

Ease of use is also another factor governing uptake and so support for a visual development paradigm is one area IBM is working on to make its Big Data platforms more attractive to a broader base of developers.

At the same time Big Data needs to be framed in the context of an enterprise information architecture – one that not only provides a blueprint for bringing all this “stuff” together, but facilitates integration with other enterprise data stores and analytic tools to stop Big Data from becoming just “another silo”. While the company is building hooks to help bridge gaps across Big Data and existing information management environments – for example around Netezza and DB2 – it still has a way to go. What’s needed in the longer term is a deeper and more consistent approach that enables organisations to integrate their Big Data and traditional data warehouse environments in a non-disruptive way and also allows them to analyse it (whether Big or otherwise) using standard BI and analytic tools such as Cognos and SPSS.

These characteristics and some early use cases  point to an early phase of adoption in the market. Of those looking at Big Data most are in experimentation mode, testing out the concepts, design and technology. For the majority many are prepared to adopt a wait-and-see approach.

Over the past couple of years we’ve all heard more and more talk about the potential for IT to transform business and drive innovation and profitability – and hand-in-hand with this, the potential for CIOs to be seen as in charge of IT groups that are true ‘strategic business enablers’ rather than simple cost centres. This is very sensible and a natural consequence of the changing role that IT has come to play in business over the past 20 years, as it’s moved out from the back office as ‘Data Processing’ to become a ubiquitous enabler for people to share information, buy products, and interact with each other.

So the idea that the effective application of IT can drive real business transformation is not what I have a problem with – I’m actually a massive proponent of this kind of vision, and indeed exploring the ins and outs of this is what MWD is essentially about.

No, the problem I have is when I see ‘experts’ positioning these things as exclusive alternatives:

• As a CIO you have to be either running an IT function that is a strategic business enabler *or* a cost centre
• You have to drive collaborative, consultative dialogues with business leaders *or* you have to be a transactional ‘order taker’
• You have to be focused on driving ‘innovation’ *or* minimising costs.

I’ve come across a number of commentators – including the normally pretty sensible Nick Carr, as well as a Research Director from one of the very largest IT industry analyst firms – argue this very black-and-white view.

The problem is, it’s a massive over-simplification of the real world. The truth is that (as many people tire of me saying over and over again) in this case as in so many others, we live in a world of ‘and’, not a world of ‘or’. The truth is most obvious in larger companies, but it’s everywhere: IT needs to play multiple roles in multiple contexts if it’s really going to serve the needs of a business in the most effective way.

If you take a capability-based view of business and explore how IT resources should support different business capabilities in different ways, it quickly becomes apparent that in some areas, even the most forward-thinking CIO with strong peer relationships at the highest level should be looking to structure some parts of his operation to act as transactional order takers, delivering ‘good enough’ service at minimal cost (email service might be a good example for many). On the other hand IT services and capabilities (examples might include services supporting sales and marketing optimisation, customer interfaces, product development) should be optimised for flexibility and creative exploration; here, IT governance policies might be best focused largely on the ‘edges’ of these areas to make sure that creative use of IT is expressed within clear boundaries. Where services and capabilities should be optimised for cost – this is where governance should focus on centralisation and standardisation as far as possible.

As the above suggests, a more nuanced view of the role that IT should play has significant impacts on the terms of reference and charters for IT governance and architecture functions. I find it alarming how many architecture teams, for example, see their role largely as one of standards-enforcement: things are starting to change, but change is slower than it needs to be IMO.

I suspect that a great many of my “Calling BS on…” series of posts are going to boil down to two possible arguments: one against simplistic either-or thinking, and the other against ‘XYZ is dead’ posturing. Let’s see, though…

As always, I’d love to get your views in comments. Come on, rant with me!

Internet/marketing guru (there’s not many other words that will do) Seth Godin wrote a post on an idea that’s dear to my heart a few days ago: Hire an architect.

For me, the killer lines are

I’m talking about intentionally building a structure and a strategy and a position, not focusing your energy on the mechanics, because mechanics alone are insufficient

and, particularly

My friend Jerry calls these people [architects] corporate chiropractors. They don’t do surgery, they realign and recognize what’s out of place.

This piece is really important because it recognises the value of IT architects not as “standards police”, or people who worry about infrastructure while everyone else worries about bells and whistles; but as people who try to work against the force of entropy that constantly nudges IT capabilities and business requirements out of alignment.

The most successful IT architects in the long term are influencers, cajolers, nudgers, tweakers. They’re not the people driving macho balls-out megabucks IT transformation programmes that likely end up being associated with words like “baby” and “bathwater”. They’re people who can work co-operatively to discover and elaborate a shared vision for how IT can contribute business value over time, and then work co-operatively to make continual course corrections – taking into account changing business priorities as well as changing technology capabilities, models and skills availability.

Back in 2007 I was lucky enough to co-author a book (along with Dale Vile, Jon Collins and my MWD co-founder Neil Macehiter) called The Technology Garden, which laid out a manifesto and roadmap for improving the ability of IT investments to deliver value to businesses. It was based on quite a number of case study conversations, and its central theme was that IT estates are much more like gardens than like tower blocks: continually changing, growing, and subject to the forces of nature and the seasons. Every effective gardener knows you have to work with nature, not against it, for the most sustainable results.

Let’s hope Seth’s great post switches yet more people on to these ideas.

In the past couple of days I’ve read a couple of articles (“IT can’t be a service provider and a partner too” and “Run IT as a business – why that’s a train wreck waiting to happen“) that riff on the same theme: that the exhortation to “run IT as a business” leads you down a road to organisational exile.

Put briefly, the thinking seems to be: if you set an IT organisation up to run as a business, you create a supplier-customer relationship with other parts of your wider organisation – and this relegates you to being a simple order taker. You’ll have to implement the requirements you’re given, and often these will be out of whack with what the organisation will really need and will raise IT costs over the long term, making an internal IT operation even less attractive and making you more likely to be outsourced.

In my experience this analysis is plain wrong, and comes from simplistic thinking about what the phrase “run X as a business” might mean. Being more business-focused has multiple facets to it, and blindly interpreting the idea leads you to daft, simplistic conclusions. Applying similar thinking to cooking would lead to the advice “don’t use sharp knives; if you do that it’ll only be a matter of time before you chop a hand off”.

To be clear: my experience and advice diverges with these other opinions not because I disagree about the risks of IT becoming a “simple order-taker”; but rather because I disagree that running IT as a business means you have to become a simple order-taker and everything else is excluded. There’s much more to it than that. The key is to see the relationship between IT and other areas of a business as having three key layers.

When I look at IT leaders who have really become strategic players at board level (and I’ve been talking to them ever since my work on The Technology Garden), it’s not the case that their organisations have stopped becoming service-focused and focus wholly on hanging out with senior business managers. If anything their organisations are more service-focused than the norm.

In the best-performing organisations, the “run IT as a business” idea is primarily about an inward-looking perspective. It’s about putting repeatable processes in place, creating a service culture, figuring out the actual costs of delivering IT services through IT processes, and looking for ways to increase IT process efficiency and effectiveness.

In high-performing IT organisations, when it comes to the outward-looking perspective (the relationship between the IT organisation and other parts of a business) the relationship has at least three layers:

1. As a foundation, IT teams have to deliver reliable operational services in line with clear promises and in the context of defined cost expectations and budgets.
2. When it comes to using IT to enable business in new ways the relationship works at a higher level, using different teams, reporting structures, skills and incentives within multidisciplinary joint IT-business teams.
3. The top layer acts to mitigate the risks of individual business units driving change that is counterproductive to the organisation as a whole, typically through some kind of IT governance structure that helps to ensure that significant IT investments are considered in their proper strategic context and that the costs and risks are properly understood by all.

That’s three layers: IT operation/service delivery; IT-business engagement; and governance/strategy. You can be focused on service provision and also on partnering. As long as you understand the bigger picture.

While I was at IASA’s ITARC NYC the other week, Matt Deacon (day job: developer/architect evangelist for Microsoft in the UK; evening job: UK Chapter President of IASA) interviewed me about my thoughts on the value of architecture, the role of IASA and also about the talk I gave at the event.

The talk I gave was on a recent survey we completed in association with IASA – focused on architects’ experiences of, and views on, Cloud Computing. In the second half of the interview Matt talks to me about some of the early findings from that survey.

The video interview with Matt and me is about 21 minutes long, and it’s published on Microsoft’s Channel 9. I think the discussion turned out pretty well, though I say so myself… Matt has also published an interview with the SEI’s Len Bass from the same conference btw, and that’s worth a look, definitely.

The full survey findings will be published as part of our new Software Delivery advisory service, which we’ll be launching this month. If you’re an enterprise IT practitioner and you’d like to find out more about the service here’s something for you; if you work for an IT vendor organisation, here’s some information for you.

I’d love to get feedback from you if you have time to sit through the interview… what did you think?

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.

We all know that the general level of industry interest in Cloud Computing is high – but how much is Cloud Computing being actively considered and pursued by “enterprise IT” organisations, as opposed to software-as-a-service startups and professional ISVs moving to the SaaS model?

To help support the launch of our new Software Delivery advisory service – which at launch will feature several advisory reports focused on the potential impact of Cloud Computing – we decided to ask the members of the IASA what they’re thinking and doing about Cloud Computing.

As I’ve mentioned before we have an ongoing research relationship with this not-for-profit global association of IT Architects (which today has around 25,000 members across a variety of industries). As in our summer BPM study, we’ve worked together with IASA to carry out a web-based survey – and although all IASA members have now been invited to take part, I wanted to make sure that you had a chance to take a look and offer your thoughts, too. If you’re in an IT architecture role, or know someone who is, we’d be delighted to have your involvement: you can find the online survey here.

Once the survey is complete, we’ll create an in-depth report drilling into the survey findings and correlating them with findings from our other Cloud Computing research work. Everyone taking part in this survey will be eligible to receive a free copy of the report. We’ll also create an IASA-only webinar, based on the survey results and adding other best-practice insights. All IASA members will be able to access this webinar free of charge.

So – if you’re an IT architect or know someone who is – we’d love to hear from you! And if you’re interested in the IASA webinar we’re creating – it’s easy to become an IASA member…

Lastly – if you’re interested in finding out more about the new Software Delivery service we’re readying for launch, please take a look at the brochures featured on our home page.