Element8 Software is a technology startup that offers a software platform called xpoint which helps customers deliver business change projects and programmes.

This On the Radar briefing note follows a simple “ten questions” format, which we designed to provide a concise but thorough overview of a company and its products and services. We use this format to focus on the capability and suitability of small, specialist vendors – to help you build the best possible vendor shortlists when looking to make new technology investments.

This report is available to paying advisory service subscribers, or can be purchased separately (see the report’s library page for more information).

You can find the report here in our library.

NOTE: this post originally appeared as an article I wrote for CIO UK. You can find the original here.

For as long as the discipline of Enterprise Architecture has been around, it’s been a slippery beast. Some organisations have embraced the practice and concepts, and have become ardent evangelists of its power to improve the aggregate return they get from IT investments over the long haul; but many others just prod the idea with a stick as if it’s a hairball that a cat has just thrown up.

It’s a big problem. The large volumes of discussion and debate ongoing on blogs and discussion groups, and at conferences, suggests that a great many organisations are still unclear about how to define it or draw a boundary around it. There are at least two dimensions of uncertainty which I’ll attempt to summarise here (and as you’ll see in a minute, two dimensions of uncertainty is quite enough to be going on with).

The first way in which people seem to struggle to agree regards the ‘what’ of Enterprise Architecture practice – which boils down to what people mean when they say ‘enterprise’. For some, ‘enterprise’ means “looking at everything in an organisation end-to-end, from strategy to execution, bridging business and IT concerns” (or in other words, pretty much everything is in scope – though perhaps not to a high level of detail). For others, ‘enterprise’ means “looking at IT concerns end-to-end” (and therefore excluding relationships to business concerns).

The second way in which people seem to struggle to agree regards the ‘how’ of Enterprise Architecture practice – which boils down to what people mean when they say ‘architecture’. Specifically, it’s about what people believe is the most important part of the practice. For some, it’s all about the tangible deliverables – the set of models that get created. For others, it’s not about the end result in isolation, but it’s at least as much about the way that those models are created in the first place. One group tends to lean towards private acts of creation and refinement: this is Enterprise Architecture as an exclusive, elevated practice, carried out by specialised practitioners, mostly in private. The other group tends to lean towards collaborative, open acts of creation and refinement: this is Enterprise Architecture as a conversation.

For many of the 15 years that I’ve been an IT industry analyst and consultant, I’ve been talking to Enterprise Architects and trying to find out what seems to work and what doesn’t work. I’ve come to the conclusion that there’s one stand-out type of approach that seems to have the best outcomes: the one that’s based on the “business and IT, strategy-to-execution” interpretation of ‘enterprise’, and that’s also based on the “open and collaborative” interpretation of ‘architecture’.

Why? Not least because – unlike when Enterprise Architecture as a concept and as a discipline first became widely considered – the biggest risks in successful business exploitation of IT aren’t, by-and-large, risks associated with the creation of large, monolithic, isolated systems. They’re risks associated with successful business understanding and use of a whole constellation of inter-related systems – most of which probably won’t be built by your people, and some of which might be ‘rented’ without you knowing (until after the fact).

Just focusing on the technology pieces of the puzzle sets you up to be blind-sided by some of the most important risks of all – risks to do with successful deployment, acceptance and adoption. And just focusing on the outputs of architecture work (the models), rather than focusing on understanding and actively engaging with the needs, concerns, priorities and fears of the people who are the real influencers of success in order to create the models, exposes you to the very same risks, but from a different angle.

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. They’re what practicing enterprise architects like Todd Biske and Leo de Sousa call “activists, not archivists”.

The problem we collectively face, as far as I can tell, is that the majority of the current literature, guidance and training related to Enterprise Architecture is not focused on this kind of broad-based, open, collaborative, activist approach to the practice. The organisations forging ahead are doing so largely under their own steam.
Perhaps, though, there are efforts out there to build up a body of material and understanding that supports ‘activist’ EA practice. If you know of anything, please pass it on!

Earlier this week I spoke at IRM’s BPM Conference Europe 2010 in London (along with many others, including Sandy Kemsley). This is a conference heavy on real-world implementation stories and comparatively lighter on industry trends and vision, and for that reason it’s always really interesting to explore. As usual, Sandy has already written up some good notes from some of the sessions; here I wanted to draw out a couple of comments that struck me as I dipped in and out.

