Archive for the ‘sustainability’ Category

Rethinking IT projects? Think service, not product, focus

Thursday, September 27th, 2007

I’ve read a number of articles and thought pieces recently that explore the problems with approaches to IT delivery that focus too much on projects as the organising concept – particularly when it comes to SOA adoption. The shortcomings of an overly project-focused approach are something I can agree with wholeheartedly. The research we conducted for The Technology Garden (Wiley, 2007) convinced me that driving IT delivery using a project-focused organising principle is one of the worst things you can do if you want to try and increase the business value delivered from IT investments.

But if projects are passé, what should they be replaced with? Most of the commentary I’ve seen suggests that a better approach is to think as if you’re developing commercial software products. The excellent Todd Biske has one such piece here.

You have to be think carefully before diving deeply into a product management mentality, though. The trouble is that taking too literal a view of IT delivery through the lens of product management can prevent you from reflecting reality the way that “customers” (regular business people in your organisation, and quite possibly those external customers that ultimately pay all the salaries) see it.

Why? Because software products have no business value, no matter how well-managed the processes to create them were. Business value only comes when you implement a software product and get business results. A shrink-wrapped DVD by itself doesn’t get you any results, only a coaster for your coffee cup. Electronic software delivery doesn’t even get you a coaster – it just fills up your hard disks with useless ones and zeroes.

You have to wrap all kinds of IT services – install and config, integration, customisation, training, administration, user support and so on – to turn a product into something that delivers real business value to real business people. The interface that regular business people have with IT isn’t with products, it’s with IT services. Even Microsoft, the ultimate software shrink-wrapper, has realised that enterprise customers don’t buy products, they buy outcomes (see this old post for info).

That’s why the only way to deliver sustainable improvements in business value delivery is recognising that for the customers of IT organisations, “service is king”, and starting to organise IT delivery around that. The first obstacle to overcome is to find ways of bridging the incredibly harmful divide that so often separates software development teams from IT operations teams.

If you take too much of a product management centric view, the danger is that you focus all your energy creating the right kind of development and deployment capabilities, without thinking of the broader service experience that customers need and expect over the lifecycle of a long-term commitment. IT operations is where the rubber meets the road, and where customer expectations are met or dashed. Too simplistic a focus on product-style management for IT delivery perpetuates the development-operations divide and squanders a great opportunity.

Posted in governance, inside-out IT, sustainability | No Comments »

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.

Posted in EA, SaaS, collaboration, discovery, sustainability | 1 Comment »

Real-world Enterprise Architecture part I: journey vs destination

Tuesday, May 15th, 2007

I was talking to Donna Burbank, Director of Enterprise Modelling and Architecture Solutions at Embarcadero a few days ago – she was briefing me about the company’s new EA/Studio product. We digressed a fair bit along the way, particularly sharing notes regarding our experiences of how Enterprise Architecture (EA) *actually* works in the real world. A key point we discussed was the importance of focusing on EA as a journey, rather than as a destination.

It’s all too easy to focus on the technical nature of EA outputs – which bits of the Zachman Framework should we complete? Should we mandate that all our models use UML? … and so on. Now don’t get me wrong, it’s important to get a handle on the scope of your efforts, and try and create some consistency in what gets done – but these things are means to an end, not the end in itself.

Where I see organisations spending a lot of time worrying about the format and scope of EA outputs and artefacts, often, perversely, it comes about because there’s a lack of organisational ambition regarding the role and contribution of EA as a practice. The hole left by a lack of ambition here is often filled by huge technical ambition – “let’s model the world”. We all know what happens if you follow that road too far.

For EA practice to have a valuable contribution, it has to be prepared to prioritise conversations with business people (and less so with other IT people) over conversations with other architects. Although that’s not within the comfort zone of every architect, it’s critical. Real architecture has to involve real stakeholder engagement – otherwise architecture is just design with a corner office.

Why is it so important to prioritise “external” conversations over noodling? Because more and more, business agendas dictate integration, harmonisation/rationalisation and collaboration efforts which have unprecedented scopes. Business teams and IT teams have to work together like never before to make these initiatives succeed, and a key plank is to create a competency that can understand and drive the kind of global (as opposed to local) IT optimisations that will enable businesses to drive their agendas forward in the 21st Century.

In summary: in the context of 21st Century business, the critical EA competency is the ability to drive shared language and multiparty understanding – and *conversations*.

Posted in EA, collaboration, sustainability | 3 Comments »

Sustainable SOA and "closed loop" thinking

Friday, January 12th, 2007

Todd Biske of Momentum has a great blog on SOA and EA, and one of his recent posts chimed particularly with something we’ve been talking about for quite a while now – sustainability. This is a theme that NeilM and I and Jon (and also Dale, our partner at Freeform Dynamics and book co-author) – have been developing throughout 2006 for our book on IT-business alignment.

The idea of sustainability isn’t really rocket science but it’s a vital touchpoint in the process of strategic IT thinking. What it means is that it’s not enough to think about technology in the context of solving a problem or addressing a need that you have today. To deliver sustainable value from IT you have to think about how technology will continue to address your needs going forward. Arguably this was a key challenge that contributed to so much disillusionment surrounding the Enterprise Application Integration (EAI) boom in the late 1990s and early 00s: EAI technology was great at fixing tactical and existing problems (how can we synchronise key customer data across these x systems? etc) but because of its sometimes esoteric (and certainly non developer friendly) nature a lot of the technology couldn’t really support a strategic shift around how *new* capabilities should be developed to make integratability a “baked in” feature. A better balanced forward-looking approach to integratability (not just integration)is of course one of the things that makes SOA so interesting.

Todd’s post is talking about how IT so often looks at things from the point of view of a set of discrete and disconnected events – and one particular piece grabbed my attention in the context of SOA:

“IT produces solutions, and then forgets about them unless a user complains or some alarm goes off. If an organization takes on SOA, but still operates with this mentality, the only thing that has changed is that they are producing services instead of applications.”

It’s more fundamental than that though.

A focus on service delivery (which for us is what SOA is really about) is a focus that is predicated on closed-loop thinking. A service is something that is experienced over a period of time by a consumer, not just a capability that you’ve built. I’d say, then, that if you work with the mentality Todd talks about then you’re not even producing services – you’re producing itty-bitty applications. The concept of “service” – a consistent experience provided to a consumer – is what underpins that evolved, closed-loop view. Without it you’re not doing SOA.

This means that SOA is only possible when you consider the whole lifecycle of services over time as they are created, changed and (yes) retired. And that’s where sustainability comes in. If you’re not thinking ahead to how you will deliver that consistent experience you’re not thinking in a sustainable way. You’re thinking about point projects, point applications, point functions, and that’s how we got into the mess we’re in.

Importantly this shift in mindset to think about how to deliver sustainable business value from IT takes us well beyond the world of technology product procurement. It’s all about process, practice, organisation and culture and nothing to do with whether you bought the blue or the red ESB.

Without this understanding at the top of your mind as you embark on SOA or indeed any other IT initiative (unless it’s responding to a *very* opportunistic and short-lived requirement) entropy will always win. If you’re always looking backwards then the reality of business requirements and the reality of IT capability will quickly diverge in unwelcome ways.

Posted in SOA, book, sustainability | 2 Comments »