The venerable (in a nice way) Roger Burlton chaired the conference and gave a  keynote session detailing a “Process Manifesto”. He proposed 8 principles of process management, covering everything from process architecture to governance. There were loads of great insights here, but two of the nuggets that particularly chimed with me were

Process models are interesting, but you only get real value from them when they’re connected with other organisational capabilities – systems, people, rules and so on

and

A diagram is not a model, but a way of viewing some of the model information from the point of view of an interested party.

Despite some timing issues and a failing laptop, this was pretty compelling stuff, and I think what he’s doing is a really worthwhile contribution to BPM. As he said in his session, most of the time when BPM projects fall short it’s because of a misunderstanding of the basics, not because of the shortcomings of a particular piece of technology. I know Roger’s business partner Paul Harmon is one of the contributors to the fledgling Process Knowledge BOK project, and I hope some of this finds its way in there.

One of the sessions immediately following Roger’s keynote was given by Phil Short, Mars Canada’s Director of IT – on “Evolving Process Thinking in the Enterprise”. Short detailed his journey introducing process thinking into Mars Canada – from an initial small project to eventually using a process management approach to shape an implementation of an ERP system. Interestingly, Mars Canada found a situation where one of its chief competitors, and one of its customers, had both suffered high-profile failures in their own attempts at ERP implementation. Short successfully used a process-first approach to set the scope and focus of the ERP implementation and drive requirements, and the result was a comparatively pain-free implementation.

Short made two comments in his presentation that particularly struck me:

“Investing in a BPM Suite should never be step 1 – changing people’s thinking has to come first”

and

“Business processes exist in your organisation, regardless of whether you choose to model them or not”.

I found it intruiging that Short has an engineering background, and it was this that got him interested in the potential of process thinking – the desire to improve the way things work. But along his journey, one of his main discoveries was understanding the importance of ‘good enough’ or (he referred to the Japanese concept of ‘toriaezu‘) to getting his organisation to keep moving and making change stick – this is definitely not the kind of approach that engineers are taught in college.

And that disparity was something I saw echoed around other sessions in the conference and in conversations with those attendees who were already succeeding with BPM. Right now, success quite often depends on driven individuals who feel compelled to transcend their technical backgrounds and learn unfamiliar skills and languages.

This might be a problem. Despite the lip-service that many companies seem to pay to ‘engaging with business’, ‘agile working’ and so on, the vast majority of IT organisations remain most at ease when surrounded by the comfort of engineering certainties. Most IT decision-makers come from engineering backgrounds, still. Increasingly, though, as the pace of business change increases and technology platforms bundle more and more high-level capabilities, the most crucial practices for IT organisations to get right themselves (rather than engaging outsourcers or professional services firms to do for them) are probably better classed as ‘art’ or ‘craft’ than ‘engineering’ – and please note that this doesn’t make them less important.

As the familiar rhetoric of IT-business engagement and alignment starts to become more a reality, though, where are organisations going to get the right kind of practitioners from? Universities in China and India are turning out hundreds of thousands of skilled developers and administrators, which is great – but the vast majority of those people, at least in the short term, are going to fuel the engines of the outsourcers. Who’s going to build the bridges that take IT right into the heart of our businesses? One thing’s for sure: people with the right blend of business, people and technology management skills are likely to be in ever shorter supply.

Of course this is hardly a new question – but it was fascinating to see it echoed through practical, real-world BPM stories.

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.

After an extended hiatus, we’re relaunching our podcasting efforts with a planned series of discussions focusing on the challenges and issues associated with software delivery processes and competence in enterprises. We’ve called this podcast series "Software Delivery InFocus", and it’s hosted by Bola Rotibi, MWD’s Principal Analyst for Software Delivery. Each podcast in the series will feature Bola and one or two guest commentators.

In this 33’06″ podcast episode Bola discusses a series of questions focused on the issue of making the right technology choices. Her guests are Alan Zeichick (Editorial Director at SD Times) and Clive Howard (Founding Partner of Howard/Baines, a web development consultancy).

In an environment where software is everywhere and increasingly business critical, but where new technologies and approaches appear on the horizon at an alarming rate – when organisations look to carry out projects, are the right technology choices being made, and if not, why not? And who’s to blame? What can organisations do to help them make better technology choices?

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).